PREStO: A Systematic Framework for Blockchain Consensus Protocols

06/15/2019 ∙ by Stefanos Leonardos, et al. ∙ 0

The rapid evolution of the blockchain community has brought together stakeholders from fundamentally different backgrounds: cryptographers, protocol designers, software developers, startup entrepreneurs, corporate executives and investors, academics of various disciplines, and end users. The result is a diverse ecosystem, presently exemplified by the development of a wide range of different blockchain protocols. This raises questions for policy and decision makers: How do different protocols compare? What are their trade-offs? Existing efforts to survey the area reveal a fragmented terminology, and the lack of a unified framework to make the different desirable properties of blockchain protocols explicit. In this paper, we work towards bridging this gap. We evaluate protocols within a five-dimensional design space with the following axes. Optimality: does the protocol achieve its main goals? Stability: are the incentives of its participating agents well-aligned? Efficiency: is its output maximal relative to its use of resources? Robustness: can it cope when its operational assumptions are invalid or perturbed? Persistence: can it recover from catastrophic events? Based on the relevant literature, we organize the properties of existing protocols in subcategories of increasing granularity. The result is a dynamic scheme – termed the PREStO framework. Its scope is to aid the communication between stakeholders of different backgrounds, including managers and investors, and to identify research challenges and opportunities for blockchain protocols in a systematic way. We illustrate this via use cases and make a first step to understand the blockchain ecosystem through a more comprehensive lens.



There are no comments yet.


page 1

page 12

page 16

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

In the seminal Bitcoin paper [137], the pseudonymous Satoshi Nakamoto pioneered the use of blockchains as a secure way of maintaining a ledger of currency transfers in a trustless peer-to-peer network. In the ten years since, blockchains have grown [60] to underpin a $100 billion cryptocurrency market [49]. Meanwhile, its applicability is increasingly understood in a broad range of other contexts [42], e.g., the Internet of Things [75], supply chain management [114], healthcare [133], etc. This rapid growth has induced a considerable number of established market parties to invest in the sector [61, 59], or even develop their own platforms. Main examples of the latter include Quorum [152], which is developed by JPMorgan Chase, and the HyperLedger umbrella project [38], hosted by the Linux Foundation and supported by, inter alia, IBM and Intel. Applications of Quorum include JPMorgan’s internal digital currency [161] and the Interbank Information Network [44, 142], a platform for cross-border money transfers. Applications of HyperLedger include a project by the US retailer Walmart to track the movement of vegetables [100, 170]. IBM by itself had 1500 employees working on 500 blockchain-related projects in September 2018 [82]. Meanwhile, new multipurpose blockchain platforms developed by startups continue to emerge, e.g., Ethereum [35], Cardano [40, 109], Algorand [31, 88], and Zilliqa [192, 193].

This proliferation of blockchain technologies and applications has brought together stakeholders with fundamentally different degrees of technical expertise. So far, the discourse between these groups has been marked by the use of sometimes incongruous terminology, and the lack of a unified communication framework [151]. This hampers the ability of managers and investors to make business decisions, and of newly proposed protocols to be compared and understood. Particularly affected are one of the most fundamental technical aspects of blockchain platforms: the consensus protocols.





Fig. 1: The PREStO framework as a nesting doll of goals.

Consensus protocols fulfill, in a decentralized setting, the role that a single authority has in a centralized database or ledger. It is the mechanism to reach agreement among self-interested peers, and for making consistent decisions out of mutually exclusive alternatives. The choice of consensus protocol has a major impact on a platform’s performance, including its security and throughput, and is therefore important for anyone who is involved in blockchain development [126], particularly executives. This can be challenging if the differences between the alternatives are not well understood.

Statement of Contribution and Managerial Relevance

In this paper, we address these difficulties by developing an accessible, yet technical and comprehensive framework to improve the communication between the diverse participants of the blockchain ecosystem. We assume only a basic understanding of mathematics and the high-level idea behind blockchains, and introduce technical terms related to blockchains and cryptocurrencies from the bottom up.

Our main contribution is the systematic development of the PREStO framework [187, 46]

, which is a dynamic tool to identify and classify properties of blockchain protocols. It is an acronym (in reverse order) of its five main axes which are: Optimality, Stability, Efficiency, Robustness and Persistence, cf.

Figure 1. In Table I, we capture the essence of each category in a single question.

Dimension Description Section
Optimality Does the protocol maximize the quality of its core outcomes under normal circumstances? III
Stability Is the designed protocol an equilibrium? IV
Efficiency How does the protocol utilize its different resources, e.g., time, space, energy, network bandwidth? V
Robustness Does the protocol’s performance withstand perturbations to its parameters? VI
Persistence If the protocol is forced out of equilibrium, does it recover? VII

TABLE I: The five axes of PREStO and their main purpose.

PREStO’s modular structure is what sets it apart from related efforts and makes it valuable for the managerial practice. Initially, the five categories can be seen as a nesting doll of design goals, where each category considers a wider range of desirable properties than the previous, cf. Figure 1. We start at the very basic – i.e., optimal performance under ideal conditions – and gradually build up to the more advanced – e.g., recovery mechanisms to survive and sustain in the long run. Subsequently, the axes are organized into subcategories of increasing granularity, and PREStO develops into a dynamic tool to identify and group together challenges and research opportunities for the various blockchain protocols, cf. Table V. We demonstrate its practical use via two running use cases, Bitcoin and Quorum, and conclude with a schematic illustration of the resulting classification in Figure 5. We draw from the existing literature to develop a systematic framework and terminology to reason about blockchain protocols.

A Growing Ecosystem

The consensus protocol introduced by the first blockchain platform – Bitcoin – is commonly called Nakamoto consensus [173]. It was designed to work in a permissionless setting, i.e., a setting in which any node in the network is allowed to add data to the blockchain. To prevent network overflow, nodes seeking to extend the blockchain must spend computational effort through a process called mining. In the presence of competing chains, honest nodes accept the chain with the most effort spent on creating it. Together, these rules ensure that if more than 50% of the computational power is in the hands of honest parties, then their chain will grow faster than all others. Nodes are compensated for the spent computational power through rewards in the form of tokens logged on the blockchain. Variations of Nakamoto consensus are currently implemented in over 600 cryptocurrencies [190, 49], including the Ethereum platform and various Bitcoin spin-offs.

In recent years, Nakamoto consensus has increasingly drawn criticism for its low transaction throughput and high energy consumption. A single Bitcoin transaction costs more energy than 100 000 Visa transactions, and the Bitcoin network as a whole consumes as much energy as a medium-sized country [63]. Furthermore, it is insecure in the sense that smaller platforms are vulnerable to attackers who seize a majority of the computational power, as witnessed by the recent 51% attacks on Ethereum Classic [104] and Bitcoin Gold [156]. Finally, research [70, 87, 160, 190] has shown that Nakamoto consensus can be incentive-incompatible, i.e., participants can increase their rewards by deviating from the protocol. To address these weaknesses, a multitude of new consensus protocols have been proposed that more closely follow traditional theory on permissioned (i.e., not open) networks. In particular, many approaches use variations of Byzantine fault tolerant (BFT) protocols [117] or other classical consensus protocols such as Paxos [116] and Raft [144]. Such approaches can achieve gains in efficiency and security at the cost of centralization. However, a precise description of this trade-off is complicated due to the wide range in different BFT protocols, and the lack of alignment between the terminology used by different parties. This motivates the need for a formal framework to describe and compare different consensus protocols.

Related Work

The necessity of developing a unified communication framework for the blockchain ecosystem was already acknowledged in [188]. Accordingly, a brief outline of the PREStO framework was first introduced in [46]. While the five main axes remain the same, their organization into subcategories is first deployed in the present paper.

The rapid growth of the blockchain-related literature has also stimulated other projects that survey the area from different perspectives. Focusing exclusively on the Bitcoin blockchain, [52] provide a systematic review of Bitcoin’s underlying features, particularly its security and privacy-related threats and vulnerabilities, and discuss directions for future research. Their analysis extends initial analyses of the backbone protocols of the main cryptocurrencies [78, 79, 146, 81]. In [173], further insight is provided into the development and functionality of the Bitcoin blockchain, in addition to a non-exhaustive, yet interesting timeline of papers related to the analysis of Nakamoto consensus.

In a spirit closer to the present study, [183] acknowledge the lack of a comprehensive literature review on the various layers of blockchain technology, and provide a rigorous vision on the organization of blockchain networks. Their work extends to all aspects of the relevant technology and provides a central reference for future work. They define four layers for any blockchain system, from top to bottom: (1) the application layer, (2) the virtual machine layer, (3) the consensus layer, and (4) the network layer. In the present study, we focus on the third (i.e., consensus) layer. That is, application-layer properties, virtual-machine-layer properties (e.g., secure smart contract languages such as Scilla [166]), and network-layer properties (e.g., vulnerability to eclipse [95], BGP hijacking [4], or DoS [105] attacks) are treated only if and when they affect the consensus layer.

The difficulty to conceptualize the dramatically evolving design landscape of blockchains is further supported by [17]. Similar to the present work, they focus on the consensus layer and discuss the various themes and key approaches that are exhibited by current blockchains. They systematize distinctive features and technical properties of existing consensus protocols and provide thorough comparisons along with open questions and directions for future research. Despite the common perspectives, our approach distinguishes itself from [17] due to its mathematical framework that allows for a description of properties from the ground up.

Using a practice-oriented focus, [66] develop BLOCKBENCH, a promising and publicly available software program that is designed to test and compare the performance of blockchain protocols. It applies to private blockchains and its findings are mainly associated with properties in the categories of Optimality and Efficiency of the PREStO framework, cf. Sections V and III. The paper features use cases of the Ethereum, Parity and Hyperledger blockchains and concludes that these systems are still far from large-scale adoption. Finally, a non-exhaustive list of related surveys with focal points ranging from smart contract execution to general blockchain applications and research perspectives includes [28, 53, 186, 9, 39, 107, 191, 65, 177, 80, 42, 10, 167].


The current paper is structured as follows. We begin by defining an abstract, high-level model of a blockchain consensus protocol in Section II. In Sections VII, VI, V, IV and III, we describe the main PREStO axes and define their subgategories. We summarize related issues and open questions related to each category in Table V. Section VIII concludes our analysis with general comments and directions for future work.

Ii A Mathematical Model for Blockchain Consensus

To rigorously define the properties covered by the PREStO framework, we require a mathematical model to serve as a basis. In this section, we will present this model by consecutively describing the data on the blockchain (in Section II-A), the participating nodes as individuals (in Section II-B), the nodes as a network (in Section II-C), and the rewards and strategies (in Section II-D). In all cases we denote the consensus protocol by . To account for the wide variety of existing protocols and the diversity of their technical features, we keep our model as general as possible. However, we illustrate our presentation using two running examples from the permissionless and permissioned settings, respectively: 1) Bitcoin [137], and 2) Quorum [152], which uses the Istanbul-BFT consensus protocol [102]. We also visualize the core concepts using Figure 2 and Table II, which display the state of a Bitcoin-like blockchain network at a given time , and this network’s evolution until and shortly after , respectively.

Fig. 2: The state of a Bitcoin-like blockchain network 700 seconds after genesis (): (a) the peer-to-peer network, including for each node their view (with the head colored), resources , and memory pool (b) the blockchain itself, given as a graph where and iff .

Ii-a Blockchains as Data Structures

At its core, a blockchain is a data structure that contains a sequence of elementary database operations called transactions. The semantics of the transactions depend on the platform [55] (e.g., they can represent token transfers, smart contract calls, or sensor readings in an IoT context, etc). The transactions are grouped into blocks. For simplicity, we assume that each block can be identified by a unique integer in (e.g., via the hash of its header). Each block not only contains transactions, but also a header that contains summary information about the block. The header of a block contains a reference to the block’s transactions – typically via a Merkle tree root [132] – a timestamp, a reference to the previous block, and some additional platform-specific data, cf. [29].

In our model, we represent the block’s timestamp as a function , i.e., if a block is created at time then .111In practice, the block creator has considerable freedom in choosing the timestamp [174]. The previous block of any block is also represented via a function , i.e., points to as its previous block. For brevity, we write , , etc. The first block is called the genesis or the genesis block, and is the only block to not have a previous block, i.e., . Using , we can construct for each block a chain of blocks to the genesis, i.e., . The chain is cryptographically secure, i.e., the relationship between a block and its predecessor is given by encapsulating all information in in via a cryptographic hash function. Essentially, if even a single bit of data in is changed, then executing the hash function on its header will produce a different hash, and the relationship between and is broken.

At any point in time, the complete structure of the blocks created so far can be represented using a Directed Acyclic Graph (DAG), where blocks are the vertices and a directed edge between blocks and exists if , see Figure (b)b for an example. In this paper, we only consider chain-based protocols, i.e., protocols for which the validity and the output of a transaction within any block depends only on . That is, we do not include protocols such as Avalanche [176] and IOTA’s Tangle, even though some of the definitions in the PREStO framework may still be applicable.

