See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/346420023

The Security Reference Architecture for Blockchains: Towards a Standardized

Model for Studying Vulnerabilities, Threats, and Defenses

Article  in  IEEE Communications Surveys & Tutorials · October 2020

DOI: 10.1109/COMST.2020.3033665

CITATIONS READS

8 126

6 authors, including:

Ivan Homoliak Sarad Venugopalan

Brno University of Technology Singapore University of Technology and Design
54 PUBLICATIONS   270 CITATIONS    12 PUBLICATIONS   86 CITATIONS   

SEE PROFILE SEE PROFILE

Daniel Reijsbergen Qingze Hum

Singapore University of Technology and Design SUTD
53 PUBLICATIONS   296 CITATIONS    8 PUBLICATIONS   41 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Optimal scheduling View project

blockchain@SUTD View project

All content following this page was uploaded by Ivan Homoliak on 29 November 2020.

The user has requested enhancement of the downloaded file.

 1

The Security Reference Architecture for

Blockchains: Towards a Standardized Model
for Studying Vulnerabilities, Threats, and Defenses
Ivan Homoliak∗† Sarad Venugopalan∗ Daniël Reijsbergen∗
Qingze Hum∗ Richard Schumi∗ Pawel Szalachowski∗
∗ Singapore University of Technology and Design
† Brno University of Technology

Abstract—Blockchains are distributed systems, in which secu- of platform-agnostic standards in blockchain implementation,
rity is a critical factor for their success. However, despite their interoperability, services, and applications, as well as the
increasing popularity and adoption, there is a lack of standard- analysis of its security threats [4], [5]. All of these areas are
ized models that study blockchain-related security threats. To
fill this gap, the main focus of our work is to systematize and challenging, and it might take years until they are standardized
extend the knowledge about the security and privacy aspects of and agreed upon across a diverse spectrum of stakeholders.
blockchains and contribute to the standardization of this domain. In this work, we aim to contribute to the standardization of
We propose the security reference architecture (SRA) for security threat analysis. We believe that it is critical to provide
blockchains, which adopts a stacked model (similar to the blockchain stakeholders (developers, users, standardization
ISO/OSI) describing the nature and hierarchy of various security
and privacy aspects. The SRA contains four layers: (1) the bodies, regulators, etc.) with a comprehensive systematization
network layer, (2) the consensus layer, (3) the replicated state of knowledge about the security and privacy aspects of today’s
machine layer, and (4) the application layer. At each of these blockchain systems.
layers, we identify known security threats, their origin, and In this work, we aim to achieve this goal, with a particular
countermeasures, while we also analyze several cross-layer depen- focus on system design and architectural aspects. We do not
dencies. Next, to enable better reasoning about security aspects of
blockchains by the practitioners, we propose a blockchain-specific limit our work to an enumeration of security issues, but
version of the threat-risk assessment standard ISO/IEC 15408 additionally, discuss the origins of those issues while listing
by embedding the stacked model into this standard. Finally, we possible countermeasures and mitigation techniques together
provide designers of blockchain platforms and applications with a with their potential implications. As our main contribution,
design methodology following the model of SRA and its hierarchy. we propose the security reference architecture (SRA) for
Index Terms—Reference architecture, blockchains, distributed blockchains, which is based on models that demonstrate the
ledgers, security, privacy, vulnerabilities, threats, ISO/IEC 15408. stacked hierarchy of different threat categories (similar to the
ISO/OSI hierarchy [6]) and is inspired by security modeling
performed in the cloud computing [7], [8]. As our next contri-
I. I NTRODUCTION bution, we enrich the threat-risk assessment standard ISO/IEC
The popularity of blockchain systems has rapidly increased 15408 [9] to fit the blockchain infrastructure. We achieve this
in recent years, mainly due to the decentralization of control by embedding the stacked model into this standard.
that they aim to provide. Blockchains are full-stack distributed This paper is based on our previous work outlining the
systems in which multiple layers, (sub)systems, and dynamics security reference architecture [10]. We substantially modify
interact together. Hence, they should leverage a secure and and extend it by the following:
resilient networking architecture, a robust consensus protocol, • We provide a theoretical background related to the
and a safe environment for building higher-level applica- security reference architecture and the environment of
tions. Although most of the deployed blockchains need better blockchains, their types, failure models, consensus pro-
scalability and well-aligned incentives to unleash their full tocols, design goals, and means to achieve these goals.
potential, their security is undoubtedly a critical factor for • For each layer, we model particular attacks or their cate-
their success. As these systems are actively being developed gories through vulnerability/threat/defense graphs, while
and deployed, it is often challenging to understand how secure we provide reasoning about several important relations
they are, or what security implications are introduced by some and causalities in these graphs.
specific components they consist of. Moreover, due to their • We modify and significantly extend the application layer,
complexity and novelty (e.g., built-in protocol incentives), where we propose a novel functionality-oriented catego-
their security assessment and analysis requires a more holistic rization, as opposed to the application-domain-oriented
view than in the case of traditional distributed systems. categorizations presented in related work [11], [12].
Although some standardization efforts have already been • We extend and revise the consensus layer by mining-pool-
undertaken, they are either specific to a particular platform [1] specific attacks, time-spoofing attacks, and we provide a
or still under development [2], [3]. Hence, there is a lack more fine-grained categorization.
 2

75 75
• For each layer, we present an incident table that lists and
61
briefly describes examples of attacks that have occurred 60 59 60

Total #References

Total #References
worldwide: either caused by malicious parties or by 43
46 47
45 45 42
researchers who demonstrated their practical feasibility. 38
29 29
• In the lessons learned, we describe the hierarchy of 30 30 26

security dependencies among particular categories, based 15

17
15
9
on which, we propose a methodology for designers of
blockchain platforms and applications. 0 0

l)

l)
ey

ey
k

us

SM

us

SM
em

em
r

r
ve

ve
rv

rv
wo

wo
ns

ns
R

R
Le

Le
t

t
Su

Su
se

se
ys

ys
et

et
The rest of the paper is organized as follows: We de-

h-

h-
on

on
os

os
N

N
ig

ig
Ec

Ec
C

C
H

H
.(

.(
.(

.(
scribe the scope and methodology of our research as well as

pp

pp
pp

pp
A

A
A

A
quantitative analysis of the included literature in Section II. (a) All references (b) Academic references
In Section III, we summarize the background on blockchain
Figure 1: Blockchain-specific references per category.
systems. Next, in Section IV we introduce the security ref-
erence architecture whose layers are discussed in the follow-
up sections. In detail, Section V deals with the security and 58 25
60 Network
privacy of the network layer, Section VI focuses on the

Total # Academic References

Consensus
20 RSM
consensus layer, Section VII overviews the replicated state App. (Ecosystem)
40 37
machine layer, and Section VIII with Section IX describe 15 App. (High-Level)
29 Survey
applications built on top of the blockchain. In Section X, 23 10
we elaborate on lessons learned and propose a methodology 20
11 12
for designers of blockchain-based solutions. We discuss the 8 5
3
limitations of our work in Section XI and we compare our 0
1 1
0
research to related work in Section XII. Finally, we conclude

11
12
13
14
15
16
17
18
19
20
11
12
13
14
15
16
17
18
19
20

20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
the paper in Section XIII. (a) #References per year (b) #References per year/category
Figure 2: Blockchain-specific academic references over time.
II. M ETHODOLOGY & S COPE
In contrast to conventional survey approaches, such as (e.g., covert mining/crypto-jacking [14]) and issues related to
grounded theory for rigorous literature review [13], we do using blockchain explorers (e.g., spoofing attacks, availability
not sample included research from existing databases queried issues). Examples of vulnerabilities that we assume only
with specific terms. Instead, we study and analyze security- tangentially are semantic bugs and programming errors in
oriented literature for vulnerabilities and threats related to the infrastructure of the blockchains – we assume that core
the blockchain infrastructure. The literature that we select as blockchain infrastructure is implemented correctly, uses secure
the input mainly covers existing blockchain-oriented surveys cryptographic primitives, and provides expected functionality.
as well as various conferences and journals in security and
distributed computing. Moreover, we include other materials A. Quantitative Analysis
published in preprints, whitepapers, products’ documentation,
and forums, which are also related. For a quantitative summary of the literature, we considered
We aim to consolidate the literature, categorize found vul- only the references from the main sections that correspond to
nerabilities and threats according to their origin, and as a particular layers of the proposed stacked model (i.e., Section V
result, we create four main categories (also referred to as to Section IX) and related work (Section XII). We excluded
layers). At the level of particular main categories, we apply references from other sections and the references on the
sub-categorization that is based on the existing knowledge and examples of incidents (Appendix C). Each assumed reference
operation principles specific to such subcategories, especially was labeled with three flags to indicate:
concerning the security implications. If some subcategories • The category to which it belongs. Note that some papers
impose equivalent security implications, we merge them into belong to multiple categories.
a single subcategory. See the road-map of all the categories • Whether it is specifically related to blockchains.
in Figure 4. Our next aim is to indicate and explain the co- • Whether it was written by academics (i.e., such that their
occurrences or relations of multiple threats, either at the same affiliation was listed in the document). Note that the
main category or across more categories. positive value of this flag covers also the papers that have
The scope of our work mainly covers aspects related to the not been peer-reviewed but which appeared on public
blockchain core elements, while we mention common opera- repositories (e.g., arXiv and Cryptology ePrint Archive).
tional security issues (e.g., key management in the blockchain In sum, we collected 276 references, of which 247 were
ecosystem) and countermeasures only tangentially if required. blockchain-specific, 211 were written by academics, and 180
Similarly, we do not pursue threats that emerge outside of the met both criteria. In Figure 1, we show the number of
blockchain infrastructure and outside of the extra infrastructure references in each of the main categories for (a) all papers
required for certain blockchain-based applications. Out-of- and (b) the academic papers. A total of 11 papers were found
scope examples are remote exploitation of arbitrary devices to belong to two categories. We observe that most of the
 3

references are presented at the application layer, which we Consensus Nodes

conjecture that occurred because each application running on • disseminate txs and
blocks
the blockchain might introduce new attack vectors. • read blockchain read
The evolution of the number of references over time is • write to blockchain write
• validate blockchain validate
depicted in Figure 2, where we observe that the number of
academic papers about blockchains and security has increased
read
steadily, although 2018 was the year with the highest number validate
Blockchain
of references selected for the current work.1 Of the four layers ad
*
e*
re lidat … Validating Nodes
discussed in this paper, the network layer has the lowest va
• disseminate txs and
number of blockchain-focused papers. A possible reason for blocks
Lightweight Nodes
it could be that among the remaining layers, the consensus • disseminate own txs • read blockchain

• read blockchain (partially) • validate blockchain

and replicated state machine (RSM) layers are more specific
• validate blockchain (partially)
to blockchains, while the application layer is popular among
practitioners building on top of other layers. Finally, we ob- Figure 3: Involved parties with their interactions and hierarchy.
serve the number of surveys is steadily growing (culminating (2) Validating nodes read the entire blockchain, validate it,
in 2019), which indicates increasing interest in this domain. and disseminate transactions. Unlike consensus nodes,
validating nodes cannot write to the blockchain, and
III. B LOCKCHAINS AT A G LANCE thus they cannot prevent malicious behaviors. On the
The blockchain is a data structure representing an append- other hand, they can detect malicious behavior since they
only distributed ledger that consists of entries (a.k.a., trans- possess copies of the entire blockchain.
actions) aggregated within ordered blocks. The order of the (3) Lightweight nodes (a.k.a., clients or Simplified Payment
blocks is agreed upon by mutually untrusting participants run- Verification (SPV) clients) benefit from most of the
ning a consensus protocol – these participants are also referred blockchain functionalities, but they are equipped only
to as nodes. The blockchain is resistant against modifications with limited information about the blockchain. These
by design since blocks are linked using a cryptographic hash nodes can read only fragments of the blockchain (usually
function, and each new block has to be agreed upon by nodes block headers) and validate only a small number of trans-
running a consensus protocol. actions that concern them, while they rely on consensus
A transaction is an elementary data entry that may contain and validating nodes. Therefore, they can detect only a
arbitrary data, e.g., an order to transfer native cryptocurrency limited set of attacks, pertaining to their own transactions.
(i.e., crypto-tokens), a piece of application code (i.e., smart Additional Involved Parties. Note that besides native types
contract), the execution orders of such application code, etc. of involved parties, many applications using or running on the
Transactions sent to a blockchain are validated by all nodes blockchain introduce their own (centralized) components.
that maintain a replicated state of the blockchain.
Blockchains were initially introduced as a means of cop-
B. Types of Blockchains
ing with the centralization of monetary assets management,
resulting in their most popular application – a decentralized Based on how a new node enters a consensus protocol, we
cryptocurrency with a native crypto-token. Nevertheless, other distinguish the following blockchain types:
blockchain applications have emerged, benefiting from fea- Permissionless blockchains allow anyone to join the consen-
tures other than decentralization, e.g., privacy, energy effi- sus protocol without permission. To prevent Sybil at-
ciency, throughput, etc. For the review of the inherent and tacks, this type of blockchains usually requires consensus
non-inherent features of the blockchains, we refer the reader nodes to establish their identities by running a Proof-of-
to Appendix A. Resource protocol, where the consensus power of a node
is proportional to its resources allocated.
Permissioned blockchains require a consensus node to obtain
A. Involved Parties permission to join the consensus protocol from a central-
Blockchains usually involve three native types of parties that ized or federated authority(ies), while nodes usually have
can be organized into a hierarchy, according to the actions that equal consensus power (i.e., one vote per node).
they perform (see Figure 3): Semi-Permissionless blockchains require a consensus node to
(1) Consensus nodes (a.k.a., miners in Proof-of-Resource obtain some form of permission (i.e., stake) before joining
protocols) actively participate in the underlying consensus the protocol; however, such permission can be given by
protocol. These nodes can read the blockchain and write any consensus node. The consensus power of a node is
to it by appending new transactions. Additionally, they proportional to the stake that it has.
can validate the blockchain and thus check whether writes
of other consensus nodes are correct. Consensus nodes
C. Design Goals of Consensus Protocols
can prevent malicious behaviors (e.g., by not appending
invalid transactions, or ignoring an incorrect chain). 1) Standard Design Goals – Liveness and Safety:
Liveness ensures that all valid transactions are eventually
1 Note that we started to work on this survey in early 2019. processed – i.e., if a transaction is received by a single honest
 4

node, it will eventually be delivered to all honest nodes. Safety However, a disadvantage of this approach is the possibility
ensures that if an honest node accepts (or rejects) a transaction, of multiple “winners” being elected, who propose conflicting
then all other honest nodes make the same decision. Usually, blocks, which naturally leads to inconsistencies called forks.
consensus protocols satisfy safety and liveness only under Forks are resolved by fork-choice rules, which compute the
certain assumptions: the minimal fraction of honest consensus difficulty of each branch and select the one. For the longest
power or the maximal fraction of adversarial consensus power. chain rule, the chain with the largest number of blocks is
With regard to safety, literature often uses the term finality and selected in the case of a conflict, while for the strongest chain
time to finality. Finality represents the sequence of the blocks rule, the selection criteria involve the quality of each block
from the genesis block up to the block B, where it can be in the chain (e.g., [22], [23], [24], [25], [18]). Note that the
assumed that this sequence of blocks is infeasible to overturn. possibility of forks in this category of protocols causes an
To reach finality up to the block B, several successive blocks increase of the time to finality, which in turn might enable
need to be appended after B – the number of such blocks is some attacks such as double-spending.
referred to as the number of confirmations. Voting-Based Protocols. In this group of protocols, the
2) Specific Design Goals: agreement on transactions is reached through the votes of all
As a result of this study, we learned that standard design participants. Examples include Byzantine Fault Tolerant (BFT)
goals of the consensus protocol should be amended by specific protocols – which require the consensus of a majority quorum
design goals related to the type of the blockchain. In permis- (usually 23 ) of all consensus nodes (e.g., [26], [27], [28], [29],
sionless type, elimination of Sybil entities, a fresh and fair [30]). The advantage of this category is a low-latency finality
leader/committee election, and non-interactive verification of due to a negligible likelihood of forks. The protocols from this
the consensus result is required to meet. In contrast, the (semi)- group suffer from low scalability, and thus their throughput
permissionless types do not require the elimination of Sybil forms a trade-off with scalability (i.e., the higher the number
entities (see details in Section X-C). of nodes, the lower the throughput).
3) Means to Achieve Design Goals: Combinations. To improve the scalability of voting-based
Simulation of the Verifiable Random Function (VRF). To protocols, it is desirable to shrink the number of consensus
ensure a fresh and fair leader/committee election, all consensus nodes participating in the voting by a lottery, so that only
nodes should contribute to the pseudo-randomness generation nodes of such a committee vote for a block (e.g., [31], [32],
that determines the fresh result of the election. This can be [33], [34], [29]). Another option to reduce active voting nodes
captured by the concept of the VRF [15], which ensures the is to split them into several groups (a.k.a., shards) that run a
unpredictability and fairness of the election process. Therefore, consensus protocol in parallel (e.g., [35], [36]). Such a setting
the leader/committee election process can be viewed as a further increases the throughput in contrast to the single-group
simulation of VRF [16]. Due to the properties of VRF, option, but on the other hand, it requires a mechanism that
the correctness of the election result can be verified non- accomplishes inter-shard transactions.
interactively after the election took place.
Incentive and Rewarding Schemes. An important aspect for E. Failure Models in Distributed Consensus Protocols
protocol designers is to include a rewarding/incentive scheme The relevant literature mentions two main failure models
that motivates consensus nodes to participate honestly in the for consensus protocols [37]:
protocol. In the context of public (permissionless) blockchains Fail-Stop Failures: A node either stops its operation or con-
that introduce their native crypto-tokens, this is achieved by tinues to operate, while obviously exposing its faulty
block creation rewards as well as transaction fees, and op- behavior to other nodes. Hence, all other nodes are
tionally penalties for misbehavior. Transaction fees and block aware of the faulty state of that node (e.g., tolerated in
creation rewards are attributed to the consensus node(s) that Paxos [38], Raft [39], Viewstamped Replication [40]).
create a valid block (e.g., [17]), although alternative incentive Byzantine Failures: In this model, the failed nodes (a.k.a.,
schemes rewarding more consensus nodes at the same time are Byzantine nodes) may perform arbitrary actions, includ-
also possible (e.g., [18]). While transaction fees are included ing malicious behavior targeting the consensus proto-
in a particular transaction, the block reward is usually part of col and collusions with other Byzantine nodes. Hence,
the first transaction in the block (a.k.a., coinbase transaction). the Byzantine failure model is of particular interest to
security-critical applications, such as blockchains (e.g.,
D. Basis of Consensus Protocols Nakamoto’s consensus [17], pure BFT protocols [26],
Lottery and voting are two marginal techniques that deal [27], [28], [41], and hybrid protocols [31], [35], [36]).
with the establishment of a consensus [19]. However, in
addition to them, their combinations have become popular. IV. T HE S ECURITY R EFERENCE A RCHITECTURE
Lottery-Based Protocols. These protocols provide consensus We present two models of the security reference architec-
by running a lottery that elects a leader/committee, who pro- ture, which facilitate systematic studying of vulnerabilities and
duces the block. The advantages of lottery-based approaches threats related to the blockchains and applications running on
are a small network traffic overheads and high scalability since top of them. First, we introduce the stacked model, which we
the process is usually non-interactive (e.g., [17], [20], [21]). then project into the threat-risk assessment model.
 5

A. Stacked Model

Higher-Level Applications
General
To classify the security aspects of blockchains, we utilize a Applications

Section IX
stacked model consisting of four layers (see Figure 4). A sim- Escrows Auctions
Reputation
Systems
ilar stacked model was already proposed in the literature [16],
but in contrast to it, we preserve only such a granularity level Data Direct
E-Voting Notaries
Provenance Trading

Application Layer
that enables us to isolate security threats and their nature,
which is the key focus of our work. In the following, we Secure
Identity

Section VIII
briefly describe each layer. Management Timestamping

Ecosystem
(1) The network layer consists of the data representation
Exchanges Oracles Filesystems
and network services planes. The data representation
plane deals with the storage, encoding, and protection of
Crypto-Tokens & Wallets
data, while the network service plane contains the discov-

Section VI Section VII

ery and communication with protocol peers, addressing,

Replicated

Machine
Smart Contracts

Layer
routing, and naming services.

State
Transactions
(2) The consensus layer deals with the ordering of trans-
actions, and we divide it into three main categories

Consensus
Byzantine Fault
Proof-of-Resource Proof-of-Stake

Layer
according to the protocol type: Byzantine Fault Tolerant, Tolerant Pro-
Protocols (PoR) Protocols (PoS)
tocols (BFT)
Proof-of-Resource, and Proof-of-Stake protocols.
(3) The replicated state machine (RSM) layer deals with
Peer Discovery
the interpretation of transactions, according to which & Management

Data Representation

Networks
Public
the state of the blockchain is updated. In this layer, DNS

Network Services
Network Layer
transactions are categorized into two parts, where the first

Section V
IP BGP
part deals with the privacy of data in transactions as well
as the privacy of the users who created them, and the
Authentication

Networks
second part – smart contracts – deals with the security

Private
and safety aspects of decentralized code execution in this Access Control
environment.
(4) The application layer contains the most common end-
Figure 4: Stacked model of the security reference architecture.
user functionalities and services. We divide this layer into
two groups. The first group represents the applications Additionally, owners involve consensus nodes that earn
that provide common functionalities for most of the crypto-tokens from running the consensus protocol.
higher-level blockchain applications, and it contains the Assets are present at the application layer, and they consist
following categories: wallets, exchanges, oracles, filesys- of monetary value (i.e., crypto-tokens or other tokens) as
tems, identity management, and secure timestamping. We well as the availability of application-layer services and
refer to this group as applications of the blockchain functionalities built on top of blockchains (e.g., notaries,
ecosystem. The next group of application types resides at escrows, data provenance, auctions). The authenticity of
a higher level and focuses on providing certain end-user users, the privacy of users, and the privacy of data
functionality. This group contains categories such as e- might also be considered as application-specific assets.
voting, notaries, identity management, auctions, escrows, Furthermore, we include here the reputation of service
etc. We found out that these higher-level applications providers using the blockchain services.
inherit security aspects from particular categories in the Threat agents are spread across all the layers of the stacked
underlying ecosystem group (see Figure 15). model, and they mostly involve malicious users whose
Throughout the paper, we summarize components and cate- intention is to steal assets, break functionalities, or disrupt
gories of particular layers of the reference architecture with services. However, threat agents might also be inadver-
their respective security threats, their origin, and corresponding tent entities, such as developers of smart contracts who
countermeasures and/or mitigation techniques. unintentionally create bugs and designers of blockchain
applications who make mistakes in the design or ignore
some issues.
B. Threat-Risk Assessment Model Threats facilitate various attacks on assets, and they exist
To better capture the security-related aspects of blockchain at all layers of the stacked model. Threats arise from
systems, we introduce a threat-risk model (see Figure 5) that vulnerabilities in the network, smart contracts, applica-
is based on the template of ISO/IEC 15408 [9] and projection tions, from consensus protocol deviations, violations of
of our stacked model (see Figure 4). This model includes the consensus protocol assumptions.
following components and actors: Countermeasures protect owners from threats by minimizing
Owners are blockchain users who run any type of node and the risk of compromising/losing the assets. Alike the
they exist at the application layer and the consensus threats and threat agents, countermeasures can be applied
layer. Owners possess crypto-tokens, and they might use at each of the layers of our stacked model, and they
or provide blockchain-based applications and services.
 6

Layer: Owners Layer: Countermeasures designed economic incentives, strong consistency, decentral-
Application Users, providers of  Multi-factor ization, and fast finality solutions. At the RSM layer, the
applications and services authentication, HW
Consensus wallets, redundancy, threat agents may stand for developers who (un)intentionally
Consensus nodes 
Application distribution of control,  introduce semantic bugs in smart contracts (intentional bugs
reputation approaches,
Layer: Threats application-level privacy represent backdoors) as well as users and external adver-
preserving constructs 
False data
feeds, censorship, front Safe languages,
saries running lightweight nodes who pose threats due to
running attacks, static/dynamic analysis,  the exploitation of such bugs. Countermeasures include safe
disruption of availability formal verification, audits,
Application and privacy, misbehaving  best practices, mixers, languages, static/dynamic analysis, formal verification, au-
manufacturer of TEE or RSM NIZKs, trusted HW, ring
token issuer, permanent signatures, blinding
dits, best practices, and design patterns. Other threats of
HW fault of TEE signatures, homomorphic the RSM layer are related to compromising the privacy of
encryption, secure MPC 
Privacy threats revealing
data and user identities, Economic incentives,
data and user identities with mitigation techniques involving
RSM exploiting smart contract- Consensus strong consistency, de- mixers, privacy-preserving cryptography constructs (e.g., non-
specific bugs centralization, fast finality
Redundancy, protection
interactive zero-knowledge proofs (NIZKs), ring signatures,
Consensus Protocol deviations,
violation of  assumptions Network of naming, availability, blinding signatures, homomorphic encryption) as well as usage
routing, anonymity, and
MITM attacks, availability data of trusted hardware (respecting its assumptions and attacker
Network attacks, network
partitioning, de- wish to minimize
to reduce models declared). At the application layer, threat agents
anonymization
Risk are broad and involve arbitrary internal or external adver-
give rise to increase
Layer: Threat Agents Loss of crypto-tokens or saries such as users, service providers, malware, designers of
assets they represent,  applications and services, manufactures of trusted execution
Arbitrary internal or loss of privacy, 
external adversary  loss of reputation, environments (TEE) for concerned applications (e.g., oracles,
(e.g., users, service broken functionalities,
Application providers, malware), disrupted services,  auctions), authorities in the case of applications that require
designers of applications
and services,
them for arbitration (e.g., escrows, auctions) or filtering of
 to
manufacturers of TEE, users (e.g., e-voting, auctions), token issuers. The threats on
authorities for arbitration, to Assets
token issuers this layer might arise from false data feeds, censorship by
Smart contract Crypto-tokens, application-specific authorities (e.g., auctions, e-voting), front
RSM developers, users, privacy of users,
external adversaries with wish to abuse privacy of data, running attacks, disruption of the availability of centralized
lightweight node or damage  authenticity of users, 
availability of applications components, compromising application-level privacy, misbe-
Consensus Consensus nodes and services,
reputation of service having of the token issuer, misbehaving of manufacturer of
Network Providers of network
services
providers TEE or permanent hardware (HW) faults in TEE. Examples
of mitigation techniques are multi-factor authentication, HW
Figure 5: Threat-risk assessment model of the security reference wallets with displays for signing transactions, redundancy/dis-
architecture. tributions of some centralized components, reputation systems,
and privacy preserving-constructs as part of the applications
involve various security/privacy/safety solutions, incen- themselves. We elaborate closer on vulnerabilities, threats, and
tive schemes, reputation techniques, best practices, etc. countermeasures (or mitigation techniques) related to each
Nevertheless, we emphasize that their utilization usually layer of the stacked model in the following sections.
imposes some limitations such as higher complexity
and additional performance overheads (e.g., resulting in Involved Parties & Blockchain’s Life-Cycle. In Sec-
decreased throughput). tion III, we presented several types of involved parties in
Risks are related to the application layer, and they are caused the blockchain infrastructure (see Figure 3). We emphasize
by threats and their agents. Risks may lead to a loss of that these parties are involved in the operational stage of the
monetary assets, a loss of privacy, a loss of reputation, blockchain’s life-cycle. However, in the design and develop-
service malfunctions, and disruptions of services and ment stages of the blockchain’s life-cycle, programmers and
applications (i.e., availability issues). designers should also be considered as potential threat agents
The owners wish to minimize the risk caused by threats that who influence the security aspects of the whole blockchain in-
arise from threat agents. Within our stacked model, different frastructure (regardless of whether their intention is malicious
threat agents appear at each layer. At the network layer, or not). This is of great concern especially for applications
there are service providers including parties managing IP built on top of blockchains (i.e., at the application layer) since
addresses and DNS names. The threats at this layer arise these applications are usually not thoroughly reviewed by the
from man-in-the-middle (MITM) attacks, network partitioning, community or public, as it is typical for other (lower) layers.
de-anonymization, and availability attacks. Countermeasures
contain protection of availability, naming, routing, anonymity,
V. N ETWORK L AYER
and data. At the consensus layer, consensus nodes may be
malicious and wish to alter the outcome of the consensus Blockchains usually introduce peer-to-peer overlay net-
protocol by deviating from it. Moreover, if they are powerful works built on top of other networks (see Figure 6). Hence,
enough, malicious nodes might violate assumptions of con- blockchains inherit security and privacy issues from their un-
sensus protocols to take over the execution of the protocol derlying networks. In our model (see Figure 4), we divide the
or cause its disruption. The countermeasures include well- network layer into data representation and network services
 7

Private D: Regular Updates

Networks
D: 2FA for Access
Blockchain Network

T: External Control Decisions

Targeted Attacks
V: Centralization D: User, System, and
of Control Network Monitoring
(e.g., SIEM, NIDS)

D: Consensus of a
T: Insiders Quorum for Access
Control Decisions
D: Respecting
Best Practices for
Insider Threat

Figure 7: Vulnerabilities, threats, and defenses in private networks

(network layer).
Underlying Network

is easier to manage and foresee, as all network participants and

the deployment scenario are known ahead of time.
2) Cons: Virtual Private Network (VPN) connectivity
is required to communicate between private networks spread
over different geographical locations. While VPNs are in
general secure, they inherit the disadvantages of running a
Legend: service over the Internet. Private networks are suitable only
Lightweight
Node
Full Storage Routing Voting
for permissioned blockchains.
Consensus Validating
Node
Lightweight
Storage
3) Security Threats and Countermeasures: We present
Node
a taxonomy of vulnerabilities, threats, and defenses against
Figure 6: Overlaying of blockchains over a private/public network. them in Figure 7. We identified insiders and external targeted
attacks as the specific security threats for the (permissioned)
sub-planes. The data representation plane is protected by cryp- blockchains running over the private networks. These threats
tographic primitives that ensure data integrity, user authentica- are possible due to a centralization of access control that might
tion, and optionally confidentiality, privacy, anonymity, non- occur in private networks, and thus permissioned blockchains.
repudiation, and accountability. The main services provided An external attacker might exploit a network or system vulner-
by the network layer are peer management and discovery, ability and obtain access to an element responsible for access
which rely on the internals of the underlying network, such control to the blockchain. In the case of the insider threat, she
as domain name resolution (i.e., DNS) or network routing may already have the necessary privileges or obtain them by
protocols. Based on permission to join the blockchain system, exploiting the system, network, or organization vulnerabilities.
the networks are either private or public. In the following, we As a result, the insider might add malicious consensus nodes
discuss the pros and cons of private and public networks as into the network or remove legitimate ones, and thereby
well as their security threats and mitigation techniques. increase the adversarial consensus power that is manifested
at the consensus layer. In turn, this may lead to plenty of
A. Private Networks attacks occurring at the consensus layer (see Section VI) such
as attacks on violation of protocol assumptions.
A private network ensures low latency, a centralized ad-
ministration, privacy, and meeting regulatory obligations (e.g., Countermeasures include regular software updates, monitor-
HIPAA2 for healthcare data). The organization owning the ing of users, network, and systems (e.g., by SIEM, anti-virus
network provides access to local participants as well as to software, intrusion detection systems), prevention techniques
external ones when required; hence, systems deploying pri- that minimize trust and maximize trustworthiness such as two-
vate networks belong to the group of permissioned private factor authentication for access control decisions (effective for
blockchains. Private networks inherently provide authentica- the external attacker), as well as respecting best practices for
tion and access control. mitigation of insider threat [42]. Another option of coping with
the centralization of access control is to embed decentralized
1) Pros: Access control is achieved by centralized access control into the consensus layer and thus mandating a
authentication of users. A private network has full control requirement on reaching a consensus of a quorum of nodes for
over routing paths and physical resources used, which enables each access control decision. In contrast to the other mentioned
suitable regulation of the network topology with regard to the countermeasures, the embedding of access control into the
given requirements. Data privacy is ensured by permissioned consensus layer is more effective since it eliminates a single-
settings. User identities might only be revealed within a point-of-failure of centralized access control service, and thus
private group of nodes. Fine-grained authorization controls are it makes an increase of adversarial consensus power more
applied by the operators of the network resources to implement difficult for the attacker – the attacker has to compromise a
the security principle of minimal exposure and thus mitigate high number of independent consensus nodes.
insider threat attacks on a local network. Resource availability
4) Side Effects of Countermeasures: Most of the
2 Health insurance portability and accountability act, https://hipaa.com/. mentioned countermeasures do not cause negative effects on
 8

the features of the blockchains under normal circumstances. D: DNSSec

The exception might be embedding of access control into the D: DANE

consensus layer under the assumption that the set of consensus D: Certificate
nodes in the network is extremely dynamic, and thus nodes Transparency
T: DNS Attacks
are entering and leaving the blockchain very often. In such a D: Alternate DNS
V: Centralization servers
case, the throughput of the blockchain might be decreased. of Control
D: Multi-Homed
Nodes

B. Public Networks / The Internet D: VPN

T: Routing Attacks
Public networks provide high decentralization, openness, D: Extra Peers

and low entry barrier, while network latency, privacy, and D: SABRE

network control are put aside. These networks are naturally V: Shared Untrusted D: BGPsec
Networks
required by all public (permissionless) blockchain systems. D: Minimum
Transaction Fee
T: DoS Attacks on
1) Pros: High availability is attractive to multi-homed Local Resources
D: Rate-Limit
nodes since they have alternate routes to send and receive Transactions
Public
messages. Multi-homed nodes may benefit from disseminating Networks D: Scoring and
Banning Peers
blocks across multiple channels, thereby increasing the chance
of blocks being appended to the blockchain. High decentral- D: VPN and anony-
T: Identity mization services
ization is achieved through geographical dispersion of nodes. Revealing Attacks
D: Design of the
Public peer-to-peer (p2p) networks are harder to shut down. V: Aspects of Consensus Protocol
DNS, and
Openness and low entry barriers on the Internet are achieved Routing Protocols D: Randomness in
Choosing the Peers
through wide adoption, technology interoperability (e.g., using
TCP/IP), economic (e.g., low cost of broadband connection), D: Redundant
Network Links
and societal (e.g., resistance to regulations) factors. D: Out-of-Band
T: Eclipse Attacks Connections /
2) Cons: Single-point-of-failure – DNS with its V: Design of Gossip Networks
hierarchy, IP addresses, and autonomous systems (ASes) are p2p Protocols
D: More Outgoing
managed by centralized parties – Internet Corporation for Peer Connections