Example 1 (Bitcoin).

In Bitcoin, transactions represent token transfers between users. Transactions also include fees that are paid to block creators. Among the block header fields, the proof-of-work, is also relevant.

Example 2 (Quorum).

Quorum is based on Ethereum, and hence the transactions not only represent token transfers, but also smart contract calls and creations. The protocol messages of Instanbul-BFT, e.g., prepare and commit messages, are also seen as transactions, even though only the commit messages are included in the block (yet they are not referred to in the header).

Ii-B Nodes and Resources

The blockchain protocol is operated by a set of agents called nodes, which are identified by their index . To participate, each node provides each of distinct resources. The amount of resource contributed by node is denoted by . Since resources change over time, we will write

for the vector of resources of node

at time point . Accordingly, let be the vector of total protocol resources at timepoint . We similarly define as the fraction of resource owned by node at . We say that a group of nodes is -strong with for resource if

This can be generalized to multiple resources, but we omit this for the sake of brevity. When only a single resource is critical to the consensus mechanism, we omit the subscript entirely and write . We will omit the superscript whenever it is irrelevant. If for all , then we will say that node is active at timepoint . Nodes communicate with other nodes via a software application called a client.

Example 1 (Bitcoin).

In Bitcoin, we can identify three major “types” of nodes:

  1. [leftmargin=*,label=0.]

  2. mining nodes, who create new blocks by solving computational “puzzles”,

  3. full nodes, who verify blocks before accepting them (i.e., check whether all the included transactions are valid), and

  4. light nodes, who only verify block headers, and are only interested in checking the inclusion of individual transactions via Simplified Payment Verification (SPV).

The foremost resource of node is processing power: typically a mining node will need a great amount of it (e.g., an ASIC rig), a full node a moderate amount (e.g., a high-end PC), and a light node very little (e.g., a smartphone). The model for Bitcoin can further be extended by including bandwidth as a separate resource .

Example 2 (Quorum).

In a permissioned blockchain, there can still be full nodes and light nodes, but mining nodes are unnecessary and processing power is less important (yet still required to, e.g., verify signatures). The main resource is access to the private keys that allow for the creation of blocks, i.e., authority. We model this in the following way: assume that there are private keys for block creation. Then for all and , it holds that if node controls key , and otherwise. Furthermore, denotes the processing power of node and the bandwidth. Note that it is possible for more than one nodes to have access to the same private key, e.g., after a hack.

TABLE II: An example of the evolution of blockchain network of Figure 2. Each row corresponds to an event: it displays its time of occurrence and its type (mining or propagation). Furthermore, we display the view of each node after the event, and note whether the nodes’ views and/or heads are consistent across the network and whether a fork is ongoing. Events related to the dissemination of transactions are not included for brevity.

Ii-C Blockchains as Peer-to-Peer Networks

Each node has incoming and outgoing connections to other protocol-running nodes. The resulting peer-to-peer network can be represented as a graph where the vertices represent nodes and edges represent connections – see Figure (a)a for an illustration. Not every node is necessarily connected to all other nodes, however it is typically assumed that from each node a path to every other node exists in the graph. If this is not the case, then there is an ongoing network partition.

At each time , each node is aware of a set of blocks: we call the view of node at time . The genesis block is the only block that all nodes are aware of at time , i.e., for all . In addition to , each node is also aware of transactions that have not been included in any block at time point . This information is stored in the memory pool, denoted by , for and . Due to the distributed nature of the network, there exist points in time for which different nodes are aware of different sets of blocks or different information, i.e., there exist and nodes such that or .

At any time , each node that can create blocks has to decide which block in to extend. This block is called the head, and is represented by the variable . A function that selects a head from a view is called a fork-choice rule. A network fork is any period during which at least two (protocol-following) nodes have incompatible blocks as heads. Here, we mean by “incompatible blocks” two blocks and such that neither is in the chain of the other, i.e., and . The term “fork” is also commonly used in practice to refer to protocol changes. That is, if the protocol is changed from to and blocks created under are still considered valid by , then this is referred to as a soft fork. If not, the change is called a hard fork.

Due to network forks, a block can be orphaned, which occurs if at some point of time , there is no such that . We say that a block is overturned by node at time if and . For example, in Table II, a network fork occurs from time 241 until time 710. Block

(the teal block) is overturned by node 2 at time 702 and by node 3 at time 710. In practice, blockchain users need either a formal or heuristic notion of

finality – i.e., a notion of when a block can be assumed to not be overturned. For example, an online retailer will need to decide when a block that contains a payment is safe enough from being overturned to dispatch the order.

Example 1 (Bitcoin).

In Bitcoin, the fork-choice rule prescribes to select the block with the highest accumulated proof-of-work, i.e.,

In case of ties, the block seen first is preferred. This can lead to soft forks that persist even when all nodes have the same view, as illustrated in Table II. In [70], it was suggested that adversarial behavior can be discouraged by using uniform tie breaking

– whenever a node learns of a new block that has as much proof-of-work as its head, it adopts the new block as its head with probability

. As further discussed in [160], this can have either a positive or negative effect on attackers, depending on how well-connected they are within the network.

For finality, Bitcoin users typically use the six confirmations rule [168]: i.e., a block is considered final by at time if there exists a such that .

Example 2 (Quorum).

In the Istanbul-BFT protocol used by Quorum, blocks are added to the blockchain if they are confirmed by more than of the voters. In particular, let, for any block and private key , equal if contains a “commit” message for signed with , and 0 otherwise. Then block is considered a valid block by node at time if

This is also the finality rule: i.e., in Quorum, all blocks are either both valid and finalized, or neither. This is true for many other BFT protocols as well.

Ii-D Actions, Strategies, and Utilities

Based on the above, the state of the blockchain at timepoint is a vector


When time is not relevant, we simply write instead of . The state space, i.e., the set of all possible states will be denoted by .

Transitions to new states typically occur through operations or actions performed by the nodes. Each protocol has its own set of actions, and conditions under which they are available. We denote by the set of all possible actions allowed by the protocol. Let a strategy be a function from the state space to the set of actions – i.e., during execution, a node uses its strategy to select which action to take given the state of the system (where ‘waiting’ can be an action). Let denote the set of all possible strategies. Particularly relevant to our presentation is the default strategy or the strategy that prescribes to follow-the-protocol as referenced, which we will denote by . We will call any other strategy with a deviant or adversarial strategy. Also, we will refer to nodes that follow as honest and to nodes that do not follow as adversarial nodes. If a node takes an action, then the system state is changed after a random delay. Let be the set of completed actions until time . This imposes a probability measure on system executions, i.e., given a strategy profile , then for all and we should be able to determine . Each agent has utility functions , which indicates their satisfaction with a given network state, and , which indicates their satisfaction with a given action. Given an initial state , the long-term average utility with a given strategy profile is then given by

In the present study, rather than analyzing individual strategic behavior, we mainly focus on collective protocol performance and blockchain properties. To formalize these notions, we define a property or feature of a blockchain protocol as a function , with the following values

Additionally, we define aggregate utilities or performance measures of protocol as functions . We will use the terms positive performance measures when higher values indicate better performance, such as throughput rate and collective profits, and negative performance measures when lower values do, such as communication complexity and operational costs.

Example 1 (Bitcoin).

The core actions that any node in Bitcoin can perform are block creation, block propagation, transaction creation, and transaction propagation

. Of these, block creation takes an amount of time that is approximately exponentially distributed

[157, 58] with a mean determined by the node’s processing power. The time needed to create transactions is negligible. Block and transaction propagation times depend on the network latency, the node’s bandwidth, connectivity, and the message size. More generally, block validation can be included as a separate action that consumes processing power. Also, if a node represents a mining pool, then the entering or exiting of by other nodes can be considered as actions.

Example 2 (Quorum).

Instanbul-BFT has the same core actions as Bitcoin, but also includes the propagation of protocol messages, e.g., prepares and commits. Unlike Bitcoin, block creation is nearly instantaneous, but a node’s block is only valid if it has been selected as the block proposer (e.g., via a round-robin scheme) for the current round. Under certain conditions, e.g., if a block proposer waits too long before proposing a block, the other nodes can request a round change. If a supermajority of nodes agree on a round change, or sign off on a block, the next round begins.

Throughout the text, we will frequently use the terms (and abbreviations)

  • [leftmargin=*]

  • Proof of Work (PoW): As already mentioned, this refers to Nakamoto consensus [137] in which nodes, also called miners, gain the right to participate in the block creation process by providing solutions to a computationally difficult and energy-consuming cryptographic puzzle.

  • Proof of Stake (PoS): Often called Virtual Mining [21], PoS emulates the above process but saves on energy waste by requiring from participating nodes to provide proof of “virtual” resources such as the platform’s native tokens.

We will call a protocol permissionless if the consensus-critical resources are not inherent to the blockchain (e.g., processing power in PoW). We will a protocol semi-permissionless if the consensus-critical resources are inherent to the blockchain, but freely divisible and transferable (e.g., tokens in PoS). We will call a protocol permissioned if the consensus-critical resources are inherent to the blockchain and indivisible. An example is given by private keys in Proof of Authority, a consensus scheme in which the only nodes that are allowed to create blocks are hard-coded in the clients and the protocol, or centrally controlled in any other way.

We are now ready to define the 5 axes of the PREStO framework and describe their subcategories.

Iii Optimality

Optimality is the most basic property of a protocol, and generally refers to whether the protocol is optimal within its operational scope. In our setting, it concerns the question:

  • Under normal conditions, does the protocol provide its core functionality in an optimal way?

By “normal conditions”, we mean that nodes do not act strategically or maliciously, and that there are no capacity constraints. However, we do consider network latency and nodes going offline. “Core functionality” primarily refers to the functionality of any distributed database, i.e., to correctly read and write to the database. However, some protocols also provide additional functionalities, e.g., a broader notion of transaction types, or a higher level of privacy.

Iii-a Liveness and Safety

Since blockchains are essentially data structures, they must adequately perform the read and write operations that are required of any database. We focus on the data in the finalized blocks of the chain, because the overturning of non-finalized blocks is not faulty behavior [168]. The “write” operation then consists of adding a transaction to a finalized block on the chain. The “read” operation consists of observing that a transaction has made it into a finalized block on the chain.

The ability to write and read correctly is formalized through the notions of liveness and safety. A liveness fault means that a node is unable to write to the blockchain. A safety fault means either that two honest nodes see different results when reading the database, or that a single node sees different results when reading the database at different times.222These two types of safety faults are practically equivalent: if two nodes see different results, then either the network remains permanently forked, or at least one of them will read a different value at some point in the future. This informs our two general definitions of liveness and safety below.

Definition 1 (Liveness).

We say that a protocol is live if from any state , any protocol-following node can take a sequence of actions that will lead to a valid transaction being added to a final block in its view.

Definition 2 (Safety).

We say that a protocol is safe if the following holds: any protocol-following node who considers a block as final at some time point , will also consider as final at any time point .

In practice, most protocols satisfy these properties only under certain conditions. In particular, most require that the honest nodes control a given fraction of the consensus-critical resources. For example, Bitcoin is safe only if the honest nodes are over -strong in terms of processing power, and even for then only with some probability.333However, this probability can be made arbitrarily high by increasing the number of confirmations required to make a block final. Quorum is live only if the honest and not permanently offline nodes are at least -strong, and safe only if the adversarial nodes are less than -strong, in terms of authority.

During a network partition, protocols can either satisfy liveness or safety, but not both – this is known as the CAP theorem [89]

. Different protocols resolve this trade-off in different ways. Liveness-oriented protocols such as Nakamoto consensus allow the chain to fork, and for this fork to be resolved when the partition ends by, e.g., the longest-chain rule. Safety-oriented protocols such as Tendermint

[115] and most other Byzantine fault tolerant protocols [38, 181] require that a (super)majority of participants sign off on each block. This means that during a network partition, at least one of the branches of the chain stops growing. In other settings, different branches of the chain can grow during a fork, but on only one of these branches can blocks be finalized. Examples include a traditional proof-of-work chain with Casper the Friendly Finality Gadget as an overlay (‘hybrid’ Casper) [37, 36]. It is also possible for protocols to guarantee neither liveness nor safety, e.g., Tangaroa [39].

In the scientific literature, the definitions and terminology used for safety and liveness properties may differ. Algorand [88] provides its own definitions of liveness (new transactions can be added to the final part of the blockchain) and safety (if a node accept a transaction as final, then it will continue to do so). In [78, 109, 57, 146], safety is called persistence – in turn, persistence and liveness can be shown to follow from the three properties common prefix, chain quality, and chain growth. For the Snow White [23, 54] and Tortoise and Hares [22] protocols, chain growth, chain quality, and consistency are considered. Here, consistency is a combination of common prefix and future self-consistency. In [17], the properties of validity and agreement are discussed as liveness properties, whereas integrity and total order are used for safety.

Typically, liveness and safety are proven for a specific protocol through a bespoke mathematical proof. However, under some assumptions on the actions in the protocol, general proof techniques may be available, e.g., model checking [25].

Iii-B Transaction Scope

Some protocols offer fundamentally different types of transactions than others. For example, Bitcoin only supports monetary transactions, which allows for the entire “state” of the system to be described using unspent transaction outputs (UTXOs). However, protocols that allow for smart contracts (e.g., Ethereum [35]) require that the clients also store the internal variables of the contracts [55]. This may have an impact of efficiency (see also Section V), both via reduced throughput due to slower transaction processing, and potentially less straightforward scalability (“state sharding” [193]).

Iii-C Privacy

The choice to put data on a blockchain instead of a centralized database has implications for privacy. On one hand, permissionless blockchains such as Bitcoin do not require identity management, which is good for privacy. On the other hand, the entire history of transactions is publicly accessible, which may allow for de-anonymization. In fact, Bitcoin transactions may be better described as pseudonymous than as anonymous [43]. Cryptographic techniques that improve privacy, e.g., zero-knowledge proofs [91] or ring signatures [155], are available, although they may impose additional computational overhead and therefore impact efficiency. Furthermore, usage pattern analysis can lead to user de-anonymization even in privacy-minded platforms such as Zcash [106].

Iv Stability

Since intended behavior cannot be enforced in decentralized settings, one of the core tasks of consensus protocols is to incentivize agents to reach an outcome that is both stable and desirable. In general, it is concerned with the question:

  • Does the protocol incentivize the intended behavior? Is implementing and following-the-protocol the best possible strategy for participating and prospective nodes?

Game theory and traditional economics provide numerous tools to analyze this setting. Yet, as consensus protocols become more elaborate, the range of incentives and the required stabilizing mechanisms also become more complicated. These issues are discussed separately below.

Iv-a Incentive Compatibility

At its core, incentive compatibility entails that it is in the participants’ best interest to follow-the-protocol. In concrete terms, and using the notation of Section II, this means that the default strategy profile is a Nash equilibrium, [180, 138]. An equilibrium is an outcome that is optimal from the perspective of all decision makers involved. Formally,

Definition 3 (Incentive Compatibility).

Let denote a protocol with active nodes , strategies , and long-term average utility functions as defined in Section II for all . Also, let denote the follow-the-protocol strategy, the strategy profile where all nodes follow , and the profile where all nodes follow except node who follows . Then, is incentive-compatible, if

and . In words, is incentive-compatible, if given that all other nodes follow the protocol, then it is optimal for an entering (or existing) node to also follow the protocol.

This definition relies on some assumptions that are not always satisfied in practice. First, it assumes that each node can take as given that all other agents do follow the protocol (strategy ) and second, that all agents are rational, i.e., utility maximizers. Also, it requires known utility functions for all nodes. While seemingly restrictive, establishing stability of a protocol within this vanilla setting is a core step in protocol design. It is within the scope primarily of robustness and to a lesser extent of persistence to explore what will happen if these assumptions are violated, cf. Sections VII and VI.

Example 1 (Bitcoin).

Nash equilibria in Bitcoin mining are discussed in [70] and [108]. Among others, these works show that whether the Bitcoin protocol is an equilibrium depends on the mining resources of a potential adversary (rational node) as a fraction of the total. [113] find that there is a multiplicity of symmetric equilibria in the Bitcoin protocol. Still, the default strategy prevails by a focal-point argument [162, 136]. [70] and [160] show that if nodes are at least -strong, where depends on their connectivity, then they are incentivized to follow the adversarial selfish mining strategy. [139] combine selfish mining – a consensus-layer attack – with an eclipse attack – a network-layer attack – to augment the rewards of selfish mining. Despite their theoretical plausibility, such attacks have not been recorded in practice.

Based on the above, the task of the blockchain architect is to engineer the consensus protocol in a way to induce the desired behavior in practice. Differences between intended and observed behavior should be addressed at this point. The theoretical discipline that models and studies such settings is mechanism design [122, 136, 14]. Applied in the blockchain context, its aim is to determine the rules of the protocol in a way that individual incentives will be perfectly aligned with societal goals.

The notion of incentive compatibility can be seen beyond just Nash equilibria. For example, depending on whether the majority is controlled by a single entity or not, one may discern between strong and weak incentive compatibility [27]. Additionally, in practice following-the-protocol extends to a set of operations that need to be performed by nodes rather than a single action. In particular, a consensus protocol of a public, permissionless blockchain needs to properly incentivize rational agents to perform the following actions:

  • [leftmargin=*]

  • Participation: acquire protocol resources, e.g., bandwidth.

  • Operations: perform core and auxiliary tasks such as proposal and creation of blocks, message propagation, transaction validation and execution, data storage, etc [43].

  • Applications: use the native cryptocurrency or blockchain related applications (“Dapps”).

Although integral to their viability, not all these actions are properly incentivized in existing blockchains, and miners’ incentives may be at odds with the underlying protocol

[171]. Additional concerns stem from the tension between short-term and long-term incentives [118]. In [153], a consensus protocol is proposed that motivates both ownership and participation, and which is apt to develop blockchains for social interaction. In [84], it is shown that economic motives for miners – transaction fees and block rewards – are also inherent to the security of PoS protocols. Finally, recent works suggest reputation systems as possible solutions to improve the incentive mechanisms of consensus protocols [141, 121].

The diversity of entities that are involved in the blockchain ecosystem introduces additional complexity. Different groups ranging from investors, developers, token holders to participating nodes and end users often do have conflicting incentives. This implies that apart from the need to incentivize certain operations, like the ones mentioned above, the blockchain protocol also needs to align potentially conflicting incentives of these groups. Similar concerns emerge in bockchain-based business markets or applications which entail the interaction between infrastructure and cyber-security providers, entrepreneurs and users in a trustless environment [74].

Theory on social choice and public goods provides insight into misaligned blockchain incentives [163]. A notable instance is captured by the free-rider or pass-the-bucket problem [19, 172]. In simplified terms, it states that rational agents who benefit from the existence of a public good – in this case, the blockchain – may shift responsibility for its creation to their peers. In the resulting equilibrium, the public good is not created, to everyone’s detriment. In public, permissionless blockchains, this translates to nodes moving costly tasks to other nodes, leading to an improper functionality of the blockchain ecosystem and deviation from its intended outcome.

Example 1 (Bitcoin).

To explain the lack of observed selfish mining incidents, [13] suggest natural incentives (i.e., mining rewards) and the high monetary value of Bitcoin as factors [77]. Yet, [68] identify incentives for attacks between miners and argue that the prevailing practice of not engaging in these attacks is fragile and if broken will lead to equilibria with dire consequences for the blockchain ecosystem.

In [12], it is argued that the Bitcoin reference protocol disincentivizes the propagation of information. In [8], it is demonstrated that the active usage of Bitcoin remains low, and largely restricted to speculation and illegal activity — this has a negative impact on the stability of Bitcoin’s exchange rate with fiat currencies, an issue also discussed in [113]. In [189], a scheme to incentivize miners to promptly propagate any blocks that they know of is proposed as a way to effectively defend against certain adversarial strategies.

Many blockchain platforms include transaction fees that are paid by the transaction creator to the node that creates a block that includes their transaction. Transaction fees also impact the incentives of Bitcoin users. Currently, Bitcoin transaction fees are low, yet non-zero [113]. However, in Turing-complete environments (e.g., Ethereum), transactions typically require more computation, which makes these environments particularly vulnerable to network-layer attacks [129]. Based on the resource utilized most, there are three main sources of cost for the miners: network, computation and storage. In [45], a fee-paying scheme for memory consumption that is typical to cloud storage services is proposed. In contrast to the currently deterministic transaction fees, [90] propose the idea of random payments to incentivize risk-neutral miners. In [41], the future of Bitcoin mining is analyzed, when mining rewards will have diminished, and conclude that if transaction fees are the only incentive, then selfish mining will be profitable for miners with arbitrarily small wealth. In the case that transaction fees can be further reduced, [47] argue that cryptocurrencies have the potential to become viable alternatives to retail payment schemes.

Protocol Resources

Protocol stability is tightly linked to the way that participating nodes acquire and increment their resources, which is starkly different between, e.g., PoW and PoS. In PoW protocols such as Bitcoin, computational (CPU) power is the consensus-critical resource. This implies that the costs for participating nodes are mainly electricity and investment in mining equipment [62]. These resources can be acquired in fiat currencies, yet, the mining rewards are distributed in the native cryptocurrency (Bitcoins).

PoS protocols generate different dynamics. Virtual miners acquire their resources by converting fiat currency to the native cryptocurrency which they then use as a proof to participate in the consensus mechanism. Mining rewards are again distributed in the native currency, however, in this case, the rewards naturally contribute to the protocol resources. This creates conflicting motives for staking nodes, since wealth and resources coincide and may lead to unpredictable inflation or disincentives to use or spend one’s stake. These observations call for a re-evaluation of the economics of different protocols through the lens of novel macroeconomic tools. Integral are the questions about the distribution of resources, the corresponding entry barriers, and market dynamics – perfect or oligopolistic competition – that they induce [5, 120].

Iv-B Decentralization

Decentralization lies at the core of blockchain design philosophy and is therefore integral for its long-term survival and sustainability [130, 120]. However, existing data shows that centralization plagues PoW (and PoS) cryptocurrencies of both high and low market values [76, 30]

. Miners join centralized pools, in particular to efficiently distribute mining rewards among their participants and hence reduce their variance

[157, 164, 175]. Yet, the operation of mining pools introduces unpredictable dynamics in the consensus mechanism and incentivizes miners (or protocol participants) to behave dishonestly, especially under high transaction loads, and destabilize the system [123, 141]. For instance, staking pools – the equivalent of mining pools in PoS protocols – can potentially evolve to become institutions with arbitrary power over their cryptocurrency [71, 30].

In conventional market economics, market concentration is measured by the Herfindahl-Hirschman Index (HHI), [154]. In general, the HHI is defined as the sum of the squares of the market shares of the firms within the industry where the market shares are expressed as percentages. As such, it can range from 0 to , with higher values indicating larger concentration444The USA Department of Justice considers a market with an HHI of less than 1,500 to be a competitive marketplace, an HHI of 1,500 to 2,500 to be a moderately concentrated marketplace, and an HHI of 2,500 or greater to be a highly concentrated marketplace. However, these thresholds refer to oligopolistic markets and should be much lower when studying decentralization in blockchains.. In the blockchain context, it can be used to study the concentration of protocol resources. For a state of protocol with active nodes , and distribution of consensus-critical resource fractions , the HHI is given by

The HHI is used in the context of antitrust management and also in applied social and political sciences to measure the concentration of political power [178, 119].

Example 1 (Bitcoin & Ethereum).

Table III

shows the estimated distribution of mining power between the top 10 Ethereum mining pools (or accounts) by number of blocks.

Bitcoin Ethereum
Entity (Pool) Blocks % Entity (Pool) Blocks %
1. Ethermine
2. AntPool Sparkpool
3. F2Pool F2Pool_2
4. Slushpool Nanopool
5. Poolin MiningPoolHub_1
6. ViaBTC Address_1
7. BTC.TOP Address_2
8. BitFury DwarfPool 1
9. BitClub Network
10. firepool
HH Index: 1075.7 1610.5

TABLE III: Concentration of mining power for the Bitcoin and Ethereum blockchains (as of 07 June 2019) and calculation of the Herfindahl Hirschman Index (HHI). Sources: and

The figures indicate a more decentralized market for Bitcoin than for Ethereum. Similar calculations indicate even higher centralization for smaller PoW platforms, for which attacks – distributions in which a single entity owns more than of the resources – are a reality [96, 104, 87]. These figures fuel the concerns that the current structure of the blockchain system is prone to centralization [86, 4].

From a stability perspective, [139] argue in favor of dispersing mining power since following the protocol remains a Nash equilibrium only for small hashpower. Incentives to derive short-term profits from attacks on mining pools threaten the long-term viability of Bitcoin and negatively impact the Bitcoin ecosystem [118]. [105] show that pool size and computational power are the main reasons to launch a network-level attack against a particular mining pool. Derivative attacks threaten also variant PoW blockchains [87].

Ideally, nodes should have no motive to band together at all. This informs the following definition:

Definition 4 (Perfect Decentralization).

Let protocol in any state consist of nodes , such that each node controls a fraction of the consensus-critical resource. Let the state , for , be the same state as except with nodes and merged, and their resources combined. Also, let denote the follow-the-protocol strategy and the strategy profile where all nodes follow . Then a protocol satisfies perfectly decentralization if