Assigned Names and Numbers (ICANN); in particular, In- D: Peer Selection

with AS Topology
ternet Assigned Numbers Authority (IANA). External adver- D: Peer only with
saries pose a threat to public networks. These adversaries Whitelisted Nodes

can be classified based on their capabilities to which the T: DoS Attacks D: On Premise Filte-
on Connectivity ring (with a Device)
blockchain network may be exposed to [43]: (1) resources
D: Cloud Filtering
under attacker control (e.g., botnets, DNS and BGP servers), (Redirection)
(2) stolen or masqueraded identities (e.g., IP addresses par- D: Hybrid Filtering
ticipating in an eclipse attack or route manipulation), (3) (Cloud+On-Premise)

MITM attacker (i.e., eavesdropping and spoofing), (4) the Figure 8: Vulnerabilities, threats, and defenses in public networks
exploitation of common network vulnerabilities, (5) revealing (network layer).
secrets (e.g., de-anonymizing peers). Efficiency – although an
average Internet bandwidth has been improved in recent years, ification, these attacks may lead to network partitioning,
distribution of powerful infrastructure is not uniform, which which in turn raises the risks of 51% attacks or selfish
results in a different latency among peers, and thus the overall mining attacks presented at the consensus layer (see
latency of the network is increased; this might result in the Section VI). Apostolaki et al. [45] demonstrated that
loss of created blocks and thus wasting consensus power. the Bitcoin protocol is vulnerable to BGP routing at-
3) Security Threats and Countermeasures: We present tacks where the attacker controlling a transit autonomous
a taxonomy of vulnerabilities, threats, and defenses related to system (AS) can modify inter-domain routes for a few
public networks in Figure 8, while in Table VI of Appendix, Bitcoin nodes and cause network partitioning. However,
we list several incidents that occurred in practice. In the perpetration of this attack reveals the identity of the
following, we describe these threats as well as possible defense malicious AS, which might have immediate reputation
techniques. consequences.
DNS attacks arise from cache poisoning that mainly affects Countermeasures are multi-homed nodes (or using VPN)
blockchains employing centralized DNS bootstrapping to for route diversity, choosing extra peers whose connec-
retrieve online peers from a hard-coded list of DNS seed- tions do not pass through the same ASes, preference
ers. One countermeasure is a security extension of DNS, of peers hosted on the same AS within the same /24
called DNSSEC, which provides authentication and data prefix (to reduce risk of partitions), and fetching the same
integrity. In addition to standard DNS, name resolution block from multiple peers [45]. Another mitigation is
can also be made using alternate DNS servers [44]. SABRE [46], a secure relay network that runs alongside
Routing attacks are traffic route diversions, hijacking, or with the Bitcoin network. Further, BGPsec is a security
DoS attacks. Besides simple data eavesdropping or mod- extension for BGP used between neighboring ASes, and
 9

it assures route origin and propagation by cryptographic nodes including scoring DoS attacks and banning mis-
verification. behaving peers. DoS attacks on connectivity may also
Eclipse attacks aim to hijack all connections of a node to its target (additional) centralized elements of blockchain
peers in a blockchain network. Consequently, all traffic infrastructure, such as servers communicating with hosted
received and sent by the node is under the full control wallets (see Section VIII-A), which in turn might lead to
of the attacker. Eclipse attacks arise from threats on application layer attacks targeting clients of the wallets.
DNS and routing in the network, and they may be a Identity revealing attacks are conducted by linking the IP
result of vulnerabilities in p2p protocols [47], [48], [49]. address of a node with an identity propagated in transac-
Eclipse attacks increase chances of selfish mining and tions [57], [58]. Traffic analysis using Sybil listeners can
double-spending attacks (see Section VI) – the eclipsed reveal the linkage of node IP addresses and their trans-
victims may unknowingly vote for an attacker’s chain, actions [59]. Countermeasures include using VPNs or
and thus cause a network partitioning. Erebus [50] is anonymization services, such as Tor. See Section VII-A1
a stealthier attack causing network partitioning as com- for further identity and privacy-protecting mechanisms at
pared to Apostolaki et al. [45]. However, Erebus is not the RSM layer.
a routing attack since it does not involve BGP prefix
4) Side Effects of Countermeasures: The anonymization
hijacking (which is easy to detect) and has a very small
services cause deterioration of connectivity for consensus
network traffic footprint. In Erebus, the attacker controls a
nodes, and these nodes might not distribute the created block
large number of shadow IP addresses and influences the
on time and thus lose their reward. On the other hand, the slow
victim’s peer selection mechanism to pick all outgoing
connectivity of anonymization services can be acceptable for
connections with shadow IP addresses. This is achieved
validating nodes and clients transmitting messages related to
through slowly flooding the victim’s peer tables by in-
the creation and validation of their transactions. The trade-
coming connections from the attacker-controlled shadow
off for connectivity and anonymity can be provided by VPN
IP addresses.
services, which are fast but they are usually operated by a
Countermeasures: Improving randomness in choosing
centralized party, and thus the risk of de-anonymization is
peers was proposed in the work of Heilman et al. [47]
higher than in the case of anonymization services. Increasing
by several rules that manage the peer table. Another
the number of outgoing peer connections as protection against
mitigation strategy against eclipse attacks is to use redun-
eclipse attacks [50] can increase the volume of data that
dant network links or out-of-band connections to verify
needs to be transferred, which might negatively impact the
transactions (e.g., by a blockchain explorer). Eclipse
throughput of blockchains. Furthermore, fetching the same
attacks can also be detected by employing out-of-band
blocks from multiple peers [45] may contribute to the net-
gossip networks (e.g., web-servers) [51] that communi-
work congestion under certain configurations of blockchains
cate with lightweight clients to exchange their views on
focusing on a high throughput – this might lead to a slow down
the blockchain (i.e., block headers) along with native
in keeping touch with the tip of the blockchain and thereby
web traffic. Erebus attacks can be made much harder
impact a response time of an application running on top of it.
by decreasing the size of the peer tables, increasing the
The response time of the application might be also impacted
number of peers, preferring the peers that provide fresh
by cloud and hybrid filtering that relay some incoming traffic
data, and incorporation the topology of ASes into the
through 3rd party services.
peer selection process. Also, note that countermeasures
for DNS and routing attacks are applicable here as well.
DoS attacks on connectivity of consensus nodes may result VI. C ONSENSUS L AYER
in a loss of consensus power, thus preventing consensus
nodes from being rewarded [52]. For validating nodes, The consensus layer of the stacked model deals with the
this attack leads to a disruption of some blockchain- ordering of transactions, while the interpretation of them is
dependent services [53]. Countermeasures: One mitiga- left for the RSM layer (see Section VII). The consensus
tion is to peer only with white-listed nodes. Methods layer includes three main categories of consensus protocols
to prevent volumetric DDoS include on-premise filtering concerning different principles of operation and thus their
(i.e., with an extra network device), cloud filtering (i.e., security aspects. First, we focus on the security aspects that
redirection of traffic through a cloud when DDoS is are generic to all categories, and then we detail each category.
detected or through a cloud DDoS mitigation service),
or hybrid filtering [54].
DoS attacks on resources such as memory and storage, may A. Generic Attacks
reduce the peering and consensus capabilities [55] of
We present a taxonomy of the generic threats to all types of
nodes. An example attack is flooding the network with
consensus protocols, their origins, and defenses against them
low fee transactions (a.k.a., penny-flooding), which may
in Figure 9. These threats originate mainly from violation of
cause memory pool depletion, resulting in a system crash.
protocol assumptions but also due to a long time to the finality
A possible mitigation is raising the minimum transaction
of some consensus protocols. In the following, we describe
fee and the rate-limit to the number of transactions. Sev-
these threats as well as possible defense techniques.
eral mitigating techniques were applied to Bitcoin [56]
 10

D: Incentive Schemes can slow down or speed up the victim node’s network
(Punishments)
T: 51% Attack or 1/3 time [64]. When such a desynchronized node creates a
Byzantine Nodes
D: Statistical Analysis block, this block can be discarded by a network due
V: Violation
to freshness constraints. To avoid de-synchronization at-
T: Breaking Network D: Asynchronous
of Protocol tacks, a node can build a reputation list of trusted peers or
Assumptions Protocols
Assumptions
employ a timestamping authority [65]. Another option to
D: Reputation List
of Trusted Peers improve the accuracy of block timestamps is to compute
them collaboratively by consensus nodes [18].
T: Time De-Synchro- D: Timestamping
nization Attacks Authority Double-Spending Attack. This attack is possible due to the
D: Collaborative
creation of two or more conflicting blocks with the same
All
Computation by height, resulting in inconsistencies called forks. Thus,
Consensus Nodes
Protocols some crypto-tokens might be temporarily spent in both
D: Wait Certain
Amount of Time
conflicting blocks, while only a single block is later
T: Double included in the honest chain. A double-spending attack
V: Slow Finality
Spending Attacks
D: Use Consensus
Protocols with mainly affects consensus protocols with slow finality.
Fast Finality
This attack usually occurs as a consequence of 51%
D: PoW for Shard attacks.3 To prevent this attack, it is recommended to wait
V: Partitioning of T: Attacks Distribution
the Consensus on Distribution
a certain amount of time (i.e., time to the finality) until
Power of Shards D: Distributed Rando- a block “is settled” or utilize consensus protocols with
mness Protocol
(RoundHound) fast time to the finality, such as BFT protocols and their
Figure 9: Generic threats and defenses of the consensus layer. combinations.
Attacks on Shards. Sharding means that consensus nodes
1) Security Threats and Mitigations: are distributed among subgroups (i.e., shards) such that
Adversarial Centralization of Consensus Power. In these each node only validates the transactions in its group.
attacks, a design assumption about the decentralized Shards operate in parallel and can achieve higher scala-
distribution of consensus power is violated. Examples of bility and throughput since each shard has a throughput
this category are 51% attacks for PoR and PoS protocols similar to an entire non-sharded blockchain. On the other
as well as 31 of Byzantine nodes for BFT protocols (and hand, sharding has the potential to harm security because
their combinations). In a 51% attack, the majority of the each shard has a lower number of participating nodes than
consensus power is held by the adversary, thus also the the entire blockchain, which means that it may be easier
result of the protocol is under her control. In Byzantine for the attacker to compromise a single shard than the en-
attacks, a quorum of 13 adversarial consensus nodes might tire blockchain [66], [67]. The main mitigation technique
cause the protocol to be disrupted or even halted. As a is to achieve a truly random distribution of nodes among
design-oriented countermeasure, it is important to pro- the shards, and thus minimize the potential for adversaries
mote decentralization by incentive schemes that reward to bias the randomness used for shard distribution. For ex-
honest participation and discourage [60] or punish [61], ample, Elastico [68] uses PoW to distribute nodes among
[32] protocol violations. Another mitigation that makes shards, whereas Omniledger [35] uses a bias-resistant
these attacks more expensive is a statistical analysis of distributed randomness protocol (e.g., RandHound [69]).
sudden anomalies in the history of the consensus power Poor design of sharding protocols may also lead to
distribution among nodes, which can be embedded in the vulnerabilities such as replay attacks [70].
fork-choice rule of the consensus protocol [62]. 2) Side Effects of Countermeasures: Some generic
Breaking Network Assumptions. Protocols assuming syn- countermeasures presented in the above text might impact
chronous or partially synchronous network delivery the features of the blockchains. For example, the application
would inevitably fail when this assumption does not layer countermeasure that uses the timestamping authority
hold. For instance, this assumption can be violated in brings centralization issues, which might impact the availabil-
BFT protocols by an unpredictable network scheduler, ity of the service and enable misbehaving of the authority
as demonstrated on PBFT protocol [63]. This fact moti- that might provide imprecise time. To cope with this issue,
vates asynchronous BFT protocols that can be based on instead of using the application layer countermeasure, the
threshold-based cryptography, which enables reliable and computation of block timestamps can be embedded into the
consistent broadcast [41] [63]. consensus protocol, e.g., by ensuring that multiple consensus
Time De-Synchronization Attacks. Usually, besides system nodes simultaneously contribute to global time using partial
time, nodes in PoW and PoS maintain network time that solutions [18].
is computed as the median value of the time obtained Enriching a fork-choice rule by statistical analysis of the
from the peers. Such a time is often put into the block history [62] might protect against sudden changes in the
header, while nodes, upon receiving a block, validate distribution of the overall consensus power (e.g., rent-and-
whether it fits freshness constraints. An attacker can
exploit this approach by connecting a significant number 3 Note that in the case of PoR protocols, this attack may also occur as a
of nodes and propagate inaccurate timestamps, which consequence of the selfish mining attack.
 11

D: Uniform D: Smallest
Tie Breaking Accumulated Hash

D: Strongest Chain D: Partial Solutions

Fork-Choice Rule for Branch Difficulty
T: Selfish Mining
D: Fork-Choice Rule D: Orphaned Blocks
by Pseudo Rnd. Func. for Branch Difficulty

V: Fork- D: Decreasing time

Choice to finality (+ BFT)
Rules

D: Partial Solutions
for Branch Difficulty
PoR
Protocols D: Orphaned Blocks
T: Feather Forking
for Branch Difficulty

D: Partial Solutions
T: Bribery Attacks
for Branch Difficulty

T: Time Spoofing D: Partial Solutions

Attacks for Timestamp

V: Incentive D: Non-Outsourceable
Schemes T: Centralization Scratch of Puzzles
of Consensus
Power in Pools D: Decreasing Pool
Size by Rewarding
Partial Solutions

T: Pool Hopping D: PPLNS Schemes

T: Pool-Specific
Attacks D: Extra Reward to
T: Block Withholding
a Miner of the Block

T: Lie-in-Wait D: Oblivious Tasks

T: Selfish Mining D: Flat Structures

on a Subchain for Storing of Shares

Figure 10: Vulnerabilities, threats, and defenses of PoR protocols (consensus layer).

attack in PoW protocols), but not against a slow gradual B. Proof-of-Resource Protocols (PoR)
increase of the consensus power by a coalition. Furthermore,
this mitigation technique incentivizes consensus nodes to use Protocols from this category require nodes to prove the
stable identifications (i.e., the same key pairs) to increase spending of a scarce resource in a lottery-based fashion [19].
the strength of the honest chain and thus the chances that Scarce resources may stand for: (1) Computation that is
it becomes the main chain after a temporary fork. This might represented by Proof-of-Work (PoW) protocols (e.g., Bitcoin,
impact the privacy and security of consensus nodes, who are Ethereum). (2) Storage used in the setting of Proof-of-Space
disincentivized to rotate keys. Note that some privacy issues protocols [73] (e.g., Spacecoin [74], SpaceMint [75]). (3)
can be resolved at the RSM layer (see Section VII). Crypto-tokens spent for Proof-of-Burn protocols [76] (e.g.,
Slimcoin [77]). (4) Combinations and modification of the
Using a BFT consensus protocol helps to significantly
previous types, such as storage and computation, called Proof-
decrease the likelihood of double-spending attacks, but on the
of-Retrievability (e.g., Permacoin [78]) and storage over time,
other hand, it worsens the scalability of the blockchain and
which is represented by Proof-of-Space protocols (e.g., File-
thus throughput, especially in the case of a high number of
coin [79]). Another hybrid example of this category is a com-
consensus nodes. These issues can be resolved by combining
bination of PoR with elapsed time, such as in PeerCoin [80].
a BFT voting protocol with lottery-based protocols that reduce
However, it is a philosophical question whether to consider
the size of the actively communicating nodes to a small
elapsed time as a resource that is spent or as a stake that is
committee (e.g., [31], [32], [33], [34], [29]). The scalability of
invested – note that literature often categorizes PeerCoin as
BFT protocols can be also improved by using threshold-based
the first instance of a (hybrid) PoS protocol, hence we incline
signature aggregation with a gossip-based communication pat-
towards the second option.
tern (e.g., [71], [72]).
PoR protocols belong to the first generation of consensus
Distributed randomness protocols and PoW for distribu-
protocols, and they are mostly based on Nakamoto Con-
tion of shards bring additional overheads, which may reduce
sensus [17] that utilizes PoW, inheriting its pros (e.g., high
the throughput of the blockchain; however, this reduction is
scalability) and cons (e.g., low throughput). For the detailed
negligible in contrast to the throughput improvement due to
analysis of several PoW designs, we refer the reader to [81].
sharding.
 12

1) Pros: In PoR protocols, malicious overriding of transactions. Before a mining round begins, an adversary
the history of the blockchain (or part of it) requires spending announces that he will not extend the block containing
at least the same amount of resources as was spent for its blacklisted transactions, and thus will attempt to extend
creation. This is in contrast to the principles of PoS protocols, a forked chain. Although this strategy is not profitable
where a big enough coalition may override the history at for the adversary and the success rate is dependent on
almost no cost. his consensus power, rational nodes prefer to join the
2) Cons: PoR protocols imply high operational costs. censorship to avoid the potential loss. Countermeasures:
Moreover, these protocols provide only probabilistic finality, design-oriented protection is to minimize the chance of
which enables attacks forking the last few blocks of the chain. the attacker being successful, which can be done by
including (and rewarding) partial solutions [25], [90],
3) Security Threats and Mitigations: We present
[86], [18] or full orphaned blocks [23], [87] into branch
a taxonomy of the attacks related to PoR protocols, their
difficulty computation.
origins, and defenses against them in Figure 10, while we
Bribery Attacks: Whereas feather forking involves adver-
list several real-world incidents in Table V of Appendix. In
saries who try to influence the behavior of miners by
the following, we describe these attacks as well as possible
threatening to hurt their profits, bribery attacks involve the
defense techniques.
offering of direct rewards to miners. For example, con-
Selfish Mining: In selfish mining [82],4 an adversary at-
sensus nodes could be bribed to enable double-spending
tempts to privately build a secret chain and reveal it
attacks [91] or to reorder transactions within a block, and
to the public only when an honest chain is “catching
thus enable the transaction front-running by other means
up” with the secret one. The longest-chain rule causes
than natural priority gas auctions (PGAs) [92].6
honest miners to adopt the attacker’s chain and invalidate
Countermeasures: assuming that the miners who accept
the honest chain, thus wasting their consensus power.
bribes constitute a minority, a possible mitigation tech-
This attack is more efficient when the consensus power
nique is to utilize partial solutions [18], [25], [90], [86],
of a selfish miner reaches some threshold (e.g., 30%).
which reduce the likelihood that the double-spending
The selfish mining strategy was later generalized [84]
attacks succeed. Regarding “bribed” transaction front-
and extended to other variants that increase the profit
running, the misbehavior happens entirely off-chain since
of the attacker [85]. Countermeasures: For the case of
miners have complete control over the transaction order-
the longest-chain rule, the first introduced mitigation is
ing process, so on-chain mitigation is challenging. More-
uniform tie-breaking [82], which tells consensus nodes
over, the likelihood of this attack is directly proportional
to choose the chain to extend uniformly at random,
to the consensus power of the bribed miner; hence, this
regardless of which one they received first. However,
attack is more feasible for mining pools. However, since
this technique is less effective when assuming network
no evidence confirming collusion between mining pools
delays [84]. As the longest-chain rule enables this attack,
and bots has been found yet, mining pools are likely to
it is recommended to use other fork-choice rules that
be discouraged from accepting bribes due to the fear of
also account for the quality of solutions and make the
consequences (e.g., a decrease in the market value of the
decision deterministic, as opposed to a uniform tie-
crypto-tokens after these attacks are publicly disclosed).
breaking. An example of such a rule is to select the block
Time-Spoofing Attacks: Time-spoofing attacks target a time-
based on the smallest hash value of the header. Another
based difficulty computation algorithm in a PoR protocol
example is to include partial solutions [25], [86], [18] or
with the intention to decrease the difficulty of the puzzle
solutions representing full (orphaned) blocks [23], [87]
and thus minimize the effort for obtaining the same
in the computation of a chain quality. These partial or
reward. In particular, the attacker is a consensus node that
orphaned solutions can be incentivized by rewards to
mines blocks with delayed timestamps, which indicates
further improve decentralization. Another option for a
that a puzzle is too hard to meet block creation rate, and
deterministic fork-choice rule is using a pseudo-random
therefore difficulty needs to be decreased. Countermea-
function [88], which moreover provides unpredictability,5
sures: A solution that improves the accuracy of the times-
hence an attacker cannot determine his chances to win
tamps may utilize partial solutions found by all nodes into
a tie. Finally, PoW protocols can be combined with
an averaged timestamp computation [18]. Note that the
BFT protocols, where PoW is used only for joining the
impact of time spoofing attack might be significant also
protocol and BFT for consensus itself (e.g., [35], [36],
at the application layer, especially in use cases that rely
[88], [34], [68]).
on timestamp accuracy (see Section VIII-F).
Feather Forking: In this attack [89], the adversary creates in-
Pool Specific Attacks: Since PoR protocols are usually
centives for rational miners to collectively censor certain
based on a lottery having a single winner [17], re-
4 Note that selfish mining is theoretically possible even in PoS proto- wards for participation impose a high payout variance
cols [83], but requiring them to have predictable randomness for the leader for solo miners (i.e., once in a few years). As a conse-
election, which is usually a design-oriented vulnerability (see Section III-C).
However, in PoR, selfish mining is possible even with unpredictable random-
ness for the leader election. 6 In PGAs, users (arbitrage bots) compete with each other to be the first to
5 As opposed to uniform-tie breaking that provides only unpredictability, interact with a smart contract (e.g., due to profit from intra-chain exchanges
this solution additionally brings determinism. – see Section VIII-B).
 13

quence, mining pools emerged and caused centralization tree or hash of a set [18].
of the mining power, which may result in selfish mining, 4) Side Effects of Countermeasures: Partial solutions
double-spending, or 51% attacks. Countermeasures: Non- for difficulty computation might cause additional network
outsourceable scratch-off puzzles [60] avoid the creation overheads and thus decrease the throughput of the protocol.
of pools but require each consensus node to meet high However, this is not the case for sufficiently long rounds of
demands on connectivity and storage, as opposed to cen- PoW protocols, such as in StrongChain [18]. On the other
tralized pools, where only a pool operator needs to meet hand, rewarding partial solutions, apart from mitigating some
these demands. If pools are acceptable, their size can be threats, helps to promote decentralization – payout variance
controlled by protocols that reward partial solutions [25], is decreased and thus mining pools are not needed in some
[90], [86], [18] and thus minimize payout variance. For a cases, and in other cases, they can be much smaller.
detailed analysis of rewarding schemes in pools, we refer
the reader to [93]. In the following, we describe several
types of pool-specific attacks. C. Byzantine Fault Tolerant (BFT) Protocols
a) Pool Hopping. The individual contribution of min- BFT protocols represent voting-based [19] consensus pro-
ers in a pool is proved by broadcasting partial solu- tocols that utilize Byzantine agreement and a state ma-
tions, called shares. If pay-per-share (PPS) rewarding is chine replication [37]. These protocols assume a fully
employed (i.e., pool operator instantly rewards miners connected topology, broadcasting messages, and a master-
showing shares), an attacker may jump into another pool replicas hierarchy. Synchronous examples of this category
after his mining time in a victim pool reaches a certain are PBFT [26], RBFT [27], eventually synchronous ex-
threshold [94] since mining at the early stages of a amples are BFT-SMaRt [99], Tendermint [28], Byzantine
round is statistically more profitable than mining at the Paxos [100], BChain [30], and asynchronous examples are
end of the round. As a countermeasure pay-per-last-N- SINTRA [41] and HoneyBadgerBFT [63]. For more details,
shares (PPLNS) scheme and its variants [95] can be used. we refer the reader to a review of BFT protocols and their
PPLNS removes the concept of rounds and instead of practical applications in both permissioned and permissionless
immediate payments, it employs deterred payments after blockchains [101].
N shares are submitted by a miner. 1) Pros: BFT protocols provide high throughput and fast
b) Block Withholding. An attacker may try to sabotage finality. Another advantage of BFT protocols is that they can
a victim pool – after mining a block in a victim pool, the be combined with PoS or PoR protocols to achieve reasonable
attacker discards this block and continues mining at an- scalability and retain their other properties. This is in line with
other pool [93]. Such withholding does not mean a direct a lottery approach [19] for selecting a portion of all nodes,
gain for the attacker, but she may do a secret agreement referred to as a committee, which further runs BFT consensus
with concurrent pool(s) that may reward the attacker for or its part (e.g., Algorand [31], Zilliqa [34], DFINITY [33]).
showing a withheld block [96] (a.k.a., sponsored block 2) Cons: The main con of traditional BFT proto-
withholding). Mitigation for this kind of attack is using cols [100], [26] is low scalability caused by a high communica-
the PPLNS scheme, giving an extra reward to the miner tion complexity (i.e., Θ(n2 )). Since these protocols can work
of the block [97], precluding miners from distinguishing efficiently only with a limited number of consensus nodes,
between a share and a full solution (i.e., oblivious tasks). they can be used in their pure form only in permissioned
c) Lie-in-Wait. If the miner finds a block in a victim pool, blockchains.
she does not immediately submit it to the pool operator, 3) Improvements: The issues with scalability vs.
but instead focuses all her available mining power on throughput of BFT protocols can be partially addressed by
the victim pool to increase her relative shares within a applying threshold signatures (e.g., HotStuff [102], Byz-
pool; after some time attacker releases the formerly found Coin [88], Theta Blockchain [71]) as well as by optimizing
block. A countermeasure for this attack is an oblivious communication patterns from original broadcast to gossip-
task [96]. ing [71] or communication trees [88]. On top of that, consen-
d) Selfish Mining on a Subchain. Decentralized mining sus nodes might be partitioned into shards that process trans-
pools, such as p2pool [98], achieve decentralization by actions in parallel (e.g., Omniledger [35], RapidChain [36]).
updating an intermediary coinbase transaction with mined 4) Security Threats and Mitigations: We present a
shares. To preserve consistency with the previous versions taxonomy of the attacks related to BFT protocols, their origins,
of the coinbase transaction within a mining round, its and defenses against them in Figure 11. In the following, we
history is kept in a subchain. However, a chaining data describe these attacks as well as possible defense techniques.
structure enables selfish mining on a subchain, besides Denial of Service on a Leader: Since BFT protocols are
the fact that it implies a high stale rate of shares in a mostly intended for (private) permissioned blockchains
subchain.7 A possible countermeasure is to use flat data that are run by trusted participants, they do not assume the
structures for aggregation of shares, such as the Merkle existence of malicious nodes whose goal is to sabotage
the protocol. However, assuming such an adversary, a
7 Note that the same applies for Flux [25] and Subchains [90] that maintain leader of the round might be DoS-ed since her leadership
a subchain but at the level of the whole network (as opposed to p2pool). is known before the round starts, which might result
 14

D: Fresh Leader Election D. Proof-of-Stake Protocols (PoS)

by Private Check of VRF
against the Threshold
Similar to the PoR category, PoS protocols are based on the
V: Predictability T: DoS on V: Leaderless Setting
of Leadership the Leader with Aggregated Signatures lottery approach [19]. However, in contrast to PoR, no scarce
BFT
Protocols D: Checkpoints
resource is spent; instead, the nodes are required “to prove
V: No Checkpoints & T: Posterior
investment” of crypto-tokens to participate in a protocol, and
D: Context-Sensitive TXs
No Key Rotation Corruption thus eventually earn interest from the invested amount. The
D: Key-Evolving Crypto /
Forward-Secure Signatures
concept of PoS was for the first time proposed in the Bit-
cointalk forum [107]. The first technical realization of PoS is
Figure 11: Vulnerabilities, threats, and defenses of BFT protocols Peercoin [80], which is a combination with PoW – each node
(consensus layer). has its particular difficulty for PoW, which is based on the age
of the coins a node owns. Although there exist a couple of pure
in a restart of the round. Countermeasures: To prevent PoS protocols (e.g., Chains of Activity [108], Ouroboros [21]),
this attack, a node can privately determine whether it is the trend is to combine them in a hybrid setting with PoR (e.g.,
a potential leader by using Verifiable Random Function Proof-of-Activity [109], Peercoin [80], Snow White [110]) or
(VRF) [31], and immediately release a block candidate; BFT protocols (e.g., Algorand [31], Theta Blockchain [71]).
hence, after publishing this data, it is too late for a In particular, a combination of PoS with BFT represents a
DoS attack on the node. Another option for coping with promising approach, which takes advantage of both lottery and
this attack can be implemented by aggregating threshold voting (i.e., scalability and throughput), where no resources are
signatures in a leaderless setting [71]. wasted.
Posterior Corruption: Posterior corruption is a specific in-
stance of a violation of protocol assumptions (see Sec- 1) Pros: The main feature of PoS protocols, as
tion VI-A) in which the adversarial consensus power compared to PoR, is their energy efficiency. Although some
reaches 23 . In posterior corruption, the adversary has PoS protocols are often combined with a PoR technique
to steal private keys of 23 possibly “retired” consensus (e.g., [110], [80]), the overall energy spent is much smaller
nodes and then rerun the consensus protocol, rewriting than in the case of pure PoR protocols.
the history of the blockchain. Although this attack is 2) Cons: The introduction of PoS protocols has brought
mainly discussed in the context of PoS protocols (see Sec- PoS specific issues and attacks, while these protocols are, at
tion VI-D), we note that in PoS the attacker’s motivation the time of writing, still not formally proven to be secure.
is typically financial and exploits an incentive scheme of Next, PoS protocols are semi-permissionless – a node needs
(semi-)permissionless blockchains. On the other hand, the to first obtain a stake from any of the existing nodes to join
attacker’s motivation might be different in BFT protocols the protocol.
in permissioned settings (e.g., governance or sabotage) 3) Security Threats and Mitigations: We present a
since many such BFT protocols do not contain an in- taxonomy of the attacks related to PoS protocols, their origins,
centive scheme. To mitigate posterior corruption, key- and defenses in Figure 12. In the following, we describe these
evolving cryptography [103] and forward-secure digital attacks as well as possible defense techniques.
signatures (e.g., d-ary certificate trees [104]) can be Nothing-at-Stake: Since generating a block in PoS does not
employed, requiring users to evolve their private keys cost any energy, a node can extend two or more conflict-
and erase already used keys. Another option is to employ ing blocks without risking its stake, and hence increase its
irreversible checkpoints after a fixed number of blocks chance to be rewarded. Such behavior increases the num-
or context-sensitive transactions, which put the hash of a ber of forks and thus time to finality. Countermeasures:
recent valid block into a transaction itself [105]. Deposit-based solutions (e.g., [61]) require nodes to make
5) Side Effects of Countermeasures and Improvements: a deposit during some fixed period/round and checkpoint-
A problem of some threshold signatures (e.g., BLS signatures) based solutions (e.g., [61], [80], [32], [111]) employ
is a lack of forward secrecy, which might enable posterior “state freezing” at periodic snapshots of the blockchain,
corruption attacks. Forward secrecy might be provided by while the blockchain can be reversed maximally up to the
schemes such as d-ary certificate trees [104]. On the other recent checkpoint. Another option is to punish a node that
hand, a disadvantage of some forward-secure digital signatures signs two conflicting blocks by embedding cryptographic
(e.g., [104]) is an extra overhead required for their verification solutions [112] that enable anybody to reveal the identity
and updating, which negatively influences the throughput of and a private key of such a node. Another countermeasure
the blockchains. This problem was addressed in Pixel signa- is to use backward penalization of nodes that produced
tures [106], in which the authors proposed aggregated signa- two or more conflicting chains [32], [61]. Finally, PoS
tures supporting forward secrecy and demonstrated bandwidth protocols can be combined with BFT approaches, and
and storage savings in contrast to d-ary certificate trees [104]. thus the probability of forks is negligible (e.g., [31]).
Pruning the number of nodes that run BFT into commit- Grinding Attack: If the leader or committee producing a
tees [31] reduces the security level of BFT and provides only block is determined before the round starts, then the
probabilistic security guarantees depending on the committee attacker can bias this process to increase her chances
size. This phenomenon might be also seen as a deterioration of being selected in the future. For example, if a PoS
of decentralization. protocol takes only a hash of the previous block for the
 15

T: Grinding D: Fresh Leader Election risk. If the attacker accumulates keys with enough stake
Attack Requiring Interaction (SMC)
in the past, he may rerun the consensus protocol and
D: Fresh Leader Election rewrite the history of the blockchain. A variant of long-
by Private Check of VRF
against the Threshold range attack that considers only transaction-fee-based
V: Predictability
T: DoS on
D: Deposit-Based rewarding and infrequent or no check-points is denoted
the Leader
of Leadership Solutions as a stake-bleeding attack [105]. Countermeasures: One
or Committee

D: State-Freezing mitigation is to lock the deposit for a longer time than