Such a definition depends strongly on the utility functions: e.g., in Bitcoin, banding together always reduces the reward variance, but when the pools, get too strong, trust in the system is undermined and Bitcoins will lose value against other (crypto)currencies. For example, the mining pool GHash.IO was forced to take action to reduce their pool size after they surpassed the mark [72].

Mining pools are not the only threat to decentralization. Other sources involve the underlying network layer, the geographic or economic motives to concentrate mining rigs in countries with low energy cost, and the increasingly sophisticated technology that is required to participate in the block creation process [183]. [50] study anti-trust policies in Turing-complete blockchains, i.e., blockchains that also support smart contract execution, and argue that although smart contracts mitigate information asymmetries and improve social welfare, they also encourage collusions and hence, generate a threat to decentralization. [81] develop a method to bootstrap the blockchain even without a genesis block created by a trusted authority. In all cases, the threats of centralization and trust formation raise the closely related question of blockchain governance and sustainability in the long run which is addressed in Section VII, [26]. Various sources of centralization in the blockchain ecosystem are illustrated in Figure 3.

Fig. 3: Centralization in the blockchain ecosystem: mining or staking pools, fin-tech institutions and intermediaries who offer services – verification, monitoring, data analytics – on public, permissionless blockchains may add value to the ecosystem but also pose a threat to decentralization. The dashed lines indicate possible interconnections between these entities which may further centralize the system.

Iv-C Fairness

An integral element of stability in non-permissioned protocols is fairness, which relies on the premise that participating nodes should be rewarded proportionally to their resource contribution. Recall that each node participates in the protocol by providing some consensus-critical resource which corresponds to a proportion of the total resources. If denotes the total rewards ( can be positive or negative) distributed by the protocol to nodes over a (long) period of time, then we can formally define fairness as follows.

Definition 5 (Fairness [147]).

The reward allocation mechanism of a protocol is said to be -fair for some , if in the presence of an -strong adversary, each node can guarantee of the rewards over any period of length .

Achieving fairness seems challenging in practice. Message delays and network latency can cause disproportional distribution of rewards [93]. Focusing on PoS protocols, [71] introduce the notion of equitability to quantify how much a proposer can amplify her stake compared to her initial investment. Even with everyone following the protocol (i.e., honest behavior), existing methods of allocating block rewards lead to poor equitability, as does the initialization of systems with small stake pools and/or large rewards relative to the stake pool. Consensus in distributed computing with weighted nodes and more general notions of fairness are studied in [83, 6, 182]. [147] extend this notion to environments with adaptive corruption by strengthening the definition of “ideal protocol quality” defined in [78] and [146].

Fairness in blockchains can be understood as a two dimensional notion that entails both the reward allocation and the block creation mechanisms, as illustrated in Figure 4. Current protocols are based on the premise that proportional voting is fair, [121]. However, the simple and seemingly appealing axiom one unit of resource (one computer or one coin), one vote has been theoretically refuted in traditional voting systems [16, 184].

Input of Resources

Blockchain Selection& Consensus Protocols

Rewards AllocationMechanism

Voting – DecisionMechanism


Output of Rewards& Consensus Outcome
Fig. 4: Fairness in the two core mechanisms of blockchain protocols: allocation of rewards and aggregation of voting data in the block creation process. Rewards are fairly allocated if they are proportional to participants’ resources. However, fairness in proportional voting is a premise that has been theoretically challenged, [73].

More importantly, node selection proportionally to their resources – as in current PoW and PoS protocols – does not necessarily imply fairness in the voting process, [73]. An illustration is provided in the following example.

Example 3.

To understand what can go wrong, consider a simplified blockchain network with three nodes that control and of protocol resources, respectively. The paradox that arises under pure proportional voting, and which is already known in political science, is that the weaker node is equally powerful with the much stronger node and in fact more desirable from the perspective of both nodes and in forming a majority () coalition.

Interestingly, this example also applies to PoW blockchains that do not involve voting. The reasoning is that coalitions between nodes with combined majority of protocol resources can control the protocol, thus creating a threatening issue in all permissionless blockchains, [120].

Fig. 5: Visual representation of the PREStO framework. The Blockchain consensus protocol lies in the middle of a series of concentric circles. The inner cycle comprises the 5 major axes of PREStO and the outer cycles correspond to subcategories of increasing granularity. Starting from this setting, the framework can be extended in a dynamic way to integrate features of future, more elaborate blockchains.

V Efficiency

After establishing that a blockchain protocol is optimal and stable, the next concern to be addressed is whether these goals are efficiently met or not. The main questions in this context relate to energy waste, scalability of operations, and comparison to centralized benchmark solutions. Formally

  • Does the implemented protocol make efficient use of its resources, and how does it compare to a conventional, centralized solution?

Efficiency of computation, at least from the perspective of time and space, has been thoroughly studied since the 1940s by Turing and von Neumann. Algorithmic game theory and mechanism design study questions on the intersection of optimality, efficiency and stability [140]. While, ideally, a protocol implements a (near) optimal equilibrium efficiently, computational complexity theory implies that there are fundamental limitations of efficient computation [145]. These limitations force us to consider trade-offs, e.g., approximate optimality versus speed or approximation algorithms [179]. The different elements of efficiency are discussed below.

V-a Energy Consumption

Efficiency exhibits a tradeoff between modest (excessive) waste of resources and high (low) risk of security attacks. Participating nodes in PoW protocols provide proofs of validity of the blockchain via energy-consumption which has been shown to make them inefficient [113]. A promising alternative is offered by the PoS or Virtual Mining protocols, in that they spare on this huge energy waste [110, 115, 21, 88, 159]. Since PoS protocols delegate decision power via proofs of coin (stake) ownership, their main advantage over Nakamoto’s PoW is the environmental sustainability [21].

Energy is not the only input that can be inefficiently used by a protocol. Data storage space, bandwidth and Random-Access Memory are only a few [45]. Other aspects of efficiency involve the times to process and finalize transactions and the communication complexity that is required for the distributed network to reach consensus [188]. Importantly, different applications introduce various degrees of uncertainty in the use of such resources and increase the challenge of designing efficient solutions. The hash rate for puzzle-solving and block propagation delay also determine the outcome of the mining competition [124]. Failing to address such issues demotivates agents from participating and leads to centralization. In this sense, efficiency is also related to stability [64].

Better ways to utilize the energy spent in PoW protocols may eliminate – if successful – the advantage of PoS over PoW protocols in terms of energy waste [15]. [181] provide a classification of other early proposals and open questions in this direction. Still, all these alternative proposals need to tackle the problem of scalability, described next.

V-B Scalability

Scalability refers to the property that the consensus protocol – and hence the blockchain – benefits from the addition of nodes or resources [194]. Generally, a blockchain is scalable if it exhibits positive scale effects, i.e., if increased participation leads to (i) increased throughput and (ii) improved liveness, safety, stability and efficiency guarantees. Since these indicators may respond differently to variations in the number of nodes (or the amount of resources), it is more convenient to understand scalability as a property of performance measures rather than of the blockchain protocol as a whole. Recall that a performance measure is called positive (negative) if increasing values indicate better (worse) performance, cf. Section II.

Definition 6 (Scalability).

Let state have consensus-critical resources , , and state resources such that . Then is scalable in the positive performance measure if for any .

Definition 6 states that a protocol is scalable in the performance measure if an increase in the resources of the current state implies an improved performance for . The definition for negative performance measures is similar.

Example 1 (Bitcoin).

To achieve its strong safety guarantees [168], the use of computational resources by the Bitcoin (PoW) protocol is not efficient: the maximum transaction throughput is the same as five years ago despite a dramatic increase in hash rate and energy consumption [143]. [24] identify excessive spending and inefficiencies in the prevailing equilibrium of following the Bitcoin protocol. [47] suggest that partial or complete substitution of energy-costly mining activities with PoS mechanisms, could benefit Bitcoin and make it more efficient in the long-run.

Attacks on the Bitcoin can inflict significant energy waste on miners [128]. In general, by partitioning the network or by either censoring or delaying the propagation of blocks, network-layer attacks can cause a significant amount of mining power to be wasted, leading to revenue losses and enabling a wide range of attacks such as double-spending. To deal with these threats, [130] propose a mining pool that will run as a smart contract and show that this is a solution with good efficiency and scaling properties.

Currently, a broadly studied solution to scalability is sharding, see e.g. Elastico [127], OmniLedger [111] and Ethereum [34, 67]. In alternative approaches, [85] model the concept of sidechains as a means to enable scalability and interoperability of blockchains. Their construction features merged-staking which prevents Goldfinger attacks – attacks whose explicit goal is to undermine and destabilize the consensus protocol [113, 26] – and cross-chain certification based on novel cryptographic primitives. [18] study a similar combination of consensus protocols with PoS subchains linked to the PoW Bitcoin blockchain.

V-C Throughput

Although throughput is closely related to scalability, a protocol can prioritize throughput even without making the protocol fundamentally more scalable. For example, by increasing the maximum number of transactions per block (e.g., Bitcoin Cash), throughput is increased without essentially affecting scalability. The same is true for protocols such as EOS and TRON, which achieve much higher throughput than, e.g., Bitcoin and Ethereum, but by curtailing the number of potential block proposers. In fact, a BFT protocol can easily achieve much higher throughput than a Nakamoto protocol if the number of nodes, denoted by , is low. However, such protocols typically suffer from negative rather than positive scale effects when the number of nodes increases due to the message complexity. So it is possible for a protocol change to have a positive effect on throughput yet a negative effect on scalability. This informs our definition below.

Definition 7 (Throughput).

Let the performance measure denote the long-term average transaction throughput, starting from state . A blockchain protocol with resources , has a higher throughput than another protocol with the same resources if .

Fundamentally, scalability concerns the effects on the outputs of a protocol due to a change in its resources, whereas throughput (as a PREStO category) concerns the effects on the outputs due to a change in protocol specifications but for the same resource allocation.

V-D Centralized Systems as Benchmarks

From a managerial perspective, the integral question in launching a blockchain project or application is whether a blockchain is indeed better than a centralized system for the intended purpose [185, 126]. Since blockchains eliminate trusted authorities to reach consensus via the coordination of distributed and self-interested entities, several questions come into play. How does the distributed system compare to a benchmark solution? Does it provide improved performance in terms of costs, efficiency and security?

Interestingly, related questions have been thoroughly researched in game theory. In particular, traffic routing, queueing theory and congestion networks explore precisely these tensions between equilibration and efficiency of centrally regulated systems, [48]. The trade-offs are quantified by the Price of Anarchy (PoA), which measures the sub-optimality caused by self-interested behavior relative to centrally designed and socially optimal outcomes [158, 101, 149]. PoA is defined as the ratio between the performance of the system at the worst-case equilibrium and that at a socially optimal state [112].

Studying this question in the current context requires us to quantify different aspects of blockchain performance and compare them to either an existing or a socially optimally (ideal) solution provided by a benevolent social planner or authority. To measure the effects of decentralizing a system when implementing it as a blockchain, we evaluate a derivative notion, the Price of Decentralization (PoD), which can be defined as


As above, denotes a performance measure of protocol . PoD compares the performance of the blockchain at state in which the system is operated by nodes who all follow the protocol, strategy profile , to its performance when it operates by a single node and in an optimal way. PoD retains the flavor of PoA but isolates the effect of decentralization. Following remarks are relevant

  • [leftmargin=*]

  • Depending on the application, the denominator may refer to an optimal solution, provided by an ideal social planner or a centralized solution, provided by a revenue-maximizing intermediary, or both.

  • The numerator evaluates the system’s performance under the assumption that all nodes follow the protocol. Thus, it does not account for strategic behavior; instead it assumes a default decentralized protocol execution and compares it to the corresponding centralized solution. More relevant in this direction is the approach of [135] who introduce the price of malice, to study how a system degrades in the presence of malicious agents.

  • Unlike PoA, the range of values of PoD is not restricted by and depends on (i) whether is a positive or negative performance measure, cf. Section II and (ii) whether the blockchain solution improves over the performance of the centralized solution or not.

Example 4.

To illustrate the above, let be the number of messages that need to be exchanged between nodes to reach consensus according to protocol . In a fully centralized execution of the system, the single entity trivially needs to send one message to each node to inform them of the the decision, leading to messages in total. However, in a BFT protocol, in which every node has to send a message to each other node, consensus takes messages, see e.g. Solidus, Algorand or Elastico, [17]. In this case, . This shows that the PoD of BFT protocol concerning the communication complexity is linear in the number of nodes and hence, is unbounded as grows to infinity.

Feature Example Protocol Transaction Scope Privacy Decentralization Fairness Scalability Throughput Attack resistance Recoverability
Partial solutions FruitChains [147], StrongChain [175] + + +
Smart contracts Ethereum [35] +
Checkpointing Casper FFG [36, 37] + +
Weighted Voting [121] + + +
Zero-knowledge proofs Zcash + +
Increased block size Bitcoin Cash +
Increased block frequency LiteCoin +
Microblocks Bitcoin-NG [69] +
Sharding Zilliqa [192], OmniLedger [111] + +
TABLE IV: Overview of the impact of several illustrative protocol features on the PREStO categories.

Vi Robustness

Suppose that a protocol has provable performance guarantees within its scope (optimality) and that following the protocol is an equilibrium (stability) at which, the protocol resources are reasonably utilized (efficiency). The next natural step in protocol design is to explore how smoothly and rapidly the protocol’s properties degrade when we move away from the vanilla setting. These concerns are expressed by the following question:

  • What is the resistance of the protocol to perturbations on its underlying assumptions?

In case of a parametrizable protocol, this question may also be phrased as the extent of parameter variation that the system can tolerate [7]. Essentially, robustness tests the assumptions that were used to equilibrate and stabilize the system. The main challenge is to assess protocol performance under practical challenges that are not captured by the ideal setting of Definition 3, such as parameter fluctuations, collusion between nodes, and malicious or irrational behavior [99].

Vi-a Alternative Equilibrium Concepts

The application of Nash equilibrium as a stability concept in blockchains is not uncontroversial [94, 11]. In particular, [94] and [56] argue that the shortcomings of Nash equilibria in distributed computational systems involve the following dimensions: unexpected behavior (irrational players with out-of-system incentives), coalitional deviations, computational limitations (resource-bounded players) and too much uncertainty or a lack of information (players are unaware of all the aspects of the game). To deal with these issues, [2, 94] propose the notion of robust strategy profiles which consist of two defining ingredients. On the one hand, they consider the profit of deviating players. If agents simultaneously deviate from a given strategy profile but are not able to increase their profits, then the strategy profile is said to be -resilient. On the other hand, they consider the harm incurred to non-deviating players. If agents simultaneously deviate from a given strategy profile but are not able to decrease the profits of non-deviating agents, then the strategy profile is said to be -immune. Combining these two elements yields the notion of -robust equilibrium as a strategy profile that is both -resilient and -immune.

Despite its theoretical appeal, [94] observes that the concept of -robust equlibrium has its own limitations and points to concepts of computational equilibria and particularly to the BAR-model – model with Byzantine, Altruistic and Rational agents – as possible alternatives [3, 11]. Nevertheless, [92] provide strong arguments to support the use of Nash equilibrium by showing that large games are inately fault tolerant. In fact, anonymous games that can be used to model blockchain mining are shown to be resilient against irrational behaviour (Byzantine faults), coalitions and asynchronous play.

In an approach that is particularly relevant to the blockchain setting, [125] define robustness of an equilibrium as the maximum proportion of malicious nodes that the desired equilibrium strategy can tolerate, in the sense that this strategy remains best strategy for rational players. In this definition, robustness is understood as a local property, i.e., as a property of a specific strategy profile and against specific adversarial strategies. This definition overcomes the computational difficulties of defining robustness on a blockchain level and utilizes the fact, that in blockchain applications, the analysis of robustness mainly concerns the default strategy profile.

Vi-B Out-of-Protocol Incentives

In reality, an adversarial node may try to change the behavior of other nodes by influencing their utility functions through threats or rewards. One of the earliest examples of this is feather forking [134] in Bitcoin: in this case, a miner threatens to refuse to extend blocks if they contain a blacklisted transaction. Even if the expected impact of the threat is small, it may be high enough compared to the small cost of enforcing the blacklist for cooperation with the threat to be rational. Similarly, bribery [27, 26, 131] or discouragement [33] attacks may impact the incentives of rational nodes.

In protocols in which it is known how much consensus-critical resources are owned by each of the nodes (i.e., semi-permissionless or permissioned blockchains), it may be possible to predict which nodes are scheduled to propose blocks in the near future. Accordingly, [29] identify two complementary properties – recency and predictability – of all longest-chain PoS protocols and devise relevant attacks to show that all such protocols are susceptible to certain kinds of malicious behavior. Finally, [165] explore the trade-offs between PoW and PoS consensus and find that a combination of both may yield robust results. In particular, for small numbers of participants PoS exhibits better security properties against 51% attacks by mining pools but as the size of the network increases, they recommend reverting to PoW.

Vi-C Resistance to Malicious Behaviour

Not all nodes are solely interested in protocol rewards – for example, they may be interested in performing a Goldfinger attack [113], in which one cryptocurrency platform is attacked to increase the value of others. One way of modeling this is to give such an attacker a utility that is the inverse of the collective utility, and calculate the total losses under the new equilibrium. Another approach is to calculate bounds on the losses that attackers can do relative to their own losses. In [32, 33] this is made explicit through the griefing factor (GF). In particular, let be nodes, be a starting state, let be the strategy profile where all nodes play the default strategy, and the profile where all nodes play except who plays . Then the griefing factor of between and is defined as

if the denominator is positive, and otherwise.

PRESTO Framework Design of Blockchain Consensus Layer
Research Challenges – Opportunities
Optimality [label=] Liveness Safety Scope Privacy features: public/private, permissioned/-less [label=] Selection of design/architecture & Sybil protection (PoW, PoS etc.). Exploring the trade-off between safety and liveness. Secure execution of smart contracts.
Stability [label=] Incentive compatibility: Participation, Operations, Applications Decentralization: Entry barriers, Distribution of resources Fairness: reward allocation, voting-decision making [label=] Design of incentive compatible mechanisms. Protection against adversarial behavior. Motivate decentralization, fair distribution of resources.
Efficiency [label=] Scalability: positive scale effects Throughput rate Economy of resources/ energy consumption Benchmarking to centralized solutions [label=] Design of scalable properties. Reduction of energy footprint. Compare blockchain to conventional solutions.
Robustness [label=] Tolerance of perturbed assumptions/irrational behaviour Out-of-Protocol Incentives Resilience to attacks: Incentives – Network – Cryptographic level [label=] Protection against collusions, Goldfinger attacks. Equilibration in elaborate adversarial models.
Persistence [label=] Weak/strong persistent properties Large scale or majority attacks Recovery mechanisms: rare events Governance & long-term sustainability [label=] Defense against 51% attacks, large network partitions Blockchain-Trilemma Design of sustainable blockchains Decision of governance schemes
TABLE V: Challenges and current research in the design of Blockchain Protocols based on the PRESTO Framework.

Vii Persistence

The four PREStO categories discussed so far consider the protocol when it operates at or near to equilibrium conditions. However, we have not treated blockchain performance under destabilizing conditions, and recovery mechanisms in the event that they occur. Hence, to establish a protocol’s persistence property, we ask the following question

  • How does a protocol recover if it is subjected to a severe attack or black-swan event? How fast, and at what cost?

Whereas for robustness, we studied performance under perturbations of the stability assumptions, for persistence, we take this idea to its logical extreme. We assume that the ecosystem is under a large-scale or protracted attack, and study whether it is designed to recover and resume its desirable properties, at least sufficiently often. Hence, we want to assess to what extent a blockchain has the qualities to survive and evolve under extreme crashes, technology shocks or other rare events.

Vii-a Weak & Strong Persistence

To understand protocols from this perspective, we formalize the notions of weakly and strongly persistent properties in the blockchain context. These ideas have been introduced within evolutionary game theory and in the study of biological systems, i.e., recovery of an ecosystem after infection from a virus [97, 169]. More relevant to the current context is the combination of these ideas with tools from optimization theory and algorithm design [20, 150]. Formally, recall that a property or feature of a protocol is defined as a function , cf. Section II.

Definition 8 (Weakly & strongly persistent properties [148]).

Consider a protocol and a property . Let be a protocol execution with initial state . We say that is

  • [topsep=0pt, noitemsep, align=left, leftmargin=*]

  • weakly persistent for protocol , if for any , and any , there exists such that .

  • strongly persistent for protocol , if for any , there exists , such that for all .

Intuitively, a weakly persistent property will eventually be satisfied and will become satisfied again infinitely often given any initial system condition, whereas a strongly persistent property will be eventually satisfied and stay satisfied given any initial system condition, [148]. These definitions capture the idea that a desirable property may not be satisfied by a system in equilibrium, but in a dynamic way. This allows for more flexibility between recovery/convergence time, “periodicity”, and the cost of implementation.

Example 5 (The Blockchain Trilemma).

The idea of supporting two or more incompatible properties in a weakly persistent manner, as described above, can be exploited to deal with the challenging “Blockchain Trilemma” [1, 51] which is illustrated in Figure 6. The vertices of the triangle correspond to the three seemingly incompatible but desirable properties that blockchain consensus protocols need to satisfy: decentralization, scalability and safety. Protocols can be thought of as points inside the triangle, with coordinates indicating the degree of satisfaction of each of these properties.

Designing an optimal protocol – i.e., a protocol which in equilibrium satisfies simultaneously all three properties – has been a formidable task for blockchain architects, [88]. Such a protocol is indicated by the green dot in Figure 6. However, the idea of weak persistence can be exploited for an alternative design: a protocol could solve the trilemma by constantly alternating between states that satisfy a non-conflicting subset of the otherwise incompatible properties. This is captured by the blue dot protocol and the dashed arrows in Figure 6 which show its transition between different states.




Fig. 6: Dealing with the Blockchain Trilemma: The green dot denotes an ideal protocol that satisfies all three properties in equilibrium. The blue dot denotes a protocol that cycles around the ideal solution and which satisfies the incompatible properties in a weakly persistent (recurrent) manner.

The idea of studying distributed computation through the lens of dynamical systems has been recently inititated by [103]. Based on their ideas, persistence can be also used to formulate a weaker definition of fairness, cf. Section IV-C. Namely, a protocol can be described as fair if each node gets to be selected in the block creation process infinitely often.

Vii-B Recovery from Majority Attacks

One of the major challenges in blockchain consensus protocols is the recovery from attacks by malicious nodes who control the majority of protocol resources, [26]. Existing protocols establish their safety and liveness properties under the assumption of either a simple – – or an enhanced – usually – honest majority of nodes, [191]. Contrary to initial beliefs, resent studies unveiled that such attacks pose a plausible threat to existing blockchain protocols [27]. An important insight from these studies is that it is suffices to gain control for some short period of time, for instance by temporarily renting protocol resources.

A suggested mechanism to recover from majority or large-scale attacks on the Ethereum blockchain is the minority fork, proposed by [34]. In brief, a minority fork is a mechanism to recover the majority of the consensus-critical resources through a fork initiated by an honest minority. Because the majority cannot create blocks on both branches of the fork, they will be seen as offline on the minority-initiated branch, which may cause their share to shrink on this branch. Such a scheme is fundamentally impossible in permissionless blockchains.

Vii-C Governance & Sustainability

Persistence is closely related to the decision processes that determine the structure and operation of the blockchain. The practical need for an optimal governance structure in the Bitcoin community has already been observed by [113]. In a different approach, [43] view the blockchain as a public good and discuss the role of intermediaries that will provide paid services of verification and monitoring of the blockchain which will add value to the whole blockchain ecosystem. Excluding tentative predictions, the formal governance structure of public, permissionless blockchains has yet to be determined, [98]. Integral to the success of blockchains, the issues of governance and long-term sustainability are central themes in current blockchain evolution.

Viii Conclusions & Future Research

A spatial representation of the PRESTO framework is given in Figure 5. In Table V, we summarize its categories and subcategories and use it to identify research challenges and perspectives. Owning to its modular structure, PRESTO can be expanded or modified to accommodate advances or additional research opportunities in the future of blockchain protocols. Accordingly, it can be used to track the evolution of the blockchain ecosystem and structure the communication between its diverse participants who range from protocol designers, technology experts and end users to academics, corporate managers and strategic investors.

Summing up, the PRESTO framework sees protocols as multi-dimensional objects with the following cascade of goals. First, optimality requires that the protocol solves the problem that it is defined to address, otherwise there is no good reason to deploy it and the designer should go back to the drawing board. Second, stability aims to ensure that self-interested agents have an incentive to follow and implement the protocol, i.e., that the protocol itself is an equilibrium. If not, the agents will deviate from it and the deployed protocol will behave unpredictably in practice. Next, efficiency requires that resources are used as efficiently as possible (e.g. time, space, network bandwidth, energy, randomness, etc.). Given an optimal, stable and efficient protocol, the next steps are to consider more elaborate behavioral models from the perspective of the agents. These entail robustness and persistence which measure the resilience of the established equilibria in less idealized settings and the performance of the blockchain in highly perturbed, non-equilibrium conditions, respectively.