(Checkpoints) the period of participation in the consensus [115]. The
D: Revealing SK of next mitigation technique is frequent periodic checkpoint-
a node that signs
PoS
V: No Risk for
T: Nothing-at 2+ conflicting blocks
ing, which causes the irreversibility of the blockchain
Extending 2+ blocks
Protocols -Stake Attack with respect to the last checkpoint. Another option is
& No Energy Spent
D: Backward
Penalization to apply key-evolving cryptography [103] and forward-
secure digital signatures [104], which require users to
D: Decreasing Time
V: No Checkpoints evolve their private keys, while already used keys are
T: Long- to Finality (+ BFT)
(Soft Finality)
Range
Attack
erased [113]. Hence, signatures cannot be forged in the
D: Frequent Checkpoints
case of compromise. The third mitigation technique is
D: Lock the Deposit for enforcing a chain density in a time-domain [105] for
V: No Key Rotation a Longer Time than
the period of Participation the protocols where the expected number of participants
in each round is known (e.g., [21]). The last mitigation
D: Key-Evolving Crypto /
Forward-Secure Signatures technique is context-sensitive transactions, which put the
hash of a recent valid block into a transaction itself [105].
D: Enforcing a Chain
Density in a Time 4) Side Effects of Countermeasures: Some countermea-
D: Context-Sensitive TXs sures for threats in PoS protocols might impact the features of
the blockchains. We note that secure multiparty coin-flipping
Figure 12: Vulnerabilities, threats, and defenses of PoS protocols
protocol brings requirements on additional interactions among
(consensus layer).
the consensus nodes, and thus it deteriorates the throughput
election process, the leader of a block may bias a hash of the protocol. On the other hand, the throughput does not
value by suitably adjusting the content of the block in a deteriorate when the leader and the committee are elected non-
few attempts. Countermeasures: The grinding attack can interactively by VRF.
be prevented by performing a fresh leader election by an
interaction of consensus nodes within some committee
VII. R EPLICATED S TATE M ACHINE L AYER
(e.g., the secure multiparty coin-flipping protocol [21]) or
by privately checking whether the VRF output is below The Replicated State Machine (RSM) layer is responsible
a certain stake-specific threshold (e.g., [31]). The input for the interpretation and execution of transactions that are
of the VRF is the user’s private key and the randomness already ordered by the consensus layer. Concerning security
unambiguously bound to the previous block; hence each threats for this layer are related to the privacy of users, privacy
consensus node might compute the only VRF output and confidentiality of data, and smart contract-specific bugs.
during each round. We split the security threats of the RSM layer into two parts:
Denial of Service on a Leader/Committee: Alike in BFT standard transactions and smart contracts.
protocols (see Section VI-C), if a leader or a committee
is publicly determined before the round starts [21], then
the adversary may conduct a DoS attack against them A. Transaction Protection
and thus cause a restart of the round – this might be Transactions containing plain-text data are digitally signed
repeated until the adversary’s desired nodes are elected. by private keys of users, enabling anybody to verify the
Countermeasures: A prevention technique was proposed validity of transactions with the corresponding public keys.
in Algorand [31] – a node privately determines whether However, such an approach provides only pseudonymous
it is a potential leader (or committee member), and identities that can be traced to real IP addresses (and some-
immediately releases a block candidate (or a vote) – times to identities) by a network-eavesdropping adversary, and
hence, after publishing this data, it is too late for a DoS moreover, it does not ensure the confidentiality of data [116].
attack. The concept of the VRF was also utilized in other Therefore, several blockchain-embedded mechanisms for the
protocols (e.g., [113], [33]). privacy of data and user identities were proposed in the liter-
Long-Range Attack: In this attack [114] (a.k.a., posterior ature, which we further elaborate on. Note that some privacy-
corruption [32]), an adversary can “bribe” previously preserving techniques can be applied also on the application
influential consensus nodes to sell their private keys or layer of our stacked model but imposing higher programming
steal the private keys by other means. Since consensus overheads and costs (e.g., see Section IX-A, Section IX-F,
nodes may exchange their crypto-tokens for fiat money and Section IX-G). This is common in the case of blockchain
anytime, selling their keys imposes no expenses and platforms that do not support them natively.
 16

D: Mixers tract platform Ethereum, and it provides a confidential

D: NIZKs payment mechanism that embeds the balance of users
D: Ring Signatures
into (secret) exponents of ElGamal encryption. Other
V: Pseudo- T: Revealing similar examples that deal with the privacy of data at
anonymity User Identities D: Secure MPC
the application layer of our stacked model are presented
D: Blinding Signatures
in Section IX-A, Section IX-G, Section IX-F.
D: Layered Encryption
2) Side Effects of Countermeasures: Since protocols of
Transactions
D: NIZKs mixing services usually contain a few rounds (that may involve
Cryptocurrency the creation of several transactions), all mixing services slow
D: Blinding Signatures
Platforms
D: Homomorphic
down the transaction throughput. The next blockchain feature
Encryption that is influenced by some mixers is decentralization. As
V: Transparency T: Revealing
of Data Data D: Trusted Transaction a consequence, centralized mixing services may misbehave
Managers
and reveal linkable information of transactions, they can be
Smart-Contract
Platforms
D: Trusted Hardware DoS-ed, or they can steal the funds. Accountability for the
misbehavior of centralized mixing service is provided in Mix-
D: Secure MPC
Coin [121] and Blindcoin [122] while the latter additionally
Figure 13: Vulnerabilities, threats, and defenses of privacy threats provides internal unlinkability by a mixing service. In contrast
(RSM layer). to centralized mixers, decentralized mixers remove a trusted
third party (i.e., no theft is possible) and provide stronger
1) Security Threats and Countermeasures: We present guarantees for unlinkability of transactions, e.g., CoinShuf-
a taxonomy of vulnerabilities, threats, and defenses related to fle [124] and CoinParty [125] require at least two and 23 m
the privacy of transaction data and user identities in Figure 13. honest participants, respectively, to provide full unlinkability.
Decentralization and availability are also impacted in solutions
Privacy Threats to User Identity. In many blockchains, that utilize trusted hardware [131], [132].
user identities can be linked with their transactions The throughput of blockchains is also impacted in crypto-
by various deanonymization techniques, such as graphic countermeasures such as NIZKs, ring signatures, and
network flow analysis, address clustering, or transaction blinding signatures. Ring signatures cause the large transaction
fingerprinting [116], [117], [118]. Moreover, blockchains size, which is linear with the number of participants in the
designed with anonymity and privacy features (e.g., anonymity set. The size of the ring signatures was optimized
Zcash, Monero) are also vulnerable to a few attack by cryptographic accumulators in [135], which in turn en-
strategies [119], [120]. Countermeasures: Various means abled the improvement of the throughput. NIZKs utilized in
are used for obfuscating user identities, including ZeroCoin [127] produce large proofs as well. The proof size
centralized [121], [122] and decentralized [123], [124], (and thus throughput) was further optimized by zk-SNARKs
[125] mixing services, ring signatures [126], and non- in ZeroCash [128]. However, the disadvantage of zk-SNARKs
interactive zero-knowledge proofs (NIZKs) [127], [128]. is the requirement for a trusted setup. This requirement is
Some mixers enable internal linkability by involved eliminated in Bulletproofs [130], which further decrease the
parties [123] or linkability by the mixers [121], which size of proofs in transactions and thus improves on throughput.
are also potential threats. Unlinkability for all parties can
be achieved by multiparty computation (MPC) [125],
blinding signatures [122], or layered encryption [124]. B. Smart Contracts
Ring signatures provide unlinkability to users in a Smart contracts introduced to automate legal contracts, now
signing group [126], enabling only the verification of serve as a method for building decentralized applications on
correctness of a signature, without revealing an identity blockchains. They are usually written in a blockchain-specific
of a signer. programming language that may be Turing-complete (i.e.,
Privacy of data. Blind signatures [129] and NIZKs such as contain arbitrary programming logic) or only serve for limited
zk-SNARKs [128] or (shorter) Bulletproofs [130] can purposes. In the following, we describe these two contrasting
be used for the preservation of data privacy. Another types of smart contract languages and their security aspects.
method is homomorphic encryption, which enables the 1) Security Threats and Countermeasures: We present
computation of certain operations over encrypted mes- a taxonomy of vulnerabilities, threats, and defenses inherent
sages (e.g., ElGamal encryption provides additive ho- to smart contract platforms in Figure 14.
momorphism). Privacy and confidentiality for smart con- Turing-Complete Languages. An important aspect of this
tract platforms can be achieved through trusted transac- smart contract language category is a large attack sur-
tion managers [131] utilizing zk-SNARKs, trusted hard- face due to the possibility of arbitrary programming
ware [132], and secure multiparty computations [133] logic. Examples of this category are Serpent, Vyper,
embedded into these platforms. Privacy of data can be Yul, Flint, LLL, and Solidity, while as of now Solidity
achieved even on blockchain platforms without embedded is the most popular and widely-used one. Serpent8 is
support of privacy-preserving constructs. For example,
Zether [134] is built on top of the public smart con- 8 https://github.com/ethereum/wiki/wiki/Serpent-%5BDEPRECATED%5D
 17

D: Safe Languages [142]. The literature contains various smart contract anal-
D: Static Code
ysis tools for the detection of vulnerabilities [143], [144].
Analysis Tools In the following, we give an overview of them:
D: Dynamic Analysis • Static analysis tools such as linters, try to find vul-
(Testing) Tools
nerabilities by inspecting the source code. For exam-
D: Formal Verification
Smart V: Smart Contract-
T: Arbitrary External Tools ple, SmartCheck [145], Solhint,14 Solium [146], and
or Internal
Contracts Specific Bugs
Adversary
D: Decompiling Tools
Slither15 belong to this category. Another example,
sCompile [147], works statically, but it also includes a
D: Semantic Audits dynamic component.
D: Best Practices and • Dynamic analysis tools seek vulnerabilities while exe-
Design Patterns
cuting the code of smart contracts. For example, simple
Figure 14: Vulnerabilities, threats, and defenses of smart contract forms of dynamic analysis are unit testing with hand-
platforms (RSM layer). crafted tests or replay testing [148], where existing
executions (or manually captured ones) are used to
a high-level language that was designed to be simple check if the same results can be reproduced. A more
and similar to the Python language. However, Serpent automated form of testing is fuzzing [149], which
was designed in an untyped fashion, lacking out-of- generates unexpected, undefined, random, or invalid
bound access checks of arrays and accepting invalid inputs to trigger a crash or reveal defects and vulnera-
code by compilers [136], which opened the door for bilities. Fuzzers, like ContractFuzzer [150], Echidna,16
plenty of vulnerabilities. Hence, Serpent showed to be and Harvey [151] can be used for automated smart
an unsuccessful attempt to simplify the coding phase. contract testing as well. Another technique of dynamic
Vyper9 is an experimental language designed to ease analysis is symbolic execution [152], where a program
the audit of smart contracts and increase security – it is executed with symbolic values (i.e., logical expres-
contains strong typing, bounds checks, and overflows. sions) that make it possible to explore all reachable
Yul10 is a typed intermediate language for Ethereum, paths of a program. For this technique, there are tools
which can be compiled to bytecode for the EVM 1.0, like Securify [153], Manticore [154], Oyente [155], and
EVM 1.5 and eWASM platforms. Snippets of Yul code Osiris [156].
can be inserted as an inline assembly within Solidity • Formal verification tools usually apply an abstract
code to perform optimizations that are applicable for model or a semantic definition to check for the se-
these three platforms. Flint [137] is a type-safe language curity and/or correctness properties of smart contracts.
for Ethereum smart contracts. The major focus of this One type of this category is represented by semantic-
language is its robustness, and it also provides some based approaches that work with a semantic language
special features such as caller protection, which can help specification defining the expected behavior of smart
to produce robust contracts. Lisp Like Language (LLL)11 contracts. Examples of this type are FSolidM [157],
is a low-level language that is similar to Assembler. It and Kevm [158]. Other types of formal verification
aims to be simple and to support the creation of clean tools are semantic-based approaches that work with
code; for example, it removes the need to code the stack a behavioral model [159]. Several formal verification
and jump management. Moreover, it enables a focus on methods [160], [161], [162] apply abstract models
the resource-constrained nature of Ethereum and allows (e.g., finite state machines) that define the expected
optimized use of the resources. Solidity12 is an object- states and outputs of smart contracts for a given input.
oriented statically-typed language that is primarily used The underlying models are used for checking the
by the Ethereum platform. Contracts written in Solidity functional correctness or the presence of vulnerabilities
can contain various types of vulnerabilities [138], [139], (e.g., Zeus [163]). Additionally, such models can be
[140], which resulted in many incidents in the past. Ta- applied to proving certain security properties [164].
ble IV of Appendix outlines the most prominent incidents • Decompiling tools. The source code of contracts is of-
and the associated vulnerabilities. In addition, the table ten not public in contrast to their bytecode. For this rea-
classifies vulnerabilities according to an existing smart son, bytecode decompilers, like Erays [165], Eveem,17
contract weakness classification (SWC) registry [141].13 or Porosity [166] can be used to (partially) reconstruct
Countermeasures: Mitigation techniques for such vulner- the source code of a contract. Additionally, there exist
abilities are static or dynamic analysis (testing) tools, for- various static bytecode analyzers, like Maian [167],
mal verification tools, security audits, as well as respect- MadMax [168], Vandal [169], and automated exploit
ing best practices and using known design patterns [141], generators, like Teether [170] that can be utilized to
find vulnerabilities in the bytecode.
9 https://vyper.readthedocs.io/en/v0.1.0-beta.9/
10 https://solidity.readthedocs.io/en/v0.5.10/yul.html
11 https://lll-docs.readthedocs.io/ 14 https://github.com/protofire/solhint
12 https://solidity.readthedocs.io/ 15 https://github.com/crytic/slither
13 Note 16 https://github.com/crytic/echidna/
that for some vulnerabilities there are no publicly available refer-
ences on incidents supporting the existence of vulnerabilities. 17 https://eveem.org/
 18

{
Turing-Incomplete Languages. The main pro of this cate-
Escrows Auctions

General Applications
gory is its design-oriented goal of a small attack surface

of Blockchain
and the emphasis on safety, which is achieved at the

Higher-Level
Applications
Reputation
cost of limited expressiveness. Examples of this cate- Systems
gory are Pact, Scilla, Bitcoin Script, Ivy, and Simplic-
ity. Pact [171] is a declarative language intended for Data Direct
E-Voting Notaries

{
the Kadena blockchain and provides type inference and Provenance Trading
module-guarded tables to prevent direct access to the
module. Pact is equipped with the ability to express Identity Secure
and check properties of its programs, also leveraging Management Timestamping

Ecosystem
satisfiability modulo theories (SMT) solvers. Scilla [172]
is designed to achieve expressiveness and tractability Oracles Filesystems Exchanges
while enabling formal reasoning about contract behavior.
Every computation utilizes an automata-based model, and
Crypto-Tokens & Wallets
computations are realized as standalone atomic transitions
that strictly terminate. Scilla enables external calls only in
the last instruction of a contract, which simplifies proving Figure 15: Hierarchy in inheritance of security aspects across
categories of the application layer. Dotted arrows represent
safety and thus mitigates a few vulnerabilities. Bitcoin application-specific and optional dependencies.
Script [173] is a stack-based language for the Bitcoin
platform. It has limited complexity and processing re- A. Crypto-Tokens & Wallets
quirements, and its main purpose is transaction process- Besides blockchains that provide cryptocurrencies with
ing. Ivy is a high-level declarative predicate language for native crypto-tokens, there are blockchain applications that
the Bitcoin platform. It can be compiled to a Bitcoin use crypto-tokens to provide owners with rights against a
script and its main advantage is its comprehensibility, third party (i.e., counter-party tokens) or with the possibil-
which enables fast writing and an easy understanding of ity of transferring asset ownership (i.e., ownership/colored
the code. Simplicity [174] is a typed functional language tokens) [175]. All types of tokens require the protection
that works with combinators. It is equipped with (formal) of private keys and secrets linked with user accounts. For
denotational and operational semantics, which facilitate this purpose, two main categories of wallets have emerged:
the estimation of the required computing resources. self-sovereign wallets (a.k.a., non-custodial) and hosted wal-
2) Side Effects of Countermeasures: Since all of the lets [176], [177]. All crypto-tokens are exposed to technical
smart contract related countermeasures are performed before and regulatory risks, while non-native tokens are also exposed
the deployment of smart contracts as part of the develop- to legal risks [175].
ment stage of the blockchain-based applications, they do not Self-Sovereign Wallets. Users of self-sovereign wallets lo-
negatively impact any blockchain features. Note that only cally store their private keys and directly interact with the
countermeasures related to the operational stage of blockchain- blockchain platform using these keys, while they verify the
based applications might influence blockchain features. inclusion of their transactions by SPV client software. The
instances of these wallets differ in several points. One of
them is the manner in which the keys are isolated – there are
VIII. A PPLICATION L AYER : E COSYSTEM A PPLICATIONS
software wallets that store the keys within the user PC (e.g.,
We present a functionality-oriented categorization of the Bitcoin Core,18 MyEtherWallet19 ) as well as hardware wallets
applications running on or utilizing the blockchain in Fig- that store keys in sealed storage, while they expose only
ure 15, where we depict hierarchy in the inheritance of security signing functionality (e.g., Trezor,20 Ledger21 ). The next type
aspects among particular categories. In this categorization, of wallets enables functionality and security customization
we divide the applications into categories according to the through a smart contract (e.g., TrezorMultisig2of3,22 Ethereum
main functionality/goal that is to be achieved by using the MultiSigWallet,23 SmartOTPs [178]).
blockchain. Security threats of this layer are mostly specific Hosted Wallets. Hosted wallets require a centralized party,
to particular types of applications. Nevertheless, there are which provides an interface for interaction with the wallet and
a few application-level categories that are often utilized by the blockchain. If a hosted wallet has full control over private
other higher-level applications. In the current section, we keys, it is referred to as a server-side wallet (e.g., Coinbase24 ),
isolate such categories into a dedicated application-level group while in the case when keys are stored in the user’s browser,
denoted as an ecosystem, while we describe the rest of the
applications in Section IX. The group of ecosystem appli- 18 https://bitcoin.org/en/download
19 https://www.myetherwallet.com/
cations contains five categories: (1) crypto-tokens and wal-
20 https://trezor.io/
lets, (2) exchanges, (3) oracles, (4) filesystems, (5) identity 21 https://www.ledger.com/products/ledger-nano-s
management, and (6) secure-timestamping. We accompany 22 https://github.com/unchained-capital/ethereum-multisig
the application layer with several incidents in Table III of 23 https://github.com/ConsenSys/MultiSigWallet

Appendix. 24 https://www.coinbase.com/
 19

T: Malware,
V: Key Stored Locally
Keyloggers
D: Use HW Wallet
Client-Side Wallets with Display
T: Tampering with
the Client
V: Trust in Online
Interface of 3rd Party
Hosted T: Disrupted Service
Wallets
T: External D: Migrate to Self-
Adversaries Sovereign Wallet

V: Single-Point-of-
Server-Side Wallets T: Insider Threat
Failure / Centralization

T: Malware, D: Use HW Wallet

Keyloggers with Display
Self-Sovereign V: Key Stored D: Multi-Signatures
Wallets Locally
T: Tampering with D: Multi-Factor D: Threshold-Based
the Client Authentication Cryptography

D: Air-Gapped OTPs
Ownership &
V: Trust in a Centra- T: Misbehaving of D: Decentralized
Counterparty
lized Party (Issuer) Issuer Reputation Systems
Tokens

Figure 16: Vulnerabilities, threats, and defenses of the crypto-token & wallets category (application layer).

a wallet is referred to as a client-side wallet (e.g., Blockchain decentralized reputation-based systems (see Section IX-B) and
Wallet25 ). We refer the reader to works [176], [178] for a notaries (see Section IX-D) that might be built on top of them.
security overview of miscellaneous wallet solutions.
2) Side Effects and Implications of Countermeasures:
1) Security Threats and Mitigations: We present a A disadvantage of some multi-factor authentication solutions
taxonomy of vulnerabilities, threats, and defenses related to is that they require the execution of smart contracts, which
the crypto-token wallets category in Figure 16. Server-side increases the costs and might slow down the throughput of the
wallets pose a single-point-of-failure, which can be exploited system. In contrast, threshold-based cryptography constructs
by external or internal adversaries, and moreover, it can be save these costs since they produce only a single signature,
subjected to availability attacks such as DoS. Since server-side which appears as it was made by a single party. However,
wallets have been the target in several security incidents [179], threshold-based cryptography requires off-chain computation,
[180], [181], their popularity has declined in favor of client- in which the duration of execution is dependent on the number
side wallets. Client-side wallets do not expose private keys of co-signing parties.
to a centralized party but store it locally. Nevertheless, they Although self-sovereign wallets provide higher security in
still trust in the online interface provided by such a party, contrast to client-side and server-side hosted wallets, they
and thus their availability is dependent on this party. Other impose overheads for storing the non-negligible part of the
threats with client-side wallets are client tampering and mal- blockchain (i.e., headers) to validate the inclusion of signed
ware/keyloggers, which focus on deceiving the user while transactions within their SPV client software – this is espe-
signing a transaction or stealing the key. Possible mitigations cially a concern when users have multiple SPV clients for
of these attacks include hardware wallets that display details multiple blockchains. BTC Relay is an early optimization
of transactions to the user, while the user confirms signing by attempt that reduces storage requirement by outsourcing the
a button (e.g., Trezor, Ledger). validation of transactions from the source blockchain to the
In contrast, self-sovereign wallets do not trust in a third target blockchain in exchange for a small fee paid to the relay
party nor rely on its availability. However, these wallets are nodes that submit headers to the target blockchain. However,
susceptible to key theft (i.e., malware [182], keyloggers [177], the costs of BTC Relay were too high and its users tend
[183]). One protection is to use a hardware wallet with a to rather store headers of source blockchain on their own.
display as described above. Another option is to protect self- Zk-relay [185] optimizes these costs by using zk-SNARKs
sovereign wallets by multi-factor/(-step) authentication using with batched block validation, achieving an improvement by
multi-signatures (e.g., TrezorMultisig2of3, Ethereum Multi- a factor of 187.
SigWallet), threshold-based cryptography [184], or air-gapped
OTPs [178]. In the case of counter-party and ownership
tokens presented at the application layer of existing public
B. Exchanges
blockchains, we emphasize the additional vulnerability caused
by trusting in the centralized party that issues such tokens If the user wishes to exchange crypto-tokens, she might
– the provided counter-party and ownership rights are only either directly find a counter-party wishing to exchange the op-
virtual, which imposes a significant risk. While this risk posite pair or approach an exchange that might be centralized
cannot be eliminated in this application scenario, a possible or decentralized (DEX). In the case of centralized exchanges,
mitigation technique for preventing fraudulent issuers is to use the security threats and implications are due to centralization,
and the only countermeasure is to use decentralized exchange
25 https://blockchain.info/wallet/ solutions that we further focus on.
 20

Cross-Chain V: Long Delays T: Fluctuating Exchange D: Punishing Misbe-

DEX & Online Availability Rate havior from Deposits

D: Off-Chain Exchange

Direct Exchange V: Different Times T: Overturning Weaker D: Increasing the Num-

with Atomic Swap to Finality Blockchain ber of Confirmations

D: Context-Sensitive
Exchanges
Transactions

Intra-Chain V: Exchange in the D: Partial Solutions for

T: Front-Running
DEX Same Chain Branch Difficulty

Centralized V: Single-Point-of T: External Adversaries, D: Use DEX or

Exchange Failure / Centralization Insider Threat Direct Atomic Swaps

Figure 17: Vulnerabilities, threats, and defenses of the exchanges category (application layer).

Direct Cross-Chain Exchange with Atomic Swap. Atomic deposited reserves of traded ERC20 tokens; examples are
swaps26 assume two parties owning crypto-tokens in two dif- Euler [189], Bancor [190], and Uniswap.29 AAM provides
ferent blockchains, and these parties wish to execute exchange high liquidity since users are not required to match their
atomically, i.e., either both of the parties receive the agreed orders, and they can directly do the exchange with the smart
amount or neither of them. The atomic swap protocol enables contract.
conditional redemption of the funds in the first blockchain Cross-Chain Communication. The concept of cross-chain
upon revealing the hash pre-image (i.e., secret) that redeems exchange can be further generalized into cross-chain com-
the funds on the second blockchain. This protocol is based on munication (CCC), which deals with the interoperability of
two Hashed Time-Lock Contracts (HTLC) that are deployed applications running on different blockchains. The security
by both parties in both blockchains, and it requires 4 transac- aspects of CCC are very similar to the exchanges, and we refer
tions (see details in Appendix B). the interested reader to the work of Zamyatin et al. [191].
Cross-Chain DEX. Although atomic swaps are, in theory,
sufficient means for the execution of fair cross-chain exchange, 1) Security Threats and Mitigations: We present an
the situation is more complicated in practice. In particular, overview of vulnerabilities, threats, and defenses related to
there might not exist a contra-party exchanging the opposite the exchanges category in Figure 17.
pair or the user might not be aware of it. This motivates In centralized exchanges, threats are caused by external
DEXes, which facilitate the process of maintaining and match- and internal adversaries, and they are identical to those of
ing the existing orders, act as a contra-party or intermediary, server-side hosted wallets (see Section VIII-A) since server-
while guaranteeing fairness (e.g., Komodo27 ). The users match side wallets always provide exchange services. So far central-
the orders, reward DEX, and afterward perform an atomic ized exchanges posed the most attractive target for adversaries
swap on their own. If users wish to trade more obscure crypto- that have caused huge financial losses [192]. There are many
tokens, for which there is no matching counter-order, DEX operation security (OPSEC) countermeasures such as multi-
may serve as a counter-party and do the atomic swap with the factor authentication, split of the funds to hot and cold wallets,
user. Moreover, if the users wish to trade colored tokens for however, none of them eliminates the single-point-of-failure
native crypto-tokens of different blockchains (e.g., A sells an coming from the centralization. Therefore, effective mitigation
asset for BTC and B buys it for ETH), DEX might serve as an from the user point of view is to use decentralized exchange
intermediary who executes the three-way atomic swap [186] solutions such as DEXes and atomic swaps; however, they also
(see details in Appendix B). contain some vulnerabilities.
Different blockchains of cross-chain decentralized (direct
Intra-Chain DEX. Some intra-chain DEX designs (e.g.,
and DEX-based) exchanges might have a different time to
Maker Market, EtherOpt, and Intrinsically Tradeable Tokens)
finality, and thus the likelihood that one blockchain will
require parties to post buy&sell offers on the blockchain,
be overturned is higher than in the case of the other one.
while smart contracts perform matches and execute trades.
Therefore, the number of required confirmations might be
However, each placing of an order or its modification requires
agreed upon by involved parties beforehand. However, this
a payment for the inclusion of a transaction. Therefore, de-
results in longer delays for the execution of the protocol
signs with off-chain order matching became more popular;
and the need for both parties to be online. In some cases,
in these designs, only trades are executed on-chain, while
such long delays might cause fluctuation in the exchange
orders and their matching is performed off-chain. An example
rate, making the exchange not attractive at a later time. As a
is 0x [187] protocol handling DEX of ERC20 tokens (e.g.,
mitigation technique, off-chain exchanges (within side-chains)
applied in EtherDelta28 ). The next intra-chain exchange design
might be used, where each blockchain is updated only with
is known as the automated market maker (AAM) [188]. AAM
the final transaction. Off-chain real-time exchanges might also
is applicable within a smart contract-based DEX that contains
be achieved with the use of TEE [193] (see below). Another
mitigation for intentional delaying of the exchange by any
26 https://en.bitcoinwiki.org/wiki/Atomic Swap
27 https://komodoplatform.com/atomic-swap-technology/
28 https://etherdelta.com/ 29 https://uniswap.io/
 21

party is to use deposit-based bonds, which will be restored could be alternatively ensured in Tesseract by smart contract-
only when a particular party acts timely. based censorship resolution [198], which, however, implies
Since intra-chain exchanges are executed in the single some extra costs for smart contract execution. Finally, TEE-
blockchain, they give rise to the transaction front-running, based solutions might be vulnerable to attacks on trusted
in which the adversary (a.k.a, arbitrage bots) front-run user hardware. As a mitigation technique to reliance on a trusted
trades by transactions containing higher fees and by optimiz- manufacturer of TEE, it is possible to use a quorum of several
ing network latency [92]. Moreover, such adversaries might redundant TEEs from multiple manufacturers. Furthermore,
compete with each other by “bidding” a higher transaction it is important to note that the assumption about the code
fee [92], which in turn targets the ordering mechanism of executed in TEE is its bug-freeness, and thus one might not use
the consensus layer, where miners might tend to overturn or return-oriented programming or other techniques to ex-filtrate
fork the blockchain while including only transactions with sealed secrets or private parameters; this is an out-of-the-scope
the highest fees. A mitigation technique to these threats is attacker model for TEE.
represented by context-sensitive transactions [105], which do
not allow overturning of the blockchain, only its extension. C. Oracles
The same effect can be achieved by partial solutions included
in branch difficulty computation [18], [25], [90], [86]. Note Oracles (a.k.a., data feeds) are trusted entities that provide
that context-sensitive transactions and partial solutions are a plausible data that reflects the state of the world beyond the
means of the consensus layer. blockchain. The authors of [199] and [200] define a few
security properties of oracles in smart contract platforms:
2) Side Effects and Implications of Countermeasures: Authenticity: Data are authentic if they are produced by
We assume centralized exchanges as the baseline that requires content providers agreed by the consumers of the data.
only two transactions for settlement of cross-chain exchange Integrity: Provided data should not be modified nor deleted
or one transaction for intra-chain exchange. Note that such set- after creation. Therefore, content providers should guar-
tlement is done only sporadically since centralized exchanges antee the correctness of the newly created data and
inherently work off-chain in real-time. In contrast, direct publicly prove their consistency with the past.
atomic swaps require 4 transactions while three-way atomic Confidentiality: Sometimes, input parameters may contain
swaps require 6 transactions. Therefore, using these constructs confidential or private data. Therefore, an oracle should
negatively affects the throughput of blockchains. Nevertheless, support such parameters and their handling.
the performance can be improved by off-chain execution of Availability: Since the execution of dependent smart contracts
atomic swaps, which provides almost immediate response, relies on data feeds delivered by oracles, they need to
e.g., off-chain swaps are possible in two-parties payment provide high availability.
channels as well as their extension to multiple parties known as We categorize existing oracles according to security impli-
the lightning network [194]. Such off-chain solutions greatly cations into three categories. Prediction markets (e.g., Au-
improve the scalability, since parties can transact directly and gur [201], Gnosis30 ) were created for the purpose of trading the
involve blockchain consensus only when they wish to settle outcome of events – individuals are incentivized to accurately
their balances (e.g., once per day or week). However, to avoid wager on outcomes serving as data feeds, while outcomes
misbehavior in which a “stale” balance is settled on-chain, are provided by either a centralized reporter or a quorum
these systems require that the parties constantly monitor the of reporters. Centralized data feeds provide arbitrary data
blockchain state. Such an always-online assumption can be from a single centralized source, and they build on existing
relaxed by employing watching services [195], [196], [197] blockchain platforms (e.g., Oraclize,31 Town Crier [202],
(a.k.a., watchtowers), which, however, incur extra costs. PDFS [199]). Finally, oracle networks internally run a con-
TEE can be also utilized as an off-chain means that sensus protocol for decentralized agreement on data (e.g.,
improves the throughput of exchange service. For example, ChainLink [200], Witnet [203]).
Tesseract [193] is a real-time exchange that leverages TEE for Prediction Markets. Augur [201] is a solution designed as the
communication with users and a target blockchain. To enter Ethereum smart contract, and it uses its own reputation token.
the system, users submit time-locked refill transactions paying The user creating the market specifies a designated reporter,
to Tesseract’s controlled address in the target blockchain, and who delivers the result of the event after it happens. However,
then Tesseract uses its SPV client to verify their inclusion. the reporter might not report the result or report incorrect
Existing users submit bid&sell requests to Tesseract, which results. When the reporter does not report within the specified
performs matching and executes trades within TEE. When time frame, Augur shifts the role of a designated reporter on
users want to sync with the on-chain state, they ask Tesser- a first-come-first-serve basis. After reporting the outcome, the
act to generate settlement transactions. Since decentralization Augur users have a specific time frame to run a decentralized
would be impacted by using a single service of Tesseract, dispute resolution, and thus obtain a different outcome of
which might censor user requests, the authors incorporate the the event in the case of misreporting. Augur incentivizes its
Paxos consensus protocol among multiple mutually untrusted users to report correct outcomes and file disputes only in
Tesseract nodes; this also increases the fault-tolerance and
avoid funds of users becoming stuck in contrast to one instance 30 https://gnosis-pm-contracts.readthedocs.io/en/latest/

of Tesseract. We note that censorship evidence (not resistance) 31 https://www.oraclize.it/

 22

Prediction V: Conflict T: False Data Feeds D: Incentives

Markets of Interest (Malicious)

D: Reputation Systems

V: Relying on T: False Data Feeds D: Authenticating Feeds

a Trusted Party (Malicious or Inadvertent) by Trusted HW

Centralized Data V: Centralized D: Use Oracle Networks

Oracles T: Availability Attacks
Feeds Design or Prediction Markets

V: Public Visibility D: Encryption by PK of

T: Privacy Leakage
of Parameters Trusted HW

V: Public Visibility T: Freeloading D: Commitment

of Results Attacks Scheme

V: Inherited from T: Inherited from D: Inherited from

Oracle Networks
Consensus Layer Consensus Layer Consensus Layer

Figure 18: Vulnerabilities, threats, and defenses of the oracles category (application layer).

justified cases by rewards and deposit-based bonds. Another otherwise. The reputation points serve as a stake in the
example of prediction markets is Apollo from Gnosis, which consensus protocol of the oracle network, hence the higher
had originally a centralized data source facilitated by Gnosis a node’s reputation, the higher the chance that it produces a
but was replaced by a decentralized one in version 2.0. block. Since more witnesses might become block producers,
Centralized Data Feeds. Oraclize enriches the data provided Witnet allows multiple chains in parallel, forming a DAG.
to smart contracts by authenticity proofs that are built upon 1) Security Threats and Mitigations: We present a
various technologies such as auditable virtual machines and taxonomy of vulnerabilities, threats, and defenses related to
trusted computing. Since authenticity proofs can be large, Ora- the oracle category in Figure 18. In the following, we describe
clize can store these proofs in the distributed file system IPFS32 these threats as well as possible defense techniques.
instead of directly providing them to the smart contracts. Town Prediction markets may suffer from conflict-of-interest
Crier [202] is an approach that provides authenticated data since the creator of the market specifies a data reporter, who
feeds to smart contracts by bridging them with public webs might also participate in the market and later report false
through a TEE component. A linkage of TEE with a smart data for her convenience. Since a prediction market might
contract is made by storing a public key (PK) of TEE at the yield significant financial value for the users with a “correct”
smart contract of Town Crier. It relies on the X.509 public guess, the malicious reporter might bribe other reporters of
key infrastructure (PKI), due to which, the provided data are dispute resolution round and still be profitable. Therefore, the
provably authenticated. PDFS [199] allows content providers incentive protocols of prediction markets must count on this
to link their web resources with corresponding smart contracts situation and incorporate feasible rewards for honest reporters.
in the blockchain. In PDFS, the data of content providers are Another mitigation for similar attacks is to keep reporters
managed in an auditable manner, enabling publicly-verifiable accountable and maintain their reputation in a decentralized
data transparency and consistency of data with the past. fashion (Section IX-B), which involves identity management
Besides content providers, PDFS introduces two entities that and verification (see Section VIII-E).
arrange a smart-contract-based agreement by specifying a par- Centralized data feeds rely on a trusted party [199],
ticular content provider required for the execution of the code [205] that may misbehave or accidentally produce wrong
in the agreement. To ensure that updates are consistent with data. For both cases, decentralized identity management can
the past, the authors apply a history tree data structure [204]. bring accountability while reputation systems further build
The authors additionally support the means to publicly prove on it, which disincentivizes malicious behaviors. Another
censorship by a content provider. option to cope with possible misbehavior of a trusted party
Oracle Networks. ChainLink [200] builds on top of existing of oracle service is to embed the logic of oracle service into a
blockchains with support for smart contracts, and it distributes TEE component [202], whose code is publicly attested. TEE
the provisioning of data feeds to multiple oracle providers. component can interact with the external world using X.509
In detail, ChainLink maintains oracle providers and their public key infrastructure (PKI), due to which obtained data
reputation, who are selected by a smart contract based on their are provably authenticated. Since some requests of data feeds
reputation to form an aggregated final result. When building might contain private parameters,33 they can be encrypted by
the final result, ChainLink discards outliers and utilizes the a PK of the TEE and further processed within TEE that com-
BFT protocol to reach a consensus on a final aggregated municates with its remote data provider through an encrypted
value. Witnet [203] is an approach similar to ChainLink but channel, while communication is facilitated by oracle’s service
in contrast to ChainLink, Witnet runs its own oracle network operator, as demonstrated in Town Crier [202]. Centralized
with a native token. Witnesses (i.e., content providers) earn data feeds might be subject to attacks on availability, leading to
reputation points when the content that they deliver matches interrupted service. A mitigation technique is to use solutions
with the majority’s content, and they lose reputation points with a higher redundancy, such as oracle networks.
32 https://ipfs.io/ 33 All transactions of permissionless blockchains are visible to public.
 23