The exploration of these trade-offs is an area for multidisciplinary research that relies on the synthesis of ideas from game theory, cryptography and theoretical computer science. In this direction, PREStO can be used as a dynamic framework to structure the communication between researchers with diverse backgrounds and to accommodate increasingly more elaborate features of future blockchain protocols.


  • [1] J. Abadi and M. Brunnermeier. Blockchain Economics. Working Paper 25407, National Bureau of Economic Research, December 2018.
  • [2] I. Abraham, D. Dolev, R. Gonen, and J. Halpern. Distributed Computing Meets Game Theory: Robust Mechanisms for Rational Secret Sharing and Multiparty Computation. In Proceedings of the Twenty-fifth Annual ACM Symposium on Principles of Distributed Computing, PODC ’06, pages 53–62, New York, NY, USA, 2006. ACM.
  • [3] A. S. Aiyer, L. Alvisi, A. Clement, M. Dahlin, J.-P. Martin, and C. Porth. BAR Fault Tolerance for Cooperative Services. In Proceedings of the Twentieth ACM Symposium on Operating Systems Principles, SOSP ’05, pages 45–58, New York, NY, USA, 2005. ACM.
  • [4] M. Apostolaki, A. Zohar, and L. Vanbever. Hijacking Bitcoin: Large-scale Network Attacks on Cryptocurrencies. CoRR, abs/1605.07524, 2016.
  • [5] N. Arnosti and S. M. Weinberg. Bitcoin: A Natural Oligopoly. In 10th Innovations in Theoretical Computer Science Conference, ITCS 2019, January 10-12, 2019, San Diego, California, USA, pages 5:1–5:1, 2019.
  • [6] G. Asharov, R. Canetti, and C. Hazay. Toward a Game Theoretic View of Secure Computation. J. Cryptol., 29(4):879–926, Oct. 2016.
  • [7] K. J. Astrom and R. M. Murray. Feedback Systems: An Introduction for Scientists and Engineers. Princeton University Press, Princeton, NJ, USA, 2010.
  • [8] S. Athey, I. Parashkevov, V. Sarukkai, and J. Xia. Bitcoin Pricing, Adoption, and Usage: Theory and Evidence. Research paper no. 16–42, Stanford University, Graduate School of Business, 2016.
  • [9] N. Atzei, M. Bartoletti, and T. Cimoli. A Survey of Attacks on Ethereum Smart Contracts SoK. In Proceedings of the 6th International Conference on Principles of Security and Trust - Volume 10204, pages 164–186, New York, NY, USA, 2017. Springer-Verlag New York, Inc.
  • [10] S. Azouvi and A. Hicks. SoK: Tools for Game Theoretic Models of Security for Cryptocurrencies. arXiv preprint arXiv:1905.08595, 2019.
  • [11] S. Azouvi, A. Hicks, and S. J. Murdoch. Incentives in Security Protocols. In V. Matyáš, P. Švenda, F. Stajano, B. Christianson, and J. Anderson, editors, Security Protocols XXVI, pages 132–141, Cham, 2018. Springer International Publishing.
  • [12] M. Babaioff, S. Dobzinski, S. Oren, and A. Zohar. On Bitcoin and Red Balloons. In Proceedings of the 13th ACM Conference on Electronic Commerce, EC ’12, pages 56–73, New York, NY, USA, 2012. ACM.
  • [13] C. Badertscher, J. Garay, U. Maurer, D. Tschudi, and V. Zikas. But Why Does It Work? A Rational Protocol Design Treatment of Bitcoin. In J. B. Nielsen and V. Rijmen, editors, Advances in Cryptology – EUROCRYPT 2018, pages 34–65. Springer International Publishing, 2018.
  • [14] M. Balcan, S. Krehbiel, G. Piliouras, and J. Shin. Minimally invasive mechanism design: Distributed covering with carefully chosen advice. To appear in the Proceedings of the 51st IEEE Conference on Decision and Control (CDC), 2012.
  • [15] M. Ball, A. Rosen, M. Sabin, and P. N. Vasudevan. Proofs of Useful Work. Cryptology ePrint Archive, Report 2017/203, 2017. [online].
  • [16] S. A. Banducci and J. A. Karp. Perceptions of Fairness and Support for Proportional Representation. Political Behavior, 21(3):217–238, 1999.
  • [17] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry, S. Meiklejohn, and G. Danezis. Consensus in the Age of Blockchains. arXiv e-prints, page arXiv:1711.03936, 2017.
  • [18] M. Bartoletti, S. Lande, and A. S. Podda. A Proof-of-Stake Protocol for Consensus on Bitcoin Subchains. In M. Brenner, K. Rohloff, J. Bonneau, A. Miller, P. Y. Ryan, V. Teague, A. Bracciali, M. Sala, F. Pintore, and M. Jakobsson, editors, Financial Cryptography and Data Security, pages 568–584, Cham, 2017. Springer International Publishing.
  • [19] W. Baumol. Welfare Economics and the Theory of the State. Harvard University Press, Cambridge, Massachusetts, 1952.
  • [20] A. Ben-Tal and A. Nemirovski. Lectures on modern convex optimization: analysis, algorithms, and engineering applications. SIAM, 2001.
  • [21] I. Bentov, A. Gabizon, and A. Mizrahi. Cryptocurrencies Without Proof of Work. In J. Clark, S. Meiklejohn, P. Y. Ryan, D. Wallach, M. Brenner, and K. Rohloff, editors, Financial Cryptography and Data Security, pages 142–157, Berlin, Heidelberg, 2016. Springer Berlin Heidelberg.
  • [22] I. Bentov, P. Hubácek, T. Moran, and A. Nadler. Tortoise and Hares Consensus: the Meshcash Framework for Incentive-Compatible, Scalable Cryptocurrencies. IACR Cryptology ePrint Archive, 2017:300, 2017.
  • [23] I. Bentov, R. Pass, and E. Shi. Snow White: Provably Secure Proofs of Stake. IACR Cryptology ePrint Archive, 2016:919, 2016.
  • [24] B. Biais, C. Bisière, M. Bouvard, and C. Casamatta. The blockchain folk theorem. IDEI Working Papers 873, Institut d’Économie Industrielle (IDEI), Toulouse, May 2017.
  • [25] A. Biere, A. Cimatti, E. M. Clarke, O. Strichman, Y. Zhu, et al. Bounded model checking. Advances in computers, 58(11):117–148, 2003.
  • [26] J. Bonneau. Hostile blockchain takeovers (short paper). In Proceedings of the 5th IFCA Workshop on Bitcoin and Blockchain Research, 2018.
  • [27] J. Bonneau, E. Felten, S. Goldfeder, J. Kroll, and A. Narayanan. Why Buy When You Can Rent? Bribery Attacks on Bitcoin-Style Consensus. In Financial Cryptography Workshops, 2016.
  • [28] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten. SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies. In 2015 IEEE Symposium on Security and Privacy, pages 104–121, 2015.
  • [29] J. Brown-Cohen, A. Narayanan, C.-A. Psomas, and S. M. Weinberg. Formal Barriers to Longest-Chain Proof-of-Stake Protocols. ArXiv e-prints, 2018.
  • [30] L. Brünjes, A. Kiayias, E. Koutsoupias, and A.-P. Stouka. Reward Sharing Schemes for Stake Pools. arXiv e-prints, page arXiv:1807.11218, 2018.
  • [31] Business Wire. Algorand secures $62m in funding and announces appointment of executive team, 2018. Available [online]. [Accessed: 26-2-2019].
  • [32] V. Buterin. The triangle of harm, 2017. Available [online]. [Accessed: 3-9-2018].
  • [33] V. Buterin. Discouragement Attacks, 2018. Available [online]. [Accessed: 13-6-2019].
  • [34] V. Buterin. Ethereum 2.0 spec – Casper and sharding, 2018. Available [online]. [Accessed: 30-10-2018].
  • [35] V. Buterin et al. A next-generation smart contract and decentralized application platform, 2014. Available [online]. [Accessed: 13-4-2018].
  • [36] V. Buterin and V. Griffith. Casper the friendly finality gadget. arXiv preprint arXiv:1710.09437, 2017.
  • [37] V. Buterin, D. Reijsbergen, S. Leonardos, and G. Piliouras. Incentives in Ethereum’s Hybrid Casper Protocol. In ICBC 2019, May 2019.
  • [38] C. Cachin. Architecture of the Hyperledger blockchain fabric. In Workshop on Distributed Cryptocurrencies and Consensus Ledgers, 2016.
  • [39] C. Cachin and M. Vukolić. Blockchain Consensus Protocols in the Wild. CoRR, abs/1707.01873, 2017.
  • [40] Cardano. [website]. [Accessed: 26-2-2019].
  • [41] M. Carlsten, H. Kalodner, S. M. Weinberg, and A. Narayanan. On the Instability of Bitcoin Without the Block Reward. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, pages 154–167, New York, NY, USA, 2016. ACM.
  • [42] F. Casino, T. K. Dasaklis, and C. Patsakis. A systematic literature review of blockchain-based applications: Current status, classification and open issues. Telematics and Informatics, 36:55–81, 2019.
  • [43] C. Catalini and J. S. Gans. Some Simple Economics of the Blockchain. Working Paper 22952, National Bureau of Economic Research, December 2016.
  • [44] F. Chaparro. Banks have a big appetite to join JPMorgan’s blockchain party. Business Insider, 2018. Available [online]. [Accessed: 25-2-2019].
  • [45] A. Chepurnoy, V. Kharin, and D. Meshkov. A Systematic Approach To Cryptocurrency Fees. Cryptology ePrint Archive, Report 2018/078, 2018. [online].
  • [46] V. Chia, P. Hartel, Q. Hum, S. Ma, G. Piliouras, D. Reijsbergen, M. van Staalduinen, and P. Szalachowski. Rethinking blockchain security: Position paper. In 1st IEEE International Conference on Blockchain, 2018.
  • [47] J. Chiu and T. Koeppl. The Economics of Cryptocurrencies – Bitcoin and Beyond. Working Paper Series 6688, Victoria University of Wellington, School of Economics and Finance, 2017.
  • [48] G. Christodoulou and E. Koutsoupias. The Price of Anarchy of Finite Congestion Games. STOC, pages 67–73, 2005.
  • [49] Coin MarketCap. Available [online]. [Accessed: 25-2-2019].
  • [50] L. Cong and Z. He. Blockchain Disruption and Smart Contracts. Working Paper No. w24399. Available at SSRN: 873, NBER, March 2018.
  • [51] M. Conti, A. Gangwal, and M. Todero. Blockchain Trilemma Solver Algorand has Dilemma over Undecidable Messages. arXiv e-prints, page arXiv:1901.10019, Jan 2019.
  • [52] M. Conti, E. S. Kumar, C. Lal, and S. Ruj. A Survey on Security and Privacy Issues of Bitcoin. IEEE Communications Surveys Tutorials, 20(4):3416–3452, 2018.
  • [53] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Saxena, E. Shi, E. Gün Sirer, D. Song, and R. Wattenhofer. On Scaling Decentralized Blockchains (Position Paper). In J. Clark, S. Meiklejohn, P. Y. Ryan, D. Wallach, M. Brenner, and K. Rohloff, editors, Financial Cryptography and Data Security, pages 106–125, Berlin, Heidelberg, 2016. Springer Berlin Heidelberg.
  • [54] P. Daian, R. Pass, and E. Shi. Snow White: Robustly Reconfigurable Consensus and Applications to Provably Secure Proof of Stake. Cryptology ePrint Archive, Report 2016/919, 2016. [online].
  • [55] S. Das, A. Kolluri, P. Saxena, and H. Yu. On the Security of Blockchain Consensus Protocols (Invited Paper). In V. Ganapathy, T. Jaeger, and R. Shyamasundar, editors, Information Systems Security, pages 465–480, Cham, 2018. Springer International Publishing.
  • [56] C. Daskalakis, P. W. Goldberg, and C. H. Papadimitriou. The Complexity of Computing a Nash Equilibrium. In

    Proceedings of the Thirty-eighth Annual ACM Symposium on Theory of Computing

    , STOC ’06, pages 71–78, New York, NY, USA, 2006. ACM.
  • [57] B. David, P. Gaži, A. Kiayias, and A. Russell. Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 66–98. Springer, 2018.
  • [58] C. Decker and R. Wattenhofer. Information propagation in the bitcoin network. In IEEE P2P 2013 Proceedings, pages 1–10. IEEE, 2013.
  • [59] M. del Castillo. Fidelity launches institutional platform for Bitcoin and Ethereum. Forbes, 2018. Available [online]. [Accessed: 25-2-2019].
  • [60] M. del Castillo. Despite crypto depression, M&A deals set new record. Forbes, 2019. Available [online]. [Accessed: 25-2-2019].
  • [61] M. del Castillo. Nasdaq leads $20 million investment in enterprise blockchain startup Symbiont. Forbes, 2019. Available [online]. [Accessed: 25-2-2019].
  • [62] S. Dhamal, T. Chahed, W. Ben-Ameur, E. Altman, A. Sunny, and S. Poojary. A Stochastic Game Framework for Analyzing Computational Investment Strategies in Distributed Computing with Application to Blockchain Mining. arXiv e-prints, page arXiv:1809.03143, 2018.
  • [63] Digiconomist. Bitcoin Energy Consumption Index. Available [online]. [Accessed: 3-9-2018].
  • [64] N. Dimitri. Bitcoin Mining as a Contest. Ledger, 2(0):31–37, 2017.
  • [65] T. T. A. Dinh, R. Liu, M. Zhang, G. Chen, B. C. Ooi, and J. Wang. Untangling Blockchain: A Data Processing View of Blockchain Systems. IEEE Transactions on Knowledge and Data Engineering, 30(7):1366–1385, 2018.
  • [66] T. T. A. Dinh, J. Wang, G. Chen, R. Liu, B. C. Ooi, and K.-L. Tan. BLOCKBENCH: A Framework for Analyzing Private Blockchains. In Proceedings of the 2017 ACM International Conference on Management of Data, SIGMOD ’17, pages 1085–1100, New York, NY, USA, 2017. ACM.
  • [67] Ethereum. Sharding Roadmap. Available [online]. [Accessed: 14-9-2018].
  • [68] I. Eyal. The Miner’s Dilemma. In Proceedings of the 2015 IEEE Symposium on Security and Privacy, SP ’15, pages 89–103, Washington, DC, USA, 2015. IEEE Computer Society.
  • [69] I. Eyal, A. E. Gencer, E. G. Sirer, and R. Van Renesse. Bitcoin-ng: A scalable blockchain protocol. In 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI), pages 45–59, 2016.
  • [70] I. Eyal and E. Sirer. Majority Is Not Enough: Bitcoin Mining Is Vulnerable. In N. Christin and R. Safavi-Naini, editors, Financial Cryptography and Data Security, pages 436–454, Berlin, Heidelberg, 2014. Springer Berlin Heidelberg.
  • [71] G. Fanti, L. Kogan, S. Oh, K. Ruan, P. Viswanath, and G. Wang. Compounding of Wealth in Proof-of-Stake Cryptocurrencies. ArXiv e-prints, 2018.
  • [72] C. Farivar. Bitcoin pool commits to 40% hashrate limit after its 51% breach. [online], 2014.
  • [73] D. Felsenthal and M. Machover. The Measurement of Voting Power: Theory and Practice, Problems and Paradoxes. Edward Elgar Publishing, Inc., 1998.
  • [74] S. Feng, W. Wang, Z. Xiong, D. Niyato, P. Wang, and S. Shuxun Wang. On Cyber Risk Management of Blockchain Networks: A Game Theoretic Approach. arXiv e-prints, page arXiv:1804.10412, Apr. 2018.
  • [75] M. A. Ferrag, M. Derdour, M. Mukherjee, A. Derhab, L. Maglaras, and H. Janicke. Blockchain technologies for the internet of things: Research issues and challenges. IEEE Internet of Things Journal, 2018.
  • [76] B. Fisch, R. Pass, and A. Shelat. Socially Optimal Mining Pools. In N. R. Devanur and P. Lu, editors, Web and Internet Economics, pages 205–218, Cham, 2017. Springer International Publishing.
  • [77] J. Garay, J. Katz, U. Maurer, B. Tackmann, and V. Zikas. Rational Protocol Design: Cryptography against Incentive-Driven Adversaries. In 2013 IEEE 54th Annual Symposium on Foundations of Computer Science, pages 648–657, Oct 2013.
  • [78] J. Garay, A. Kiayias, and N. Leonardos. The Bitcoin Backbone Protocol: Analysis and Applications. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 281–310. Springer, 2015.
  • [79] J. Garay, A. Kiayias, and N. Leonardos. The Bitcoin Backbone Protocol with Chains of Variable Difficulty. In J. Katz and H. Shacham, editors, Advances in Cryptology – CRYPTO 2017, pages 291–323, Cham, 2017. Springer International Publishing.
  • [80] J. A. Garay and A. Kiayias. SoK: A Consensus Taxonomy in the Blockchain Era. IACR Cryptology ePrint Archive, 2018:754, 2018.
  • [81] J. A. Garay, A. Kiayias, N. Leonardos, and G. Panagiotakos. Bootstrapping the Blockchain, with Applications to Consensus and Fast PKI Setup. In Public Key Cryptography, 2018. [online].
  • [82] A. Garcia. IBM is betting big on blockchain technology. Is it worth the risk? CNN Business, 2018. Available [online]. [Accessed: 25-2-2019].
  • [83] V. K. Garg and J. Bridgman. The Weighted Byzantine Agreement Problem. In 2011 IEEE International Parallel Distributed Processing Symposium, pages 524–531, May 2011.
  • [84] P. Gazi, A. Kiayias, and A. Russell. Stake-Bleeding Attacks on Proof-of-Stake Blockchains. 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), pages 85–92, 2018.
  • [85] P. Gazi, A. Kiayias, and D. Zindros. Proof-of-Stake Sidechains. Cryptology ePrint Archive, Report 2018/1239, 2018. [online].
  • [86] A. Gervais, G. O. Karame, V. Capkun, and S. Capkun. Is Bitcoin a Decentralized Currency? IEEE Security & Privacy, 12(3):54–60, May 2014.
  • [87] A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, and S. Capkun. On the Security and Performance of Proof of Work Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, pages 3–16, New York, NY, USA, 2016. ACM.
  • [88] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, pages 51–68. ACM, 2017.
  • [89] S. Gilbert and N. Lynch. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. Acm Sigact News, 33(2):51–59, 2002.
  • [90] H. Gjermundrød, K. Chalkias, and I. Dionysiou. Going Beyond the Coinbase Transaction Fee: Alternative Reward Schemes for Miners in Blockchain Systems. In Proceedings of the 20th Pan-Hellenic Conference on Informatics, PCI ’16, pages 35:1–35:4, New York, NY, USA, 2016. ACM.
  • [91] S. Goldwasser, S. Micali, and C. Rackoff. The knowledge complexity of interactive proof systems. SIAM Journal on computing, 18(1):186–208, 1989.
  • [92] R. Gradwohl and O. Reingold. Fault tolerance in large games. Games and Economic Behavior, 86:438–457, 2014.
  • [93] R. Guerraoui and J. Wang. On the unfairness of blockchain. Technical report, EPFL Scientific Publications, 2018.
  • [94] J. Y. Halpern. Beyond Nash Equilibrium: Solution Concepts for the 21st Century. In J. S. Baras, J. Katz, and E. Altman, editors, Decision and Game Theory for Security, pages 1–3, Berlin, Heidelberg, 2011. Springer Berlin Heidelberg.
  • [95] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg. Eclipse Attacks on Bitcoin’s Peer-to-Peer Network. In 24th USENIX Security Symposium (USENIX Security 15), pages 129–144, Washington, D.C., 2015. USENIX Association.
  • [96] A. Hertig. Blockchain’s Once-Feared 51% Attack Is Now Becoming Regular., 2018. Available [online]. [Accessed: 26-02-2019].
  • [97] J. Hofbauer and K. Sigmund. Evolutionary Games and Population Dynamics. Cambridge University Press, Cambridge, 1998.
  • [98] C. Hoskinson. Ethereum Cofounder Says Blockchain Presents “Governance Crisis”, 2019. Available [online]. [Accessed: 11-4-2019].
  • [99] Z. Hu and J. Zhang. Toward General Robustness Evaluation of Incentive Mechanism Against Bounded Rationality. IEEE Transactions on Computational Social Systems, 5(3):698–712, Sep. 2018.
  • [100] HyperLedger. Walmart turns to blockchain (and Hyperledger) to take on food traceability and safety, 2018. Available [online]. [Accessed: 25-2-2019].
  • [101] N. Immorlica, E. Markakis, and G. Piliouras. Coalition Formation and Price of Anarchy in Cournot Oligopolies. In A. Saberi, editor, Workshop on Internet and Network Economics (WINE), pages 270–281, Berlin, Heidelberg, 2010. Springer Berlin Heidelberg.
  • [102] Istanbul Byzantine Fault Tolerance. website. [Accessed: 13-6-2019].
  • [103] A. D. Jaggard, N. Lutz, M. Schapira, and R. N. Wright. Dynamics at the Boundary of Game Theory and Distributed Computing. ACM Trans. Econ. Comput., 5(3):15:1–15:20, 2017.
  • [104] G. Jenkinson. Ethereum Classic 51% Attack – The Reality of Proof-of-Work., 2019. Available [online]. [Accessed: 26-02-2019].
  • [105] B. Johnson, A. Laszka, J. Grossklags, M. Vasek, and T. Moore. Game-Theoretic Analysis of DDoS Attacks Against Bitcoin Mining Pools. In R. Böhme, M. Brenner, T. Moore, and M. Smith, editors, Financial Cryptography and Data Security, pages 72–86, Berlin, Heidelberg, 2014. Springer Berlin Heidelberg.
  • [106] G. Kappos, H. Yousaf, M. Maller, and S. Meiklejohn. An empirical analysis of anonymity in Zcash. In 27th USENIX Security Symposium, pages 463–477, 2018.
  • [107] A. Kaushik, A. Choudhary, C. Ektare, D. Thomas, and S. Akram. Blockchain – Literature survey. In 2017 2nd IEEE International Conference on Recent Trends in Electronics, Information Communication Technology (RTEICT), pages 2145–2148, 2017.
  • [108] A. Kiayias, E. Koutsoupias, M. Kyropoulou, and Y. Tselekounis. Blockchain Mining Games. In Proceedings of the 2016 ACM Conference on Economics and Computation, pages 365–382. ACM, 2016.
  • [109] A. Kiayias, A. Russell, B. David, and R. Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357–388. Springer, 2017.
  • [110] S. King and S. Nadal. PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake, 2012.
  • [111] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford. Omniledger: A secure, scale-out, decentralized ledger via sharding. In 2018 IEEE Symposium on Security and Privacy (SP), pages 583–598. IEEE, 2018.
  • [112] E. Koutsoupias and C. H. Papadimitriou. Worst-case Equilibria. In Annual Symposium on Theoretical Aspects of Computer Science (STACS), pages 404–413. Springer-Verlag, 1999.
  • [113] J. A. Kroll, I. C. Davey, and E. W. Felten. The Economics of Bitcoin Mining, or Bitcoin in the Presence of Adversaries. In Workshop on the Economics of Information Security, volume 2013, page 11, 2013.
  • [114] N. Kshetri. Blockchain’s roles in meeting key supply chain management objectives. International Journal of Information Management, 39:80–89, 2018.
  • [115] J. Kwon. Tendermint: Consensus without mining, 2014.
  • [116] L. Lamport et al. The part-time parliament. ACM Transactions on Computer Systems, 1998.
  • [117] L. Lamport, R. Shostak, and M. Pease. The byzantine generals problem. ACM Transactions on Programming Languages and Systems (TOPLAS), 4(3):382–401, 1982.
  • [118] A. Laszka, B. Johnson, and J. Grossklags. When Bitcoin Mining Pools Run Dry. In M. Brenner, N. Christin, B. Johnson, and K. Rohloff, editors, Financial Cryptography and Data Security, pages 63–77, Berlin, Heidelberg, 2015. Springer Berlin Heidelberg.
  • [119] C. Lees. Coalition Formation and the German Party System. German Politics, 20(1):146–163, 2011.
  • [120] N. Leonardos, S. Leonardos, and G. Piliouras. Oceanic Games: Centralization Risks and Incentives in Blockchain Mining. The 1st International Conference on Mathematical Research for Blockchain Economy, page arXiv:1904.02368, Apr 2019.
  • [121] S. Leonardos, D. Reijsbergen, and G. Piliouras. Weighted Voting on the Blockchain: Improving Consensus in Proof of Stake Protocols. In ICBC 2019, May 2019.
  • [122] S. R. Leonid Hurwicz. Designing Economic Mechanisms. Cambridge University Press, New York, USA, 2006.
  • [123] Y. Lewenberg, Y. Bachrach, Y. Sompolinsky, A. Zohar, and J. S. Rosenschein. Bitcoin Mining Pools: A Cooperative Game Theoretic Analysis. In Proceedings of the 2015 International Conference on Autonomous Agents and Multiagent Systems, AAMAS ’15, pages 919–927, Richland, SC, 2015. International Foundation for Autonomous Agents and Multiagent Systems.
  • [124] X. Liu, W. Wang, D. Niyato, N. Zhao, and P. Wang. Evolutionary Game for Mining Pool Selection in Blockchain Networks. IEEE Wireless Communications Letters, 7(5):760–763, Oct 2018.
  • [125] Y. Liu, J. Zhang, B. An, and S. Sen. A simulation framework for measuring robustness of incentive mechanisms and its implementation in reputation systems. Autonomous Agents and Multi-Agent Systems, 30(4):581–600, Jul 2016.
  • [126] D. LLP. Blockchain Enigma. Paradox. Opportunity, 2019. Available [online]. [Accessed: 10-4-2019].
  • [127] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena. A secure sharding protocol for open blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 17–30. ACM, 2016.
  • [128] L. Luu, R. Saha, I. Parameshwaran, P. Saxena, and A. Hobor. On Power Splitting Games in Distributed Computation: The Case of Bitcoin Pooled Mining. In 2015 IEEE 28th Computer Security Foundations Symposium, pages 397–411, 2015.
  • [129] L. Luu, J. Teutsch, R. Kulkarni, and P. Saxena. Demystifying Incentives in the Consensus Computer. In Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security, CCS ’15, pages 706–719, New York, NY, USA, 2015. ACM.
  • [130] L. Luu, Y. Velner, J. Teutsch, and P. Saxena. SMARTPOOL: Practical Decentralized Pooled Mining. In Proceedings of the 26th USENIX Conference on Security Symposium, SEC’17, pages 1409–1426, Berkeley, CA, USA, 2017. USENIX Association.
  • [131] P. McCorry, A. Hicks, and S. Meiklejohn. Smart contracts for bribing miners. In International Conference on Financial Cryptography and Data Security, pages 3–18. Springer, 2018.
  • [132] R. C. Merkle. A digital signature based on a conventional encryption function. In Conference on the theory and application of cryptographic techniques, pages 369–378. Springer, 1987.
  • [133] M. Mettler. Blockchain technology in healthcare: The revolution starts here. In 2016 IEEE 18th International Conference on e-Health Networking, Applications and Services (Healthcom), pages 1–3. IEEE, 2016.
  • [134] A. Miller. Feather-forks: enforcing a blacklist with sub-50% hash power, 2013. Available [online]. [Accessed: 3-9-2018].
  • [135] T. Moscibroda, S. Schmid, and R. Wattenhofer. The Price of Malice: A Game-Theoretic Framework for Malicious Behavior in Distributed Systems. Internet Mathematics, 6(2):125–155, 2009.
  • [136] R. B. Myerson. Game Theory. Harvard University Press, Cambridge, Massachusetts, 2007.
  • [137] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. Available [online]. [Accessed: 14-11-2018].
  • [138] J. Nash. Equilibrium points in n-person games. Proceedings of the National Academy of Sciences, pages 48–49, 1950.
  • [139] K. Nayak, S. Kumar, A. Miller, and E. Shi. Stubborn Mining: Generalizing Selfish Mining and Combining with an Eclipse Attack. In 2016 IEEE European Symposium on Security and Privacy (EuroS P), pages 305–320, March 2016.
  • [140] N. Nisan, T. Roughgarden, E. Tardos, and V. V. Vazirani. Algorithmic Game Theory. Cambridge University Press, New York, NY, USA, 2007.
  • [141] M. Nojoumian, A. Golchubian, and L. Njilla. Incentivizing Blockchain Miners to Avoid Dishonest Mining Strategies By a Reputation-Based Paradigm. In IEEE Science and Information Conference, pages 1118–1134, 2017.
  • [142] L. Noonan. JPMorgan widens blockchain payments to more than 75 banks. Financial Times, 2018. Available [online]. [Accessed: 25-2-2019].
  • [143] K. J. O’Dwyer and D. Malone. Bitcoin mining and its energy footprint. In 25th IET Irish Signals Systems Conference 2014 and 2014 China-Ireland International Conference on Information and Communications Technologies (ISSC 2014/CIICT 2014), pages 280–285, June 2014.
  • [144] D. Ongaro and J. Ousterhout. In search of an understandable consensus algorithm. In 2014 USENIX Annual Technical Conference, pages 305–319, 2014.
  • [145] C. H. Papadimitriou. Computational complexity. John Wiley and Sons Ltd., 2003.
  • [146] R. Pass, L. Seeman, and A. Shelat. Analysis of the blockchain protocol in asynchronous networks. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 643–673. Springer, 2017.
  • [147] R. Pass and E. Shi. FruitChains: A Fair Blockchain. In Proceedings of the ACM Symposium on Principles of Distributed Computing, PODC ’17, pages 315–324, New York, NY, USA, 2017. ACM.
  • [148] G. Piliouras, C. Nieto-Granda, H. I. Christensen, and J. S. Shamma. Persistent Patterns: Multi-agent Learning Beyond Equilibrium and Utility. In Proceedings of the 2014 International Conference on Autonomous Agents and Multi-agent Systems, AAMAS ’14, pages 181–188, Richland, SC, 2014. International Foundation for Autonomous Agents and Multiagent Systems.
  • [149] G. Piliouras, E. Nikolova, and J. S. Shamma. Risk Sensitivity of Price of Anarchy Under Uncertainty. ACM Trans. Econ. Comput., 5(1):5:1–5:27, Oct. 2016.
  • [150] G. Piliouras and J. S. Shamma. Optimization despite chaos: Convex relaxations to complex limit sets via Poincaré recurrence. In Proceedings of the twenty-fifth annual ACM-SIAM Symposium on Discrete Algorithms, pages 861–873. SIAM, 2014.
  • [151] Researchers link realism to blockchain’s promise, 2018. Available [online]. [Accessed: 10-4-2019].
  • [152] Quorum. [website]. [Accessed: 25-2-2019].
  • [153] L. Ren. Proof of Stake Velocity: Building the Social Currency of the Digital Age, 2014.
  • [154] S. Rhoades. The Herfindahl-Hirschman Index. Federal Reserve Bulletin, 79:188, 1993.
  • [155] R. L. Rivest, A. Shamir, and Y. Tauman. How to leak a secret. In International Conference on the Theory and Application of Cryptology and Information Security, pages 552–565. Springer, 2001.
  • [156] J. J. Roberts. Bitcoin Spinoff Hacked in Rare “51% Attack”. Fortune, 2018. Available [online]. [Accessed: 15-03-2019].
  • [157] M. Rosenfeld. Analysis of bitcoin pooled mining reward systems. arXiv preprint arXiv:1112.4980, 2011.
  • [158] T. Roughgarden. Intrinsic robustness of the price of anarchy. In Proceedings of the 41st Annual ACM Symposium on Theory of Computing, STOC 2009, Bethesda, MD, USA, May 31 - June 2, 2009, pages 513–522, 2009.
  • [159] F. A. Saleh. Blockchain Without Waste: Proof-of-Stake, 2017.
  • [160] A. Sapirshtein, Y. Sompolinsky, and A. Zohar. Optimal Selfish Mining Strategies in Bitcoin. In J. Grossklags and B. Preneel, editors, Financial Cryptography and Data Security, pages 515–532, Berlin, Heidelberg, 2017. Springer Berlin Heidelberg.
  • [161] A. Saxena. JPMorgan Chase to create digital coins using blockchain for payments. Reuters, 2019. Available [online]. [Accessed: 25-2-2019].
  • [162] T. C. Schelling. The Strategy of Conflict. Harvard University Press, Cambridge, Massachusetts, 2005.
  • [163] K. M. Schmidt and E. Fehr. A Theory of Fairness, Competition, and Cooperation*. The Quarterly Journal of Economics, 114(3):817–868, 08 1999.
  • [164] O. Schrijvers, J. Bonneau, D. Boneh, and T. Roughgarden. Incentive Compatibility of Bitcoin Mining Pool Reward Functions. In J. Grossklags and B. Preneel, editors, Financial Cryptography and Data Security, pages 477–498, Berlin, Heidelberg, 2017. Springer Berlin Heidelberg.
  • [165] S. Seang and D. Torre. Proof of Work and Proof of Stake Consensus Protocols: A Blockchain Application for Local Complementary Currencies, 2018.
  • [166] I. Sergey, A. Kumar, and A. Hobor. Scilla: a smart contract intermediate-level language. arXiv preprint arXiv:1801.00687, 2018.
  • [167] A. Shahaab, B. Lidgey, C. Hewage, and I. Khan. Applicability and appropriateness of distributed ledgers consensus protocols in public and private sectors: A systematic review. IEEE Access, 7:43622–43636, 2019.
  • [168] E. G. Sirer. Bitcoin guarantees strong, not eventual, consistency, 2016. Available [online]. [Accessed: 19-2-2019].
  • [169] H. L. Smith and H. R. Thieme. Dynamical systems and population persistence, volume 118. American Mathematical Soc., 2011.
  • [170] M. Smith. In Wake of Romaine E. coli Scare, Walmart Deploys Blockchain to Track Leafy Greens. CNN Business, 2018. Available [online]. [Accessed: 25-2-2019].
  • [171] Y. Sompolinsky and A. Zohar. Bitcoin’s Underlying Incentives. Commun. ACM, 61(3):46–53, 2018.
  • [172] M. Steffel, E. F. Williams, and J. Perrmann-Graham. Passing the buck: Delegating choices to others to avoid responsibility and blame. Organizational Behavior and Human Decision Processes, 135:32–44, 2016.
  • [173] N. Stifter, A. Judmayer, P. Schindler, A. Zamyatin, and E. R. Weippl. Agreement with Satoshi – On the Formalization of Nakamoto Consensus. IACR Cryptology ePrint Archive, 2018:400, 2018.
  • [174] P. Szalachowski. Towards more reliable Bitcoin timestamps. In Crypto Valley Conference on Blockchain Technology (CVCBT), 2018.
  • [175] P. Szalachowski, D. Reijsbergen, I. Homoliak, and S. Sun. StrongChain: Transparent and collaborative proof-of-work consensus. In 28th USENIX Security Symposium, 2019.
  • [176] Team Rocket. Snowflake to Avalanche: A novel metastable consensus protocol family for cryptocurrencies, 2018.
  • [177] R. Thurimella and Y. Aahlad. The Hitchhiker’s Guide to Blockchains: A Trust Based Taxonomy, 2018. Available [online]. [Accessed: 15-11-2018].
  • [178] U.S. Antitrust Division. Herfindahl-Hirschman index. Available [online]. [Accessed: 1-3-2019].
  • [179] V. V. Vazirani. Approximation algorithms. Springer Science & Business Media, 2013.
  • [180] J. von Neumann and O. Morgenstern. Theory of Games and Economic Behavior. Princeton University Press, 1944.
  • [181] M. Vukolić. The Quest for Scalable Blockchain Fabric: Proof-of-Work vs. BFT Replication. In J. Camenisch and D. Kesdoğan, editors, Open Problems in Network Security, pages 112–125. Springer International Publishing, 2016.
  • [182] J. R. Wallrabenstein and C. Clifton. Equilibrium Concepts for Rational Multiparty Computation. In S. K. Das, C. Nita-Rotaru, and M. Kantarcioglu, editors, Decision and Game Theory for Security, pages 226–245, Cham, 2013. Springer International Publishing.
  • [183] W. Wang, D. T. Hoang, P. Hu, Z. Xiong, D. Niyato, P. Wang, and Y. Wen. A Survey on Consensus Mechanisms and Mining Strategy Management in Blockchain Networks. IEEE Access, 2019.
  • [184] T. Wong. An application of game theory to corporate governance. Omega, 17(1):59–67, 1989.
  • [185] K. Wüst and A. Gervais. Do you need a blockchain? In 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), pages 45–54. IEEE, 2018.
  • [186] J. Yli-Huumo, D. Ko, C. S., P. S., and S. K. Where Is Current Research on Blockchain Technology?—A Systematic Review. PLoS ONE, 11(10):e0163477, 2016.
  • [187] V. Zamfir. personal communication.
  • [188] A. Zamyatin, N. Stifter, P. Schindler, E. R. Weippl, and W. J. Knottenbelt. Flux: Revisiting Near Blocks for Proof-of-Work Blockchains. IACR Cryptology ePrint Archive, 2018:415, 2018.
  • [189] R. Zhang and B. Preneel. Publish or Perish: A Backward-Compatible Defense Against Selfish Mining in Bitcoin. In CT-RSA, 2017.
  • [190] R. Zhang and B. Preneel. Lay Down the Common Metrics: Evaluating Proof-of-Work Consensus Protocols? Security. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2019.
  • [191] Z. Zheng, S. Xie, X. Chen, and H. Wang. Blockchain Challenges and Opportunities: A Survey. International Journal of Web and Grid Services (IJWGS), 14(4):352–375, 2018.
  • [192] Zilliqa. [website]. [Accessed: 26-2-2019].
  • [193] Zilliqa Team. The Zilliqa Technical Whitepaper, 2017. Available [online]. [Accessed: 26-2-2019].
  • [194] A. Zohar. Securing and Scaling Cryptocurrencies. In

    Proceedings of the Twenty-Sixth International Joint Conference on Artificial Intelligence, IJCAI-17

    , pages 5161–5165, 2017.