Fully Replicated V: High Network T: Exhausting

D: Partial Replication
FSs with Ledger Expansion Factor Storage

V: Missing Accountability T: Tampering

D: Involve Ledger
and Non-Repudiation Attacks
Partially Replicated
FSs without Ledger T: Sybil Attacks on D: Unique Encoding of
Duplicate Storage Each Data Copy
(Proof-of-Replication)
Filesystems T: De-Duplication D: Time Constraints on
Attacks Delivery of Response
(Proof-of-Replication)
Partially Replicated V: Replication Design T: Outsourcing
FSs with Ledger Attacks D: Non-Outsourceable
of FSs
Scratch-Off Puzzles
T: Generation D: Multiple Consensus
Attacks Nodes for a File Upload
Centralized Storage
of Off-Chain Data`
T: Availability Attacks
& Dropping Data D: Erasure Encoding

V: Reliance on Provider’s D: Use Replicated

Cloud Services T: Availability Attacks
Infrastructure Decentralized FSs

Figure 19: Vulnerabilities, threats, and defenses of the filesystems category (application layer).

Oracle networks eliminate trust in a single party by running Fully Replicated FS with Ledger. A naive approach is to
a consensus protocol either natively [203] or utilizing an store the full content of data at the blockchain, and thus
existing smart contract platform to facilitate the service and achieve full data replication, extremely high data durability
its consensus [200]. Running the native consensus protocol of (i.e., availability of data) as well as network expansion factor
an oracle network imposes the security threats related to the (i.e., storage overhead). An example is storing data using
consensus layer (see Section VI). Specific threats to oracle the instruction OP RET U RN in Bitcoin or storing data
networks are freeloading attacks, in which an oracle provider as key:value pairs within Namecoin.34 However, such an
might copy a publicly visible value provided by other oracles approach results in high storage overheads required for full
without any effort. The authors of ChainLink [200] propose replication of the data among the consensus nodes.
the usage of a commitment scheme to cope with this attack. Partially Replicated FS with Ledger. To decrease the costs
2) Side Effects and Implications of Countermeasures: while preserving reasonable durability, partial replication of
The data provision time of prediction markets may be too long the data with erasure encoding is often used (e.g., Perma-
for many applications, and they are convenient to use only for coin [78], Storj [206], and KopperCoin [207]). In erasure
specific use cases that are limited to provided data events. encoding, the data block is encoded using two numbers (k, n),
The data provision time is prolonged even more in the case of where n represents the number of total erasure shares and k
disputes, whose resolution may require several days or weeks. represents the minimum number of shares required for data
In contrast to limited data of prediction markets, centralized recovery. Permacoin incorporates Proof-of-Retrievability in the
data feeds enrich the data domain and significantly shorten the consensus layer, where consensus nodes store large segments
provisioning time. of data provided by an authoritative file dealer. KopperCoin
In the case of oracle providers that offer authenticated data follows a similar approach, but it does not need the trusted
feeds using trusted hardware [205], [202], a vulnerability in dealer for the initial distribution of data files since files are
trusted hardware (caused by a manufacturer) may result in the uploaded by the users. Storj uses a 3rd party distributed ledger
entire data feed being compromised. As a mitigation technique for storage of metadata, such as file hash, network locations of
to reliance on a trusted manufacturer of TEE, it is possible copies, and Merkle roots of data. Permacoin, KopperCoin, and
to use a quorum of several redundant TEEs from multiple Storj enable probabilistic audits using Proof-of-Retrievability,
manufacturers. which proves that a node stores certain data at the time of
Since ChainLink [200] is an oracle network running over the the challenge. Filecoin is an incentive mechanism of any
public smart contract platform, it imposes significant execution distributed FS (e.g., IPFS), and in contrast to previous works,
costs. To reduce the on-chain cost of BFT execution, the it can guarantee the data possession over a certain time
authors discuss the use of threshold-based signatures for col- range in a setting of Proof-of-Spacetime. Moreover, Filecoin
lective off-chain signing of the final value; however, freeload- uses Proof-of-Replication [208], which guarantees physically
ing attacks remain unresolved. When freeloading attacks are unique copies of data for each node.
resolved by a commitment scheme, it negatively impacts the
Partially Replicated FS without Ledger. IPFS and Swarm35
provisioning delay and costs for data providers, who have to
utilize the concept of distributed hash tables (DHT). DHT
submit another transaction with a commitment.
provides a decentralized data lookup service with key:data
mappings, in which the set of nodes storing the data is
D. Filesystems unambiguously determined by the key associated with the
Filesystems (FS) serve as a distributed data storage infras-
tructure that borrows ideas from peer-to-peer storage systems, 34 https://bit.namecoin.org/

while additionally incentivizing data preservation by tokens. 35 https://swarm-guide.readthedocs.io/en/latest/

 24

data (i.e., its hash). Since the lookup service and data storage attacks, on the other hand, it imposes higher overheads for
are (partially) distributed, a change in the set of participants file distribution on clients, which might negatively influence
causes only a negligible disruption of availability. IPFS does the throughput of data. Similarly, additional overheads on the
not contain any incentive mechanism and the availability of client during the file upload is imposed by the use of multiple
the data is dependent on its popularity. Although IPFS does consensus nodes for file upload. Although erasure encoding
not involve a blockchain, it may achieve its properties. In aims to decrease costs, it must be viewed in a trade-off with
particular, nodes may optionally store a BitSwap ledger that the availability of data that is negatively affected by it.
logs data transfers with other nodes.
Centralized Storage of Off-Chain Data. Alternatively to E. Identity Management
decentralized filesystems, decoupling of the data from the Identity management refers to binding identities of entities
blockchain itself through the storage of on-chain integrity to their public keys. This concept is also referred to as Public
proofs (see Section VIII-F) and off-chain data is also an Key Infrastructure (PKI), and it has a few security goals [209]:
option; however, it introduces a single-point-of-failure and Accurate Registration: The user must be unable to register
thus may not provide sufficient availability. Besides centralized an identity that she does not own.
storage of data, cloud services are promising approaches for Identity Retention: The user must be unable to impersonate
decentralized yet manageable data storage, for which integrity an identity already registered.
and consistency proofs are stored on some blockchain. Censorship Resistance: The user must be able to register any
1) Security Threats and Mitigations: We present a identity that she owns.
taxonomy of vulnerabilities, threats, and defenses related to In computer science, some have conjectured that it is highly
the filesystems category in Figure 19. While fully replicated unlikely to design an identity management system in which
and partially replicated decentralized filesystems handle avail- identifiers would be selected in a distributed fashion while
ability using decentralized infrastructure, centralized storage remaining secure and human-readable. These three properties
with integrity proofs and cloud services relies on a centralized are often referred to as Zooko’s triangle [210]. However, this
provider. In a Sybil attack on a replicated FS, a malicious situation has been changed with the invention of blockchains;
node claims the storage of multiple copies of the same data. in particular, their immutability feature (Appendix A1).
Similarly, in a de-duplication attack, more consensus nodes Namecoin36 is a native blockchain that facilitates identity
may collude to claim that each of them is storing an indepen- management since it allows for the unique registration of
dent copy of the data, while only one of the nodes stores the key:value mappings. However, searching for a value associated
data. These attacks can be prevented by a unique encoding with a key requires full storage and traversal of the blockchain,
of each data copy proposed in Proof-of-Replication [208]. In which is costly. Blockstack [211] is a similar approach as
an outsourcing attack, a malicious consensus node claims Namecoin, providing decentralized DNS, but in contrast to
the storage of more data than it can physically store while Namecoin, it off-chains the data storage of domain name
relying on data retrieval from outsourced data providers. In mappings and keeps only references to hashes of zone-files in
a generation attack, a malicious node can re-generate the its blockchain. Zone-files (and their referred DNS entries) are
previously uploaded data upon request using some algorithm, stored off-chain. Certcoin [209] is built on top of the Namecoin
which may increase its chances to be rewarded: a node might blockchain, where entities publish their public keys (PK)
commit to storing of a huge volume of generated data. by posting an identity-PK pair to the Namecoin blockchain.
On top of the unique encoding of each data copy, a Certcoin utilizes cryptographic accumulators, which represent
mitigation technique for outsourcing and generation attacks a space-efficient data structure that supports the verification
is to put time constraints on the delivery of the response by of set membership within the {ID, P K} domain, imposing
a prover, as proposed in Proof-of-Replication [208]. In detail, only a logarithmic time complexity in the number of registered
the function used for the encoding of data replicas must not users (in contrast to linear time complexity of Namecoin). Fur-
be parallelizable (e.g., symmetric encryption in CBC mode) to thermore, to speed up the PK lookup queries, Certcoin lever-
mitigate generation attacks. In the case of outsourcing attacks, ages the concept of DHT (see Section VIII-D), which enables
the time constraints must distinguish whether cloud access it to achieve a constant lookup time complexity. Ethereum
was made or not. Similar mitigation for outsourcing attacks Name Service37 (ENS) maps human-readable domain names
is the use of non-outsourceable scratch-off puzzles [78], [60], to Ethereum addresses in a similar fashion as in DNS. The
in which the computation of the puzzle requires access to the root domain of ENS is maintained by a multi-signature smart
storage in random order; hence, many round-trips are incurred contract owned by trustworthy individuals from the Ethereum
during one attempt of solving a puzzle. Another attack might community. Similarly, uPort [212] utilizes smart contracts to
target the reputation of a network by dropping data and its keep a registry that maintains a mapping of the user addresses
redundant copies. A simple mitigation technique is to use to hashes of claims38 that are stored off-chain. In contrast to
multiple consensus nodes for a file upload, which diminishes ENS, uPort does not provide human-readable user identifiers
the chance of the attack being successful. Another mitigation and discusses the possibility of using ENS as a naming layer.
is to increase the durability by erasure encoding.
36 https://www.namecoin.org/
2) Side Effects and Implications of Countermeasures: 37 https://ens.domains/

Although unique encoding of each data copy thwarts several 38 Claims as such belong to the notaries category (see Section IX-D).
 25

T: Violation of Security D: Oracles for Delivery the first time. These two strategies stand for auctions and
Goals of Identity Data

D: Auctions algorithmic fees, both having their respective cons. Auctions

for Primary Market
V: Unverified Mapping
are problematic since they may be initiated at any time, and
T: Cyber-Squatting Attacks D: Algorithmic Fees
of Names to Values (for Human Readable IDs) for Primary Market some potentially interested bidders might not be available.
D: Use Non-Human
Readable IDs
An improvement is to specify a fixed time when auctions
V: A Nature of Shared
T: Front Running Attacks
D: Commitment Scheme start. Another approach for coping with cyber-squatting is an
Public Network in Requests for Names
Identity
Management
algorithmic fee solution, which assigns the price based on
D: Off-Chaining Data
V: Public Data on
T: Privacy Issues
the deterministic observables, such as length of the name, a
Blockchain D: User-Level
Encryption rank of the domain, occurrence of human-readable words, etc.
D: Fully On-Chain Nevertheless, this approach may require a data feed provider
Systems
V: Reliance on
T: Availability Issues
D: Partially Replicated
(see Section VIII-C). In contrast to human-readable identifiers,
Provider’s Infrastructure Decentralized FSs
(for Off-Chain Systems) non-human readable identifiers, such as DIDs, do not suffer
D: On-chain Censorship
T: Censorship
Resolution from the cyber-squatting threat.
Figure 20: Vulnerabilities, threats, and defenses of the identity
Another challenge is a front-running attack (i.e., a MITM
management category (application layer). attack), in which an adversary may intercept and override the
user’s transaction with a malicious transaction containing the
Smart contracts for managing identities of humans, groups, same domain name but a higher fee. A prevention technique
objects, and machines are also used in the ERC 725 standard,39 is a variant of the commitment scheme where the user first
in which, identity is associated with several keys serving publishes a sealed (domain) name and public bid, while in the
various purposes. ShoCard [213] is another example that builds second step she submits the plain text of the name.
on top of existing public blockchains, but in contrast to the Further, identity-related user data that are published on the
previous examples, it builds a sidechain containing encrypted blockchain are subject to certain privacy issues. Mitigation
identity-specific data such as biometric data, scans of IDs, is to keep only integrity information (such as hashes) on
etc. The user may then decide to whom she will reveal the the blockchain, while data should be stored off-chain [213],
encrypted data. The Sovrin [214] is an example providing [211], [212] or encrypted by the user’s private key [213].
a public permissioned blockchain that consists of consensus Moreover, all the approaches that rely on off-chain storage
nodes approved by Sovrin. It focuses on high throughput and and service provisioning are vulnerable to availability is-
low operational costs. Decentralized Identifiers (DIDs) [215] sues (e.g., [212], [215]) and censorship attacks (e.g., [214]).
represent a new type of universally unique identifiers whose Mitigation that provides censorship evidence is an on-chain
control is decentralized since all roots of trust are contained censorship resolution [198].
in the blockchain and each entity might create its own root of 2) Side Effects and Implications of Countermeasures:
trust. DID employs the same hierarchical scheme for globally Side effects of oracles depend on their category, and we
unique strings as URI, and it maps strings to DID documents mention them in Section VIII-C. If a beginning time of the
containing data such as PKs, endpoints of the entity, or links to auctions on the primary market is fixed, bidders can be DoS-
off-chain data. Only the owner can create, manage, and prove ed and prevented from bidding. Anonymization networks and
ownership of her DID entries. VPNs used by bidders might mitigate this problem. While off-
1) Security Threats and Mitigations: We present a chaining of identity-related data helps to cope with privacy
taxonomy of vulnerabilities, threats, and defenses related to issues and decreases operational costs, on the other hand, it
the identity management category in Figure 20. As mentioned means dependency on centralized storage, which negatively
by Kalodner et al. [216], most of the solutions address the impacts the availability of data. Possible mitigations are par-
problem of mapping names to values but for identity manage- tially replicated decentralized filesystems (see Section VIII-D).
ment, it is essential to build a mapping of entities (i.e., persons,
companies) to values. However, to establish such a mapping F. Secure Timestamping
in a trustworthy way, a human arbitration or a trusted party is The role of secure timestamping is to prove that some data
needed. For this purpose, oracles (see Section VIII-C) might existed prior to some point in time – also referred to as proof-
deliver verified data about the identity of users. of-existence. In the decentralized setting of blockchains, the
Since the space of human-readable IDs is scarce, they hold blockchain serves as a trusted notary that enables such proofs
some market value in contrast to an almost infinite number of since it provides immutability of the history. Nevertheless, the
non-human-readable IDs, such as hashes. This opens a door blockchain “does not understand” the semantics of data that
to cyber-squatting attacks, in which anybody might seize an are timestamped, and thus it cannot vet or certify them.
ID that does not belong to her and then sell the ID in the The simple examples of secure timestamping are Com-
secondary market at an inflated price. Kalodner et al. [216] mitCoin [217], STAMPD,40 Bitcoin.com Notary,41 and Ori-
found in 2015 that from around 120, 000 registered names in ginStamp [218], all enabling to post a document’s hash
Namecoin, only 28 were not squatted and had human-readable into a single blockchain transaction. OpenTimestamps42 and
content. They discussed two strategies to prevent such attacks
40 https://stampd.io/
within the primary market, in which names are issued for
41 https://notary.bitcoin.com/
39 https://erc725alliance.org/ 42 https://opentimestamps.org/
 26

V: Inaccuracy and D: Timestamping

Imprecision
T: Disputes Requiring
Authorities
A. E-Voting
Time Accuracy
of Timestamps
D: Partial Solutions for
Timestamp Computation Kiayias et al. [219] and Groth [220] state several properties
T: Disputes Requiring (Consensus Layer)
Secure Timestamping V: Aggregation Delays
Finer Time Granularity
D: One Transaction per
that are desirable in e-voting applications:
Hash of Record
Perfect Ballot Secrecy: implies that finding partial results
V: Offline Storage D: Decentralized
T: Availability Attacks
of Timestamped Data Filesystems (i.e., partial tally) before the voting finishes is possible
Figure 21: Vulnerabilities, threats, and defenses of the secure only if all voters are involved in its computation.
timestamping category (application layer). Fairness: the final tally can be computed only when all
participants already had a chance to cast their vote.
POEX.IO43 are examples that define a set of operations for Public Verifiability: any public observer can verify the valid-
creating timestamps and their verification as part of a Merkle ity of all votes and final tally. This is achieved by using a
tree that aggregates hashes of timestamped objects. The root public bulletin board (e.g., blockchain). A consequence of
of the Merkle tree is then stored in the blockchain and later the public verifiability is dispute-freeness, i.e., the result
used for verification of timestamped data. of the voting is indisputable.
Self-Tallying: once the voting stage has finished, anyone
1) Security Threats and Mitigations: Figure 21 depicts
can compute the final tally. This property together with
a taxonomy of vulnerabilities, threats, and defenses related to
fairness ensures that the last voter is unable to compute
the secure timestamping systems. Since these systems have
the tally before casting her vote.
a narrow principle of operation and provided functionality,
Fault Tolerance/Robustness: a voting protocol is able to
their attack surface is very limited, too. The main security
recover from a fixed number of faulty voters who do not
threats stem from inaccuracy and imprecision of timestamps
vote or whose vote is invalid.
provided by blockchain network as well as aggregation delays
Receipt-Freeness: a participant is unable to supply a receipt
of certain secure timestamping services. As a consequence,
of her vote after casting the vote. The goal is to prevent
the result of certain disputes might be influenced. A possible
vote-selling and post-election coercion.
mitigation technique to improve the accuracy of timestamps
E-voting [221], [222] has tried to mimic many of the security
is to use timestamping authorities [65] or partial solutions for
properties provided by paper voting. In decentralized e-voting,
block timestamp computation [18].44 A mitigation technique
the protocol is carried out in phases and requires a multiparty
for long aggregation delays is to employ timestamping au-
computation (MPC) [219], [220] executed by the voters. De-
thorities or use one transaction per hash of the timestamped
centralized voting involves an interaction among participants
record. Another class of attacks concerns the availability of
and is less robust concerning fault tolerance – i.e., if voters
timestamped data, for which decentralized filesystems might
drop out midway, a recovery round has to be initiated. The
be utilized as a mitigation technique while storing data in
main advantages of using the blockchain for e-voting are its
encrypted or plaintext form (depending on the use case).
immutability, public verifiability, enforcing protocol rules by
2) Side Effects and Implications of Countermeasures: the smart contract, and higher availability [223].
Although one transaction per hash of a timestamped record An example of a decentralized e-voting is the Open Vot-
mitigates the impact of aggregation delays in solutions such ing Network (OVN) [224], which for the first time utilizes
as OpenTimestamps and POEX.IO, on the other hand, it blockchain as an instantiation of the public bulletin board.
requires a higher amount of data posted to blockchains, and OVN is implemented using Ethereum smart contracts, and it
thus it deteriorates the throughput and imposes higher costs. enables boardroom voting of up to ∼50 voters with support
Therefore, the choice of either an aggregated solution or a for two choices. OVN requires the authority to initialize
single hash per record depends on a particular use case. e-voting, compute multiparty keys from data submitted by
voters, and reveal the result of the final tally. However, the
authority is unable to influence the outcome of voting or
IX. A PPLICATION L AYER : H IGHER -L EVEL A PPLICATIONS
compromise the privacy of voters (i.e., cast votes). Although
In this section, we elaborate on more specific higher- OVN preserves the privacy of voters and provides self-tallying,
level applications as opposed to ecosystem applications. In it does not provide receipt-freeness. OVN uses deposit-based
detail, we deal with the following categories: (1) e-voting, penalties to incentivize the authority and voters to actively
(2) reputation systems, (3) data provenance, (4) notaries, participate. Zhang et al. [225] present a distributed e-voting
(5) direct trading, (6) escrows, (7) auctions, and (8) gen- scheme that uses the blockchain, but the proposed protocol
eral application of blockchains. We describe each of the (like OVN) does not provide a fault tolerance – a restart
categories, present a few examples, and then summarize the of voting is required if any voter does not cast her vote.
potential security vulnerabilities, threats, and defenses. For This enables sabotaging of the voting process by a single
other detailed reviews of blockchain applications, we refer the malicious voter. Venugopalan et al. [226] propose a boardroom
reader to Casino et al. [11] and Zheng et al. [12], which in voting over Ethereum, which supports n voting choices and
contrast to our work follow domain-oriented classification. provides a fault tolerance mechanism. Li et al. [227] propose
an approach that assumes an interactive honest verifier for
43 https://poex.io/ the zero-knowledge proof presented; however, the verifier can
44 Note that this is a countermeasure specific to the consensus layer. select a biased challenge, which enables collusion of the
 27

V: Lacking Fault T: Non-Voting D: Fault-Tolerant 2) Side Effects and Implications of Countermeasures:

Tolerance Voter Saboteur Protocols
Receipt-free voting protocols can protect against vote-selling
V: Mis-Aligned T: Non-Voting D: Deposit-Based
Incentives Colluding Voters Bonds or coercion but on the other hand, they imply additional
V: Unmanaged Voting
in Permissionless
T: Double Voting D: Use Trusted computational overhead for voters, which increases the cost
(Sybil Voting) Authority
Blockchains of running a decentralized protocol. Although authority can
T: Censoring of D: Use Identity
Voters Management Solution prevent double voting, it is trusted with managing voters hon-
V: Authority as a Single- and Eliminate Authority
E-Voting
Point-of-Failure
T: Disruption of the
estly and completing all actions required for progressing the
Protocol by Authority D: Replace Authority by
an Arbitrary Voter protocol from one stage to the next stage (e.g., [224], [226]).
V: Absent Receipt-
Freeness
T: Vote-Selling However, the authority represents a single-point-of-failure,
D: Receipt-Free Voting
T: Post-Voting Protocols since it might disrupt the execution of the protocol. Deposit-
Coercion
V: Violation of Security
based bonds can be employed as a mitigation technique, or the
T: Inherited from D: Inherited from
Goals in Identity
Management Identity Management Identity Management authority can be replaced by an arbitrary voter for the purpose
V: Absent Self-Tallying T: Premature Tally D: Commitment Scheme of execution of the voting protocol (but not for managing
for the Last Voter Computation for Votes
voters). Regarding the management of voters, an important
Figure 22: Vulnerabilities, threats, and defenses of the e-voting threat is the possibility that the authority might censor some
category (application layer). eligible voters. A solution for eliminating the authority (or a
delegation of this problem to a different application type) is
verifier and the authority. permitting voters to vote upon successful registration of their
identities within a certain identity management application
1) Security Threats and Mitigations: We present a
(see Section VIII-E). Fault-tolerant voting protocols impose
taxonomy of vulnerabilities, threats, and defenses related to
additional overheads, where all remaining voters must actively
the decentralized e-voting category in Figure 22. The first
participate in the recovery round – this implies additional costs
e-voting-specific group of threats represents vote-selling and
on such voters, and it slows down the protocol. Similarly, a
post-voting coercion. In vote-selling, the voter can prove to
commitment scheme for coping with violation of self-tallying
a briber that she voted as agreed, while in post-election
in the case of the last voter implies additional overheads and
coercion the voter is coerced to show her vote by decryption
costs for a dedicated commitment stage.
of the blinded vote. Mitigation is to use receipt-free voting
protocols that thwart both attacks [228], [229]. Existing solu-
tions for achieving receipt-freeness assume a secret channel B. Reputation Systems
(bi-directional [228] or uni-directional [230]), use deniable Reputation systems commonly serve as a means to (1) mea-
encryption [231], [232], or employ randomizers [233]. sure the level of trust in particular entities that provide a certain
The next threat is double-voting (with Sybil accounts) service, (2) verify claims of user achievement or authenticity
in the case of unmanaged public voting in permissionless of issued counter-party/ownership tokens. The reputation is
blockchains. To prevent double-voting and ensure that only usually quantified based on the voting of parties/users that
eligible voters can vote, it is usually required that a voting independently analyze the history of interactions/records pro-
authority permits voters to vote.45 Another issue is a pos- duced by entities in a reputation query.
sibility of voters not voting despite enrollment, resulting in In reputation assessment, there are two options to determine
the sabotage of the voting round (possible in [220], [225], the eligibility to rate. In the first option, an arbitrary legitimate
[224]) or privacy issue related to more fine-grained inference participant can rate a product that she has bought or a service
of the actual votes of the remaining voters who voted. Deposit- that she has consumed. In the second option, only a limited
based bonds might be employed as penalties for saboteurs and number of selected participants can vote on the authenticity
disincentivize such behaviors [224]. Another countermeasure of individual records (e.g., accreditation). In reputation-based
for saboteurs is a fault-tolerant voting protocol (e.g., [234], systems, identity management is two-fold since the identity of
[226]), in which the remaining honest voters can recover the both voters and the record owners/merchants/service providers
final tally even without votes of saboteurs. Since e-voting needs to be verified.
might assume verified identities of all participants, the next Rating by Arbitrary Participants. A privacy-preserving
group of threats that is worth noting is inherited from identity reputation system for e-commerce was proposed in [235]. The
management (see Section VIII-E). authors utilize blinding signatures and merchant-issued tokens
The last threat relates to the self-tallying property, which to achieve the privacy of reviews and avoid bad-mouthing and
might not hold if no countermeasure is applied, as the last ballot-stuffing attacks. A feedback-based reputation approach
participant can compute the tally and only after that decide on that utilizes the incentive-based scheme of the Bitcoin network
her vote. Simple mitigation is to use an additional “dummy” is proposed in [236]. In this approach, any consumer might rate
participant that is handled by the voting authority. Another the service of the producer, while obtaining a voucher for the
solution is to enforce participants to first commit to their votes feedback. Zhao et al. [237] propose a reputation management
and then cast the committed votes in the later stage [224] scheme that utilizes additive secret sharing to achieve the
privacy of participants in reputation assessments.
45 This is represented by know your client (KYC) compliance, and it is Rating by Several Selected Participants. An example of such
related to the principles of permissioned blockchains. a reputation-based application is related to accreditation of
 28

V: Missing Sybil D: Filtering Legitimate T: Compromising

T: Bad-Mouthing V: Vulnerable Data D: TPMs
Protection Participants Devices & Stealing
Producers (IoTs)
Secrets
D: Host-Based Intrusion
V: Design of the D: Spending
T: Ballot-Stuffing Prevention (HADES-IoT)
Reputation Incentives in Protocol Resources
Systems
T: Data Availability D: Convenient Decen-
V: Missing or Insuffi- D: Oracles for Delivery Issues tralized Filesystem
T: Whitewashing
cient Identity Checks of Verified Identity Data

D: TEE for the Logger

V: Inherited from T: Inherited from D: Inherited from
E-Voting E-Voting E-Voting
Data V: Centralized T: Tampering with a D: Log Extension by
Provenance Infrastructure Log by the Logger a Smart Contract
Figure 23: Vulnerabilities, threats, and defenses of the reputation
systems category (application layer). D: Audits by Data
Producers or Auditors

T: Censorship by D: On-Chain Censorship

educational institutions by other higher-level institutions and the Logger Resolution

organizations [238]. V: Inherited from T: Inherited from

D: Inherited from
Identity Identity
Identity Management
1) Security Threats and Mitigations: We present a Management Management

taxonomy of vulnerabilities, threats, and defenses related to Figure 24: Vulnerabilities, threats, and defenses of the data
the reputation systems category in Figure 23. Specific security provenance category (application layer).
threats to reputation systems with an arbitrary number of
legitimate participants are bad-mouthing, ballot-stuffing, and provenance assumes known verified identities of the involved
whitewashing attacks [235]. In bad-mouthing attacks, the parties.
customer (e.g., competitor) lies about the product or service, An application of data provenance is supply-chain man-
while in the ballot-stuffing attacks, the service provider might agement [240], [241], where the goal is to resolve potential
increase her reputation by herself. Bad-mouthing can be issues in the traceability of goods and provenance of associated
mitigated by filtering only authorized participants to submit data [242]. Blockcloud is an approach that utilizes blockchains
reputation assessments (e.g., by review tokens [235], [236]). for data provenance in cloud computing [243]. The authors aim
Although bad-mouthing cannot be completely prevented, it at the accountability of data creation and manipulation with
requires participants to spend resources (e.g., buying a product the intention to detect malicious insiders and intrusions. The
or paying transaction fees) to be eligible for rating a service idea of using the blockchain for tracking packages and mails
provider. Similarly to bad-mouthing, the ballot-stuffing attack as part of supply chain management was proposed in [244].
cannot be eliminated but only mitigated by requiring to spend ChainAnchor [245] is a framework for the commissioning and
resources (i.e., tokens) for each rating entry. If a service decommissioning of IoT devices in a cloud-based ecosystem.
provider accumulates a significant negative reputation, it has In a commissioning procedure, devices prove their manufac-
an incentive for a whitewashing attack – the service provider turing provenance to a verifier in a privacy-preserving fashion
creates a new service with a neutral reputation, which is un- without a need for interaction with the manufacturer. An
linkable to her previous service. To mitigate this attack, oracles additional goal of ChainAnchor is to reward owners of IoT
for obtaining verified data about identities of entities can be devices for sharing data in a privacy-preserving manner. A
employed, possibly as part of the identity management system. data provenance approach that focuses on the integrity of IoT-
Since reputation systems resemble e-voting in general, generated data is proposed in [246]. A framework to achieve
concerning security threats are inherited from there (see data provenance of multimedia objects such as artworks and
Section IX-A) and its dependency on identity management books was proposed in [247]. The authors use watermarking
(Section VIII-E). In particular, only authorized participants are techniques to embed transaction metadata of objects into the
allowed to participate in the voting process and no duplicate objects themselves to prove data tampering.
votes are allowed (ensured by identity management), while Catena [248] guarantees a non-equivocation of its append-
the votes/ratings should remain blinded (ensured by e-voting) only log and relatively low storage overheads (i.e., storing
unless the particular use case requires otherwise. all the blockchain headers). The hash of each off-chain data
2) Side Effects of Countermeasures: Since some block is added to the append-only log of Catena as a single
countermeasures in reputation systems are inherited from transaction, which is bound to the previous Catena transaction.
the e-voting and oracles categories, the side effects are also The same method of binding consecutive transactions in an
inherited from these categories. append-only log was utilized in Contour [249]. In contrast to
general Catena, Contour focuses on non-equivocation during
the distribution of open-source software packages by a spec-
C. Data Provenance ified authority. Grech and Camilleri [238] elaborate on the
Data provenance represents the ownership history of an usage of blockchain for the issuance of educational certificates
arbitrary object. However, in the cyber-world, objects are rep- by academic institutions. Such certificates might be issued by
resented by data that can be changed, and thus the history must institutions whose identities are verified (see Section VIII-E).
account also for the modifications [239]. Data provenance with 1) Security Threats and Mitigations: We present
the use of blockchains has the potential to resolve various a taxonomy of vulnerabilities, threats, and defenses related
disputes and issues related to intellectual property, authorship, to the data provenance category in Figure 24. Since data
the validity of certificates or other issued documents, etc. Data provenance infrastructure might involve simple IoT devices
 29

V: Inaccuracy and
and sensors that are often not updated nor physically protected, Imprecision
T: Inherited from D: Inherited from
Secure Timestamping
Secure Timestamping
of Timestamps
it is important to ensure that these devices are tamper-proof Notaries
and no secret can be stolen from them. As a countermeasure, V: Violation of Security
T: Inherited from D: Inherited from
Goals in Identity
Identity Management Identity Management
Trusted Platform Modules (TPMs) may be used if they are Management

available. We note that the current trend is to involve TPMs in Figure 25: Vulnerabilities, threats, and defenses of the notaries
the hardware of contemporary IoT devices. However, TPMs category (application layer).
are often not available in numerous legacy IoT devices. In
such cases, it is possible to leverage kernel-space and user- where, all ownership transfers can be executed without any
space memory isolation as part of the intrusion prevention trusted party, but the trusted party is required for introducing
system (e.g., [250]). Another vulnerability originates from the initial ownership record to the blockchain. The own-
a possible centralized logger component of data provenance ership register for vehicles was proposed by Notheisen et
solutions (e.g., [248], [249], [251], [252]). Hence, availability al. [259], where trusted third parties, such as police depart-
issues for data storage must be considered and possibly ments and transport authorities provide and verify vehicle-
resolved by a convenient decentralized filesystem approach specific information. SilentNotary47 is a smart contract-based
(see Section VIII-D). Another threat concerning the centralized system for self-certifying of files produced by registered users.
infrastructure of loggers is the possibility of data tampering PADVA [198] is a Transport Layer Security (TLS) notary
and censorship. Data tampering can be detected by data service realized as a smart contract-based two-party agreement
producers or auditors that do periodic audits [253]. To cope (i.e., Service Level Agreement). PADVA introduces notary
with censorship, an on-chain smart contract-based censorship entities that are obligated to periodically check the validity
resolution can be utilized [198], [252]. of PKs in a specified set of certificates.
2) Side Effects and Implications of Countermeasures: 1) Security Threats and Mitigations: We present a
Although auditors might detect tampering with data by a taxonomy of vulnerabilities, threats, and defenses related to
logger entity, their periodic activity implies high operational the notaries category in Figure 25. Notaries inherit security
costs. A possible option to save such costs is an auditor-free threats related to timestamp accuracy from the secure times-
update of the log using a smart contract [251], alternatively tamping category (see Section VIII-F). In addition, since they
combined with TEE [252] to enforce even stronger properties assume verified identities of involved parties, they inherit
(i.e., the correctness of the execution by logger). However, security issues from the identity management category (see
TEE has also its cons, which we discussed above. Moreover, Section VIII-E). In particular, many notary services assume
since countermeasures of the data provenance category depend a centralized identity management system, which might be
on the identity management and filesystems category, the side subject to tampering or censorship issues. Next, a very specific
effects are inherited from them as well. threat to PADVA is a cheating notary, who quietly does not
run the service periodically or runs it only sporadically. Such
cheating can be revealed by clients on an ad-hoc basis, who
D. Notaries
punish notaries by the smart contract logic that causes notaries
In contrast to secure timestamping, the role of the notary to lose their deposit.
system is not only to prove the existence of documents at cer- 2) Side Effects of Countermeasures: Since security
tain points in time but also to vet and certify documents [254]; aspects in notaries are inherited from the secure timestamping
hence, notary systems assume known verified identities of and identity management categories, the side effects are also
involved parties who do the vetting. In addition to the above inherited from these categories.
two functionalities, the definition of the notary system involves
document preservation, which, however, in the context of the
public blockchain is optional. The involved parties may decide E. Direct Trading
whether to store vetted documents in a database of a notary While blockchain-based cryptocurrencies enable native se-
service provider (e.g., PADVA [198]) or whether to keep it cure transfers of crypto-tokens among their owners, a chal-
privately at the client-side (e.g., Blockusign46 ). lenge arises when owners want to exchange crypto-tokens
A blockchain-based notarization platform on Ethereum was they hold for goods outside of the cryptocurrency blockchain.
proposed in the post [255], where an arbitrary number of This challenge is also referred to as the buyer/seller dilemma:
users/entities with verified identities may sign/approve the “Should the buyer trust the seller and pay her before receiving
documents and their new versions, respectively. The proposal goods or should the seller trust the buyer and ship the goods
assumes a certification authority that verifies the identities of before receiving the payment?” In the direct trading category,
involved entities, and as an example, the authors suggest the this problem is resolved directly between the buyer and
use of the ERC 725 standard [256]. ADVOCATE [257] is seller, without the need for a mediator, under the assumption
an approach for notarization of agreements about personal of a trusted seller with a verified identity. For example in
data processing in IoT between owners of IoT devices and BIP-70 [260], the buyer first verifies the authenticity of the
data processing services – both must co-sign an agreement. seller using its X.509 certificate and then issues a payment
Mizrahi [258] proposes a system for property ownership, transaction.
46 https://blockusign.co/ 47 https://silentnotary.com/
 30

D: Reputation Systems T: Unfair Mediator

D: Reputation Systems
for Seller for Mediators
V: Trust Assumption T: Misbehaving
on the Seller Seller D: Verified Identity D: Group of Mediators
of Sellers T: DoS by
Direct
Trading Mediator
D: Accept only D: Bond by Mediator
V: Accepting V: Single
T: Misbehaving Confirmed Transactions
Unconfirmed Trusted Mediator
Buyer D: Escrowed Value
Transactions D: Consensus Protocols T: Stealing of Escrowed
Transferrable only to
with Fast Finality Value by Mediator
Buyer or Seller

Figure 26: Vulnerabilities, threats, and defenses of the direct T: Revealed Addresses D: Blinding Mediator’s
of Parties to Mediator Next Address
trading category (application layer).
V: Design of the
Escrows Escrow Protocol T: Revealed Addresses
D: Encrypt-and-Swap
of Parties to Public
1) Security Threats and Mitigations: We present a
T: Revealed Addresses
taxonomy of vulnerabilities, threats, and defenses related to of Parties to Public
D: Threshold-Based
Cryptography 2-of-3
in the Case of Dispute
the direct trading category in Figure 26. The first vulnerability
V: Using Unconfirmed T: Double-Spending D: Accept only
represents the assumption of trust in the seller. For example in Payment Transactions of Escrowed Payment Confirmed Transactions
as Checks Transaction by Buyer in the Blockchain
BIP-70, the buyer might ask the seller to interrupt the request
and get a refund but the seller may misbehave, and thus risk Figure 27: Vulnerabilities, threats, and defenses of the escrows
a reputation loss. On the other hand, this might be tolerated if category (application layer).
the seller spoofed her identity. A mitigation technique is to use
a strong means for identity verification, including assessments to avoid DoS by the mediator. Note that blinding of the
from reputation systems. Another attack on BIP-70 that is mediator’s next address hides the execution of the protocol
worth mentioning is the Silkroad trader attack [261], in which to the mediator only in the case when no dispute has arisen.
a malicious buyer might replace her refund address and then Group-Based Mediator. In these protocols, disputes are re-
ask the seller for a refund. After a refund, the buyer might solved by a majority vote. DoS attack is thwarted as long as
plausibly deny receipt of a refund (and ask for a refund again) the majority of mediators is willing to finish the execution of
due to missing authentication on the refund address. Another the protocol. The privacy of some protocols is preserved by
potential attack related to direct trading is double-spending blinding, similarly as in the case of single mediator protocols.
performed as part of the selfish mining or 51% attacks – An example of a distributed marketplace was proposed
therefore, it is important to wait for enough confirmations by in [263], where a marketplace contract lists the products and
the seller before releasing the goods or use consensus protocols an escrow agent contract serves for resolution of disputes by
having a fast finality (see Section VI-A). a mediator (viz. single or group-based mediator). The authors
2) Side Effects and Implications of Countermeasures: discuss the integration of logistic parties with verified identities
Enough confirmations by the seller imply a long waiting time and reputation systems to assess these parties and mediators.
for the buyer before the seller releases the goods and issues OpenBazaar48 is a distributed marketplace that uses smart
a receipt for it. In particular, this might be problematic in the contract-based escrows with 2-of-3 multi-signatures, where the
case of on-premise purchases. The waiting time is dependent mediator is agreed by the buyer and seller. A similar example
on the time to the finality of the underlying consensus protocol, is Escaroo49 but in contrast to Openbazaar, it has its own
and thus a consensus protocol with a low time to finality trusted mediator. Natmin50 is an escrow example that utilizes
represents a solution. However, it is the means of the consensus a public group of mediators for dispute resolution, while the
layer (see Section VI). reputation of the mediators is adjusted according to their votes
and a result of the dispute.
F. Escrows 1) Security Threats and Mitigations: We present a
Escrows address the same problem as direct trading but in taxonomy of vulnerabilities, threats, and defenses related to
contrast to direct trading, escrows do not assume a trusted the escrow category in Figure 27. The first group of threats
seller; instead, escrows outsource the trust into the third refers to a trusted mediator who represents a single-point-
party, referred to as a mediator. The mediator might actively of-failure. The mediator might disrupt the execution of the
participate in the escrow protocol or she might be involved escrow protocol or decide unfairly in the case of a dispute. The
only in the case of a dispute. According to the decentralization existence of these threats depends on the design of an escrow
of the mediator, escrow protocols can be split into single me- protocol. For example, in the Silk Road marketplace [264], a
diator protocols and protocols with a group-based mediator. mediator requests the sending of crypto-tokens to her address,
Goldfeder et al. [262] propose a few escrow protocols from while she is trusted to send the crypto-tokens to the seller upon
both categories, which we briefly review. delivery confirmation from the buyer.51 However, the mediator
Single Mediator. Several proposed protocols contain a single might refuse to do so and keep the value for herself. The
mediator and involve 2-of-3 multi-signatures for splitting mitigation techniques are group-based mediators, requiring a
the control, threshold-based signatures for improving privacy,
48 https://openbazaar.org/
and protocols leveraging homomorphic properties of elliptic 49 https://escaroo.com/
cryptography to achieve privacy (i.e., by blinding the media- 50 https://www.natmin.io/
tor’s next address) and non-interactiveness. Another protocol 51 Instead of a single mediator, the Silk Road marketplace utilized several
combines multi-signatures with bonds deposited by a mediator intermediaries to increase the anonymity of the buyer and seller.
 31

consensus of the majority to decide on a case or requiring Privacy of bids ensures that values of particular bids are not
the mediator to put a bond into the escrow protocol. Another revealed to anybody before committing to them.
mitigation technique is to use reputation systems for the Posterior privacy ensures that all bids remain private after
assessment of a single mediator. the auction ends.
To avoid stealing of the escrowed value by the mediator, Publicly verifiable correctness enables anybody to verify
the protocol should by design allow releasing value only the results of the auction through the blockchain.
to the buyer or seller (using rules of a smart contract), Resistance against DoS ensures that no bidder or auctioneer
while assuming a timeout. For example, an early version of can prematurely abort a protocol without being penalized.
OpenBazaar utilized smart contracts for trading but without The authors of [265] instantiate the auction as a smart contract,
any timeout. As a result, many buyers did not release the to which, bidders submit homomorphic commitments of their
funds to the seller upon successful delivery. However, when a sealed bids and then reveal their commitments to the auction-
timeout is adopted, upon its expiration, a seller can unilaterally eer via a PK encryption. Afterward, the auctioneer deciphers
release and acquire the funds from the escrow. the bids, determines the winner, and announces it to the public
The next class of threats is related to revealing the private while providing zero-knowledge proofs of the correctness.
information about running the protocol to the public or media- As part of their other contribution [266], the same authors
tor (e.g., involved parties, occurrences of disputes). The coun- improved on high costs intrinsic to their former work [265]
termeasures are blinding the mediator’s address, threshold- by using zk-SNARKs and its off-chain computation, which
based cryptography, including its special variant encrypt-and- requires only a single on-chain proof verification of the whole
swap [262], which uses a 3-of-3 threshold signature protocol auction process. However, in both approaches [266], [265], the
that assigns one private share to the buyer and one to the auctioneer might compromise the privacy of all bids, which led
seller, while the third share is known to both parties. Both the same authors to propose Trustee [267], an approach based
parties reveal their private share to the mediator, who, upon on TEE. In Trustee, the bidders submit encrypted bids to the
dispute, provides the winning party with the missing share. auctioneer’s TEE, which confidentially evaluates a winner and
Another possible threat is the double-spending of an un- generates a blockchain transaction proving it.
confirmed escrowed payment transaction by the buyer. For
Strain [268] is an auction protocol that guarantees the
example, if a (naive) escrow protocol requires a mediator to
privacy of bids against malicious bidders and, in contrast
escrow a signed transaction by the buyer and release it to the
to [265], [266] also against the auctioneer. Strain is executed in
blockchain only upon delivery confirmation, the buyer might
four rounds (i.e., four blocks), and it assumes a semi-honest
not confirm delivery and perform a double-spending attack
(i.e., passive) auctioneer who acts as a judge verifying the
(see Section VI). As a prevention technique, unconfirmed
correctness of zero-knowledge proofs. Neither the auctioneer
transactions should not be accepted by the sellers at all.
nor a malicious bidder learns anything about bids of honest
Moreover, we highlight that some escrow protocols (similarly
bidders; however, the order of the bids is leaked to the public.
as atomic swaps) are sensitive to double-spending performed
Strain requires each bidder to commit publicly to her bid,
by the selfish mining or 51% attacks – therefore, in these pro-
while the proposed scheme enables a majority of honest
tocols, it is important to wait for enough confirmations or use
bidders to open other bidders’ commitments in the case that
consensus protocols having a fast finality (see Section VI-A).
they abort the protocol. For the sake of efficiency (i.e., a con-
2) Side Effects and Implications of Countermeasures: stant number of rounds), the authors provide weaker security
Although group-based mediators are more robust to attacks properties in contrast to MPC protocols, where no semi-honest
misusing a trust in a single mediator, they are more expensive judge is required. Finally, the authors propose an extension
to run, requiring the interaction of enough mediators with the of their scheme to support the anonymity of all bidders by
blockchain. This in turn slows down the throughput of the blinding RSA signatures and the Dining Cryptographers (DC)
escrow protocol. The extra operational overheads are also im- network.
posed by the reputation systems for single mediators. Although Another approach that preserves the privacy of the bid
encoding the escrow logic into a smart contract is supported values (but not the privacy of their order) is proposed in [269].
in some implementations (e.g., OpenBazaar, Escaroo), they The protocol requires off-chain interaction for two-party com-
require the deployment of a new smart contract per each putation protocol that performs a pairwise comparison of
trade, which is a costly option. Such logic can be implemented blinded bids among bidders and the auctioneer.
even within a single smart contract. Similar to direct trading,
not accepting unconfirmed transactions implies a long waiting 1) Security Threats and Mitigations: We present a
time for the buyer; this is not the case for the consensus taxonomy of vulnerabilities, threats, and defenses related to
protocols with a fast finality. Finally, using reputation systems the auctions category in Figure 28. There are several possible
brings their security aspects. issues related to privacy leakage in the auction protocols. The
first privacy issue stands for revealing addresses of bidders
and/or order of their bids to the public. For example, the
G. Auctions authors of [265] do not provide anonymity of bidders, since
In auctions, sellers promote the sale of their goods through bidders use their existing Ethereum addresses to interact with
blockchain while buyers place bids for them. Galal and the protocol. A mitigation technique using blinding RSA sig-
Youssef [265] specify several desired properties of auctions: natures and the DC network was proposed in [268]; however,
 32

T: Privacy Leakage of D: Blinding Signatures generated by TEE. Authors also discuss another option to cope
the Order of Bids and and Dining Cryptogra-
their Accounts phers Network with this attack by embedding an SPV client within the TEE
V: Design of the
Auction Protocol D: MPC Protocols
that would evaluate the state of the blockchain; however, this
for Commitments solution would impose a high memory consumption of already
T: DoS by
Any Party
D: Deposit-Based
constrained TEE and would expose TEE to vulnerabilities
Bonds presented in SPV client. Another implication of using TEE-
D: Privacy-Preserving
based auction is the possibility of a local replay attack dis-
V: Auctioneer Has T: Posterior Privacy Integer Comparison cussed in [267], where the auctioneer might provide different
Auctions Values of Bids Leakage of Bids to
in Plain-text the Auctioneer
D: Trusted Computing- instances of TEE with a different subset of the bids, and hence
Based Solutions obtain the values of particular bids. As described in [267],
D: Penalties for such a privacy threat can be prevented by a TEE specific
Misbehavior
V: Centralization T: Censoring of construct called hardware monotonic counter, which cannot
of the Auctioneer Some Bidders
D: Smart Contract-Based be reverted once incremented. Finally, one has to consider that
Censorship Resolution
a vulnerability in trusted hardware may result in the unfairness
Figure 28: Vulnerabilities, threats, and defenses of the auctions of the auction process and compromise of its privacy.
category (application layer).
H. General Applications of Blockchains
network-level attacks on revealing locations/IP addresses of
parties remain possible (see Section V). There are many use cases of applying blockchain to a
Since the auctioneer of some protocols (e.g., [265], [266]) particular domain that contains mutually untrusted partici-
sees the bidders and their bids in plain-text, she might either pants: these participants are represented by consensus nodes
intentionally or accidentally (e.g., an external compromise) executing a consensus protocol. Applications from this cat-
leak these data (and their corresponding proofs) that are egory focus on leveraging inherent blockchain features and
attributable to particular bidders. The protection technique is to sometimes even on non-inherent features (see Appendix A).
An example that uses permissioned blockchain for the man-
avoid the auctioneer from seeing the plain-text of the bids, and
agement of healthcare data is proposed in [270], in which new
instead use privacy-preserving integer comparison (e.g., [268])
data are included in the blockchain upon majority agreement.
or trusted computing-based solutions (e.g., [267]).
Another threat originates from a centralized auctioneer who The consensus nodes of this approach are represented by
might censor some bidders (e.g., due to collusion with another a patient, her family, and healthcare providers. The authors
bidder) by claiming that their bids are invalid, i.e., claiming discuss an issue regarding the right to delete personal data,
that a commitment does not open to the sealed bid. To cope which is contrary to the inherent features of the blockchain. A
with this threat, the auction can utilize a smart contract-based data protection framework for energy grids and power systems
resolution mechanism in which the bidder might prove the op- was proposed in [271]. The authors suggest that smart meters
posite by revealing her value of the bid, causing a penalization act as consensus nodes and store the data of the blockchain
of the auctioneer [265]. Deposit-based bonds and penalization in their memory.52 DistBlockNet [272] is the approach for
of the involved parties can be used as a protection against ensuring state consistency among multiple SDN controllers
abortion of the protocol (i.e., DoS) by any party. For example, with the utilization of dedicated blockchain. In detail, flow rule
the protocol of [265] splits penalties to honest participants in tables of SDN controllers are managed by these controllers,
the case of abortion by some party. Another option to cope while other entities in the system use blockchain as a reference
with the abortion of the auction protocol is to use multiparty point for downloading these tables. A federated permissioned
computation (MPC) for the commitment of sealed bids [268], blockchain used as a cloud-based data storage requiring the
which enables the opening of the commitment of the aborting consensus of all nodes53 is proposed in work [273]. The
party and thus to continue in the auction protocol. authors propose to use two tiers of blockchain. The blockchain
at the first tier is private and serves for consensus of partici-
2) Side Effects and Implications of Countermeasures: pants, while the blockchain of the second tier is public PoW
Although censoring of bids can be prevented by a smart (e.g., Bitcoin) and serves for periodic publishing of integrity
contract-based resolution mechanism [265], it has privacy proofs of the first tier blockchain. Two-tier blockchain was
consequences since it leaks the value of the bid and its also applied in the domain of IoT [274]. The authors of [274]
corresponding bidder. Deposit-based bonds can disincentivize deem the first tier blockchain as local to a group of IoT devices
the abortion of the auction protocol but they require a restart owned by a single party, while the second tier blockchain
of the round. In contrast to it, MPC protocols for commitments serves for sharing the data among multiple untrusted parties.
can recover the current auction round but with additional The authors demonstrate the applicability in a case study
overheads and costs imposed on a smart contract platform. involving several smart homes.
In the case of using a TEE-based solution, the malicious
1) Security Threats and Mitigations: Security threats
auctioneer might perform censorship of some bidders due
of this general category vary case by case and usually concern
to collusion with other bidders. To avoid this threat, the
the privacy of data shared among involved parties [270],
authors of [267] propose a smart contract-based mechanism
that verifies whether the set of sealed bids submitted to the 52 These are unrealistic assumptions.
smart contract corresponds to the list of bids in the proof 53 Note that such a proposal has very low fault tolerance.
 33

[271], [274]. Another common issue is an application of vulnerabilities presented at lower layers of SRA might be
the blockchain with unrealistic assumptions about the target manifested at the same layers (i.e., reflexive dependencies)
environment, e.g., low processing or storage performance of but more importantly, they are manifested at higher layers,
smart meters/IoT devices, no HW support for asymmetric especially at the application layer. For example, context-
cryptography, no tamper-proof means in devices producing sensitive transactions and partial solutions as countermeasures
transactions, etc. Some applications try to optimize throughput of the consensus layer can protect against front-running at-
or finality of the blockchain by introducing their own consen- tacks of intra-chain DEXes, which occur at the application
sus mechanisms (e.g., [274], [273]); however, this might not layer. Another example represents programming bugs in the
be the best option since new attack vectors might be created. RSM layer, which influence the correct functionality at the
A general recommendation is to study and understand security application layer. The eclipse attack is an example that im-
issues and countermeasures of the state-of-the-art approaches pacts the consensus layer from the network layer – a victim
of the consensus layer (see Section VI) as well as privacy consensus node operates over the attacker-controlled chain,
concerns presented at the RSM layer (see Section VII). and thus causes a loss of crypto-tokens by a consensus node
and at the same time it decreases honest consensus power
X. L ESSONS L EARNED of the network. In turn, this might simplify selfish-mining
attacks at the consensus layer, which in turn might impact the
In this section, we summarize lessons learned concerning correct functionality of a blockchain-based application at the
the security reference architecture (SRA) and its practical application layer. Bottom-up security dependencies are also
utilization. First, we describe the hierarchy of security depen- presented in the context of the application layer, as we have
dencies among particular layers of the SRA. Second, assuming already mentioned in Section VIII.
such a hierarchy, we describe a security-oriented methodology
for designers of blockchain platforms and applications. Next,
we summarize the design goals of particular blockchain types B. Methodology for Designers
and discuss the security-specific features of the blockchains. A hierarchy of security dependencies in the SRA can be
Finally, we analyze observations from the incidents that oc- utilized during the design of new blockchain-based solu-
curred in practice, limitations in the literature, and we propose tions. When designing a new blockchain platform or a new
future research directions. blockchain application, we recommend designers to specify
requirements on the blockchain features (see Appendix A) and
afterward analyze design options and their attack surfaces at
A. Hierarchy of Dependencies in the SRA
the first three layers of the stacked model of SRA. We briefly
In the proposed model of the SRA, we observe that con- summarize the pros and cons of particular categories within
sequences of vulnerabilities presented at lower layers of the the first three layers of SRA in Table I, while security threats
SRA are manifested in the same layers and/or at higher layers, and mitigations are covered in Section V, Section VI, and
especially at the application layer. Therefore, we refer to Section VII.
security dependencies of these layers on lower layers or the On top of that, we recommend the designers of a new
same layers, i.e., reflexive and bottom-up dependencies. We blockchain application to analyze particular options and their
describe these two types of dependencies in the following. security implications at the application layer of SRA. We list
Reflexive Dependencies. If a layer of the SRA contains some the pros and cons of a few categories from the application
assets, it also contains a reflexive security dependency on layer in Table II,54 while security threats and mitigation
the countermeasures presented in the same layer. It means techniques of this layer are elaborated in Section VIII and
that a countermeasure at a particular layer protects the assets Section IX. During this process, we recommend the designers
presented in the same layer. For example, in the case of the to follow security dependencies of the target category on other
consensus layer whose protocols reward consensus nodes for underlying categories (see Figure 15) if their decentralized
participation, the countermeasures against selfish mining at- variants are used (which is a preferable option from the
tacks protect rewards (i.e., crypto-tokens) of consensus nodes. security point-of-view). For example, if one intends to design
In the case of the RSM layer, the privacy of user identities and a decentralized reputation system, she is advised to study
data is protected by various countermeasures of this layer (e.g., the security threats from the reputation system category and
blinding signatures, secure multiparty computations). Another its recursive dependencies on e-voting, identity management,
group of reflexive security dependencies is presented at the crypto-tokens & wallets, and (optionally) filesystems.
application layer. Although the application layer contains some
bottom-up security dependencies (see Figure 15), we argue Divide and Conquer. If a designer of the blockchain appli-
that with regard to the overall stacked model of the SRA cation is also designing a blockchain platform, we recom-
they can be viewed as reflexive security dependencies of the mend her to split the functionality of the solution with the
application layer. divide-and-conquer approach respecting particular layers of
our stacked model. In detail, if some functionality is specific
Bottom-Up Dependencies. If a layer of the SRA contains
to the application layer, then it should be implemented at
some assets, besides reflexive security dependencies, it also
contains bottom-up security dependencies on the counter- 54 Note that the table contains only categories with specified sub-
measures of all lower layers. Hence, the consequences of categorizations that represent the subject to a comparison.
 34

Category
Layer Pros Cons
in a Layer
• low latency, high throughput • VPN is required for geographically spread
• centralized administration, ease of access control participants
Private
Network Layer

• the privacy of data and identities • suitable only for permissioned blockchains
Networks
• meeting regulatory obligations • insider threat and external attacks at nodes with
• resilience to external attacks administrative privileges
• high and non-uniform latency
• high decentralization • single-point-of-failure (DNS, IP, and ASes
Public • high availability are managed by centralized parties)
Networks • openness & low entry barrier (low cost of • external adversaries (botnets, compromised
broadband connection, resistance to regulations) BGP/DNS servers)
• stolen identities
• high operational costs
• high cost of overriding the history of blockchain
PoR • low throughput
• high scalability
• low finality
• low scalability
• high throughput (with a small number of nodes) • high communication complexity
BFT
• fast finality • limited number of nodes (efficient use only
in permissioned blockchains)
Consensus Layer

• PoS specific attacks and issues

PoS • energy efficiency • supports only semi-permissionless setting
• slow finality
• energy efficiency
• high scalability • some PoS specific attacks
PoS+BFT
• probabilistic security guarantees • supports only semi-permissionless setting
• lower communication overheads than BFT
• high scalability
PoR+BFT • spending some scarce resources
• fast finality
• spending some scarce resources
PoR+PoS
• high scalability • some PoS specific attacks
(i.e., PoA)
• slow finality
• identities are only pseoudonymous and can
• fast processing
Standard Approach be traced to IPs
• ease of verification
• all data of transactions are publicly visible
Protecting Identities

• additional complexity, in some cases unlinkability

Standard Approach • privacy identity protection of users in a group
by the mixer or involved parties in a group
+ Mixers • ease of verification
Replicated State Machine Layer

• all data of transactions are publicly visible

NIZKs and • identities are anonymized to the extend of • additional computation overheads for running
Transactions

Ring-Signatures the group the schemes

MPC
• additional computation overheads for running
Blinding Signatures, • unlinkability for all involved parties
the schemes
Layered-Encryption
NIZKs, Blinding
• privacy of data in cryptocurrency • additional computation overheads for running
Protecting Data

Signatures, Homomor-
platforms the schemes
phic Encryption
Trusted Transaction
Managers, • privacy of data in transactions of smart contract • additional computation overheads for running
Trusted Hardware, platforms the schemes
MPC
Turing-Complete • smart contracts may contain an arbitrary • wide surface for making the programming bugs
Contracts

Languages programming logic that often results in vulnerabilities

Smart

Turing-Incomplete • the programming logic serves only for limited

• small attack surface and emphasis on safety
Languages purposes

Table I: Pros and cons of various categories within the first three layers of the stacked model.

Design Elimination of Sybil

Goals Entities
Liveness Permissionless
Fresh & Fair Leader /
Standard Specific Committee Election
Safety Permissioned &
Semi-Permissionless Non-Interactive Verifi-
cation of the Result

Figure 29: Standard and specific design goals of consensus protocols.

 35

Application
Subcategory Pros Cons
Category
Server-Side • keys stored at the server, susceptibility to the theft of keys by external
• simplicity of control for end-users
Hosted or internal attacks
• no storage requirements for end-users
Wallets • single-point-of-failure, availability attacks
Wallets

Client-Side • simplicity of control for end-users • single-point-of-failure, availability attacks

Hosted • no storage requirements for end-users • possibility of key theft by malware
Wallets • keys stored locally • possibility of tampering attacks
• moderate storage requirements for end-users
Self-Sovereign • keys stored locally
• more difficult control for end-users
Wallets or in a dedicated hardware device
• extra device to carry in the case of hardware wallet
• a high throughput and speed of operations • risk of insider threat due to centralization
Centralized • the simplicity of control for end-users • external threats to exchange infrastructure
Exchange • low costs for exchange transactions • overheads for secure storage of secrets
• trading of obscure crypto-tokens • a fee specified by the operator
• costs for 4 transactions of the atomic swap
Exchanges

Direct • user has to find the counter-order on her own

• fairness of the exchange
Cross-Chain • counter-orders might not exist
• no fee to any operator
Exchange • a lower throughput than in a centralized exchange
• a higher complexity for end-users
• fairness of the exchange • costs for 4 or 6 transactions of the atomic swap
Cross-Chain
• order matching made by DEX • a lower throughput than in a centralized exchange
DEX
• trading of obscure crypto-tokens • a fee specified by the operator
• fairness of the exchange • a limited number of pairs that are specific to the target platform
Intra-Chain
• uniform finality for every pair • a fee specified by the operator
DEX
• a high speed of operations • costs for smart contract execution
• possible conflict of interest
• early (close to accurate) estimation
Prediction • a limited set of data specific to a few events
of the future event’s result
Markets • a long time to obtain a final result, especially in
• decentralization
the case of disputes
Oracles

• wide range of data

Centralized • fast provisioning time • centralization (accidentally or intentionally wrong data)
Data Feeds • handling of private parameters of requests • availability issues
• censorship evidence
• decentralization
Oracle • unsupported private parameters of requests
• wide range of data
Networks • publicly visible data and requests
• fast provisioning time
Fully
• a high availability • a high storage overheads and operational costs
Replicated FSs
• accountability and auditability • a high price
with Ledger
Partially • reasonably high availability
Filesystems

Replicated FSs • accountability and auditability • attack vectors specific to partial replication
with Ledger • a lower price than in a full replication
Partially
• reasonably high availability • a lack of native accountability and auditability
Replicated FSs
• a lower price than in a full replication • low durability due to a lack of incentives for storage
without Ledger
Centralized
• a low price
Storage of • a low availability
• accountability and auditability
Off-Chain Data

Table II: Pros and cons of some categories from the application layer.

that layer. Such an approach minimizes the attack surface presented at the consensus layer. Therefore, the consensus
of a solution and enables isolating the threats to specific layer also embeds a part of functionality from the application
layers, where they are easier to protect from and reviewed layer. However, when filesystems are in security dependencies
by the community. A contra-example is to incorporate a part of the target application other than filesystems, one should
of application layer functionality/validation into the consensus realize that they are usually running on a different blockchain
layer. The consensus layer should deal only with the ordering or infrastructure than the target application, and this exception
of transactions, and it should be agnostic to the application. is not a concern.
Nevertheless, it is worth noting that the divide-and-conquer
approach might not be suitable for some very specific C. Blockchain Types & Design Goals
cases. For example, some decentralized filesystems (see Sec- We learned that the type of a blockchain (see Section III-B)
tion VIII-D) might combine data storage as an application- implies the specific design goals of its consensus protocol (see
layer service with the proof-of-storage consensus algorithm, Figure 29), which must be considered on top of the standard
 36

design goals (i.e., liveness and safety) and the inherent features deteriorate the finality of BFT in a probabilistic ratio that is
(see Appendix A1) during the design of a particular blockchain commensurate to the committee size. In the case of PoR pro-
platform and its consensus protocol. In the following, we tocols with partial solutions, finality is improved as opposed to
elaborate on such specific design goals. pure PoR protocols; however, it is also probabilistic, depending
Permissionless Type. The first design goal is to eliminate on the number of partial solutions.
Sybil entities – such elimination can be done by requiring that
some amount of scarce resources is spent for extension of the E. Incidents in Practice
blockchain, and hence no Sybil entity can participate. This
We list several incidents at each layer of the SRA in
implies that no pure PoS protocol can be permissionless since
Table VI, Table V, Table IV, and Table III of Appendix. The
it never spends resources on running a consensus protocol. The
observations about the number of different incident types vary
next design goal is a fresh and fair leader/committee election,
layer by layer. In the case of the network layer, many of the
which ensures that each consensus node influences the result of
attacks described in the SRA occurred or were demonstrated
a consensus commensurately to the number of scarce resources
with a proof-of-concept. However, incidents that occurred at
spent. Moreover, freshness avoids the prediction of the selected
the consensus layer mostly contained 51% attacks with double-
nodes, and therefore elected nodes cannot become the subject
spending, while incidents that occurred on the application
of targeted DoS attacks. The last design goal is the non-
layer were mostly caused by the exploitation of centralized
interactive verification of the consensus result by any node
components. In the case of the RSM layer, most of the
– i.e., any node can verify the result of the consensus based
incidents occurred due to bugs in smart contracts. Finally,
on the data presented in the blockchain.
we observed that most of the incidents that occurred at the
Permissioned and Semi-Permissionless Types. These types application layer were caused due to a single-point-of-failure,
of blockchains require fresh and fair leader/committee elec- e.g., centralized components or the insider threat.
tion as well as non-interactive verification of the result of Although the number of occurred incident types is low as
the consensus. However, in contrast to the permissionless compared to described vulnerabilities and threats, we argue
blockchains, they do not require a means for the elimination that the adoption of blockchains for practical applications is
of Sybil entities, as permission to enter the system is given by still in its infancy, and thus we may expect that the number
a centralized entity (i.e., permissioned type) or any existing of different incident types observed in practice will grow.
consensus node (i.e., semi-permissionless type).
Blockchain Types and Incentives. We observed that no
F. Limitations in the Literature and Practice
application running on a public (permissioned) blockchain
has been able to work without introducing crypto-tokens (i.e., Applications of Blockchains. Although the literature contains
an incentive scheme), even if the use case is not financial surveys and overviews [11], [12], [277] of blockchain-based
in nature, e.g., e-voting, notaries, secure timestamping, or applications, these works introduce only domain-oriented cat-
reputation systems. In these blockchains, incentive schemes egorizations (i.e., categories such financial, governance, se-
serve as a means for the elimination of Sybil entities, besides curity, education, supply chain, etc.) and they do not in-
other purposes. The situation is different in the context of vestigate the security aspects and functionalities that these
private (permissioned) blockchains, which are usually pro- applications leverage on and whether some of the applications
visioned by a single organization or a consortium and do do not belong to the same category from the security and
not necessarily need crypto-tokens to operate. Misaligned functionality point-of-view. To address this limitation, we
incentives can cause consensus-level vulnerabilities, e.g., when provide a security-driven functionality-oriented categorization
it becomes profitable to drop blocks of other nodes to earn of blockchain-based applications (see Section VIII), which is
higher mining rewards [82] or transaction fees [275]. The agnostic to an application domain and thus can generalize
design of incentive mechanisms is a research field by itself different application scenarios. Furthermore, our proposed
and we refer the reader to the work of Leonardos et al. [276]. categorization enables us to model security and functionality-
based dependencies among particular categories, which is not
D. Security-Specific Features of Blockchains possible with state-of-the-art categorizations.
We realized that consensus protocols are the target of most Centralization. Even though blockchains are meant to be fully
financially-oriented attacks on the decentralized infrastructure decentralized, we have seen that this does not hold at some
of blockchains, even if such attacks might originate from the layers of the SRA – the network and application layers, in
network layer (e.g., routing and eclipse attacks). The goal particular. In the network layer, some attacks are possible due
of these attacks is to overturn and re-order already ordered to centralized DNS bootstrapping, while in the application
blocks while doing double-spending. Hence, the finality is layer a few categories utilize centralized components to ensure
the most security-critical feature of the consensus layer. The some functionality that cannot run on-chain or its provisioning
finality differs per various categories of the consensus layer. would be too expensive and slow, which, however, forms the
The best finality is achieved in the pure BFT protocols, and trade-off with the security. Some applications might depend on
the worse finality is achieved in the single-leader-based PoR components from other application categories (e.g., identity
and PoS protocols. On the other hand, combinations of the management) but implementing these components in a cen-
BFT with PoS protocols (i.e., introducing committees) slightly tralized fashion, even though there exist some decentralized
 37

variants that are gaining popularity (e.g., DIDs [215] for types of blockchain-oriented applications that directly inherit
identity management). security aspects from already existing categories; therefore, we
omitted such application types in our work.
G. Future Research Directions
Fast Finality. Although finality is the most security-critical A. Stacked Model
feature of the consensus layer (see Section X-D), it forms Versatility. The hierarchical stacked model that is the SRA
the trade-off with scalability. Therefore, we believe that the based on was already utilized in other domains before. A
future focus of the consensus research should be in a thorough well-known example is the ISO/OSI model with seven layers
evaluation of this trade-off across various consensus protocols. or later derived TCP/IP model with four layers in the field
Network-Layer Security. We learned that a substantial body of communication networks. The stacked model was also
of security research in blockchains is focusing on the consen- applied in cloud computing, referred to as cloud stack [278], in
sus and RSM layers since these layers are mostly identified which, each layer represents one service model in the model’s
with the blockchains. As opposed to them (see Figure 1), the hierarchy. Nevertheless, the stacked model was also applied in
network layer is not so popular even though the serious threats the field of blockchains [16].
originating from this layer might hurt the higher layers and The versatility of the stack model allows not only for
their assets. Therefore, a potential direction for future research modeling the hierarchy in a particular domain but also for
lies in studying the security aspects of network protocols, partitioning the corresponding security issues and their coun-
their suitability for a decentralized environment, and potential termeasures based on the layers of the model. This was done
improvements. for the ISO/OSI model [279], TCP/IP model [280], and cloud
Privacy Preservation & Performance. All cryptographic computing [8], while in this work we focus on the security
privacy preservation techniques (see Section VII-A1) bring threats related to blockchains and propose the SRA.
additional computation overhead, and thus they negatively Modularity. The stack model of SRA enables extensions
impact the throughput of the blockchains. On the other hand, of particular categories within each layer by adding new
privacy-preserving solutions that are based on the trusted vulnerabilities, threats, and their respective countermeasures.
hardware might provide higher performance, but they rely Likewise, the new categories can be modularly added to each
on the manufacturer of trusted hardware and the assumption of the SRA layers. Afterward, the security implications of a
that it will not be compromised. Therefore, we believe that new category, threat, or a countermeasure within some layer
optimizing the trade-off between performance and privacy- should be studied with regard to particular categories in higher
preservation is an important future research direction concern- layers – a new category might be beneficial or detrimental
ing the RSM layer. to them from a security point-of-view. When introducing a
Security Analysis of the Application Layer. Although many new defense or mitigation technique, it is also important to
references included in this study are presented in the appli- evaluate its side effects and implications on the features of the
cation layer, only a very few of them analyze thoroughly blockchain that are manifested at the same and higher layers.
security aspects of a particular application layer category or A general guideline for extending the SRA is to introduce
its instance. Therefore, as a future research direction, we only such categories that have unique features from the secu-
recommend the authors of the blockchain-based applications rity point-of-view, while in the case of the application layer,
to analyze the resistance of their applications to all known functionality point-of-view should be considered as well.
threats of a particular application category (e.g., with help
of our work), while broadly think of new vulnerabilities and B. Additional Security Aspects
threats that might be specific to their application type.
Secure Cryptography Primitives. We emphasize that for
Decentralization. Since some blockchain applications utilize each layer of our stacked model, we assume the use of secure
centralized components while their decentralized variants al- cryptographic primitives with recommended key lengths55 that
ready exist Section X-F, we suggest that a potential future are based on existing standards (e.g., [281], [282]). Examples
direction for researchers and practitioners might be the con- include secure communication (i.e., network layer), the use
cept of a fully decentralized blockchain ecosystem. Such an of private keys for transaction signing (i.e., consensus layer),
ecosystem might consist of only decentralized (or partially and password management for blockchain-based services (i.e.,
decentralized) application types, for example, the ones that application layer). Since the area of cryptographic primitives
we reviewed in the application layer of the SRA. is standardized and extensively covered in existing research,
we treat security incidents that break these primitives as out-
XI. D ISCUSSION of-scope in the current paper.
In this section, we first discuss the versatility and modularity Semantic Bugs. We deal with semantic bugs only at the
of the stacked model that is the proposed security reference level of the RSM layer as part of the smart contracts (see
architecture (SRA) based on. Then, we outline a few additional Section VII-B). However, we emphasize that semantic bugs
security aspects related to blockchains, which, for clarity and in the blockchain infrastructure may occur at each of the
simplicity, we have not pursued throughout this paper or
mentioned them only tangentially. Finally, we discuss a few 55 https://www.keylength.com
 38

proposed layers, whereas in the case of the RSM layer, besides categorization is lacking. The authors deal with selfish mining,
smart contracts, they may occur in compilers, interpreters, etc. the DAO hack, BGP hijacking, and eclipse attacks, while
In this work, we assume that the software of the blockchain- all of them are mentioned as individual incidents. Conti et
related infrastructure does not contain any programming se- al. [290] present an overview of consensus- and network-layer
mantic bugs at each of the layers, and it provides the expected attacks inherent to the Bitcoin blockchain. One interesting
functionality. On the other hand, we emphasize that these contribution is its overview of client-side attacks and attacks
semantic bugs had already accounted for several incidents in on exchange systems. Many attacks presented in this work
the past, e.g., [283], [284], [285], [286]. To achieve safe and are supported by evidence of incidents. On the other hand,
correct software at each of the layers, similar to the case of the the authors spent only a little effort on the issues related to
RSM layer, developers and designers should utilize verification the RSM and application layers.
tools, testing, code reviews, audits, known design patterns, best
practices, etc. Research with Layered or Stacked Categorization. Wang
et al. [16] are the first to propose a 4-layer model denoted
C. Other Blockchain-Oriented Applications as “a network implementation stack.” Despite proposing the
stacked model, the authors do not focus on attacks and
There are several other applications of blockchain that we
countermeasures concerning each of the layers. The main
do not mention in our work because their security aspects
focus of their work is on the consensus layer, where the
are inherited from one or more categories presented in Sec-
authors dedicate most of their attention to PoR, PoS, and BFT
tion VIII and Section IX. For example, insurance applications
protocols as well as improving blockchain performance by
running on smart contract platforms inherit security aspects
sharding, side-chains, and non-linear data organization. In the
from the oracles category, as they require data to be delivered
application layer, the authors discuss a few types of emerging
into the blockchain from the outside world. The next example
blockchain-based applications, such as general-purpose data
is the trading of crypto-tokens within the same blockchain
storage and access control. Saad et al. [291] identify three
platform – it inherits security aspects from the crypto-tokens
categories of attacks: blockchain structure attacks, peer-to-peer
and wallets category (see Section VIII-A). Another example
system attacks, and application-oriented attacks. As compared
is cross-chain communication, which is a generalization of the
to our work, it mostly holds that their peer-to-peer system
exchanges category, and it also inherits most of the security
attacks encompass our network and consensus layer attacks,
aspects from it.
whereas their application-oriented attacks include the RSM
and application-layer attacks from our work. In contrast to
XII. R ELATED W ORK
our work, Saad et al. [291] put double-spending attacks into
The security reference architecture that has been presented application-oriented attacks, whereas in our case, they are part
in our work offers a comprehensive overview of blockchain- of the consensus layer since the means for their realization
related security vulnerabilities, threats, and mitigation tech- resides in this layer. Moreover, the authors of this paper deal
niques. We adapted a custom version of the four-layer stacked with crypto-jacking attacks, which are out-of-the-scope for our
model, initially presented in the work of Wang et al. [16]. reference architecture, as they are not related to the infrastruc-
In the following, we present an overview of the state-of-the- ture of the involved parties we consider (see Section III-A).
art survey papers related to blockchain research while we Chen et al. [292] propose a 4-layer model similar to ours,
highlight the differences in contrast to our work. We consider which is used to study vulnerabilities in Ethereum. The authors
three groups of blockchain-oriented research: (1) papers that identify 44 vulnerabilities, 26 attacks, and 47 defenses in total.
use a flat categorization of threats and vulnerabilities, (2) In contrast to our model, the authors use the “data” layer
papers that use a stacked or other multi-layered models, and in place of our RSM layer. This leads to a difference in
(3) papers that focus on incidents that belong to a single layer. interpretation between their framework and ours: e.g., they
Research with Flat Categorization. Bonneau et al. [177] consider reentrancy bugs as an application layer vulnerability,
present the first major survey of blockchain-specific security whereas we treat them as an RSM-layer vulnerability. Since
aspects, with a particular focus on Bitcoin and cryptocur- the authors focus on Ethereum, most vulnerabilities belong
rencies. The authors aim at the consensus-layer properties, to the RSM layer; however, some of the other vulnerabilities
although some network-layer aspects (e.g., DoS attacks) are (e.g., the BGP hijacking attack against MyEtherWallet [293],
discussed as well. Since smart contract functionality was in its [294]) do not seem to be specific for Ethereum. In contrast,
early stages of development at that time, not much is said about our work takes a broader view, and we do not constrain
RSM-layer properties, and little is said about applications be- it to a single blockchain. Another stack-based model was
yond cryptocurrencies and data storage. Similarly, Tschorsch proposed by Zhang et al. [295] and consists of six layers,
et al. [287] and Yli-Huumo et al. [288] present early survey where the layers stand for the application, contract, incentive,
papers that focus mostly on consensus- and network-layer consensus, network, and a data layer. The works of Alkhalifah
attacks, but they also deal with user privacy. The latter [288] et al. [296] and Zhu et al. [297] feature groupings consisting
has a particular focus on the publication details of blockchain of five (network, consensus, mining pool, smart contract, and
research until 2016, e.g., the venues and the countries of client vulnerabilities) and four (data privacy, data availability,
the authors’ institutions. Li et al. [289] present a high-level data integrity, and data controllability attacks) categories,
overview of blockchain security threats and incidents, but the respectively. Natoli et al. [298] focus mainly on the consensus
 39

layer but include some network-layer attacks as well (e.g., [4] L. Goasduff, “Gartner Says Blockchain Deployments Across Financial
eclipse attacks and BGP hijacking). Services Ecosystems Are At Least Three Years Away,” 2019.
[Online]. Available: https://www.gartner.com/en/newsroom/press-
Research Focusing on a Particular Layer. Finally, there is releases/09-16-2019-gartner-says-blockchain-deployments-across-
a number of survey papers that explicitly focus on specific financial-services-ecosystems-are-at-least-three-years-away
[5] J. Barry, “Blockchain Technology Needs Standardization,”
layers: the network layer [299], the RSM layer (in particular 2018. [Online]. Available: https://medium.com/blockchain-standards/
smart contracts) [138], [300], [301], protocols of the consensus blockchain-technology-needs-standardization-596fbea2d0cf
layer [101], [115], [302], [276], [303], [304], incentives at [6] H. Zimmermann, “OSI reference model-the ISO model of architecture
for open systems interconnection,” IEEE Transactions on communica-
the consensus layer [305], [306], and application layer from tions, vol. 28, no. 4, 1980.
the general standpoint [11], or with a focus on the IoT [7] F. Liu, J. Tong, J. Mao, R. Bohn, J. Messina, L. Badger, and D. Leaf,
domain [307], [308], [309], [310]. “NIST cloud computing reference architecture,” NIST special publica-
tion, vol. 500, no. 2011, pp. 1–28, 2011.
[8] Z. Xiao and Y. Xiao, “Security and privacy in cloud computing,” IEEE
Communications Surveys & Tutorials, vol. 15, no. 2, 2013.
XIII. C ONCLUSION [9] Common Criteria, “Common criteria for information technologyse-
curity evaluation. part 1: Introduction and general model,” 2017.
In this paper, we focused on the systematization of the [Online]. Available: https://www.commoncriteriaportal.org/files/ccfiles/
knowledge about security aspects of blockchain systems, CCPART1V3.1R5.pdf
while we aimed to create a standardized model for studying [10] I. Homoliak, S. Venugopalan, Q. Hum, and P. Szalachowski, “A
security reference architecture for blockchains,” in The 2nd IEEE
vulnerabilities and security threats. We proposed a stack- International Conference on Blockchain (Blockchain-2019). IEEE,
modeled security reference architecture (SRA) consisting of 2019.
four layers, and at each of the layers, we surveyed categories [11] F. Casino, T. K. Dasaklis, and C. Patsakis, “A systematic literature
review of blockchain-based applications: current status, classification
and options for their instantiation with their respective security and open issues,” Telematics and Informatics, 2018.
implications and properties. We modeled particular categories [12] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, “Blockchain
as vulnerability/threat/defense graphs, which we provided as challenges and opportunities: A survey,” International Journal of Web
and Grid Services, vol. 14, no. 4, pp. 352–375, 2018.
a means for reasoning about imposed security aspects. Next, [13] J. F. Wolfswinkel, E. Furtmueller, and C. P. Wilderom, “Using
we collected a sample of blockchain-related incidents that grounded theory as a method for rigorously reviewing literature,”
occurred in practice, which we further categorized using our European journal of information systems, vol. 22, no. 1, pp. 45–55,
2013.
proposed model. We observed that the number of incident [14] R. Tahir, M. Huzaifa, A. Das, M. Ahmad, C. Gunter, F. Zaffar, M. Cae-
types occurred in practice is substantially smaller than the sar, and N. Borisov, “Mining on someone else’s dime: Mitigating
number of described threats, especially in the consensus and covert mining operations in clouds and enterprises,” in International
Symposium on Research in Attacks, Intrusions, and Defenses. Springer,
application layer. In the case of the application layer, most 2017, pp. 287–310.
of the incidents occurred due to exploiting a centralized [15] S. Micali, M. Rabin, and S. Vadhan, “Verifiable random functions,”
component by external or internal attackers, while in the case in 40th Annual Symposium on Foundations of Computer Science (Cat.
No. 99CB37039). IEEE, 1999, pp. 120–130.
of the consensus layer, most of the incidents occurred due to [16] W. Wang, D. T. Hoang, P. Hu, Z. Xiong, D. Niyato, P. Wang, Y. Wen,
temporary violation of protocol assumptions by 51% attacks. and D. I. Kim, “A survey on consensus mechanisms and mining strategy
Finally, we presented a security-oriented methodology for de- management in blockchain networks,” IEEE Access, vol. 7, pp. 22 328–
22 370, 2019.
signers of blockchains platforms and applications, respecting [17] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
the proposed SRA. [18] P. Szalachowski, D. Reijsbergen, I. Homoliak, and S. Sun,
“Strongchain: Transparent and collaborative proof-of-work consensus,”
in 28th USENIX Security Symposium, USENIX Security 2019, Santa
ACKNOWLEDGMENT Clara, CA, USA, August 14-16, 2019., 2019, pp. 819–836.
[19] Hyperledger team, “Hyperledger architecture, volume 1: Consensus,”
This work was supported by the NRF, Prime Minister’s 2017. [Online]. Available: https://www.hyperledger.org/wp-content/
Office, Singapore, under its National Cybersecurity R&D uploads/2017/08/Hyperledger Arch WG Paper 1 Consensus.pdf
[20] L. Chen, L. Xu, N. Shah, Z. Gao, Y. Lu, and W. Shi, “On security
Programme (Award No. NRF2016NCR-NCR002-028) and ad- analysis of proof-of-elapsed-time (poet),” in International Symposium
ministered by the National Cybersecurity R&D Directorate. on Stabilization, Safety, and Security of Distributed Systems. Springer,
Next, this work was supported by the project 20-07487S of 2017.
[21] A. Kiayias, A. Russell, B. David, and R. Oliynykov, “Ouroboros: A
the Czech Science Foundation, the H2020 ECSEL project provably secure proof-of-stake blockchain protocol,” in CRYPTO’17.
VALU3S (876852), and the internal project of Brno University Springer, 2017.
of Technology (FIT-S-20-6427). We would also like to thank [22] Y. Sompolinsky, Y. Lewenberg, and A. Zohar, “Spectre: Serialization of
proof-of-work events: confirming transactions via recursive elections,”
our colleagues Pieter Hartel, Stefanos Leonardos, and Mark 2016.
van Staalduinen for their valuable feedback. [23] Y. Sompolinsky and A. Zohar, “Accelerating bitcoin’s transaction
processing. fast money grows on trees, not chains.” IACR Cryptology
ePrint Archive, vol. 2013, no. 881, 2013.
R EFERENCES [24] W. Tang, “Ecip-1029: Include uncles in total difficulty calculation,”
2017. [Online]. Available: https://github.com/ethereumproject/ECIPs/
[1] Enterprise Ethereum Alliance, “Enterprise Ethereum Alliance,” 2019. pull/71
[Online]. Available: https://entethalliance.org/ [25] A. Zamyatin, N. Stifter, P. Schindler, E. Weippl, and W. J. Knottenbelt,
[2] ISO, “ISO/DTR 23245: Blockchain and distributed ledger technologies “Flux: Revisiting Near Blocks for Proof-of-Work Blockchains,” 2018,
– Security risks, threats and vulnerabilities,” 2019. [Online]. Available: https://eprint.iacr.org/2018/415/20180529:172206.
https://www.iso.org/standard/75062.html?browse=tc [26] M. Castro, B. Liskov et al., “Practical byzantine fault tolerance,” in
[3] ISO, “ISO/CD 23257: Blockchain and distributed ledger technologies OSDI, vol. 99, 1999.
– Reference architecturevulnerabilities,” 2019. [Online]. Available: [27] P.-L. Aublin, S. B. Mokhtar, and V. Quéma, “RBFT: Redundant
https://www.iso.org/standard/75093.html?browse=tc byzantine fault tolerance,” in ICDCS. IEEE, 2013.
 40

[28] E. Buchman, J. Kwon, and Z. Milosevic, “The latest gossip on bft [55] S. D. Lerner, “New DoS vuln by Forcing Continuous Hard Disk
consensus,” 2018. Seek/Read Activity (fixed in 0.8.0),” 2019. [Online]. Available:
[29] A. Kiayias and A. Russell, “Ouroboros-BFT: A Simple Byzantine Fault https://bitcointalk.org/index.php?topic=144122.0
Tolerant Consensus Protocol,” 2018. [56] BitcoinWiki, “Weaknesses,” 24 July 2018. [Online]. Available: https:
[30] S. Duan, H. Meling, S. Peisert, and H. Zhang, “Bchain: Byzantine //en.bitcoin.it/wiki/Weaknesses#Denial of Service .28DoS.29 attacks
replication with high throughput and embedded reconfiguration,” in [57] A. Biryukov and I. Pustogarov, “Bitcoin over tor isn’t a good idea,”
OPODIS. Springer, 2014. in 2015 IEEE Symposium on Security and Privacy, SP 2015, San
[31] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich, “Al- Jose, CA, USA, May 17-21, 2015. IEEE Computer Society, 2015,
gorand: Scaling byzantine agreements for cryptocurrencies,” in SOSP. pp. 122–134. [Online]. Available: https://doi.org/10.1109/SP.2015.15
ACM, 2017. [58] A. Miller, J. Litton, A. Pachulski, N. Gupta, D. Levin, N. Spring,
[32] P. Daian, R. Pass, and E. Shi, “Snow white: Robustly reconfigurable and B. Bhattacharjee, “Discovering Bitcoin’ s public topology and
consensus and applications to provably secure proofs of stake,” 2017. influential nodes,” University of Maryland, College Park, Tech. Rep.,
[33] T. Hanke, M. Movahedi, and D. Williams, “Dfinity technology 2015.
overview series, consensus system,” 2018. [59] G. Caffyn, “Chainalysis CEO Denies Sybil Attack on Bitcoin
[34] ZILLIQA Team, “The ZILLIQA Technical Whitepaper,” 2017. Network,” 2015. [Online]. Available: https://www.coindesk.com/
[35] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network
and B. Ford, “Omniledger: A secure, scale-out, decentralized ledger [60] A. Miller, A. Kosba, J. Katz, and E. Shi, “Nonoutsourceable scratch-off
via sharding,” in 2018 IEEE S&P 2018, Proceedings, 21-23 May puzzles to discourage Bitcoin mining coalitions,” in ACM CCS. ACM,
2018, San Francisco, California, USA, 2018. [Online]. Available: 2015.
https://doi.org/10.1109/SP.2018.000-5 [61] V. Buterin and V. Griffith, “Casper the friendly finality gadget,” 2017.
[36] M. Zamani, M. Movahedi, and M. Raykova, “Rapidchain: Scaling [62] X. Yang, Y. Chen, and X. Chen, “Effective scheme against 51%
blockchain via full sharding,” in ACM CCS, 2018. [Online]. Available: attack on proof-of-work blockchain with history weighted information,”
https://doi.org/10.1145/3243734.3243853 in 2019 IEEE International Conference on Blockchain (Blockchain).
[37] F. B. Schneider, “Implementing fault-tolerant services using the state IEEE, 2019, pp. 261–265.
machine approach: A tutorial,” ACM CSUR, vol. 22, no. 4, 1990. [63] A. Miller, Y. Xia, K. Croman, E. Shi, and D. Song, “The honey badger
[38] L. Lamport et al., “The part-time parliament,” ACM Transactions on of bft protocols,” in ACM CCS. ACM, 2016.
Computer systems, vol. 16, no. 2, 1998. [64] A. Boverman, “Timejacking & Bitcoin,” 2011. [Online]. Available:
[39] D. Ongaro and J. Ousterhout, “In search of an understandable consen- http://culubas.blogspot.com/2011/05/timejacking-bitcoin 802.html
sus algorithm,” in USENIX ATC, 2014. [65] P. Szalachowski, “(Short Paper) Towards More Reliable Bitcoin Times-
[40] B. M. Oki and B. H. Liskov, “Viewstamped replication: A new primary tamps,” in IEEE CVCBT. IEEE, 2018.
copy method to support highly-available distributed systems,” in ACM [66] S. Dexter, “1% shard attack explained – ethereum sharding (contd..),”
Symposium on Principles of Distributed Computing. ACM, 1988. https://www.mangoresearch.co/1-shard-attack-explained-ethereum-
[41] C. Cachin and J. A. Poritz, “Secure intrusion-tolerant replication on sharding-contd/, 2018.
the internet,” in Proceedings International Conference on Dependable
[67] M. Bjelic, “On the probability of 1% attack,” https://ethresear.ch/t/on-
Systems and Networks. IEEE, 2002, pp. 167–176.
the-probability-of-1-attack/4009/6.
[42] M. L. Collins, M. C. Theis, R. F. Trzeciak, J. R. Strozer, J. W. Clark,
[68] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena,
D. L. Costa, T. Cassidy, M. J. Albrethsen, and A. P. Moore, “Common
“A secure sharding protocol for open blockchains,” in Proceedings of
sense guide to prevention and detection of insider threats 5th edition,”
the 2016 ACM SIGSAC Conference on Computer and Communications
Published by CERT, SEI, CMU, 2016.
Security. ACM, 2016, pp. 17–30.
[43] D. S. H. Rosenthal, P. Maniatis, M. Roussopoulos, T. J. Giuli, and
[69] E. Syta, P. Jovanovic, E. K. Kogias, N. Gailly, L. Gasser, I. Khoffi, M. J.
M. Baker, “Notes on the design of an internet adversary,” CoRR, vol.
Fischer, and B. Ford, “Scalable bias-resistant distributed randomness,”
cs.DL/0411078, 2004. [Online]. Available: http://arxiv.org/abs/cs.DL/
in 2017 IEEE Symposium on Security and Privacy (SP). Ieee, 2017,
0411078
pp. 444–460.
[44] S. Bradshaw and L. DeNardis, “The politicization of the Internet’s
Domain Name System: Implications for Internet security, universality, [70] A. Sonnino, S. Bano, M. Al-Bassam, and G. Danezis, “Replay attacks
and freedom ,” 2016. [Online]. Available: https://journals.sagepub. and defenses against cross-shard consensus in sharded distributed
com/doi/full/10.1177/1461444816662932 ledgers,” ArXiv, vol. abs/1901.11218, 2019.
[45] M. Apostolaki, A. Zohar, and L. Vanbever, “Hijacking bitcoin: Routing [71] J. Long and R. Wei, “Scalable bft consensus mechanism through
attacks on cryptocurrencies,” in 2017 IEEE Symposium on Security aggregated signature gossip,” in 2019 IEEE International Conference
and Privacy, SP 2017, San Jose, CA, USA, May 22-26, 2017. IEEE on Blockchain and Cryptocurrency (ICBC). IEEE, 2019, pp. 360–367.
Computer Society, 2017, pp. 375–392. [72] F. Silva, A. Alonso, J. Pereira, and R. Oliveira, “A comparison of
[46] M. Apostolaki, G. Marti, J. Müller, and L. Vanbever, “SABRE: message exchange patterns in BFT protocols,” in IFIP International
Protecting Bitcoin against routing attacks,” NDSS 2019, 2019. Conference on Distributed Applications and Interoperable Systems.
[47] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg, “Eclipse attacks on Springer, 2020, pp. 104–120.
Bitcoin’s peer-to-peer network,” in USENIX Security, 2015, pp. 129– [73] S. Dziembowski, S. Faust, V. Kolmogorov, and K. Pietrzak, “Proofs of
144. space,” in CRYPTO’15, 2015.
[48] K. Wüst and A. Gervais, “Ethereum eclipse attacks,” ETH Zurich, Tech. [74] S. Park, K. Pietrzak, J. Alwen, G. Fuchsbauer, and P. Gazi, “Spacecoin:
Rep., 2016. a cryptocurrency based on proofs of space (vol. 528),” https://eprint.
[49] Y. Marcus, E. Heilman, and S. Goldberg, “Low-resource eclipse attacks iacr.org/2015/528.pdf, IACR Cryptology ePrint Archive., Tech. Rep.,
on Ethereum’s peer-to-peer network.” 2018. 2015.
[50] M. Tran, I. Choi, G. J. Moon, A. V. Vu, and M. S. Kang, “A [75] T. Hønsi, “Spacemint-a cryptocurrency based on proofs of space,”
stealthier partitioning attack against bitcoin peer-to-peer network,” in Master’s thesis, NTNU, 2017.
IEEE Symposium on Security and Privacy (S&P), 2020. [76] K. Karantias, A. Kiayias, and D. Zindros, “Proof-of-burn,” IACR
[51] B. Alangot, D. Reijsbergen, S. Venugopalan, and P. Szalachowski, Cryptology ePrint Archive, 2019, https://eprint.iacr.org/2019/1096.pdf.
“Decentralized lightweight detection of eclipse attacks on bitcoin [77] P4Titan, “Slimcoin: A peer-to-peer crypto-currency with
clients,” in IEEE International Conference on Blockchain, Blockchain proof-of-burn,” https://github.com/slimcoin-project/slimcoin-
2020, Greece, Rhodes Island, November 02-06, 2020. IEEE, 2020. project.github.io/blob/master/whitepaperSLM.pdf, Slimcoin, Tech.
[52] S. Higgins, “Bitcoin mining pools targeted in wave of DDoS attacks,” Rep., 2014.
2015. [Online]. Available: https://www.coindesk.com/bitcoin-mining- [78] A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz, “Permacoin:
pools-ddos-attacks Repurposing Bitcoin work for data preservation,” in IEEE S&P. IEEE,
[53] D. Shares, “Major DDoS attacks hit Bitcoin.com,” 2017. 2014.
[Online]. Available: https://news.bitcoin.com/ddos-attacks-bitcoin- [79] Protocol Labs, “Filecoin: A decentralized storage network,” Protocol
com-uncensored-information/ Labs, Tech. Rep., 2017.
[54] E. Arazi, “Choosing the Right DDoS Solution (Part 4): Hybrid [80] S. King and S. Nadal, “Ppcoin: Peer-to-peer crypto-currency with
Protection,” 2018. [Online]. Available: https://blog.radware.com/ proof-of-stake,” 2012. [Online]. Available: https://peercoin.net/assets/
security/2018/04/choosing-the-right-ddos-solution-hybrid-protection/ paper/peercoin-paper.pdf
 41

[81] R. Zhang and B. Preneel, “Lay down the common metrics: Evaluating [111] D. Karakostas and A. Kiayias, “Securing proof-of-work ledgers via
proof-of-work consensus protocols’ security.” in IEEE S&P. IEEE, checkpointing.” IACR Cryptololgy ePrint Archive, vol. 2020, p. 173,
2019. 2020.
[82] I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining is [112] W. Li, S. Andreina, J.-M. Bohli, and G. Karame, “Securing proof-of-
vulnerable,” Communications of the ACM, vol. 61, no. 7, 2018. stake blockchain protocols,” in DPM. Springer, 2017, pp. 297–315.
[83] J. Brown-Cohen, A. Narayanan, A. Psomas, and S. M. Weinberg, “For- [113] B. David, P. Gaži, A. Kiayias, and A. Russell, “Ouroboros Praos:
mal barriers to longest-chain proof-of-stake protocols,” in Proceedings An adaptively-secure, semi-synchronous proof-of-stake blockchain,” in
of the 2019 ACM Conference on Economics and Computation. ACM, EUROCRYPT. Springer, 2018.
2019, pp. 459–473. [114] V. Buterin, “Long-range attacks: The serious problem with adaptive
[84] A. Sapirshtein, Y. Sompolinsky, and A. Zohar, “Optimal selfish mining proof of work,” Ethereum Blog, May, 2014.
strategies in Bitcoin,” in FC. Springer, 2016. [115] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry, S. Meik-
[85] K. Nayak, S. Kumar, A. Miller, and E. Shi, “Stubborn mining: lejohn, and G. Danezis, “Sok: Consensus in the age of blockchains,”
Generalizing selfish mining and combining with an eclipse attack,” in Proceedings of the 1st ACM Conference on Advances in Financial
in IEEE EuroSP. IEEE, 2016. Technologies, AFT 2019, Zurich, Switzerland, October 21-23, 2019.
[86] R. Pass and E. Shi, “Fruitchains: A fair blockchain,” in PODC. ACM, ACM, 2019, pp. 183–198.
2017. [116] Q. Feng, D. He, S. Zeadally, M. K. Khan, and N. Kumar, “A survey
[87] R. Zhang and B. Preneel, “Publish or perish: A backward-compatible on privacy protection in blockchain system,” Journal of Network
defense against selfish mining in Bitcoin,” in CT-RSA. Springer, 2017. and Computer Applications, vol. 126, 2019. [Online]. Available:
[88] E. K. Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, and B. Ford, http://www.sciencedirect.com/science/article/pii/S1084804518303485
“Enhancing Bitcoin security and performance with strong consistency [117] A. Biryukov, D. Khovratovich, and I. Pustogarov, “Deanonymisation
via collective signing,” in USENIX Security, 2016. of clients in Bitcoin P2P network,” in ACM CCS. ACM, 2014.
[89] A. Miller, “Feather-forks: enforcing a blacklist with sub - 50% hash [118] I. Pustogarov, “Deanonymisation techniques for Tor and Bitcoin,” Ph.D.
power,” https://bitcointalk.org/index.php?topic=312668.0, 2013. dissertation, University of Luxembourg, 2015.
[90] P. R. Rizun, “Subchains: A technique to scale Bitcoin and improve the [119] G. Kappos, H. Yousaf, M. Maller, and S. Meiklejohn, “An empirical
user experience,” Ledger, vol. 1, 2016. analysis of anonymity in zcash,” in USENIX Security, 2018.
[91] J. Bonneau, E. W. Felten, S. Goldfeder, J. A. Kroll, and A. Narayanan, [120] M. Möser, K. Soska, E. Heilman, K. Lee, H. Heffan, S. Srivastava,
“Why buy when you can rent? Bribery attacks on Bitcoin consensus,” in K. Hogan, J. Hennessey, A. Miller, A. Narayanan et al., “An empirical
Proceedings of the 3rd Workshop on Bitcoin and Blockchain Research analysis of traceability in the Monero blockchain,” PETS, vol. 2018,
(BITCOIN ’16), 2016. no. 3, 2018.
[92] P. Daian, S. Goldfeder, T. Kell, Y. Li, X. Zhao, I. Bentov, L. Brei- [121] J. Bonneau, A. Narayanan, A. Miller, J. Clark, J. A. Kroll, and E. W.
denbach, and A. Juels, “Flash boys 2.0: Frontrunning in decentralized Felten, “Mixcoin: Anonymity for Bitcoin with accountable mixes,” in
exchanges, miner extractable value, and consensus instability,” in 2020 FC. Springer, 2014, pp. 486–504.
IEEE Symposium on Security and Privacy (SP), 2020, pp. 566–583. [122] L. Valenta and B. Rowan, “Blindcoin: Blinded, accountable mixes for
[93] M. Rosenfeld, “Analysis of Bitcoin pooled mining reward systems,” bitcoin,” in Financial Crypto, M. Brenner, N. Christin, B. Johnson, and
CoRR, vol. abs/1112.4980, 2011. [Online]. Available: http://arxiv.org/ K. Rohloff, Eds., Berlin, Heidelberg, 2015.
abs/1112.4980 [123] G. Maxwell, “Coinjoin: Bitcoin privacy for the real world,” in Post on
[94] Raulo, “Optimal pool abuse strategy,” http://bitcoin.atspace.com/ Bitcoin forum, 2013.
poolcheating.pdf, 2011. [124] T. Ruffing, P. Moreno-Sanchez, and A. Kate, “Coinshuffle: Practical
[95] O. Schrijvers, J. Bonneau, D. Boneh, and T. Roughgarden, “Incentive decentralized coin mixing for Bitcoin,” in ESORICS. Springer, 2014.
compatibility of Bitcoin mining pool reward functions,” in Financial [125] J. H. Ziegeldorf, R. Matzutt, M. Henze, F. Grossmann, and K. Wehrle,
Crypto. Springer, 2016. “Secure and anonymous decentralized Bitcoin mixing,” Future
[96] S. Bag, S. Ruj, and K. Sakurai, “Bitcoin block withholding attack: Generation Computer Systems, vol. 80, 2018. [Online]. Available:
Analysis and mitigation,” IEEE Transactions on Information Forensics http://www.sciencedirect.com/science/article/pii/S0167739X16301297
and Security, vol. 12, no. 8, 2017. [126] S. Noether, “Ring signature confidential transactions for monero,”
[97] S. Bag and K. Sakurai, “Yet another note on block withholding attack 2015.
on Bitcoin mining pools,” in International Conference on Information [127] I. Miers, C. Garman, M. Green, and A. D. Rubin, “Zerocoin: Anony-
Security. Springer, 2016. mous distributed e-cash from bitcoin,” in 2013 IEEE Symposium on
[98] P2Pool.org, “P2Pool – Decentralized Bitcoin Mining Pool,” 2017. Security and Privacy. IEEE, 2013, pp. 397–411.
[Online]. Available: http://p2pool.org/ [128] E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer,
[99] A. Bessani, J. Sousa, and E. E. Alchieri, “State machine replication and M. Virza, “Zerocash: Decentralized anonymous payments from
for the masses with bft-smart,” in IEEE/IFIP DSN. IEEE, 2014. Bitcoin,” in IEEE S&P. IEEE, 2014.
[100] C. Cachin, “Yet another visit to paxos,” IBM Research, Zurich, Switzer- [129] E. Heilman, F. Baldimtsi, and S. Goldberg, “Blindly signed contracts:
land, Technical Report RZ3754, 2009. Anonymous on-blockchain and off-blockchain Bitcoin transactions,” in
[101] C. Cachin and M. Vukolić, “Blockchain consensus protocols in the FC. Springer, 2016.
wild,” 2017. [130] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille, and G. Maxwell,
[102] M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, “Hot- “Bulletproofs: Short proofs for confidential transactions and more,” in
stuff: Bft consensus with linearity and responsiveness,” in Proceedings 2018 IEEE Symposium on Security and Privacy (SP). IEEE, 2018,
of the 2019 ACM Symposium on Principles of Distributed Computing, pp. 315–334.
2019, pp. 347–356. [131] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk:
[103] M. Franklin, “A survey of key evolving cryptosystems,” International The blockchain model of cryptography and privacy-preserving smart
Journal of Security and Networks, vol. 1, no. 1-2, 2006. contracts,” in IEEE S&P. IEEE, 2016.
[104] M. Bellare and S. K. Miner, “A forward-secure digital signature [132] R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. Johnson, A. Juels,
scheme,” in CRYPTO’99. Springer, 1999. A. Miller, and D. Song, “Ekiden: A platform for confidentiality-
[105] P. Gaži, A. Kiayias, and A. Russell, “Stake-bleeding attacks on proof- preserving, trustworthy, and performant smart contracts,” in 2019 IEEE
of-stake blockchains,” in IEEE CVCBT. IEEE, 2018. European Symposium on Security and Privacy (EuroS&P). IEEE,
[106] M. Drijvers, S. Gorbunov, G. Neven, and H. Wee, “Pixel: Multi- 2019, pp. 185–200.
signatures for consensus,” in 29th {USENIX} Security Symposium [133] G. Zyskind, O. Nathan, and A. Pentland, “Enigma: Decentralized com-
({USENIX} Security 20), 2020, pp. 2093–2110. putation platform with guaranteed privacy,” ArXiv, vol. abs/1506.03471,
[107] QuantumMechanic, “Proof of stake instead of proof of work,” 2011. 2015.
[Online]. Available: https://bitcointalk.org/index.php?topic=27787.0 [134] B. Bünz, S. Agrawal, M. Zamani, and D. Boneh, “Zether:
[108] I. Bentov, A. Gabizon, and A. Mizrahi, “Cryptocurrencies without proof Towards privacy in a smart contract world,” IACR Cryptology
of work,” in FC. Springer, 2016. ePrint Archive, vol. 2019, p. 191, 2019. [Online]. Available:
[109] I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld, “Proof of activity: https://eprint.iacr.org/2019/191
Extending Bitcoin’s proof of work via proof of stake.” in ACM [135] S.-F. Sun, M. H. Au, J. K. Liu, and T. H. Yuen, “Ringct 2.0: A compact
SIGMETRICS, 2014. accumulator-based (linkable ring signature) protocol for blockchain
[110] I. Bentov, R. Pass, and E. Shi, “Snow white: Provably secure proofs cryptocurrency monero,” in European Symposium on Research in
of stake.” 2016. Computer Security. Springer, 2017, pp. 456–474.
 42

[136] Zeppelin Solutions, “Serpent compiler audit,” 2017. and K. Sako, Eds., vol. 10957. Springer, 2018, pp. 523–540. [Online].
[Online]. Available: https://docs.google.com/document/d/1 Available: https://doi.org/10.1007/978-3-662-58387-6 28
PqXuAkvgUAOG3jbBvaUvqN6W90eJ3N4IdTLNMRAijo/edit# [158] E. Hildenbrandt, M. Saxena, X. Zhu, N. Rodrigues, P. Daian, D. Guth,
heading=h.pe41jxc4c6xs and G. Rosu, “Kevm: A complete semantics of the Ethereum virtual
[137] F. Schrans, S. Eisenbach, and S. Drossopoulou, “Writing safe machine,” 2017.
smart contracts in Flint,” in Conference Companion of the 2nd [159] T. Abdellatif and K. Brousmiche, “Formal verification of smart
International Conference on Art, Science, and Engineering of contracts based on users and blockchain behaviors models,” in 9th IFIP
Programming, Nice, France, April 09-12, 2018, S. Marr and International Conference on New Technologies, Mobility and Security,
J. B. Sartor, Eds. ACM, 2018, pp. 218–219. [Online]. Available: NTMS 2018, Paris, France, February 26-28, 2018. IEEE, 2018, pp.
https://doi.org/10.1145/3191697.3213790 1–5. [Online]. Available: https://doi.org/10.1109/NTMS.2018.8328737
[138] N. Atzei, M. Bartoletti, and T. Cimoli, “A survey of attacks on [160] Y. Murray and D. A. Anisi, “Survey of formal verification methods for
Ethereum smart contracts (SoK),” in POST. Springer, 2017. smart contracts on blockchain,” in 10th IFIP International Conference
[139] A. Manning, “Solidity security: Comprehensive list of known attack on New Technologies, Mobility and Security, NTMS 2019, Canary
vectors and common anti-patterns,” https://blog.sigmaprime.io/solidity- Islands, Spain, June 24-26, 2019. IEEE, 2019, pp. 1–6. [Online].
security.html, 2018. Available: https://doi.org/10.1109/NTMS.2019.8763832
[140] Aion Foundation, “List of historical vulnerabilities.” [On- [161] X. Bai, Z. Cheng, Z. Duan, and K. Hu, “Formal modeling and
line]. Available: https://learn.aion.network/docs/list-of-historical-big- verification of smart contracts,” in Proceedings of the 7th International
vulnerabilities Conference on Software and Computer Applications, ICSCA 2018,
[141] SmartContractSecurity, “Smart contract weakness classifica- Kuantan, Malaysia, February 08-10, 2018, K. Z. Zamli, V. Mezhuyev,
tion registry,” 2019. [Online]. Available: https://github.com/ and L. Benedicenti, Eds. ACM, 2018, pp. 322–326. [Online].
SmartContractSecurity/SWC-registry/ Available: https://doi.org/10.1145/3185089.3185138
[142] Trailofbits, “Awesome Ethereum security,” 11 Aug 2018. [Online]. [162] Z. Nehai, P. Piriou, and F. F. Daumas, “Model-checking
Available: https://github.com/trailofbits/awesome-ethereum-security of smart contracts,” in IEEE International Conference on
[143] R. M. Parizi, A. Dehghantanha, K.-K. R. Choo, and A. Singh, “Empir- Internet of Things (iThings) and IEEE Green Computing and
ical vulnerability analysis of automated smart contracts security testing Communications (GreenCom) and IEEE Cyber, Physical and
on blockchains,” in Proceedings of the 28th Annual International Social Computing (CPSCom) and IEEE Smart Data (SmartData),
Conference on Computer Science and Software Engineering. IBM iThings/GreenCom/CPSCom/SmartData 2018, Halifax, NS, Canada,
Corp., 2018. July 30 - August 3, 2018. IEEE, 2018, pp. 980–987. [Online].
[144] Consensys, “Security tools,” 2016. [Online]. Available: https: Available: https://doi.org/10.1109/Cybermatics 2018.2018.00185
//consensys.github.io/smart-contract-best-practices/security tools/ [163] S. Kalra, S. Goel, M. Dhawan, and S. Sharma, “ZEUS: analyzing
[145] S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy, R. Takhaviev, safety of smart contracts,” in 25th Annual Network and Distributed
E. Marchenko, and Y. Alexandrov, “Smartcheck: Static analysis of System Security Symposium, NDSS 2018, San Diego, California,
ethereum smart contracts,” in 2018 IEEE/ACM 1st International Work- USA, February 18-21, 2018. The Internet Society, 2018. [Online].
shop on Emerging Trends in Software Engineering for Blockchain Available: http://wp.internetsociety.org/ndss/wp-content/uploads/sites/
(WETSEB). IEEE, 2018, pp. 9–16. 25/2018/02/ndss2018 09-1 Kalra paper.pdf
[146] R. Dua, “Solium documentation release 1.0.0,” 11 Feb 2019. [Online]. [164] I. Grishchenko, M. Maffei, and C. Schneidewind, “A semantic
Available: https://media.readthedocs.org/pdf/solium/latest/solium.pdf framework for the security analysis of Ethereum smart contracts,” in
[147] J. Chang, B. Gao, H. Xiao, J. Sun, Y. Cai, and Z. Yang, “sCompile: Principles of Security and Trust - 7th International Conference, POST
Critical path identification and analysis for smart contracts,” in Formal 2018, Held as Part of the European Joint Conferences on Theory and
Methods and Software Engineering - 21th International Conference Practice of Software, ETAPS 2018, Thessaloniki, Greece, April 14-20,
on Formal Engineering Methods, ICFEM 2019, Shenzhen, China, 2018, Proceedings, ser. Lecture Notes in Computer Science, L. Bauer
November 5th-9th, 2019, Proceedings. Springer, 2019. and R. Küsters, Eds., vol. 10804. Springer, 2018, pp. 243–269.
[148] P. Hartel and M. van Staalduinen, “Truffle tests for free – replaying [Online]. Available: https://doi.org/10.1007/978-3-319-89722-6 10
Ethereum smart contracts for transparency,” Singapore Univ. of [165] Y. Zhou, D. Kumar, S. Bakshi, J. Mason, A. Miller, and M. Bailey,
Technology and Design, Singapore, Technical Report, Jul 2019. “Erays: reverse engineering Ethereum’s opaque smart contracts,” in
[Online]. Available: https://arxiv.org/abs/1907.09208 USENIX Security, 2018.
[149] M. Sutton, A. Greene, and P. Amini, Fuzzing: brute force vulnerability [166] M. Suiche, “Porosity: A decompiler for blockchain-based smart con-
discovery. Pearson Education, 2007. tracts bytecode,” DEF CON, vol. 25, 2017.
[150] B. Jiang, Y. Liu, and W. Chan, “Contractfuzzer: Fuzzing smart contracts [167] I. Nikolić, A. Kolluri, I. Sergey, P. Saxena, and A. Hobor, “Finding
for vulnerability detection,” in Proceedings of the 33rd ACM/IEEE the greedy, prodigal, and suicidal contracts at scale,” in Proceedings of
International Conference on Automated Software Engineering. ACM, the 34th Annual Computer Security Applications Conference, ACSAC
2018. 2018, San Juan, PR, USA, December 03-07, 2018. ACM, 2018.
[151] V. Wüstholz and M. Christakis, “Harvey: A greybox fuzzer for smart [168] N. Grech, M. Kong, A. Jurisevic, L. Brent, B. Scholz, and
contracts,” CoRR, vol. abs/1905.06944, 2019. [Online]. Available: Y. Smaragdakis, “Madmax: surviving out-of-gas conditions in
http://arxiv.org/abs/1905.06944 Ethereum smart contracts,” PACMPL, vol. 2, no. OOPSLA, pp. 116:1–
[152] J. C. King, “Symbolic execution and program testing,” 116:27, 2018. [Online]. Available: https://doi.org/10.1145/3276486
Communincations of the ACM, vol. 19, no. 7, pp. 385–394, [169] L. Brent, A. Jurisevic, M. Kong, E. Liu, F. Gauthier, V. Gramoli,
1976. [Online]. Available: https://doi.org/10.1145/360248.360252 R. Holz, and B. Scholz, “Vandal: A scalable security analysis
[153] P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Buenzli, and framework for smart contracts,” CoRR, vol. abs/1809.03981, 2018.
M. Vechev, “Securify: Practical security analysis of smart contracts,” [Online]. Available: http://arxiv.org/abs/1809.03981
in ACM CCS. ACM, 2018. [170] J. Krupp and C. Rossow, “teether: Gnawing at Ethereum to automati-
[154] Trailofbits, “Manticore documentation release 0.1.0,” 2019. cally exploit smart contracts,” in USENIX Security, 2018.
[Online]. Available: https://media.readthedocs.org/pdf/manticore/latest/ [171] S. Popejoy, “The Pact smart contract language,” http://kadena.io/docs/
manticore.pdf Kadena-PactWhitepaper.pdf, 2016.
[155] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making [172] I. Sergey, V. Nagaraj, J. Johannsen, A. Kumar, A. Trunov, and
smart contracts smarter,” in ACM CCS. ACM, 2016. K. C. G. Hao, “Safer smart contract programming with scilla,” Proc.
[156] C. F. Torres, J. Schütte, and R. State, “Osiris: Hunting for integer ACM Program. Lang., vol. 3, no. OOPSLA, pp. 185:1–185:30, 2019.
bugs in Ethereum smart contracts,” in Proceedings of the 34th Annual [Online]. Available: https://doi.org/10.1145/3360611
Computer Security Applications Conference, ACSAC 2018, San Juan, [173] R. Klomp and A. Bracciali, “On symbolic verification of Bitcoin’s
PR, USA, December 03-07, 2018. ACM, 2018, pp. 664–676. script language,” in Data Privacy Management, Cryptocurrencies and
[Online]. Available: https://doi.org/10.1145/3274694.3274737 Blockchain Technology - ESORICS 2018 International Workshops,
[157] A. Mavridou and A. Laszka, “Designing secure ethereum smart DPM 2018 and CBT 2018, Barcelona, Spain, September 6-
contracts: A finite state machine based approach,” in Financial 7, 2018, Proceedings, ser. Lecture Notes in Computer Science,
Cryptography and Data Security - 22nd International Conference, FC J. Garcı́a-Alfaro, J. Herrera-Joancomartı́, G. Livraga, and R. Rios,
2018, Nieuwpoort, Curaçao, February 26 - March 2, 2018, Revised Eds., vol. 11025. Springer, 2018, pp. 38–56. [Online]. Available:
Selected Papers, ser. Lecture Notes in Computer Science, S. Meiklejohn https://doi.org/10.1007/978-3-030-00305-0 3
 43

[174] R. O’Connor, “Simplicity: A new language for blockchains,” in [198] P. Szalachowski, “PADVA: A blockchain-based TLS notary service,”
Proceedings of the 2017 Workshop on Programming Languages in 25th IEEE International Conference on Parallel and Distributed
and Analysis for Security, PLAS@CCS 2017, Dallas, TX, USA, Systems, ICPADS 2019, Tianjin, China, December 4-6, 2019.
October 30, 2017. ACM, 2017, pp. 107–120. [Online]. Available: IEEE, 2019, pp. 836–843. [Online]. Available: https://doi.org/10.1109/
https://doi.org/10.1145/3139337.3139340 ICPADS47876.2019.00124
[175] MME, “Conceptual framework for legal and risk as- [199] J. Guarnizo and P. Szalachowski, “PDFS: practical data feed service
sessment of crypto tokens,” 2018. [Online]. Avail- for smart contracts,” in Computer Security - ESORICS 2019 - 24th
able: https://www.mme.ch/fileadmin/files/documents/180501 BCP European Symposium on Research in Computer Security, Luxembourg,
Framework for Assessment of Crypto Tokens - Block 2.pdf September 23-27, 2019, Proceedings, Part I, 2019, pp. 767–789.
[176] S. Eskandari, J. Clark, D. Barrera, and E. Stobert, “A first look at the [200] S. Ellis, A. Juels, and S. Nazarov, “ChainLink: A Decentralized
usability of Bitcoin key management,” 2018. Oracle Network,” 2017. [Online]. Available: https://link.smartcontract.
[177] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. com/whitepaper
Felten, “Sok: Research perspectives and challenges for Bitcoin and [201] J. Peterson and J. Krug, “Augur: a decentralized, open-source platform
cryptocurrencies,” in IEEE S&P. IEEE, 2015. for prediction markets,” ArXiv, vol. abs/1501.01042, 2015.
[178] I. Homoliak, D. Breitenbacher, O. Hujnak, P. Hartel, A. Binder, and [202] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town Crier:
P. Szalachowski, “Smartotps: An air-gapped 2-factor authentication for An authenticated data feed for smart contracts,” in ACM CCS. ACM,
smart-contract wallets,” 2020. 2016.
[179] Wolfie Zhao, “Bithumb $31 Million Crypto Exchange Hack: What We [203] A. S. de Pedro, D. Levi, and L. I. Cuende, “Witnet: A decentralized
Know (And Don’t),” 2018. [Online]. Available: https://www.coindesk. oracle network protocol,” arXiv preprint arXiv:1711.09756, 2017.
com/bithumb-exchanges-31-million-hack-know-dont-know/ [204] S. A. Crosby and D. S. Wallach, “Efficient data structures for tamper-
evident logging.” in USENIX Security Symposium, 2009, pp. 317–334.
[180] Rachel Abrams and Nathaniel Popper, “Trading Site
[205] Proovable Team, “The Provable blockchain oracle for modern DApps,”
Failure Stirs Ire and Hope for Bitcoin,” 2014. [On-
2019. [Online]. Available: https://www.oraclize.it/
line]. Available: https://dealbook.nytimes.com/2014/02/25/trading-site-
[206] S. Sen and J. Wang, “Analyzing peer-to-peer traffic across
failure-stirs-ire-and-hope-for-bitcoin/
large networks,” p. 219–232, Apr. 2004. [Online]. Available:
[181] Reuters, “Bitcoin Worth $72M was Stolen in Bitfinex Exchange Hack https://doi.org/10.1109/TNET.2004.826277
in Hong Kong,” 2016. [Online]. Available: http://fortune.com/2016/ [207] H. Kopp, C. Bösch, and F. Kargl, “Koppercoin–a distributed file storage
08/03/bitcoin-stolen-bitfinex-hack-hong-kong/ with financial incentives,” in International Conference on Information
[182] Dell SecureWorks, “Cryptocurrency-stealing malware Security Practice and Experience. Springer, 2016, pp. 79–93.
landscape,” Dell SecureWorks, 2015. [Online]. [208] J. Benet, D. Dalrymple, and N. Greco, “Proof of replication,” Protocol
Available: http://www.opensource.im/cryptocurrency/cryptocurrency- Labs, July, vol. 27, 2017.
stealing-malware-landscape-dell-secureworks.php [209] C. Fromknecht, D. Velicanu, and S. Yakoubov, “A decentralized public
[183] A. Peyton, “Cyren sounds siren over Bitcoin siphon scam,” FinTech key infrastructure with identity retention.” IACR Cryptology ePrint
Futures, 2017. [Online]. Available: https://www.bankingtech.com/ Archive, vol. 2014, p. 803, 2014.
2017/01/cyren-sounds-siren-over-bitcoin-siphon-scam/ [210] Z. Wilcox-O’Hearn, “Names: Decentralized, secure, human-
[184] S. Goldfeder, R. Gennaro, H. Kalodner, J. Bonneau, J. A. Kroll, meaningful: Choose two,” https://web.archive.org/web/
E. W. Felten, and A. Narayanan, “Securing Bitcoin wallets via a new 20011020191610/http://zooko.com/distnames.html, 2003.
DSA/ECDSA threshold signature scheme,” 2015. [211] M. Ali, J. Nelson, R. Shea, and M. J. Freedman, “Bootstrapping trust
[185] M. Westerkamp and J. Eberhardt, “zkrelay: Facilitating sidechains in distributed systems with blockchains,” USENIX Magazine, vol. 41,
using zksnark-based chain-relays,” Contract, vol. 1, no. 2, p. 3, 2020. no. 3, 2016.
[186] M. Herlihy, “Atomic cross-chain swaps,” in Proceedings of the 2018 [212] C. Lundkvist, R. Heck, J. Torstensson, Z. Mitton, and M. Sena, “uPort:
ACM Symposium on Principles of Distributed Computing. ACM, a platform for self-sovereign identity,” 2016. [Online]. Available:
2018, pp. 245–254. http://blockchainlab.com/pdf/uPort whitepaper DRAFT20161020.pdf
[187] W. Warren and A. Bandeali, “0x: An open protocol for decen- [213] S. Inc., “Shocard: Identity management verified using the blockchain,”
tralized exchange on the ethereum blockchain,” URl: https://github. 2017. [Online]. Available: http://shocard.com/wp-content/uploads/
com/0xProject/whitepaper, 2017. 2018/01/ShoCard-Whitepaper-Dec13-2.pdf
[188] H. Berg, T. A. Proebsting et al., “Hanson’s automated market maker,” [214] A. Tobin and D. Reed, “The inevitable rise of self-sovereign identity,”
Journal of Prediction Markets, vol. 3, no. 1, pp. 45–59, 2009. 2016. [Online]. Available: https://sovrin.org/wp-content/uploads/2018/
[189] N. Johnson, “Euler: The simplest exchange and token currency,” 2016. 03/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf
[Online]. Available: https://www.reddit.com/r/ethereum/comments/ [215] W3C community, “Decentralized Identifiers (DIDs),” 2019. [Online].
54l32y/euler the simplest exchange and currency/ Available: https://w3c-ccg.github.io/did-spec/
[190] E. Hertzog, G. Benartzi, and G. Benartzi, “Bancor Protocol: [216] H. A. Kalodner, M. Carlsten, P. Ellenbogen, J. Bonneau, and
A Hierarchical Monetary System and the Foundation of A. Narayanan, “An empirical study of Namecoin and lessons for
a Global Decentralized Autonomous Exchange,” 2017. [On- decentralized namespace design.” in WEIS. Citeseer, 2015.
line]. Available: https://www.regulus.com/wp-content/uploads/2018/ [217] J. Clark and A. Essex, “Commitcoin: Carbon dating commitments with
11/BancorProtocolWhitepaperPublicDraftv0.7.pdf Bitcoin,” in International Conference on Financial Cryptography and
Data Security. Springer, 2012, pp. 390–398.
[191] A. Zamyatin, M. Al-Bassam, D. Zindros, E. Kokoris-Kogias,
[218] B. Gipp, N. Meuschke, and A. Gernandt, “Decentralized trusted
P. Moreno-Sanchez, A. Kiayias, and W. J. Knottenbelt, “Sok: Commu-
timestamping using the crypto currency Bitcoin,” CoRR, vol.
nication across distributed ledgers,” IACR Cryptology ePrint Archive,
abs/1502.04015, 2015.
vol. 2019, p. 1128, 2019.
[219] A. Kiayias and M. Yung, “Self-tallying elections and perfect ballot
[192] K. Oosthoek and C. Doerr, “From hodl to heist: Analysis of cyber secrecy,” in Public Key Cryptography, D. Naccache and P. Paillier, Eds.
security threats to bitcoin exchanges,” in 2020 IEEE International Berlin, Heidelberg: Springer Berlin Heidelberg, 2002, pp. 141–158.
Conference on Blockchain and Cryptocurrency (ICBC), 2020. [220] J. Groth, “Efficient maximal privacy in boardroom voting and anony-
[193] I. Bentov, Y. Ji, F. Zhang, Y. Li, X. Zhao, L. Breidenbach, P. Daian, and mous broadcast,” in Financial Cryptography, A. Juels, Ed. Berlin,
A. Juels, “Tesseract: Real-time cryptocurrency exchange using trusted Heidelberg: Springer Berlin Heidelberg, 2004, pp. 90–104.
hardware.” IACR Cryptology ePrint Archive, vol. 2017, p. 1153, 2017. [221] D. L. Chaum, “Untraceable electronic mail, return addresses, and
[194] J. Poon and T. Dryja, “The Bitcoin lightning network: Scalable off- digital pseudonyms,” Communincations of the ACM, vol. 24, no. 2,
chain instant payments,” 2016. pp. 84–90, Feb. 1981. [Online]. Available: http://doi.acm.org/10.1145/
[195] G. Avarikioti, F. Laufenberg, J. Sliwinski, Y. Wang, and R. Wattenhofer, 358549.358563
“Towards secure and efficient payment channels,” CoRR, 2018. [222] J. D. Cohen and M. J. Fischer, “A robust and verifiable
[196] P. McCorry, S. Bakshi, I. Bentov, A. Miller, and S. Meiklejohn, “Pisa: cryptographically secure election scheme,” in Proceedings of the 26th
Arbitration outsourcing for state channels,” IACR Cryptology ePrint Annual Symposium on Foundations of Computer Science, ser. SFCS
Archive, https:// eprint.iacr.org/ 2018/ 582, 2018. ’85. Washington, DC, USA: IEEE Computer Society, 1985, pp.
[197] B. Liu, P. Szalachowski, and S. Sun, “Fail-safe watchtowers and short- 372–382. [Online]. Available: https://doi.org/10.1109/SFCS.1985.2
lived assertions for payment channels,” The 15th ACM ASIA Conference [223] P. Boucher, “What if blockchain technology revolutionised voting,”
on Computer and Communications Security (AsiaCCS’20), 2020. Unpublished manuscript, European Parliament, 2016.
 44

[224] P. McCorry, S. F. Shahandashti, and F. Hao, “A smart contract for [245] T. Hardjono and N. Smith, “Cloud-based commissioning of constrained
boardroom voting with maximum voter privacy,” in Financial Cryp- devices using permissioned blockchains,” in Proceedings of the 2nd
tography and Data Security - 21st International Conference, FC 2017, ACM international workshop on IoT privacy, trust, and security. ACM,
Sliema, Malta, April 3-7, 2017, Revised Selected Papers, 2017, pp. 2016, pp. 29–36.
357–375. [246] B. Liu, X. L. Yu, S. Chen, X. Xu, and L. Zhu, “Blockchain based data
[225] W. Zhang, Y. Yuan, Y. Hu, S. Huang, S. Cao, A. Chopra, and S. Huang, integrity service framework for IoT data,” in 2017 IEEE International
“A privacy-preserving voting protocol on blockchain,” in 11th IEEE Conference on Web Services (ICWS), June 2017, pp. 468–475.
International Conference on Cloud Computing, CLOUD 2018, San [247] D. Bhowmik and T. Feng, “The multimedia blockchain: A distributed
Francisco, CA, USA, July 2-7, 2018, 2018, pp. 401–408. and tamper-proof media transaction framework,” in 2017 22nd Inter-
[226] S. Venugopalan, I. Homoliak, Z. Li, and P. Szalachowski, “Bbb-voting: national Conference on Digital Signal Processing (DSP), Aug 2017,
1-out-of-k blockchain-based boardroom voting,” 2020. pp. 1–5.
[227] Y. Li, W. Susilo, G. Yang, Y. Yu, D. Liu, and M. Guizani, “A [248] A. Tomescu and S. Devadas, “Catena: Efficient non-equivocation via
blockchain-based self-tallying voting scheme in decentralized IoT,” Bitcoin,” in 2017 IEEE Symposium on Security and Privacy (SP), May
CoRR, vol. abs/1902.03710, 2019. 2017, pp. 393–409.
[228] J. Benaloh and D. Tuinstra, “Receipt-free secret-ballot elections [249] M. Al-Bassam and S. Meiklejohn, “Contour: A practical system for
(extended abstract),” in Proceedings of the Twenty-sixth Annual binary transparency,” in Data Privacy Management, Cryptocurrencies
ACM Symposium on Theory of Computing, ser. STOC ’94. New and Blockchain Technology. Springer, 2018, pp. 94–110.
York, NY, USA: ACM, 1994, pp. 544–553. [Online]. Available: [250] D. Breitenbacher, I. Homoliak, Y. L. Aung, N. O. Tippenhauer, and
http://doi.acm.org/10.1145/195058.195407 Y. Elovici, “HADES-IoT: A Practical Host-Based Anomaly Detection
[229] O. Baudron, P.-A. Fouque, D. Pointcheval, J. Stern, and G. Poupard, System for IoT Devices,” in Proceedings of the 2019 ACM Asia
“Practical multi-candidate election system,” in Proceedings of the twen- Conference on Computer and Communications Security, AsiaCCS
tieth annual ACM symposium on Principles of distributed computing. 2019, Auckland, New Zealand, July 09-12, 2019, 2019, pp. 479–484.
ACM, 2001, pp. 274–283. [251] J. Guarnizo and P. Szalachowski, “Pdfs: Practical data feed service for
[230] K. Sako and J. Kilian, “Receipt-free mix-type voting scheme,” in smart contracts,” 2018.
Advances in Cryptology — EUROCRYPT ’95, L. C. Guillou and J.- [252] I. Homoliak and P. Szalachowski, “Aquareum: A centralized ledger
J. Quisquater, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, enhanced with blockchain and trusted computing,” ArXiv, vol.
1995, pp. 393–403. abs/2005.13339, 2020.
[231] R. Canetti and R. Gennaro, “Incoercible multiparty computation,” in [253] R. Paccagnella, P. Datta, W. U. Hassan, A. Bates, C. W. Fletcher,
Proceedings of 37th Conference on Foundations of Computer Science, A. Miller, and D. Tian, “Custos: Practical tamper-evident auditing of
Oct 1996, pp. 504–513. operating systems using trusted execution,” in Proc. of the Symposium
[232] R. Canetti, C. Dwork, M. Naor, and R. Ostrovsky, “Deniable encryp- on Network and Distributed System Security (NDSS), 2020.
tion,” in Advances in Cryptology — CRYPTO ’97, B. S. Kaliski, Ed. [254] National Notary Association, CA, “What is notarization?” 2019.
Berlin, Heidelberg: Springer Berlin Heidelberg, 1997, pp. 90–104. [Online]. Available: https://www.nationalnotary.org/knowledge-center/
[233] O. Baudron, P.-A. Fouque, D. Pointcheval, J. Stern, and G. Poupard, about-notaries/what-is-notarization
“Practical multi-candidate election system,” in Proceedings of the [255] Heleness, “Blockchain-based notarization platform on Ethereum,”
Twentieth Annual ACM Symposium on Principles of Distributed Com- 2018. [Online]. Available: https://ethresear.ch/t/blockchain-based-
puting, ser. PODC ’01. New York, NY, USA: ACM, 2001, pp. 274– notarization-platform-on-ethereum/5326
283. [256] ERC-725 Alliance, “Erc-725: Ethereum identity standard,” 2018.
[234] D. Khader, B. Smyth, P. Y. A. Ryan, and F. Hao, “A fair and robust [Online]. Available: https://erc725alliance.org/
voting system by broadcast,” in 5th International Conference on [257] K. Rantos, G. Drosatos, K. Demertzis, C. Ilioudis, and A. Papaniko-
Electronic Voting 2012, (EVOTE 2012), Co-organized by the Council laou, “Blockchain-based consents management for personal data pro-
of Europe, Gesellschaft für Informatik and E-Voting.CC, July 11-14, cessing in the IoT ecosystem.” in ICETE (2), 2018, pp. 738–743.
2012, Castle Hofen, Bregenz, Austria, 2012, pp. 285–299. [Online]. [258] A. Mizrahi, “A blockchain-based property ownership recording sys-
Available: https://dl.gi.de/20.500.12116/18220 tem,” A Blockchain-based Property Ownership Recording System,
[235] A. Schaub, R. Bazin, O. Hasan, and L. Brunie, “A trustless privacy- 2015.
preserving reputation system,” in IFIP International Conference on ICT [259] B. Notheisen, J. B. Cholewa, and A. P. Shanmugam, “Trading real-
Systems Security and Privacy Protection. Springer, 2016, pp. 398–411. world assets on blockchain,” Business & Information Systems Engi-
[236] D. Carboni, “Feedback based reputation on top of the Bitcoin neering, vol. 59, no. 6, pp. 425–440, 2017.
blockchain,” CoRR, vol. abs/1502.01504, 2015. [Online]. Available: [260] G. Andresen and M. Hearn, “Bip-70,” 2016. [Online]. Available:
http://arxiv.org/abs/1502.01504 https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
[237] K. Zhao, S. Tang, B. Zhao, and Y. Wu, “Dynamic and privacy- [261] P. McCorry, S. F. Shahandashti, and F. Hao, “Refund attacks on
preserving reputation management for blockchain-based mobile crowd- Bitcoin’s payment protocol,” in International Conference on Financial
sensing,” IEEE Access, vol. 7, pp. 74 694–74 710, 2019. Cryptography and Data Security. Springer, 2016, pp. 581–599.
[238] A. Grech and A. F. Camilleri, “Blockchain in education,” 2017. [262] S. Goldfeder, J. Bonneau, R. Gennaro, and A. Narayanan, “Escrow
[239] P. Buneman, S. Khanna, and T. Wang-Chiew, “Why and where: A protocols for cryptocurrencies: How to buy physical goods using
characterization of data provenance,” in International conference on Bitcoin,” in International Conference on Financial Cryptography and
database theory. Springer, 2001, pp. 316–330. Data Security. Springer, 2017, pp. 321–339.
[240] N. Kshetri, “1 blockchain’s roles in meeting key supply chain [263] O. R. Kabi and V. N. Franqueira, “Blockchain-based distributed
management objectives,” International Journal of Information marketplace,” in International Conference on Business Information
Management, vol. 39, pp. 80 – 89, 2018. [Online]. Available: Systems. Springer, 2018, pp. 197–210.
http://www.sciencedirect.com/science/article/pii/S0268401217305248 [264] N. Christin, “Traveling the silk road: A measurement analysis of a
[241] Deloitte, “Continuous interconnected supply chain Us- large anonymous online marketplace,” in Proceedings of the 22nd
ing Blockchain and Internet-of-Things in sup- international conference on World Wide Web. ACM, 2013, pp. 213–
ply chain traceability,” 2017. [Online]. Avail- 224.
able: https://www2.deloitte.com/content/dam/Deloitte/lu/Documents/ [265] H. S. Galal and A. M. Youssef, “Verifiable sealed-bid auction on
technology/lu-blockchain-internet-things-supply-chain-traceability.pdf the Ethereum blockchain,” in International Conference on Financial
[242] H. M. Kim and M. Laskowski, “Toward an ontology-driven blockchain Cryptography and Data Security. Springer, 2018, pp. 265–278.
design for supply-chain provenance,” Intelligent Systems in Accounting, [266] H. Galal and A. Youssef, “Succinctly verifiable sealed-bid auction
Finance and Management, vol. 25, no. 1, pp. 18–27, 2018. smart contract,” in Data Privacy Management, Cryptocurrencies and
[243] S. Shetty, V. Red, C. Kamhoua, K. Kwiat, and L. Njilla, “Data Blockchain Technology. Springer, 2018, pp. 3–19.
provenance assurance in the cloud using blockchain,” in Disruptive [267] H. S. Galal and A. M. Youssef, “Trustee: Full privacy preserving
Technologies in Sensors and Sensor Systems, vol. 10206. International vickrey auction on top of ethereum,” in Financial Cryptography
Society for Optics and Photonics, 2017, p. 102060I. and Data Security - FC 2019 International Workshops, VOTING
[244] C. Jaag and C. Bach, “Blockchain technology and cryptocurrencies: and WTSC, St. Kitts, St. Kitts and Nevis, February 18-22, 2019,
Opportunities for postal financial services,” in The Changing Postal Revised Selected Papers, ser. Lecture Notes in Computer Science,
and Delivery Sector. Springer, 2017, pp. 205–221. A. Bracciali, J. Clark, F. Pintore, P. B. Rønne, and M. Sala,
 45

Eds., vol. 11599. Springer, 2019, pp. 190–207. [Online]. Available: [291] M. Saad, J. Spaulding, L. Njilla, C. A. Kamhoua, S. Shetty, D. Nyang,
https://doi.org/10.1007/978-3-030-43725-1 14 and A. Mohaisen, “Exploring the attack surface of blockchain: A
[268] E.-O. Blass and F. Kerschbaum, “Strain: A secure auction for systematic overview,” ArXiv, vol. abs/1904.03487, 2019.
blockchains,” in European Symposium on Research in Computer Secu- [292] H. Chen, M. Pendleton, L. Njilla, and S. Xu, “A survey on ethereum
rity. Springer, 2018, pp. 87–110. systems security: Vulnerabilities, attacks, and defenses,” ACM Com-
[269] J. Ma, B. Qi, and K. Lv, “Fully private auctions for the highest bid,” in puting Surveys (CSUR), vol. 53, no. 3, pp. 1–43, 2020.
Proceedings of the ACM Turing Celebration Conference-China. ACM, [293] D. Floyd, “150K Stolen From MyEtherWallet Users in DNS Server
2019, p. 64. Hijacking,” 2018. [Online]. Available: https://www.coindesk.com/
[270] C. Esposito, A. De Santis, G. Tortora, H. Chang, and K.-K. R. Choo, 150k-stolen-myetherwallet-users-dns-server-hijacking
“Blockchain: A panacea for healthcare cloud-based data security and [294] L. Poinsignon, “BGP leaks and cryptocurrencies,” 2018.
privacy?” IEEE Cloud Computing, vol. 5, no. 1, pp. 31–37, 2018. [Online]. Available: https://blog.cloudflare.com/bgp-leaks-and-crypto-
[271] G. Liang, S. R. Weller, F. Luo, J. Zhao, and Z. Y. Dong, “Distributed currencies/
blockchain-based data protection framework for modern power systems [295] R. Zhang, R. Xue, and L. Liu, “Security and privacy on blockchain,”
against cyber attacks,” IEEE Transactions on Smart Grid, vol. 10, no. 3, ACM Computing Surveys, vol. 52, no. 3, Jul. 2019. [Online]. Available:
pp. 3162–3173, 2018. https://doi.org/10.1145/3316481
[272] P. K. Sharma, S. Singh, Y.-S. Jeong, and J. H. Park, “Distblocknet: A [296] A. Alkhalifah, A. Ng, A. Kayes, J. Chowdhury, M. Alazab, and
distributed blockchains-based secure sdn architecture for iot networks,” P. Watters, “A taxonomy of blockchain threats and vulnerabilities,”
IEEE Communications Magazine, vol. 55, no. 9, pp. 78–85, 2017. Unpublished, 2019.
[273] E. Gaetani, L. Aniello, R. Baldoni, F. Lombardi, A. Margheri, and [297] L. Zhu, B. Zheng, M. Shen, S. Yu, F. Gao, H. Li, K. Shi, and K. Gai,
V. Sassone, “Blockchain-based database to ensure data integrity in “Research on the security of blockchain data: A survey,” ArXiv, vol.
cloud computing environments,” in Proceedings of the First Italian abs/1812.02009, 2018.
Conference on Cybersecurity (ITASEC17), Venice, Italy, January 17- [298] C. Natoli, J. Yu, V. Gramoli, and P. Verı́ssimo, “Deconstructing
20, 2017., 2017, pp. 146–155. blockchains: A comprehensive survey on consensus, membership and
[274] A. Dorri, S. S. Kanhere, and R. Jurdak, “Towards an optimized structure,” ArXiv, vol. abs/1908.08316, 2019.
blockchain for IoT,” in Proceedings of the Second International Confer- [299] T. Neudecker and H. Hartenstein, “Network layer aspects of per-
ence on Internet-of-Things Design and Implementation. ACM, 2017, missionless blockchains,” IEEE Communications Surveys & Tutorials,
pp. 173–178. vol. 21, no. 1, pp. 838–857, 2018.
[275] M. Carlsten, H. A. Kalodner, S. M. Weinberg, and A. Narayanan, [300] D. Harz and W. Knottenbelt, “Towards safer smart contracts: A survey
“On the instability of Bitcoin without the block reward,” in of languages and verification methods,” ArXiv, vol. abs/1809.09805,
Proceedings of the 2016 ACM SIGSAC Conference on Computer 2018.
and Communications Security, 2016. [Online]. Available: http: [301] M. Di Angelo and G. Salzer, “A survey of tools for analyzing
//doi.acm.org/10.1145/2976749.2978408 Ethereum smart contracts,” in 2019 IEEE International Conference on
[276] S. Leonardos, D. Reijsbergen, and G. Piliouras, “Presto: A systematic Decentralized Applications and Infrastructures (DAPPCON). IEEE,
framework for blockchain consensus protocols,” IEEE Transactions on 2019.
Engineering Management, 2020. [302] Y. Xiao, N. Zhang, W. Lou, and Y. T. Hou, “A survey of distributed
[277] K. Wüst and A. Gervais, “Do you need a blockchain?” in 2018 Crypto consensus protocols for blockchain networks,” IEEE Communications
Valley Conference on Blockchain Technology (CVCBT). IEEE, 2018, Surveys & Tutorials, vol. 22, pp. 1432–1465, 2020.
pp. 45–54. [303] J. A. Garay and A. Kiayias, “SoK: A consensus taxonomy in the
[278] A. Lenk, M. Klems, J. Nimis, S. Tai, and T. Sandholm, “What’s inside blockchain era.” IACR Cryptology ePrint Archive, vol. 2018, p. 754,
the cloud? an architectural map of the cloud landscape,” in 2009 ICSE 2018.
workshop on software engineering challenges of cloud computing. [304] A. Shahaab, B. Lidgey, C. Hewage, and I. Khan, “Applicability and
IEEE, 2009, pp. 23–31. appropriateness of distributed ledgers consensus protocols in public
[279] J. Verschuren, R. Govaerts, and J. Vandewalle, “Iso-osi security archi- and private sectors: A systematic review,” IEEE Access, vol. 7, pp.
tecture,” in Computer Security and Industrial Cryptography. Springer, 43 622–43 636, 2019.
1993, pp. 179–192. [305] S. Azouvi and A. Hicks, “SoK: Tools for game theoretic models of
[280] S. M. Bellovin, “Security problems in the tcp/ip protocol suite,” ACM security for cryptocurrencies,” ArXiv, vol. abs/1905.08595, 2019.
SIGCOMM Computer Communication Review, vol. 19, no. 2, pp. 32– [306] J. Huang, K. Lei, M. Du, H. Zhao, H. Liu, J. Liu, and Z. Qi, “Survey
48, 1989. on blockchain incentive mechanism,” in International Conference of
[281] P. Pritzker and W. E. May, “Secure Hash Standard (SHS),” National Pioneering Computer Scientists, Engineers and Educators. Springer,
Institute of Standards and Technology, Tech. Rep., 2015. 2019, pp. 386–395.
[282] R. Cavanagh, “Federal Information Processing Standard (FIPS) 186- [307] A. Panarello, N. Tapas, G. Merlino, F. Longo, and A. Puliafito,
4, Digital Signature Standard; Request for Comments on the NIST- “Blockchain and IoT integration: A systematic survey,” Sensors,
Recommended Elliptic Curves,” National Institute of Standards and vol. 18, no. 8, p. 2575, 2018.
Technology, Tech. Rep., 2015. [308] M. S. Ali, M. Vecchio, M. Pincheira, K. Dolui, F. Antonelli, and M. H.
[283] A. Narayanan, “Analyzing the 2013 Bitcoin fork: centralized Rehmani, “Applications of blockchains in the Internet of Things: A
decision-making saved the day,” 2018. [Online]. Avail- comprehensive survey,” IEEE Communications Surveys & Tutorials,
able: https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013- vol. 21, no. 2, pp. 1676–1717, 2018.
bitcoin-fork-centralized-decision-making-saved-the-day/ [309] F. Restuccia, S. D’Oro, S. S. Kanhere, T. Melodia, and S. K. Das,
[284] A. Hertig, “‘Bitcoin bug’ exploited on crypto fork as “Blockchain for the internet of things: Present and future,” ArXiv, vol.
attacker prints 235 million pigeoncoins,” 2018. [Online]. Avail- abs/1903.07448, 2019.
able: https://www.coindesk.com/bitcoin-bug-exploited-on-crypto-fork- [310] M. A. Ferrag, M. Derdour, M. Mukherjee, A. Derhab, L. Maglaras,
as-attacker-prints-235-million-pigeoncoins and H. Janicke, “Blockchain Technologies for the Internet of Things:
[285] Bitcoin Wiki, “Value overflow incident,” 2016. [Online]. Available: Research Issues and Challenges,” IEEE Internet of Things Journal,
https://en.bitcoin.it/wiki/Value overflow incident vol. 6, no. 2, pp. 2188–2204, April 2019.
[286] ocminer, “Network Attack on XVG / VERGE,” 2018. [Online]. [311] Team Rocket, “Snowflake to avalanche: A novel metastable consensus
Available: NetworkAttackonXVG/VERGE protocol family for cryptocurrencies,” 2018.
[287] F. Tschorsch and B. Scheuermann, “Bitcoin and beyond: A technical [312] S. Popov, “The Tangle,” http://tanglereport.com/wp-content/uploads/
survey on decentralized digital currencies,” IEEE Communications 2018/01/IOTA Whitepaper.pdf, 2016.
Surveys & Tutorials, vol. 18, no. 3, pp. 2084–2123, 2016. [313] R. L. Rivest, A. Shamir, and Y. Tauman, “How to leak a secret,” in
[288] J. Yli-Huumo, D. Ko, S. Choi, S. Park, and K. Smolander, “Where International Conference on the Theory and Application of Cryptology
is current research on blockchain technology? – a systematic review,” and Information Security. Springer, 2001.
PloS one, vol. 11, no. 10, p. e0163477, 2016. [314] E. Ben-Sasson, A. Chiesa, E. Tromer, and M. Virza, “Succinct non-
[289] X. Li, P. Jiang, T. Chen, X. Luo, and Q. Wen, “A survey on the security interactive zero knowledge for a von neumann architecture,” in USENIX
of blockchain systems,” Future Generation Computer Systems, 2017. Security, 2014.
[290] M. Conti, E. S. Kumar, C. Lal, and S. Ruj, “A survey on security and [315] S. Micali, “Simple and fast optimistic protocols for fair electronic
privacy issues of Bitcoin,” IEEE Communications Surveys & Tutorials, exchange,” in Proceedings of the twenty-second annual symposium on
vol. 20, no. 4, 2018. Principles of distributed computing. ACM, 2003, pp. 12–19.
 46

[316] Bitcoin Wiki, “Atomic Swap,” 2018. [Online]. Available: https: [341] D. Canellis, “Bitcoin wallet Electrum hit by DoS
//en.bitcoinwiki.org/wiki/Atomic Swap attack from 140,000-strong botnet,” 2019. [Online].
[317] D. Shares, “Gatecoin official statement: Hot wallet breach Available: https://thenextweb.com/hardfork/2019/04/08/bitcoin-wallet-
losses estimated to be $2m usd,” 2016. [Online]. Avail- electrum-dos-attack-botnet-phishing/
able: https://news.bitcoin.com/gatecoin-official-statement-hot-wallet- [342] M. Apostolaki et al., “Blockchain meets internet routing,” 2017.
breach-losses-estimated-2m-usd/ [Online]. Available: https://btc-hijack.ethz.ch/
[318] P. Delaney, “Major attack reported on dogecoin vault leads to [343] M. Tran, I. Choi, G. J. Moon, A. V. Vu, and M. S. Kang, “A
shutdown,” 2014. [Online]. Available: https://www.ccn.com/major- stealthier partitioning attack against bitcoin peer-to-peer network,” in
attack-reported-dogecoin-vault-leads-shutdown/ IEEE Symposium on Security and Privacy (S&P), 2020.
[319] S. Khandelwal, “Danish Bitcoin exchange bips hacked and [344] M. Saad, L. Njilla, C. Kamhoua, J. Kim, D. Nyang, and A. Mohaisen,
1,295 Bitcoins worth $1 million stolen,” 2013. [On- “Mempool optimization for defending against ddos attacks in pow-
line]. Available: https://thehackernews.com/2013/11/danish-bitcoin- based blockchain systems,” in 2019 IEEE International Conference on
exchange-bips-hacked-and 25.html Blockchain and Cryptocurrency (ICBC), 2019, pp. 285–292.
[320] S. Higgins, “The bitfinex Bitcoin hack: What we know (and don’t [345] J. Young, “Analyst: Suspicious Bitcoin mempool activ-
know),” 2016. [Online]. Available: https://www.coindesk.com/bitfinex- ity, transaction fees spike to $16,” 2017. [Online].
bitcoin-hack-know-dont-know Available: https://cointelegraph.com/news/analyst-suspicious-bitcoin-
[321] D. Bradbury, “Hackers hit Bitcoin central exchange,” 2013. mempool-activity-transaction-fees-spike-to-16
[Online]. Available: https://www.coindesk.com/hackers-hit-bitcoin-
central-exchange
[322] C. Jentzsch, “The history of the DAO and lessons learned,” A PPENDIX
2016. [Online]. Available: https://blog.slock.it/the-history-of-the-dao-
and-lessons-learned-d06740f8cfa5/ A. Features of Blockchains
[323] K. Elby, “King of the Ether Throne: Post mortem investigation,” 2016.
[Online]. Available: https://www.kingoftheether.com/postmortem.html
Blockchains were initially introduced as a means of cop-
[324] S. C. Bürgel, “Rock paper scissors on Ethereum,” 2016. [Online]. ing with the centralization of monetary assets management,
Available: https://github.com/SCBuergel/ethereum-rps resulting in their most popular application – a decentral-
[325] H. Official, “Unit underflows and overflows – ized cryptocurrency with native crypto-tokens. However, other
Ethereum solidity vulnerability,” 2018. [Online]. Avail-
able: https://medium.com/haloblock/unit-underflows-and-overflows- blockchain applications have meanwhile started to proliferate
ethereum-solidity-vulnerability-39a39355c422 as well, benefiting from features other than decentralization.
[326] Mahendar B., “Unexpected ether,” 2019. [Online]. Available: https: We summarize the inherent and non-inherent features of
//www.nvestlabs.com/2019/04/23/unexpected-ether/
[327] P. Technologies, “The multi-sig hack: A postmortem,” 2017. [Online].
blockchains in the following.
Available: https://www.parity.io/the-multi-sig-hack-a-postmortem/
[328] E. Ward, “Breaking randomness in the Ethereum universe,” 1) Inherent Features:
2018. [Online]. Available: https://blog.gdssecurity.com/labs/2018/6/ Decentralization: is achieved by a distributed consensus pro-
1/breaking-randomness-in-the-ethereum-universe-part-1.html tocol – the protocol ensures that each modification of the
[329] F. Hildebrand, “The state of ponzi schemes,” 2018. [Online].
Available: https://medium.com/solidified/the-state-of-ponzi-schemes- ledger is a result of interaction among participants. In the
98dde4518431 consensus protocol, participants are equal, i.e., no single
[330] J. Wilcke, “The Ethereum network is currently undergoing a DoS entity is designed as an authority. An important result of
attack,” 2016. [Online]. Available: https://blog.ethereum.org/2016/09/
22/ethereum-network-currently-undergoing-dos-attack/
decentralization is resilience to node failures.
[331] GuardRails, “Write to arbitrary storage locations.” [Online]. Avail- Censorship Resistance: is achieved due to decentralization,
able: https://www.guardrails.io/docs/en/vulnerabilities/solidity/write and it ensures that each valid transaction is processed and
to arbitrary storage location included in the blockchain.
[332] A. Akentiev, “Parity Multisig Hacked. Again,” 2017. [Online]. Avail-
able: https://medium.com/chain-cloud-company-blog/parity-multisig- Immutability: means that the history of the ledger cannot
hack-again-b46771eaa838 be easily modified – it requires a significant quorum of
[333] A. Butler, “Ethereum Classic attacked! how does the 51% attack colluding nodes. The immutability of history is achieved
occur?” 2019. [Online]. Available: https://hackernoon.com/ethereum-
classic-attacked-how-does-the-51-attack-occur-a5f3fa5d852e by a cryptographic one-way function (i.e., a hash func-
[334] D. Gutteridge, “Japanese cryptocurrency monacoin hit by selfish tion) that creates integrity-preserving links between the
mining attack,” 2018. [Online]. Available: https://www.ccn.com/ previous record (i.e., block) and the current one. In this
japanese-cryptocurrency-monacoin-hit-by-selfish-mining-attack/
way, integrity-preserving chains (e.g., blockchains) or
[335] G. Milton, “Hackers launch ’double-spend’ attack on Bitcoin
gold to steal over $18 million,” 2018. [Online]. Avail- graphs (e.g., direct acyclic graphs [22], [311], [312] or
able: https://cyware.com/news/hackers-launch-double-spend-attack- trees [23]) are built in an append-only fashion. However,
on-bitcoin-gold-to-steal-over-18-million-011a29e2 the immutability of new blocks is not immediate and de-
[336] Bitcoin Exchange Guide News Team, “Litecoin cash (lcc)
experiencs 51% attack, cryptocurrency dies on spot,” 2018. pends on the time to the finality of a particular consensus
[Online]. Available: https://bitcoinexchangeguide.com/litecoin-cash- protocol (see Section III-C).
lcc-experiencs-51-attack-cryptocurrency-dies-on-spot/ Availability: although distributed ledgers are highly redun-
[337] ZenCash, “Zencash statement on double spend attack,” 2018.
[Online]. Available: https://blog.zencash.com/zencash-statement-on- dant in terms of data storage (i.e., full nodes store repli-
double-spend-attack/ cated data), the main advantage of such redundancy is
[338] K. Sedgwick, “Verge is forced to fork after suffering a 51% attack,” paid off by the extremely high availability of the system.
2018. [Online]. Available: https://news.bitcoin.com/verge-is-forced-to-
fork-after-suffering-a-51-attack/
This feature may be of special interest to applications that
[339] A. Judmayer, N. Stifter, A. Zamyatin, I. Tsabary, I. Eyal, P. Gaži, cannot tolerate outages.
S. Meiklejohn, and E. Weippl, “Pay-to-win: Incentive attacks on proof- Auditability: correctness of each transaction and block
of-work cryptocurrencies,” IACR Cryptology ePrint Archive, 2019. recorded in the blockchain can be validated by any
[340] A. Greenberg, “Hacker redirects traffic from 19 internet providers
to steal Bitcoins,” 2014. [Online]. Available: https://www.wired.com/ participating node, which is possible due to the publicly-
2014/08/isp-bitcoin-theft/ known rules of a consensus protocol.
 47

Transparency: the transactions stored in the blockchain as protocol is based on two Hashed Time-Lock Contracts (HTLC)
well as the actions of protocol participants are visible to that are deployed by both parties in both blockchains.
other participants and in most cases even to the public. Although HTLCs can be realized by Turing-incomplete
smart contracts with support for hash-locks and time-locks,
2) Non-Inherent Features:
for clarity, we provide a description assuming Turing-complete
Additionally to the inherent features, blockchains may be
smart contracts, requiring four transactions:
equipped with other features that aim to achieve extra goals.
Below we list a few examples of such non-inherent features. 1) A chooses a random string x (i.e., a secret) and computes
Energy Efficiency: running an open distributed ledger often its hash h(x). Using h(x), A deploys HT LCA on the
means that scarce resources are wasted (e.g., Proof-of- first blockchain and sends the agreed amount to it, which
Work). However, there are available consensus protocols later enables anybody to do a conditional transfer of that
that do not waste scarce resources, but instead emulate amount to B upon calling a particular method of HT LCA
the consumption of scarce resources (i.e., Proof-of-Burn), with x = h(x) as an argument (i.e., hash-lock). Moreover,
or the interest rate on an investment (i.e., Proof-of-Stake). A defines a time-lock, which, when expired, allows A
See examples of these protocols in Section VI. to recover funds into her address by calling a dedicated
Scalability: describes how the consensus protocol scales method: this is to prevent aborting of the protocol by
when the number of participants increases. Protocols another party.
whose behavior is not negatively affected by an increasing 2) When B notices that HT LCA has been already deployed,
number of participants have high scalability. she deploys HT LCB on the second blockchain and sends
Throughput: represents the number of transactions that can the agreed amount there, enabling a conditional transfer
be processed per unit of time. Some consensus proto- of that amount to A upon revealing the correct pre-image
cols have only a small throughput (e.g., Proof-of-Work), of h(x) (h(x) is visible from already deployed HT LCA ).
while others are designed with the intention to maximize B also defines a time-lock in HT LCB to handle abortion
throughput (e.g., Byzantine Fault Tolerant (BFT) proto- by A.
cols with a small number of participants). See examples 3) Once A notices deployed HT LCB , she calls a method
of BFT protocols in Section VI-C. of HT LCB with revealed x, and in turn, she obtains the
Privacy & Anonymity: by design, data recorded on a pub- funds on the second blockchain.
lic blockchain is visible to all nodes or public, which 4) Once B notices that x was revealed by A on the second
may lead to privacy and anonymity issues. There- blockchain, she calls a method of HT LCA with x as an
fore, multiple solutions increasing anonymity (e.g., ring argument, and in turn, she obtains the funds on the first
signatures [313] in Monero) and privacy (e.g., zk- blockchain.
SNARKs [314] in Zcash) were proposed in the context of If any of the parties aborts, the counter-party waits until the
cryptocurrencies, while other efforts have been made in time-lock expires and redeems the funds.
privacy-preserving smart contract platforms [131], [132]. Atomic Swap for Three Parties. In the following, we outline
Accountability and Non-Repudiation: if blockchains or ap- a three-way atomic swap protocol, where party A wishes to
plications running on top of them are designed in such sell an asset a for BTC, the party B wishes to buy a for ETH,
a way that identities of nodes (or application users) are and DEX E is inter-mediating the asset transfer:
known and verified, accountability and non-repudiation 1) B chooses a random string x (i.e., a secret) and computes
of actions performed can be provided too. its hash h(x). Using h(x), B deploys HT LCB on the
Ethereum blockchain and sends the agreed ETH amount
B. Atomic Swap Protocols there, which later enables anybody to do a conditional
transfer of that amount to E upon calling a particular
Atomic Swap for Two Parties. Atomic swaps assume method of HT LCB with x = h(x) as an argument.
two parties A and B owning crypto-tokens in two different Moreover, B defines a time-lock to handle abortion by
blockchains. A and B wish to execute cross-chain exchange any party.
atomically and thus achieve a fairness property, i.e., either both 2) Once E notices that HT LCB has been already deployed
of the parties receive the agreed amount of crypto-tokens or on the Ethereum blockchain, she deploys HT LCE on the
neither of them. First, this process involves an agreement on Bitcoin blockchain and sends the agreed BTC amount
the amount and exchange rate, and second, the execution of there, enabling a conditional transfer of that amount to
the exchange itself. A upon revealing the correct pre-image of h(x) (which
In a centralized scenario [315], the approach is to utilize is visible in already deployed HT LCB ). E also defines a
a trusted third party for the execution of the exchange. In time-lock in HT LCE .
contrast to the centralized scenario, blockchains allow us to 3) Once A notices that HT LCA has been already deployed
execute such an exchange without a requirement of the trusted on the Bitcoin blockchain, she deploys HT LCA on the
party. The atomic swap protocol [316] enables conditional asset blockchain and lock the asset a there, enabling a
redemption of the funds in the first blockchain to B upon conditional transfer of a to B upon revealing the correct
revealing of the hash pre-image (i.e., secret) that redeems pre-image of h(x) (which is visible in already deployed
the funds on the second blockchain to A. The atomic swap HT LCB and HT LCE ). A also defines a time-lock in
 48

HT LCA . C. Examples of Incidents

4) When B notices that both HT LCE and HT LCA have In the current section, we list several incidents at each
been already correctly deployed, she reveals the secret x layer of the security reference architecture. In detail, Table VI
as a part of the transaction sent to HT LCA . This triggers contains incidents of public networks at the network layer,
a transfer of asset a to B. Table V lists incidents of the consensus layer, Table IV focuses
5) Once A notices that x was revealed, she sends a transac- on the RSM layer, and Table III shows a few examples of
tion with x to HT LCE , obtaining BTC from E. incidents at the application layer.
6) Once E notices that x was revealed, she sends a transac-
tion with x to HT LCB , obtaining ETH from B.

Acronym
Threat Reference Description Impact ($)
/ Incident
/ Vulnerability
Gatecoin
Centralized server com- [317] The exchange was the victim of a man-in-the-middle attack. The 25,160,000
(May 2016)
promise (single-point-of- malicious external party was involved in this breach, and it managed to
failure) alter Gatecoin’s system so that deposit transfers bypassed the multisig
cold storage and went to hot wallets, which were exploited due to
OPSEC issues.
Doge Vault
Centralized server com- [318] The attacker gained access to the server where Doge Vault’s virtual 56,000
(May 2014)
promise (single-point-of- machines were running, providing him with full access to the systems.
failure)
BIPS.me
DDoS + access subver- [319] An initial DDoS attack caused vulnerability to the system, which 554,260
(November 2013)
sion on centralized server has then enabled the attacker to gain access and compromise several
(single-point-of-failure) wallets.
Bitfinex
Centralized server (single- [320] Although Bitfinex used 2-of-3 multisig wallets, two of these keys were 71,288,416
(August 2016)
point-of-failure) owned by Bitfinex (one stored in cold wallet), while the user owned
only a single key. It is not clear whether this incident involved insider
threat or it was conducted externally.
Bitcoin Central
Centralized server com- [321] Password was reset from the hosting provider’s web interface, enabling —
(April 2013)
promise (single-point-of- the attacker to lock out of the interface and request a reboot of the
failure) machine into rescue mode. Next, the attacker has stolen private keys
from the hot wallet.
Cyber-squatting attacks
Violation of accurate reg- [216] Cyber-squatters seized identities that do not belong to them nor —
in NameCoin
istration represent themselves.
Front-Running on
Front-running in [92] Arbitrage bots front-run user issued exchange transactions with the —
Ethereum Exchanges
Intra-Chain Exchanges ones with the higher fees. Therefore, user issued transactions are
discarded or traded with worse exchange rate as intended.

Table III: Incidents that occurred at the application layer.

 49

Acronym
Threat Reference Description Impact ($) SWC Entry
/ Incident
/ Vulnerability
DAO Attack
Reentrancy [322] A vulnerability in the code allowed a repeated with- 70,000,000 SWC-107
(June 2016)
drawal of ether, which could be exploited with a
malicious fallback function.
King of the Ether Throne
Unchecked return [323] An unchecked return value prevented the rightful 300 SWC-104
(February 2016)
value compensation of the user.
RockPaperScissors Storing secrets [324] A smart contract relied on a secret value that should —
not be visible to other users.
Integer overflow and [325] The user’s input was not properly sanitized and SWC-101
underflow overflow / underflow was possible.
Unexpected value re- [326] A smart contract may contain conditions that rely — SWC-132
ceived on a certain balance, but the attacker is able to send
an unexpected monetary value to the contract and
disrupt the intended functionality.
Delegatecall [139] Solidity has a feature called delegatecall that enables — SWC-112
remote calls of other contracts. Such calls cause an
execution of untrusted contracts in the context of the
caller, hence all vulnerabilities of the remote code
can be exploited.
Parity multisig hack
Default function visi- [327] Solidity functions are public per default. This can 30,000,000 SWC-100
(July 2017)
bility be easily exploited if a developer forgets to make
critical functions private.
TheRun
Weak source of ran- [328] Relying on the block number or timestamp as a — SWC-120
(April 2016)
domness source for randomness is not safe, since it can allow
a prediction of the next random number.
GovernMental SWC-113,
DoS [329] The gas limit or failing calls to external functions can 11,000
(March 2016) SWC-128
lead to situations where a contract becomes unusable.
EXTCODESIZE DoS attack
DoS [330] The attack exploited a mismatch between the com- —
(September 2016)
putational cost of some operations and their gas cost.
Rubixi SWC-105,
Unprotected Ether [139] The access to administration or initialization func- —
(March 2016) SWC-118
withdrawal tions had not been adjusted properly. Missing modi-
fiers or an improperly named function might lead to
unauthorized access.
Bancor
Front-running / trans- [139] Some contracts rely on the transaction order to — SWC-114
(June 2017)
action order depen- make a decision. For example, a winner of a game
dency is chosen from the first transaction with a correct
answer. Since the transactions can be inspected by
the consensus nodes before they are included, the
attacker might steal the answer and make a transac-
tion with a higher fee, which will be included as the
first one.
Timestamp [140] Some contracts might use the current timestamp to — SWC-116
dependency trigger certain events. However, timestamps can be
adjusted by malicious consensus nodes.
Write to an arbitrary [331] By taking advantage of neighboring addresses in — SWC-124
storage location the storage and un-sanitized code, the unauthorized
attacker might write to sensitive storage locations.
Parity multisig hack 2
Unprotected [332] The unprotected self destruct functionality can be 150,000,000 SWC-106
(November 2017)
selfdestruct call exploited to destroy contracts (or libraries), and
potentially freeze funds in them.

Table IV: Incidents and possible vulnerabilities at the RSM layer.

 50

Acronym
Threat Reference Description Impact ($)
/ Incident
/ Vulnerability
Ethereum Classic 51% attack & double spend- [333] A 51% attack on Ethereum Classic led to a deep chain reorganization, 1,100,000
(January 2019) ing (violation of assump- which included double-spending attacks against Binance and Bitrue
tions) wallets.
Monacoin 51% attack & double spend- [334] A block reorganization on Monacoin included double-spending attacks 90,000
(May 2018) ing (violation of assump- that targeted several “Western exchanges” (particularly Livecoin).
tions) Unconfirmed reports on Reddit mention losses of 90,000 USD.
Bitcoin Gold 51% attack & double spend- [335] A Block withholding attack on Bitcoin Gold led to 76 double-spent 18,600,000
(May 2018) ing (violation of assump- transactions, mostly targeting cryptocurrency exchanges.
tions)
Litecoin Cash 51% attack & double spend- [336] A similar double-spending attack targeted Litecoin cash – the lead —
(May 2018) ing (violation of assump- developer “Tanner” stated that he believes the mining power may have
tions) been rented.
Zencash 51% attack & double spend- [337] A 51% attack led to several block reorganizations, with the largest 550,000
(June 2018) ing (violation of assump- one that reversed 38 blocks. Only two transactions included double
tions) spending, but these were large enough to cause considerable losses.
Verge 51% attack & semantic bug [286] A vulnerability in Verge’s difficulty adjustment algorithm was used to 3,850,000
(April 2018) (violation of assumptions) amplify a 51% attack.
Verge 51% attack & semantic bug [338] An inadequate response by Verge developers to the previous attack led 1,750,000
(May 2018) (violation of assumptions) to it being repeated a month later.
Checklocktime, Bribery attacks [339] Various bribery attacks have been listed in the literature. In these —
CensorshipCon, attacks, it is profitable for consensus nodes to accept bribes for
GoldfingerCon, deviation from the protocol.
etc.

Table V: Incidents that occurred at the consensus layer.

Acronym
Threat Reference Description Impact ($)
/ Incident
/ Vulnerability
Canadian Bitcoin hijack BGP prefix hijacking [340] Intercepted data between Bitcoin miners and Bitcoin mining pools. 83,000
(February 2013) (routing attack & eclipse Tricked honest miners were mining on an attacker controlled pool.
attack)
Bitcoin deanonymiza- Sybil attack (identity re- [59] A large number of fake nodes were introduced to deanonymize client —
tion (March 2015) vealing attacks) traffic.
MyEtherWallet hijack BGP hijacking (routing [293], [294] A BGP hijack have been performed against Amazon DNS, leading to 152,000
(April 2018) attack) the wallet’s server domain name being resolved to a Russian phishing
site in several cities.
Electrum DoS Volumetric DoS [341] DoS of legitimate Electrum servers was conducted as an attempt to In millions
(August 2019) get connected vulnerable Electrum wallets to a malicious server, which
resulted in a loss of wallet funds.
Bitcoin partitioning Prefix hijacking (routing [342] An attack to partition Bitcoin network by hijacking IP prefixes. —
(proof-of-concept) attack)
Erebus (proof-of- Malicious ISP attack [343] ISP uses its topological advantage to launch a stealthy partition attack. —
concept)
Eclipse attack on Bit- Un-authenticated and [47] A view of the network by eclipsed peers is fully under the attacker’s —
coin (proof-of-concept) unreliable peers control.
De-anonymization in Abusing Bitcoin DoS [57] Bitcoin peers were forced to ban Tor exit nodes of attacker’s choice by —
Bitcoin with Tor protection (identity re- abusing Bitcoin DoS protection. Thus, the attacker was able to control
(proof-of-concept) vealing attack) all remaining Tor exit nodes and cause client traffic to pass through
them.
Suspected Penny flood- DoS on a mempool (at- [344] Flooding a mempool with low fee transactions resulted in clogged up —
ing on Bitcoin (Decem- tacking local resources) memory of consensus nodes and increased transaction processing fees.
ber 2017)
2X-Mempool-Attack on Flooding by high-fee [345] Mempool is flooded by high-fee transactions, preventing regular-fee —
Bitcoin (suspected) transactions (DoS on transactions being processed timely.
processing of legitimate
transactions)

Table VI: Incidents that occurred at the network layer (public networks).

View publication stats