1432 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO.

2, SECOND QUARTER 2020

A Survey of Distributed Consensus Protocols

for Blockchain Networks
Yang Xiao , Student Member, IEEE, Ning Zhang , Member, IEEE, Wenjing Lou , Fellow, IEEE,
and Y. Thomas Hou , Fellow, IEEE

Abstract—Since the inception of Bitcoin, cryptocurrencies and system and a secure-by-design technology. The blockchain
the underlying blockchain technology have attracted an increas- itself is a database that keeps track of all transactions occurred
ing interest from both academia and industry. Among various in the network and is replicated at every participating node.
core components, consensus protocol is the defining technol-
ogy behind the security and performance of blockchain. From It essentially realizes a distributed ledger without relying on
incremental modifications of Nakamoto consensus protocol to a central authority to bootstrap the trust among participants
innovative alternative consensus mechanisms, many consensus or to clear the transactions. It also does not assume trust
protocols have been proposed to improve the performance of among the participating nodes. Blockchain is meant to enable
the blockchain network itself or to accommodate other specific trusted computation among a group of mutually distrustful par-
application needs. In this survey, we present a comprehensive
review and analysis on the state-of-the-art blockchain consensus ticipants. On the other hand, blockchain is also known for
protocols. To facilitate the discussion of our analysis, we first providing trustworthy immutable record keeping service. The
introduce the key definitions and relevant results in the clas- block data structure adopted in a blockchain embeds the hash
sic theory of fault tolerance which help to lay the foundation of the previous block in the next block generated. The use of
for further discussion. We identify five core components of a hash chain ensures that data written on one block can not be
blockchain consensus protocol, namely, block proposal, block val-
idation, information propagation, block finalization, and incentive modified without invalidating later blocks. In addition, a pub-
mechanism. A wide spectrum of blockchain consensus proto- lic blockchain system supports third-party auditing and some
cols are then carefully reviewed accompanied by algorithmic blockchain systems support a high level of anonymity, that is,
abstractions and vulnerability analyses. The surveyed consensus a user can transact online using a pseudonym without revealing
protocols are analyzed using the five-component framework and his/her true identity.
compared with respect to different performance metrics. These
analyses and comparisons provide us new insights in the funda- The security properties promised by blockchain is unprece-
mental differences of various proposals in terms of their suitable dented and truly inspiring. Pioneering blockchain systems such
application scenarios, key assumptions, expected fault tolerance, as Bitcoin have greatly impacted the digital payment world. It
scalability, drawbacks and trade-offs. We believe this survey will is envisioned that blockchain technology and applications built
provide blockchain developers and researchers a comprehensive on top of it will revolutionize a broad array of financial service
view on the state-of-the-art consensus protocols and facilitate the
process of designing future protocols. industries as well as non-financial sectors. Among the many
technical components that a blockchain system is composed
Index Terms—Blockchain, distributed consensus, fault toler- of, the distributed consensus protocol is the key technology
ance, protocol design.
that enables blockchain’s decentralization, or more specifi-
cally, that ensures all participants agree on a unified transaction
ledger without the help of a central authority. The distributed
I. I NTRODUCTION
consensus protocol specifies message passing and local deci-
INCE Bitcoin’s inception in late 2008, cryptocurrencies
S and the underlying blockchain technology have piqued
great interest from the financial industry and society as a
sion making at each node. Various design choices in the
consensus protocol can greatly impact a blockchain system’s
performance, including its transaction capacity, scalablity, and
whole. Blockchain is widely cited as a fully decentralized fault tolerance.
The Nakamoto consensus protocol [1] is the protocol imple-
Manuscript received April 7, 2019; revised October 14, 2019 and November
29, 2019; accepted January 13, 2020. Date of publication January 28, 2020; mented in the Bitcoin network. With the help of this consensus
date of current version May 28, 2020. This work was supported in part protocol, Bitcoin became the first digital currency system to
by U.S. National Science Foundation under Grant CNS-1916902 and Grant resist double-spending attacks in a decentralized peer-to-peer
CNS-1916926. (Corresponding author: Wenjing Lou.)
Yang Xiao and Y. Thomas Hou are with the Bradley Department of network of little trust. As the Bitcoin network continues to grow,
Electrical and Computer Engineering, Virginia Polytechnic Institute and State Nakamoto consensus has encountered several performance bot-
University, Blacksburg, VA 24061 USA (e-mail: [email protected]; [email protected]). tlenecks and sustainability problems. Researchers in blockchain
Ning Zhang is with the Department of Computer Science and Engineering,
Washington University in St. Louis, St. Louis, MO 63130 USA (e-mail: communities have raised the following concerns on Nakamoto
[email protected]). consensus and particularly its proof-of-work (PoW) mining
Wenjing Lou is with the Department of Computer Science, Virginia mechanism: 1) unsustainable energy consumption, 2) low trans-
Polytechnic Institute and State University, Blacksburg, VA 24061 USA
(e-mail: [email protected]). action capacity and poor scalability, 3) long-term security
Digital Object Identifier 10.1109/COMST.2020.2969706 concerns as mining rewards diminish. For instance, the Bitcoin
1553-877X 
c 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See https://www.ieee.org/publications/rights/index.html for more information.
Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1433

network currently consists of roughly ten thousand nodes [2], 3) identifying four classes of proof of stake (PoS) based
while the maximum transaction capacity of Bitcoin is 7 trans- consensus protocols and providing algorithmic abstrac-
actions per second (TPS) and can be increased to at most 25 tions for them;
TPS by tuning protocol parameters without jeopardizing con- 4) comparing all mentioned consensus protocols with
sensus safety [3]. In contrast, the VISA network consists of respect to the five-component framework, fault toler-
50 million participants and can handle up to 65,000 TPS [4]. ance, and transaction processing capability.
A single Bitcoin transaction (November 2019) consumes the 5) providing a succinct tutorial on blockchain consen-
equivalent amount of electricity that would power 21 average sus protocol design with respect to the security-
U.S. households for one day [5]. decentralization-scalability trilemma.
In response to the above performance limitations of PoW The remaining part of this survey is organized as fol-
mining, blockchain researchers have been investigating new lows. Section II reviews related surveys and tutorials on
block proposing mechanisms such as proof of stake (PoS), blockchain consensus protocols. Section III provides a back-
proof of authority (PoA), and proof of elapsed time (PoET) ground of classical fault tolerant consensus in distributed
which do not require computation-intensive mining, thus systems. Several legacy BFT consensus protocols designed
effectively reducing energy consumption. In some cases, cryp- for both partially synchronous and asynchronous networks
tographic methods can be used to establish trust among nodes, are introduced. Section IV presents the basic framework of
enabling the use of more coordinated block proposing schemes blockchain and the consensus goals, and introduces the five
such as round-robin and committee-based block generation. essential components of a blockchain consensus protocol.
Appropriate incentives that will continue to encourage hon- Section V focuses on the well-known Nakamoto consensus
est participation in the blockchain network is another key protocol, the defining technology of Bitcoin, and its vulnerabil-
component of consensus protocol. Therefore, alternative block ities and improvement ideas. Section VI provides a systematic
proposing schemes are often accompanied by a new incentive view of the PoS protocols, the most promising competitors
mechanism that promotes participation fairness and increases to the PoW-based Nakamoto consensus for public blockchain.
overall system sustainability. Popular blockchain consensus Section VII discusses alternative consensus protocols usable
protocols encompassing these ideas include Peercoin [6], under specific application scenarios. Section VIII compares all
Bitcoin-NG [7], Ourosboros (Cardano) [8], Snow White [9], blockchain consensus protocols studied and summarizes their
and EOSIO [10], POA Network [11], etc. design philosophy. Section IX discusses the paradigm shift
Besides block proposing and incentive mechanisms, in consensus protocol design and provides a succinct tutorial.
researchers have been seeking solutions from the prior Section X concludes the paper.
wisdom—primarily classical Byzantine fault tolerant (BFT)
consensus and secure multi-party computation (MPC)—for effi-
cient block finalization methods. For example, the state machine II. P REVIOUS S URVEYS AND T UTORIALS
replication (SMR) based BFT consensus algorithms have great The comparison study by Vukolić [18] treats two gen-
potential in permissioned blockchain networks operated with res of blockchain consensus protocols, namely PoW-based
static and revealed identities, of which TenderMint [12], and BFT-based, with respect to transaction throughput, scal-
Algorand [13], Casper FFG [14], and Hyperledger Fabric [15] ability limits, consensus finality, and security implications.
are well-known use cases. Moreover, asynchronous consen- PoW-based protocols scale well with network size and are
sus protocols such as HoneyBadgerBFT [16] and BEAT [17] suited for permissionless blockchains, but yield very lim-
were proposed to provide robust block finalization under severe ited throughput and long confirmation latency. This is due
network conditions with uncertain message delays. to the security implication of their lack of consensus final-
Our Contribution: With more blockchain consensus mecha- ity and limited capacity of raising block frequency and block
nisms being proposed, there is a pressing need to analyze and size. In comparison, BFT protocols have built-in consensus
compare them in a formal and cohesive manner. In this survey finality and achieve much higher transaction capacity, but
we present a comprehensive review and analysis of the state- incur high messaging complexity per block (O(N 2 ) versus
of-the-art blockchain consensus protocols and their devel- PoW’s O(N), N is network size) and need a permissioned
opment history, with a special focus on their performance, network for identity management. As a result they do not
fault tolerance, and security implications. Our information scale well with network size. Besides remarking their differ-
sources include academic papers, consensus protocol white ences, this paper also explores how the hybrid use of BFT and
papers, official documentation and statistics websites of cryp- PoW can enhance the performance of established blockchain
tocurrencies. Specifically, our survey features the following systems and provides tentative solutions to improve blockchain
contributions: scalability.
1) providing a background of classical distributed con- Cachin and Vukolić [19] gives an overview of thirteen
sensus research, including partially synchronous and prominent consensus protocols designed for permissioned
asynchronous BFT protocols that are applicable to blockchain platforms along with their fault tolerance and
blockchain consensus; security properties. The authors also make a powerful state-
2) reviewing a broad array of blockchain consensus pro- ment that the design of blockchain consensus protocols
tocols with a proposed five-component framework and should follow the rigor established in prevailing wisdom of
analyzing their design philosophy and security issues; cryptography, security, and distributed systems, rather than in

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1434 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

an ad hoc manner. This is particularly true when the consen- mechanisms, and a detailed guide on when and how to
sus protocol regulates significant financial values and societal use which blockchain technology. The consensus mecha-
trust. However, they do not provide a methodology to combine nisms covered include PoW, PoS, BFT algorithms, and hybrid
the prevailing wisdom in order to design a consensus protocol BFT-based algorithms. Notably, this paper also gives a quan-
for specific needs. titative comparison of consensus mechanisms with respect to
The work by Bano et al. [20] is the first well-structured fault tolerance, node scalability, throughput, and transaction
survey of blockchain consensus protocols. It identifies three latency. Though with great details on building and managing
classes of consensus protocols based on committee formation a blockchain system, this vademecum can be perfected with
and block proposing rules: 1) PoW, 2) proof of X (PoX) alter- an abstraction for each type of consensus mechanisms and
natives to PoW, and 3) hybrid consensus protocols that take a high-level tutorial on how to reach a compromise between
advantage of classical distributed consensus techniques. This different desired features.
paper emphasizes the role of committee in hybrid consensus
protocols. General discussions on the formation and configu- III. FAULT-T OLERANT D ISTRIBUTED C ONSENSUS
ration of committee and possible solutions to multi-committee
The fault-tolerant (FT) distributed consensus problem has
(i.e., sharding-based) consensus are provided. This paper also
been extensively studied in distributed systems since the late
presents an evaluation framework that takes into account the
1970s and recently gained popularity in the blockchain com-
protocol safety (censorship resistance, DoS resistance and
munity, especially for permissioned blockchains where every
fault tolerance) and performance (throughput and latency).
consensus participant reveals its identity. Generally, consensus
Notably, this paper is the closest work to our survey in terms
in a distributed system represents a state that all participants
of classification of block proposing mechanisms. However,
agree on the same data values. Depending on the medium for
other protocol components need finer classification and the
message exchange, distributed systems are classified into two
variety of PoS proposals deserves a more comprehensive
types: message passing and shared memory [24]. In this sec-
treatment.
tion we are interested in message passing systems because
Wang et al. [21] provides a comprehensive survey of
of their resemblance to contemporary blockchain systems,
blockchain consensus protocols and an in-depth review of
wherein distributed consensus on a single network history is
incentive mechanism designs. The paper starts with a layered
reached through peer-to-peer communication. We will use the
view of the blockchain network including the consensus part
terms process/node/server interchangeably, as they all refer to
followed by a general discussion on the compatibility between
an individual participant of distributed consensus.
consensus protocol and incentive mechanism. Then detailed
consensus schemes are introduced, including Nakamoto con-
sensus, proof-of-concept consensus schemes, and virtual min- A. System Model
ing techniques such as proof of stake (PoS) along with the 1) Distributed System and Task: We consider a distributed
usability of trusted hardware. Hybridization between PoX and system that consists of N independent processes. Each process
classical BFT protocols is also discussed. This survey features pi begins with an individual initial value xi and communi-
a game-theoretical characterization of Nakamoto consensus’ cates with others to update this value. Each local value can
incentive mechanism and its influence on system fairness be used for a certain task, such as computation or just stor-
and decentralization. The efficiency-scalability trade-off is age. If the processes are required to perform the same task,
also explored. Despite of having rich details on consensus consensus on a single value is required before they proceed
techniques and insights into blockchain protocol design, this to the task.
survey does not provide a concise abstraction that captures 2) Process Failure: A process suffers a crash failure if it
different functional components of a consensus protocol or a abruptly stops working without resuming. The common causes
cohesive characterization on fault-tolerant distributed consen- of a crash failure include power shutdown, software error, and
sus primitives that can be used for blockchain consensus. DoS attack. A Byzantine failure, however, is much severer
Xiao et al. [22] provides a succinct tutorial on distributed in that the process can act arbitrarily while appearing nor-
consensus protocols, from classical BFT protocols to the mal. It can send contradicting messages to other processes in
Nakamoto consensus protocol as well as recent breakthroughs hope of sabotaging the consensus. “Byzantine” was coined by
in blockchain consensus. Specially this tutorial provides an Lamport et al. [25] in 1982 when describing the Byzantine
abstraction of consensus goals for permissionless blockchains Generals Problem, an allegorical case for single-value con-
following the paradigm of classical BFT consensus. The sensus among distributed processes. The common cause of
authors also remark that the network model and trust model a Byzantine failure is adversarial influence, such as mal-
should be jointly considered when designing blockchain con- ware injection and physical device capture. Multiple Byzantine
sensus protocols for practical applications. However, this processes may collude to deal more damage.
tutorial skips details on each consensus protocols and does not 3) Network Synchrony: Network synchrony defines the
clarify how different components of a blockchain consensus level of coordination among all processes. Three levels of
protocol contribute to system performance and security. synchrony, namely synchronous, partially synchronous, and
Belotti et al. [23] provides a vademecum on blockchain asynchronous, are often assumed in the literature [22], [26].
technology including development history, transaction and • In a synchronous network, operations of processes are
ledger structure, blockchain system abstraction, consensus coordinated in rounds with clear time constraints. In each

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1435

round, all processes perform the same type of operations.

This can be achieved by a centralized clock synchroniza-
tion service and good network connectivity. Practically, a
network is considered synchronous if message delivery is
guaranteed within a fixed delay Δ, for which the network
is also called Δ-synchronous.
• In a partially synchronous network, operations of
processes are loosely coordinated in a way that mes-
sage delivery is guaranteed but with uncertain amount
of delays. Within the scope of partial synchrony, weak Fig. 1. A high-level illustration of SMR-based distributed computing that
serves four operation requests from two clients.
synchrony requires message delay not grow faster than
the elapsing time indefinitely [27], while eventual syn-
chrony ensures Δ-synchrony only after some unknown
ones. Interested readers are referred to [26], [30] for detailed
instant [28]. In either case, operations of the networked
proofs.
processes can still follow that of a synchronous network
if the time horizon is long enough.
• In an asynchronous network, operations of processes are C. Consensus in Distributed Computing
hardly coordinated. There is no delay guarantee on a Consensus in distributed computing is a more sophisti-
message except for its eventual delivery. And the coor- cated realization of the aforementioned distributed system. In
dination of processes (if there is any) is solely driven a typical distributed computing system, one or more clients
by the message delivery events. This is often caused by issue operation requests to the server consortium, which pro-
the absence of clock synchronization (thus no notion of vides timely and correct computing service in response to
shared time) or the dominance of a mighty adversary over the requests despite some of servers may fail. Here the cor-
all communication channels. rectness requirement is two-fold: correct execution results
It has been shown by Fischer et al. [29] that under the for all requests and correct ordering of them. According to
asynchronous case, consensus cannot be guaranteed with even Alpern and Schneider’s work on liveness definition [31] in
a single crash failure. This is commonly known as the FLP 1985, the correctness of consensus can be formulated into
impossibility, for the authors’ namesake. However, this impos- two requirements: safety—every server correctly executes the
sibility can be practically circumvented using randomized same sequence of requests, and liveness—all requests should
decision making and a relaxed termination property, as we be served.
will show in Section III-E. To fulfill these requirements even in the presence of faulty
servers, server replication schemes especially state machine
replication (SMR) are often heralded as the de facto solu-
B. Byzantine Fault Tolerant Consensus tion. SMR, originated from Lamport’s early works on clock
We call a consensus protocol crash fault tolerant (CFT) synchronization in distributed systems [32], [33], was for-
or Byzantine fault tolerant (BFT) if it can tolerate a certain mally presented by Schneider [34] in 1990. Setting in the
amount of crash or Byzantine process failures while keep- client-server framework, SMR sets the following requirements:
ing normal functioning. Because of the inclusive relationship 1) All servers start with the same initial state;
between a crash failure and Byzantine failure, a BFT consen- 2) Total-order broadcast: All servers receive the same
sus protocol is naturally CFT. BFT consensus is defined by sequence of requests as how they were generated from
the following four requirements [22], [26], [28]: clients;
• Termination: Every non-faulty process decides an output. 3) All servers receiving the same request shall output the
• Agreement: Every non-faulty process eventually decides same execution result and end up in the same state.
the same output ŷ. Total-order broadcast is also known as atomic broadcast
• Validity: If every process begins with the same input x̂ , (ABC) [35], which is in contrast to the reliable broadcast
then ŷ = x̂ . (RBC) [36] primitive. The latter only requires all servers
• Integrity: Every non-faulty process’ decision and the receive the same requests without enforcing the order. It is
consensus value ŷ must have been proposed by some shown in [37], [38] that atomic broadcast and distributed
non-faulty process. consensus are equivalent problems.
The four requirements provide a general target for distributed A high-level diagram of SMR-based distributed computing
consensus protocols. For any consensus protocol to attain is illustrated in Fig. 1. The N-server consortium accepts oper-
these BFT requirements, the underlying distributed network ation requests from clients. Servers confirm each other’s state
should satisfy the following condition: N ≥ 3f + 1 where before reaching consensus and executing requests. In many
f is the number of Byzantine processes. This fundamental cases, especially randomized consensus protocols, there can be
result was first proved by Pease et al. [30] in 1980 and an alternating procedure of total-order broadcast and local state
later adapted to the BFT consensus framework. The proof update until a certain consensus target is met, before moving
involves induction from N = 3 and partitioning all processes on to execution. In practice, SMR is often implemented in
into three equal-sized groups, with one containing the faulty a leader-based fashion. A primary server (say S1 in Fig. 1)

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1436 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

receives client requests and starts the broadcast procedure so Algorithm 1: PBFT (Normal-Operation Protocol)
that the other N − 1 replica servers receive the same requests /* Request */
and update their local states to that of the primary. 1 Client sends an operation request to the primary;
In the rest of this section we summarize several well-known /* Phase 1: Pre-prepare */
consensus protocols (some are based on SMR) designed under 2 The primary relays this request to replicas via
different network synchrony assumptions. Pre-prepare messages;
3 Replicas record the request and update local states;
D. Consensus Protocols for Partially Synchronous Network /* Phase 2: Prepare */
4 Replicas send Prepare messages to all servers (replicas
The ground-breaking work by Dwork et al. [28] in 1988 laid
and the primary);
the theoretical foundation of partially synchronous consensus.
5 Once receiving ≥ 2f + 1 Prepare messages, every server
By dissecting the consensus objective into termination and
updates local state and is ready to commit;
safey, the authors were able to formally prove the feasibility
/* Phase 3: Commit */
of four consensus goals, including CFT, omission-tolerance,
6 Servers send Commit messages to each other;
BFT, unauthenticated BFT, under the Δ-synchrony/eventual
7 Once receiving ≥ 2f + 1 Commit messages, every server
synchrony condition. Notably, this work has inspired numer-
starts to execute the client request and then updates
ous proposals for partially synchronous consensus schemes,
local state;
including the later known PBFT.
/* Reply */
1) DLS Protocol: The same paper [28] also proposes a
8 Every server replies its result to the client.
prototype consensus protocol (called DLS for authors’ name-
sake) featuring a broadcast primitive for each consensus cycle.
Specifically, the broadcast primitive is started by an arbitrary
process p and consists of two initial rounds and subsequent similarities to VR. Paxos classifies nodes into three roles: pro-
iterative rounds. Through the message exchange in each round, posers, acceptors, and learners. A proposer suggests a value in
the iterative procedure eventually drives the processes to reach the beginning and the system goal is to make acceptors agree
agreement on a common value (either the one proposed by on a single value, and learners learn this value from acceptors.
p or a default value). At message complexity O(N 2 ) (N is In the client-server scenario depicted in Fig. 2(b), the client is
the number of processes), the broadcast primitive essentially the learner, the primary is the proposer, and the replicas are
enables the DLS protocol to tolerate f Byzantine processes if acceptors. After updating to the same state, all servers exe-
N ≥ 3f + 1. The cryptocurrency Tendermint uses an adapted cute the request and send it to the client who then chooses the
version of DLS for block finalization. majority result. When the proposer suffers a crash failure, the
2) Viewstamped Replication (VR): Proposed by Oki and acceptors elects a new leader through a similar propose-accept
Liskov [39] in 1988, viewstamped replication is a server procedure. Akin to VR, Paxos can tolerate f crashed accep-
replication scheme for handling server crashes. It was tors when N ≥ 2f + 1, but no Byzantine failures. Because of
later extended into a consensus protocol by Liskov and the mutual messaging during the accept phase, the message
Cowling [40] in 2012, which we will refer to as VR. VR complexity of Paxos is O(N 2 ).
is a SMR scheme designed in the client-server framework Embarking from its original design, Paxos has grown
and consists of three sub-protocols: 1) Normal-operation, into a family of consensus protocols, including multi-Paxos,
2) View-change, 3) Recovery. The primary server receives a cheap-Paxos, and fast-Paxos, each features a specific goal.
client request and starts the normal operation, as is shown Raft, a SMR consensus protocol developed by Ongaro and
in Fig. 2(a). In the case of a crash failure of the primary, Ousterhout [43] in 2014 and popular in the blockchain com-
the View-change protocol is triggered at every replica per munity, is based off Paxos but with a more understandable
the timeout of the Prepare message. They broadcast View- design.
change messages to each other and count the receptions. After 4) Practical Byzantine Fault Tolerance (PBFT): Developed
receiving View-change messages from more than half of the by Castro and Liskov [27] in 1999, PBFT is the first SMR-
replicas, the next-in-line replica becomes the new primary based BFT consensus protocol that has gained wide recog-
and informs the others to resume the normal operation. The nition for practicality. It has become almost synonymous to
Recovery protocol is used by any server to recover from a BFT consensus in the blockchain community. PBFT originated
crash. VR can tolerate f crashed replicas if the network popu- from the VR framework and took inspiration from Paxos.
lation N ≥ 2f + 1. However it does not tolerate any Byzantine PBFT consists of three sub-protocols: 1) Normal-operation,
failure, because the replicas simply follow the instructions 2) Checkpoint, 3) View-change.
from the primary without mutual state confirmation nor com- The Normal-operation protocol is shown in Algorithm 1
munication with the client. On the up side, this makes VR and Fig. 2(c). Ideally, all results replied to the client should
efficient, with O(N) message complexity. be the same; otherwise the client chooses the majority result.
3) Paxos: Paxos is a SMR scheme proposed by The Checkpoint protocol serves as a logging tool that keeps
Lamport [41] in 1989 that imitates the ancient Paxos part-time a sliding window (of which the lower bound is the stable
parliament and later elaborated in 2001 [42]. It was designed checkpoint) to track active operation requests. The latest sta-
specifically for fault tolerant consensus while bearing many ble checkpoint is used for safely discarding older requests in

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1437

Fig. 2. Messaging diagram during the normal operation of three SMR protocols. C is the client. S0 is the primary server (leader) who receives requests from
the client and starts the consensus. S1+ are replica servers. Every server updates local state after receiving a message. Circled gear icon represents request
execution. VR and Paxos can tolerate one crash failure when N = 3. PBFT can tolerate one Byzantine failure when N = 4.

the operation log and facilitating the view change protocol. In First of all, according to [52] the termination property
the case of a primary failure, the View-change protocol is trig- presented in Section III can be subdivided into two classes:
gered at every replica that detects the timeout of the primary’s • Deterministic termination: Every non-faulty process
message. They oust the incumbent primary and broadcast decides an output by round r, a predetermined parameter.
view-change messages to each other and count receptions. • Probabilistic termination: The probability that a non-
After receiving View-change messages from 2f peers, the next- faulty process is undecided after r rounds approaches zero
in-line replica becomes the new primary and informs the rest as r grows to infinity.
to resume the normal operation. For synchronous or partially synchronous networks where
The message complexity of PBFT normal operation is message delay and round period are bounded, protocols like
O(N 2 ) because of the mutual messaging in Prepare and PBFT can exploit a timeout mechanism to detect anomaly
Commit phase. As for the fault tolerance, since a server needs of the primary, which makes deterministic termination an
to receive more than 2f + 1 Prepare (Commit) messages in achievable goal. For asynchronous networks where messages
Prepare (Commit) phase before proceeding to the next action, delivery has no timing guarantee, the consensus process can
there will be at least 2f + 1 (as N ≥ 3f + 1) honest servers only be driven by the message delivery events themselves. This
in the same state after Commit phase and producing the same limitation demands probabilistic termination. To realize prob-
result; the f Byzantine servers are not able to sway the majority abilistic termination, randomization (simultaneously proposed
consensus. Therefore PBFT can tolerate f Byzantine repli- by Ben-Or [53] and Rabin [54] in 1983) can be instantiated in
cas when the server population N ≥ 3f + 1, which is in the consensus protocol. The basic idea is that a process makes
accordance to the fundamental 1/3 BFT threshold. Interested a random choice when there are not enough trusted messages
readers are referred to [22], [27] for detailed proofs. received for making a final decision.
PBFT has inspired numerous BFT consensus protocols Next we introduce four primitives/protocols that aim to
with enhanced security and performance. Well-known pro- solve asynchronous BFT consensus. Though in different con-
posals include Quorum/Update (QU) [44], Hybrid Quorum texts, they all feature probabilistic termination and make use
(HQ) [45], Zyzzyva (using speculative execution) [46], of randomization.
FaB [47], Spinning [48], Robust BFT SMR [49], and 1) Bracha’s RBC and Asynchronous Consensus Protocol:
Aliph [50]. Interested readers are referred to Bessoni’s tuto- Bracha [55] proposed the pioneering reliable broadcast (RBC)
rial [51] for an overview of these protocols. primitive and an asynchronous consensus protocol in 1984
to solve the Byzantine Generals Problem [25], in which
E. Consensus Protocols for Asynchronous Network all non-faulty processes should eventually make the same
For distributed systems that are predominantly built upon binary decision. Bracha’s RBC guarantees that non-faulty
wired communication and reliable transport-layer protocols, processes will never accept contradicting messages from any
partial synchrony is a practical assumption. However in scenar- process and forces the faulty ones to output either nothing
ios such as mobile ad hoc network (MANET) and delay toler- (mimicking the crash failure) or the correct value. Bracha’s
ant networks (DTN), the network is considered of near-to-none asynchronous consensus protocol, adapted from Ben-Or’s
synchrony. As is proved by the FLP impossibility [29], con- 1983 work [53], runs by phases and each phase contains
sensus can not be guaranteed in a fully asynchronous network three RBC rounds for inter-process value exchange. We show
with even one crash failure. Moreover, unreliable communica- the round-3 of each phase, which contains the randomiza-
tion links have an equivalent effect of a Byzantine scheduler. tion step. After receiving at least N − f value messages
Nonetheless, this impossibility result can be practically cir- (f is the presumed Byzantine population), a process Pi
cumvented by two primitives: probabilistic termination and does:
randomization. 1) If receiving a value v from more than 2f peers, decide v;

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1438 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

Algorithm 2: Ben-Or’s ACS Protocol (at Player Pi ) analysis, Bracha’s RBC (in the benign case) and Canetti’s
/* Phase 1: Reliable Broadcast ABA have message complexity of O(N 2 ) and O(N 3 ) [57]
*/
1 Start RBCi to propose my input xi to the network; respectively, and all ABA instances end in constant rounds.
2 Participate in other RBC instances; As a result, Ben-Or’s ACS protocol has a bit-denominated
/* Phase 2: Asynchronous BA communication complexity of O(mN 2 + N 3 ) at each player,
*/
3 while round ≤ MaxRound do where m is the maximum bit-size of any input.
4 if receiving xj from RBCj then As we will see next, ACS can be conveniently adapted
5 Join ABAj with input 1; to asynchronous BFT consensus for blockchain systems, by
6 end substituting inputs with transaction sets.
7 if completion of N − f ABA instances then
8 Join other BA instances with input 0; 3) HoneyBadgerBFT: Proposed by Miller et al. [16] in
9 end 2016, HoneyBadgerBFT is the first asynchronous BFT con-
10 if completion of all N ABA instances then sensus protocol specifically designed for blockchain. It essen-
11 ComSubset = {xk |ABAk outputs 1}; tially realizes atomic broadcast: N players with different sets
12 return ComSubset; of transactions work to agree on a common set of sorted
13 end transactions that will be included in a block.
14 end Though using the multi-value Byzantine agreement prim-
itive (MVBA) from Cachin et al. [58] as the bench-
mark, HoneyBadgerBFT actually follows Ben-Or’s ACS
construction [56] for better communication efficiency.
2) Else if receiving a value v from more than f peers, hold HoneyBadgerBFT’s ACS cherry-picks the design of its sub-
v as proposal value and go to the next phase; components: Cachin and Tessaro’s erasure-coded RBC [59]
3) Else, toss a coin (1/2 chance for 0 or 1) for the proposal and Mostéfaouil et al.’s common-coin based ABA [60]. They
value and go to the next phase. together incur O(mN +N 2 log N ) communication complexity
When enough phases pass, the executions of step 2 and step 3 at each player. To prevent an adversary from censoring partic-
of RBC round-3 at all non-faulty processes will gradually fil- ular transactions, threshold public key encryption (TPKE) [61]
ter out the influence of contradicting messages and eventually is used before ACS so that consensus is performed on
make the correct decision via step 1. Note this convergence ciphertexts. In the decryption phase when a player receives
only happens if N ≥ 3f + 1, which is the fundamental bound enough shares from peers (generated by TPKE.DecShare)
of BFT consensus. that exceed a threshold, it proceeds to the actual decryption
In terms of performance, the message complexity of RBC task (TPKE.Dec) and sorts the transactions. The communica-
is O(N 2 ) in each round and the expected number of rounds tion complexity of the decryption process is O(N 2 ). Fig. 3
to reach consensus is O(2N ) if f = O(N), which √ gives a total illustrates the workflow of these components for one block
message complexity of O(N 2 2N ). If f = O( N ) (the benign cycle.
case), it is shown in [53], [55] that the expected number of HoneyBadgerBFT processes transactions in batches. Let B
rounds to reach consensus for the randomized protocol is a be the predefined batch size, denoting the maximum number of
constant, yielding a total message complexity of O(N 2 ). transactions that a block may enclose. For every block cycle,
2) Ben-Or’s ACS Protocol for MPC: Agreement on a com- each player proposes a set of B/N transactions, which are ran-
mon subset (ACS) was used by Ben-Or et al. [56] in 1994 as a domly chosen from recorded transactions. This is to ensure
consensus primitive for secure and efficient multi-party com- transaction sets proposed by different players are mostly dis-
putation (MPC) under asynchronous setting. In a network of N joint so as to maximize blockchain throughput. Assuming the
|t|B
players, each player holds a private input xi that was acquired average bit-size of a transaction set m:= N  N where |t|
secretly. The goal of MPC is to let the players collectively is the average transaction bit-size. Then the protocol’s com-
compute a function F (x1 , . . . , xN ) and obtain the same result. munication overhead will be dominated by the RBC, yielding
Assuming f players can be faulty, the ACS primitive requires overall communication complexity of O(|t|B) at one player, or
the players to agree on a common subset ComSubset of at least O(|t|N) for one transaction.
N − f honest inputs, which are then used for computing F (·). Compared to popular partially synchronous consensus pro-
Ben-Or’s ACS protocol builds on two primitives: RBC tocols such as PBFT, HoneyBadgerBFT has a higher cryp-
and binary asynchronous Byzantine agreement (ABA) which tography overhead but features two advantages. First, as
allows players to agree on the value of a single bit. Bracha’s an asynchronous protocol HoneyBadgerBFT does not rely
RBC [55] and Canetti and Rabin Fast ABA [57] are suggested on a timeout mechanism for detecting malfunctioning play-
respectively in [56] and used as black-boxes. Algorithm 2 ers. This makes HoneyBadgerBFT less sensitive to unpre-
shows the ACS protocol at each player. In the end, there will dictable network delays that might stall consensus. Second,
be at least N − f completed ABA instances with output 1, HoneyBadgerBFT does not need a leader rotation scheme.
yielding a F -computable ComSubset. In PBFT every round of consensus is started by a leader
Because both Bracha’s RBC and Canetti’s ABA can tolerate (the primary), while in HoneyBadgerBFT every node starts its
f Byzantine players when N ≥ 3f + 1, the same fault tolerance own broadcast and Byzantine agreement instance for proposed
result is inherited by Ben-Or’s ACS protocol. For complexity transactions; the concurrent execution of these instances
Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1439

such as PBFT execution is integrated into the consensus pro-

cess. An early work by Yin et al. [63] presents an alternative
BFT-SMR framework that separates consensus (i.e., agreement
on execution order) from execution, as the latter conveniently
requires only an honest majority of execution nodes instead of
an honest two-thirds of consensus nodes required by the for-
mer. This separation scheme is adopted by Zyzzyva [46] and
TenderMint [12] wherein a small group of nodes are dedicated
to the consensus task. Hyperledger Fabric [15] further sepa-
Fig. 3. HoneyBadgerBFT workflow. TXSi is the set of transactions proposed rates the consensus task into ordering service and validation
by player Pi . CS is the common subset output of ACS, comprising of at
least N − f encrypted transactions. The decryption process outputs sorted service for better modularity.
transactions that will be finalized in the block. From the performance perspective, BFT protocols are noto-
rious for their limited scalability in network size. Epitomized
by PBFT, the message complexity of partially synchronous
effectively saves the need of a leader. As a result, the band- BFT protocols grows quadratically with the network size N.
width of any individual leader will not become a bottleneck This means that given a fixed network bandwidth at each node,
of the entire network’s transaction capacity. Currently the a growing network size leads to exploding communication
blockchain initiative POA Network [11] is considering to adopt overhead and diminishing transaction capacity. According to
HoneyBadgerBFT. the performance evaluation in [16], PBFT achieves a max-
On the other hand, due to HoneyBadgerBFT’s asynchronous imum throughput of 16,000 TPS when N = 8; this figure
design philosophy that consensus progress is driven by mes- drops to around 3,000 when N = 64. On the other hand, for
sage deliveries, transaction confirmation latency is externally asynchronous protocols like HoneyBadgerBFT where erasure
influenced and uncontrollable. This leads HoneyBadgerBFT coding and threshold encryption are used to reduce commu-
to overly emphasize high transaction throughput and decen- nication complexity and enhance security, the extensive use
tralization. In various applications such as industrial control of cryptography also brings non-negligible computation over-
and supply chain management, low transaction latency is often head, adding to local processing delays. On the bright side, a
times a more important metric than throughput. typical BFT protocol achieves deterministic finality, which is
In response to the said inflexibility of HoneyBadgerBFT, also known as forward security [64] in that a settled transac-
Duan et al. [17] proposed BEAT in 2018, which is a tion will never be altered. As we will discuss in Section V,
collection of five asynchronous BFT protocols based off this allows BFT protocols to take advantage of shorter block
HoneyBadgerBFT but with carefully picked components that intervals and attain high transaction throughput.
are optimized for different objectives. Among the five con- Other blockchain compatibility challenges for BFT-SMR
stituent protocols, the baseline BEAT0 uses a more effi- protocols include: 1) allowing nodes to join and leave flexibly
cient threshold encryption scheme [62] and outperforms without interrupting consensus while countering Sybil attacks;
HoneyBadgerBFT in throughput, latency and access overhead. 2) adapting to real-world peer-to-peer networks that are
BEAT1 and BEAT2 adopt a more efficient broadcast scheme, sparsely connected. In later sections we will revisit these issues
Bracha’s RBC [52], and are optimized for transaction latency. for blockchain protocols that incorporate BFT consensus.
BEAT3 is optimized for throughput and storage and bandwidth
saving while BEAT4 further reduces the bandwidth usage for
clients that read particular stored transactions. Interested read- IV. A N OVERVIEW OF B LOCKCHAIN C ONSENSUS
ers are referred to the BEAT paper [17] for detailed discussion Compared to traditional distributed computing with a clear
on the authors’ design choices. client-server model, a blockchain network allows every partic-
ipant to be both a client (to issue transactions) and a server
F. Blockchain Compatibility of Classical BFT-SMR Protocols (to validate and finalize transactions). The underlying ledger
In a blockchain network, every consensus participant can data structure, the blockchain, is the consensus target and con-
validate transactions and propose new blocks. For BFT-SMR sists of chronologically ordered and hash-chained blocks. Each
consensus protocols that rely on a dedicated primary server block contains a bundle of valid transactions and transactions
to receive client requests and start the consensus, the fol- across the blockchain should be consistent with each other (i.e.,
lowing adaptation is needed: allowing all servers to act as a no double-/over-spending or misappropriation). Meanwhile, a
primary to propose transactions/blocks and reaching consen- blockchain system is often associated with a financial applica-
sus on the finality of multiple transactions/blocks concurrently. tion and bears the responsibility of transaction processing and
For example, Casper FFG [14], a BFT-style blockchain proto- clearing. As a result, the responsibility of a blockchain con-
col, allows every eligible participant to propose a block during sensus protocol is further-reaching than traditional distributed
a checkpoint cycle. The network finalizes only one block out consensus protocols. In this section we provide a background
of multiple proposed blocks for each checkpoint. of the blockchain network and data structure, introduce the
For blockchain networks with a complex application layer blockchain consensus goal adapted from the BFT consensus
such as smart contract, transaction execution often incurs sig- paradigm and the five-component framework that we use to
nificant computation. While in popular BFT-SMR schemes analyze blockchain consensus protocols.

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1440 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

TABLE I
A. Blockchain Infrastructure A C OMPARISON OF P ERMISSIONLESS AND P ERMISSIONED B LOCKCHAIN
Network: The foundational infrastructure of blockchain, as
is adopted by most public cryptocurrencies and distributed
ledger systems, is a peer-to-peer overlay network on top of
the Internet. Every node (or peer) in the network operates
autonomously with respect to the same set of rules that cover
peering protocol, consensus protocol, transaction processing,
ledger management, and in some cases a wire protocol for
transport-layer communication [65], [66].
Depending on the control of network participation,
blockchain networks generally fall into two categories: per-
missionless and permissioned.
• A permissionless blockchain allows for free join and
leave without any authorization, as long as the node
holds a valid pseudonym (account address) and is able
to send, receive, and validate transactions and blocks by
common rules. Permissionless blockchain is also known
as public blockchain for that there is usually one such
blockchain network instance on a global scale which
is subject to public governance. Specifically, anyone
can participate in blockchain consensus, though one’s
voting power is typically proportional to its posses-
sion of network resources, such as computation power,
token wealth, storage space, etc. The operational envi-
ronment of permissionless blockchain is often assumed as
large-scale and zero-trust, which often cautions the com-
munity against increasing transaction processing capacity Fig. 4. Blockchain data structure. Blocks are sequentially chained together
or using more efficient consensus schemes [22]. via hash pointers. The Merkle tree root (MT root) is a digest of all transactions
• A permissioned blockchain requires participants to be included in a block.
authorized first and then participate in network operation
with revealed identity. The network governance and con-
sensus body can be either the subsidiaries of a single pri- asynchronous consensus protocols such as HoneyBadgerBFT,
vate entity or a consortium of entities [19]. Compared to as we discussed in Section III.
permissionless blockchain, the identity-revealing require- Transaction: A blockchain transaction can be regarded as a
ment and more effective network governance of permis- public static data record showing the token value redistribution
sioned blockchain make it ideal for internal or multi-party between sender and receiver [21]. Take Bitcoin as an exam-
business applications. Meanwhile, the limited size of a ple, a transaction transfers token ownership from the sender
permissioned blockchain’s consensus body allows for the account to the receiver account(s). It specifies a list of inputs
deployment of more efficient consensus protocols that and a list of outputs, with each input claiming a previous
achieve higher transaction capacity [22], [67]. unspent transaction output (UXTO) that belongs to the sender,
Table I summarizes the major differences between permission- who needs to attach its signature to the inputs to justify the
less and permissioned blockchain in nine aspects. claim. Each output specifies how many tokens go to which
Beneath the blockchain peer-to-peer network lies the basic receiver and the total token value of the outputs is equal to
infrastructure of the Internet. Thanks to the transport layer the UXTOs claimed by the inputs. Therefore, we can always
protocols (especially the retransmission mechanism), mes- recover the ownership records of any specific token by trac-
sage delivery is considered guaranteed, while the message ing back the signatures along the chain of transactions. The
delay may vary but most likely will not grow longer as token balance of an account equals to the summed UXTOs
time elapses (weak synchrony) or remains within a certain that belong to the account.
bound (Δ-synchrony). Therefore we often consider a practical Blockchain Data Structure: Blockchain is the underlying
blockchain network partially synchronous, just like most dis- data structure for transaction ledger keeping. It is also the con-
tributed networks overlaying on the Internet. This allows the sensus target of the network. The basic structure of blockchain
consensus protocol to take advantage of the timing services is illustrated in Fig. 4. Every block encloses a set of trans-
of the Internet. For example, in Bitcoin the partial synchrony actions that should be valid and clear of double spending.
assumption is echoed by its usage of local timestamps for As was pioneered by Bitcoin, the transactions are often orga-
loose chronological ordering, showing time consciousness. For nized in a Merkle tree. Merkle tree is a data structure widely
the blockchain networks that reside on an ad hoc infrastruc- used for data storage and efficient data integrity check [68].
ture not based on the Internet, the message transmission is In blockchain, every block contains one Merkle tree in which
subject to unexpected network delays, which gives rise to each leaf node is labeled with a transaction hash. The Merkle

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1441

TABLE II
F IVE C OMPONENTS OF A B LOCKCHAIN C ONSENSUS P ROTOCOL

tree root serves as a digest of the transaction set and is placed nodes. An accepted block should be assigned the same
in the block header. The block header also contains a hash of sequence number by every honest node.
the previous block (except in the genesis block) and other con- • Validity: If every node receives a same valid transac-
figuration information, which typically includes a timestamp tion/block, it should be accepted into the blockchain.
and the blockchain state at block generation. The growing • Integrity: At every honest node, all accepted transactions
chain of blocks and the aforementioned transaction format should be consistent with each other (no double spend-
essentially constitute the blockchain data structure used for ing). All accepted blocks should be correctly generated
the storage, serialization, and validation of new transactions and hash-chained in chronological order.
which are continuously injected into the network. The termination and validity requirements are similar to
Aside from recording the transaction history, the blockchain their counterparts in classical distributed consensus, as they
can also record auxiliary information used for other purposes. represent the system’s liveness. The agreement requirement
The locking and unlocking scripts associated with transaction is enhanced with total ordering, which represents the serial-
inputs and outputs can be repurposed for constructing off- ization of blocks and transactions. The integrity requirement
chain payment channels (e.g., Lightning Network [69]) and dictates the correctness of the origin of transactions and
a global state machine that helps build smart contracts, which blocks, fulfilling the promise of anti-double-spending and
are the basis of many important applications such as supply ledger tamper-proofing. These requirements can serve as the
chain management and decentralized autonomous organiza- design principles of new blockchain protocols. For different
tion. The block header may contain extra fields that facilitate application scenarios, they can be tailored or supplemented
system coordination. For example, Ethereum’s proof-of-stake with more specification.
(PoS) scheme Casper FFG [70] utilizes smart contract to
implement the staking process; Algorand [13] attaches a cryp- C. Components of Blockchain Consensus Protocol
tographic proof to each new block to show the block proposer’s Based on the discussion on consensus goal and our digest
eligibility to propose. As a result, the blockchain can hold of the blockchain documentation corpus, we identify five key
the necessary control information usable by the consensus components of a blockchain consensus protocol:
protocol. We will revisit these protocols in later sections. • Block Proposal: Generating blocks and attaching gener-
ation proofs.
B. Consensus Goal • Information Propagation: Disseminating blocks and
The goal of a blockchain consensus protocol is to ensure that transactions across network.
all participating nodes agree on a common network transaction • Block Validation: Checking blocks for generation proofs
history, which is serialized in the form of a blockchain. Based and transaction validity.
on the previous discussion on BFT consensus and the consen- • Block Finalization: Reaching agreement on the accep-
sus goal abstraction provided in [22], we similarly define the tance of validated blocks.
following requirements for blockchain consensus: • Incentive Mechanism: Promoting honest participation and
• Termination: At every honest node, a new transaction is creating network tokens.
either discarded or accepted into the blockchain, within For each component we also specify its counterpart in tradi-
the content of a block. tional SMR consensus protocols and a list of available options
• Agreement: Every new transaction and its holding block in Table II. The available options are non-exhaustive, as many
should be either accepted or discarded by all honest more are being developed at the time of writing. It is worth

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1442 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

Fig. 5. A toy example of block propagation in the Bitcoin network. (a) The P2P network structure, an undirected graph. (b) The gossiping process. A solid
blue arrow represents one-hop block propagation (advertise→get block→transmit), while a dotted black arrow represents only advertise. Number denotes the
gossiping hop (0 for the block producer). (c) Block propagation in one hop.

noting that the incentive mechanism is unique to blockchain drawbacks and vulnerabilities. We also introduce two well-
consensus and has no counterpart in traditional SMR consen- known improvement proposals and four hybrid PoW-BFT
sus protocols. The reason is that traditional SMR protocols protocols in the later part of this section.
are purely designed for transaction processing and serializa-
tion within a preexisting network of participants, of which A. Network Setting and Consensus Goal
the continuous participation of honest parties is presumed.
In blockchain networks, block or transaction messages are
Meanwhile, a typical blockchain network allows for voluntary
propagated across the P2P network through gossiping. Fig. 5
participation and often bears numerous real-world obligations.
shows an example of block propagation in the Bitcoin network.
To this end, a fair and universal incentive mechanism is needed
Specifically, the one-hop propagation adopts advertisement-
to encourage honest participation, so as to sustain the system’s
based gossiping, as was first characterized in [73]. For each
reliable operation. For large-scale permissionless blockchains,
new block received and validated, a node advertises it to
a robust incentive mechanism along with the block generation
peers, who will request for this block if it extends their local
proofs help demoralize Sybil attackers.
blockchain. The gossiping process continues until every node
Though the five components provide important functional-
in the network has this block.
ities for blockchain consensus, a new blockchain consensus
Compared to the general consensus goal introduced in
protocol proposal may not cover all of them. For example,
Section IV, Nakamoto enhances the termination requirement
the incentive mechanism is indispensable to permissionless
with the probabilistic finality specification:
blockchain networks especially those carrying a financial
• Probabilistic finality: For any honest node, every new
responsibility; however for permissioned blockchains in which
block is either discarded or accepted into its local
participation is sanctioned as a privilege (similar to a tradi-
blockchain. An accepted block may still be discarded
tional distributed computing system), it is not a must-have.
but with an exponentially diminishing probability as the
Interestingly, many new public blockchain initiatives have
blockchain continues to grow.
been fixating only on block proposal, while inheriting the other
The probabilistic finality property echoes the probabilistic
four components from the Nakamoto consensus protocol of
termination property for asynchronous consensus. As we will
Bitcoin. This is likely due to that Bitcoin’s PoW-based block
show later, because of this property the Nakamoto consensus
proposal attracts the most criticism for its limited scalabil-
protocol can only achieve eventual double-spending resistance
ity and inefficient energy use. For this reason, block proposal
in a decentralized network of pseudonymous participants.
mechanism can be a good reference angle for a general clas-
sification of consensus protocols. In the remaining part we
dedicate Section V to Nakamoto consensus and its variations B. The Nakamoto Consensus Protocol
that are built upon PoW, while Section VI is dedicated to four In correspondence to the five components of a blockchain
genres of PoS-based protocols. Detailed protocol composition consensus protocol, the Nakamoto consensus protocol can be
is described when it comes to specific features. summarized by the following rules:
• Proof of Work (PoW): Block generation requires finding
a preimage to a hash function so the hash result satis-
V. T HE NAKAMOTO C ONSENSUS P ROTOCOL fies a difficulty target, which is dynamically adjusted to
AND VARIATIONS maintain an average block generation interval.
The Nakamoto consensus protocol is the key innovation • Gossiping Rule: Any newly received or locally generated
behind Bitcoin [1] and many other established cryptocurrency transaction or block should be immediately advertised
systems such as Ethereum [71] and Litecoin [72]. In this and broadcast to peers.
section we use Bitcoin as the application background to intro- • Validation Rule: A block or transaction needs to be val-
duce the Nakamoto consensus protocol and summarize its idated before being broadcast to peers or appended to

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1443

the blockchain. The validation includes double-spending Algorithm 3: Nakamoto Consensus Protocol General
check on transactions and proof-of-work validity check Procedure
on block header. /* Joining network */
• Longest-Chain Rule: The longest chain represents 1 Join the network by connecting to known peers;
network consensus, which should be accepted by any 2 Start BlockGen();
node who sees it. Mining should always extend the /* Main loop */
longest chain. 3 while running do
• Block Rewards and Transaction Fees: Generator of a 4 if BlockGen() returns block then
block can claim a certain amount of new tokens plus 5 Write block into blockchain;
fees collected from all enclosed transactions, in the form 6 Reset BlockGen() to the current blockchain;
of a coinbase transaction to itself. /* Gossiping rule */
The hashing-intensive PoW mechanism is designed for mit- 7 Broadcast block to peers;
igating Sybil attacks. Due to Bitcoin’s permissionless and 8 end
pseudonymous nature, Sybil attackers can obtain new iden- /* Longest-chain/validation rule */
tities or accounts with little effort. Hashing power, however, 9 if block received & is valid & extends the longest
comes from real hardware investment and cannot be easily chain then
forged. The longest-chain rule implies that the stabilized pre- 10 Write block into blockchain;
fix of the longest chain can act as a common reference of the 11 Reset BlockGen() to the current blockchain;
network history, given that no one is authoritative in Bitcoin’s 12 Relay block to peers;
decentralized network. Block rewards and transaction fees are 13 end
used to incentivize miners to participate honestly and inject 14 end
new coins into circulation. /* PoW-based block generation */
To better illustrate how these rules harmonize with each 15 Function BlockGen():
other, we present an abstracted version of the Nakamoto 16 Pack up transactions (including coinbase);
protocol in Algorithm 3. During block generation, a higher 17 Prepare a block header context C containing the
mining difficulty demands more brute-force trials in order transaction Merkle tree root, hash of the last block
to find a fulfilling nonce. To ensure every block is suf- in the longest chain, timestamp, and other essential
ficiently propagated before the next block comes out, the information reflecting blockchain status;
mining difficulty is adjusted every 2016 blocks so that the /* PoW hashing puzzle */
expected block interval remains a constant value (10 min- 18 Find a nonce that satisfies the following condition:
utes in Bitcoin) no matter how the gross hashing power
fluctuates. Hash(C |nonce) < target
Fork resolution: Ideally, the 10-minute block interval should wherein more preceding zero bits in target indicate
be enough to ensure the thorough propagation of a new block a higher mining difficulty;
so that no block of the same height is proposed. However due 19 return new block;
to the delay during the message propagation and the prob- 20 end
abilistic nature of the hashing game, the possibility of two
blocks of the same height being propagated concurrently in
the network can not be ignored. This situation is called a
“fork”, detectable by any node. Correspondingly, the longest- Security Analysis: In contrast to the classical dis-
chain rule provides the criterion for fork resolution. Assume tributed computing system whose fault tolerance capability is
a miner receives two valid blocks B1k , B2k of the same block characterized by the number of faulty nodes the system can
height k sequentially, then a fork is detected by this miner. It tolerate, fault tolerance of Nakamoto consensus is by charac-
chooses B1k (the first arrived) to continue and may encounter terized by percentage of adversarial hashing power the system
the following cases: can tolerate. It is proved by Garay et al. [74] that if the
• Case 1: If receiving or successfully generating a block
network synchronizes faster than the PoW-based block propos-
B1k +1 confirming B1k , accept B1k , B1k +1 and orphans B2k . ing rate, an honest majority among the equally-potent (in
k +1
• Case 2: If receiving a block B2 confirming B2k , switch hashing power and bandwidth) miners can guarantee the con-
k +1
to B2 and accept B2 , then orphans B1k .
k
sensus on an ever-growing prefix of the blockchain. The prefix
k +1
• Case 3: If simultaneously receiving two blocks B1 and represents the probabilistically stable part of the blockchain.
k +2 k k
B2 confirming respectively B1 and B2 , choose one to As long as less than 50% of total hashing power is maliciously
follow and continue until case 1 or 2 is met. controlled, the blocks produced by honest miners are timely
Wherein to “orphan” a block means to deny it into the main propagated, the main chain contributed by the honest majority
chain. Because of the randomized nature of PoW mining, can eventually outgrow any malicious branch.
the likelihood of encountering case 3 drops exponentially as From the perspective of classical distributed consensus,
time elapses, reflecting the probabilistic finality of Nakamoto Nakamoto consensus cleverly circumvents the fundamental 1/3
consensus. BFT bound by adopting probabilistic finality. In classical BFT

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1444 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

consensus if more than 1/3 of population are malicious, the miners to invest into more mining equipment with higher hash-
honest nodes will end up deciding conflicting values, lead- ing rates. This vicious cycle shall continue as Bitcoin gains
ing to consensus failure. In Nakamoto consensus, however, more popularity. In response, the blockchain community has
conflicting decisions are allowed temporarily in the form of come up with various block proposing schemes such as proof
blockchain forks, as long as they will be eventually trimmed of stake (PoS), proof of authority (PoA), proof of elapsed time
out by continuing effort of the honest majority. Therefore, the (PoET) as energy-saving alternatives to PoW.
1/3 BFT bound is not applicable to Nakamoto consensus or 3) Eclipse Attack: As was discussed above, the security
other blockchain consensus protocols designed for probabilis- of Bitcoin network relies on the hashing power and commu-
tic finality. Readers are referred to Abraham and Malkhi [75] nication capability of honest miners. If a powerful attacker
for an interesting discussion on the correspondence between manages to dominate the in/outward communication between
Nakamoto consensus and classical BFT-SMR framework. a victim miner and the main network (i.e., “eclipsing”), then
As for double-spending resistance, assuming the adversary the victim will no longer be able to contribute to the exten-
controls α fraction of the total hashing power and wishes to sion of the main chain [77]. Assume the percentage of hashing
double-spend an output which is m blocks old, it needs to redo power controlled by the eclipse attacker, the eclipsed victims,
the PoW mining all the way from m blocks behind and grow the remaining honest miners are α, , 1 − α − , then the
a malicious chain fast enough to overtake the incumbent main attacker’s mining power shall be amplified to at least 1− α . If
α )m
chain. The probability of this adversarial catch-up is ( 1−α the attacker decides to exploit the eclipsed victims for growing
if α < 50%, which drops exponentially as m increases, the malicious chain, its mining power can be further enhanced
reflecting probabilistic finality. This probability equals to 1 up to α+ [78]. As a result, a double-spending attack becomes
if α ≥ 50%. As a result, the 50% threshold is the safeguard viable for the eclipse attacker if α +  > 50%.
behind Bitcoin’s probabilistic finality, as well as resistance to Eclipse attack is in fact an exploit of the weak connec-
double-spending and transaction history tampering. tivity of permissionless peer-to-peer network based upon the
Internet, which is subject to unpredictable physical bottlenecks
and adversarial influences. A general approach to counter
C. Drawbacks and Vulnerabilities of Nakamoto Consensus eclipse attacks is to secure the communication channels and
1) Tight Tradeoff Between Performance and Security: The increase the connectivity and geographical diversity of the
Nakamoto consensus is widely criticized for its low transac- peer-to-peer connections.
tion throughput. For instance, Bitcoin can process up to 7 4) Selfish Mining: The 50% fault tolerance of Nakamoto
TPS meanwhile the VISA payment network processes 2500 consensus is built upon the assumption that all miners (both
TPS on average [76]. The limited performance of Nakamoto honest and malicious) strictly follow the broadcast rule that
consensus protocol follows from the security implication of new blocks are broadcast immediately upon successful gen-
its probabilistic finality and two protocol parameters: block eration. If a malicious mining group withholds newly mined
interval and block size. As we discussed previously, the 10- blocks and strategically publicizes them to disrupt the prop-
minute block interval ensures every new block is sufficiently agation of blocks mined by honest miners, they can partially
propagated before a new block is mined. Reducing the block nullify the work of honest miners and amplify their effective
interval increases the transaction capacity, but leaves new mining power. This strategy is known as selfish mining. It is
blocks insufficiently propagated and causes more fork inci- shown by Eyal and Sirer [79] that a selfish mining group can
dents, undermining the security of the main chain. Note that generate a disproportionately higher revenue than that from
although any fork can be resolved given enough time, the honest mining if the group’s mining power surpasses a certain
higher the fork rate, the larger the portion of honest mining threshold θ, assuming the group has a certain communication
power is wasted, which enables a double-spending attacker to capability measured by γ ∈ [0, 1], which is the fraction of
overthrow the main chain with less than 50% mining power honest nodes that will follow the malicious chain in case of
(estimated chance of 49.1% by Decker and Wattenhofer [73] forks. As a result, the selfish mining group can attract new
in 2013). On the other hand, increasing the block size (cur- miners and eventually outgrow the honest miners. Notably, θ
rently 1MB) has the same effect, since larger block sizes approaches zero if the selfish mining group are able to con-
lead to higher block transmission delays and insufficient vince almost all honest miners to follow the malicious chain
propagation. According to the measurement and analysis by (i.e., γ → 1). It is also shown that by adopting a randomized
Croman et al. [3] in 2016, given the current 10-min block chain selection strategy at honest miners, which is equivalent
interval the maximum block size should not exceed 4MB, to setting γ = 0.5, θ can be raised up to 25%. A later work by
which yields a peak throughput of 27 TPS. Sapirshtein et al. [80] shows that an optimized selfish mining
2) Energy Inefficiency: As of November 2019, an average strategy can further enhance the selfish mining pool’s effec-
Bitcoin transaction consumes 431 KWh of electricity which tive mining power fraction from α to the upper bound 1−α α
can power 21 U.S. households for a day [5]. This enor- (achievable when γ = 1).
mous energy consumption is directly caused by the PoW-based Selfish mining attack and eclipse attack have only hap-
block proposing scheme of Nakamoto consensus. As Bitcoin pened to smaller blockchains such as Monacoin [81], but never
network’s gross mining capacity grows, the Nakamoto con- to Bitcoin or other mainstream blockchains. This is proba-
sensus protocol has to raise the mining difficulty to maintain bly due to two reasons. First, miners in established public
the average 10-min block interval, which in turn encourages blockchain networks actually care about the system’s longevity

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1445

and reputation, which can positively affect the exchange

rate of the cryptocurrency and thus their mining revenue.
Second, established blockchains tend to be better connected
(reflected by the existence of dedicated mining pools and
relay networks), which allows for an effective detection of
any selfish mining or eclipse attack behavior.
5) Mining Pools and Centralization Risk: According to
the incentive mechanism of Nakamoto consensus, the min- Fig. 6. Bitcoin-NG blockchain data structure. Key blocks track miners and are
ing revenue of a miner is proportional to its computing power. generated through PoW. Micro blocks curate transactions and are generated
Since bitcoins can be traded for fiat currencies at exchanges, by the most recent key block miner.
higher-earning miners have the financial advantage to pur-
chase more efficient mining hardware, which consumes less
joules per hash operation. Furthermore, higher-earning miners will hold as long as more than 50% of mining power are
are often backed by large organizations that can direct huge honest.
capital into the mining business. As a result, small individ- The simulation result in [84] shows that given the same
ual miners are either forced out of the game, or alternatively block interval, applying GHOST rule leads to a slightly lower
join in mining pools for stabler income. All members in a transaction throughput than that with the longest-chain rule
mining pool are registered with a coordinator and work to when block interval is fixed, but effectively prevents the secu-
extend a common chain, while transaction validation, packag- rity degradation when the block interval decreases, allowing
ing and block proposal can be performed independently. To for a higher transaction throughput. A variation of GHOST is
incentivize pool participation, block rewards are redistributed implemented in the Ethereum blockchain, wherein the “uncle
among the pool through a reliable remuneration scheme so blocks” (i.e., blocks with a valid proof of work but orphaned
that every pool member routinely gets a fair share of the pool’s out of the main chain) may get rewarded for their redundant
mining rewards according to its registered computing power. mining effort. As a result, Ethereum adopts a much shorter
In fact, joining in a mining pool has become the domi- block interval (10-15 seconds) and achieves up to 25 TPS
nant way of participation in major PoW-based blockchains. throughput, in contrast to Bitcoin’s 10-minute block interval
The measurement study by Gencer et al. [82] in 2018 shows and 7 TPS throughput.
that throughout a one-year observation period, over 50% of 2) Bitcoin-NG: Bitcoin-NG was proposed by Eyal et al. [7]
the gross mining power was controlled by eight mining pools in 2016 to scale up Bitcoin’s transaction capacity. A vari-
in Bitcoin and five mining pools in Ethereum. Moreover, ant of Bitcoin-NG called Waves-NG [85] is currently used
the empirical study by Kondor et al. [83] in 2014 shows in Wave Platform, a blockchain initiative. The key insight of
that the wealth distribution among Bitcoin addresses has Bitcoin-NG is decoupling block generation into two planes:
been converging to a stable exponential distribution, and the leader-election and transaction serialization, which respec-
wealth accumulation of node is positively related to its abil- tively correspond to two types of blocks: key blocks and micro
ity to attract new connections, which is another advantage of blocks. The key blocks resemble Bitcoin’s blocks, which con-
established well-connected miners. tain a solution to a hash puzzle representing the proof of work
and have an average block interval of 10 minutes, except for
the actual transactions which are included in the micro blocks.
Once a key block is mined, all subsequent micro blocks shall
D. Improvements to the Nakamoto Consensus Protocol be generated by the current key block miner until the genera-
1) GHOST Rule: The greedy heaviest-observed sub- tion of the next key block. The generation of micro blocks is
tree (GHOST) block finalization rule was proposed by deterministic and does not contain proof of work. As a result,
Sompolinsky and Zohar [84] for Bitcoin in 2015. According the micro block frequency is in the control of the key block
to the longest-chain rule, all unconfirmed blocks in a fork miner (up to a maximum) to accommodate as many transac-
shall be orphaned, resulting in a waste of honest mining tions as possible. The blockchain data structure of Bitcoin-NG
power which could otherwise have been used to contribute to is shown in Fig. 6.
the longest-chain’s security. The longest-chain rule also lim- The longest-chain rule is still applied to finalize and resolve
its the transaction capacity since the tight tradeoff between forks of key blocks. As for the micro blocks, since they
performance and security mandates that the block interval are batch-generated by key block miners, Bitcoin-NG relies
should be sufficiently long. The GHOST rule is an alterna- on a combination of a heaviest-chain extension rule and a
tive to the longest-chain rule that the orphaned blocks also longest-chain extension rule to finalize and resolve forks of
contribute to the main chain security, effectively reducing the micro blocks. To encourage honest participation and discour-
impacts of forks, allowing for a shorter block interval and thus age the current key block miner from double-spending and
higher transaction capacity. GHOST requires that given a tree other malfeasance, 60% of the transaction fees collected from
of blocks with the genesis block being the root, the longest micro blocks by the current key block miner are redistributed
chain within the heaviest subtree shall be used as the main to the miner of the next key block.
chain. Similar to the Nakamoto consensus, the probabilistic As for Bitcoin-NG’s performance, since key blocks do not
finality of the heaviest subtree up to the current block height carry transactions, the transaction throughput entirely depends

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1446 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

on the micro block size and frequency. The micro block committee assumes the preexistence of network coordination,
frequency needs to be controlled, for an excessive amount which to some extent counters the decentralized ideal of public
of them may exhaust the network bandwidth and cause fre- blockchains.
quent key block forks. Hypothetically, if we kept the key block Notably, using sharding to scale up blockchain transac-
frequency at 10 minute and micro block size at 1MB, set the tion throughput has been extensively studied in the developer
micro block frequency to 12 seconds (the minimum practical communities. Interested readers are referred to [89] for a
block interval under current Bitcoin network condition [86]), development history and the state-of-the-arts of blockchain
Bitcoin-NG would achieve up to 200 TPS throughput. sharding.
On the downside, due to the determinism in micro block 3) ByzCoin: ByzCoin was proposed by Kokoris-
generation, the key block miner may become a target of denial- Kogias et al. [90] in 2016 as a blockchain consensus
of-service or corruption attacks. A compromised key block protocol that leverages PoW for consensus group membership
miner may enclose transactions selectively or finalize contra- management and BFT for transaction finalization. ByzCoin
dicting transactions, the inconsistency caused by which can takes inspiration from Bitcoin-NG’s ledger structure but
cost the network more than one key block cycle to remedy. features a subtle difference. Instead of a linear structure,
ByzCoin’s ledger consists of two parallel blockchains: a
keyblock chain and a microblock chain. Keyblocks are mined
E. Hybrid PoW-BFT Consensus Protocols via PoW as in Nakamoto consensus and used for maintaining
The limited transaction capacity and tight tradeoff between a consensus group from recent keyblock miners according
performance and security of Nakamoto consensus are much to a sliding-share-window mechanism. Specifically, when
warranted by its probabilistic finality and decentralized ideal. a miner finds a new keyblock, it is credited one share
In contrast, BFT consensus assumes fixed participants with in the consensus group and the share window moves one
revealed identities and achieves deterministic finality, allowing share forward. Only miners with shares in the window can
much shorter block intervals and thus much higher transaction participate in the subsequent consensus. Old shares expire
throughput. In response, hybrid PoW-BFT protocols have been once being left out of the window and so does the share
proposed to get the best of two worlds. Here we introduce four owner’s eligibility of consensus participation. The window
popular proposals. length is subject to designer’s choice on the consensus group
1) PeerConsensus: Proposed by Decker et al. [64] in 2014, size as well as the overall consensus participation fairness.
PeerConsensus uses a PoW-based blockchain to throttle and A microblock is produced by the current consensus group
certify new identities joining the network, while being agnos- via an adapted PBFT protocol based on collective signing
tic to any application built upon it. The number of identities (CoSi) [91]. Compared to the original PBFT, the CoSi-based
a player may control is proportional to its share of computa- PBFT reduces the communication complexity from O(N 2 )
tion power, which provides Sybil resistance. With the identities to O(N log N) and thus scales better to large consensus
established by the blockchain, the application can employ an groups. As for transaction finalization, the current keyblock
efficient BFT protocol such as PBFT and SGMP [87] for miner packs up new transactions into a microblock and acts
committing transactions. The transaction fees collected are dis- as the leader to trigger the CoSi-based PBFT. In the end,
tributed to all identities equally. As a result, PeerConsensus the microblock will be finalized and contain the collective
effectively decouples participation management from transac- signature of the consensus group and the hash pointer to
tion processing, allowing the latter to scale up throughput. On the preceding keyblock, which also contains the collective
the downside, since the transaction history is not recorded in signature.
blockchain, PeerConsensus cannot control the malleability of ByzCoin configures that the sliding-share-window mecha-
transactions. nism replaces one member of the consensus group at a new
2) SCP: The scalable consensus protocol (SCP), proposed keyblock. This yields a slightly tighter fault-tolerance thresh-
by Luu et al. [88] in 2015, incorporates BFT and sharding into old than that of classical BFT consensus: N ≥ 3f + 2 is
blockchain consensus. The key idea of SCP is to partition the needed anytime, where N is the consensus group size and f
network into sub-committees (i.e., shards) with a PoW mech- the Byzantine population. Meanwhile, ByzCoin’s PoW-based
anism, so that each sub-committee controls a limited amount keyblock chain is still susceptible to forks. A fork can split
of computation power and the number of sub-committees is the consensus group and potentially make the PBFT consensus
proportional to the network’s gross computation power. This stall, which can further aggravated by the presence of selfish
is aimed to limit the size of a sub-committee, which oper- miners. In response, ByzCoin relies on a deterministic priori-
ates independently and curates a local blockchain using a tization function tweaked with high output entropy to resolve
BFT consensus protocol. A dedicated finalization committee forks timely and reduce the impact of selfish miners.
is responsible for combining the outputs of all sub-committees 4) Pass and Shi’s Hybrid Consensus: As a concurrent
into the global blockchain. A block in the global chain stores work to ByzCoin, the hybrid consensus protocol proposed by
the hash and transaction Merkle tree root of every block Pass and Shi [92] adopts a sliding-window idea similar to
proposed by every sub-committee. To ensure consensus safety, ByzCoin’s but less susceptible to forks. That is, assuming the
SCP requires each sub-committee as well as the whole network window size λ, the consensus group is populated by the last λ
to maintain a two-thirds majority of honest computation power. miners of the “stable part” of the blockchain, which is the main
However, the use of sharding and a dedicated finalization chain truncated off Θ(λ) blocks. This protocol keeps the PBFT

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1447

consensus off-chain; only the consensus epoch number and a

digest of the transaction log are attached to the new block.
Moreover, this protocol advocates using FruitChain [93] as the
underlying PoW blockchain, which was proposed by the same
authors and allegedly achieves better ledger tamper-resistance
than Nakamoto’s blockchain.
A Short Summary: Due to the scalability concern that BFT
protocol’s communication overhead would be overwhelmingly
high if the consensus group grew out of control, the above
hybrid PoW-BFT protocols share a common trait that the PoW
mechanism is used for maintaining a stable consensus group
for each BFT protocol instance. Since the PoW-based par-
ticipation control does not involve actual authorization and is
open to any one with computation power, we consider it a form
of soft permission control for public blockchains. Moreover,
novel signature schemes such as CoSi [91] and aggregated sig-
nature gossip [94] can help reduce communication complexity
in a sparsely-connected peer-to-peer network and allow for a
larger number of consensus participants.
We stress that there are more ways to hybridize PoW and
BFT in addition to the above proposals. Moreover, indepen-
dently proposed cryptographic techniques are often comple- Fig. 7. Popular PoS blockchain initiatives classified under four classes and
performance highlights.
mentary to the hybrid design. This observation also applies to
general hybrid PoX-BFT schemes.

A. Chain-Based PoS
Chain-based PoS is an early PoS scheme proposed
VI. P ROOF - OF -S TAKE BASED C ONSENSUS P ROTOCOLS by Bitcoin developers as an alternative block generation
Proof-of-Stake (PoS) originates from the Bitcoin commu- mechanism to PoW. It is within the framework of Nakamoto
nity as an energy efficient alternative to PoW mining. In the consensus in that the gossiping-style message passing, block
simplest terms, a stake refers to the coins or network tokens validation rule, longest-chain rule, and probabilistic finality
owned by a participant that can be invested in the blockchain are preserved. Early full-fledged chain-based PoS blockchain
consensus process. From the security point of view, PoS lever- systems include Peercoin and Nxt.
ages token ownership for Sybil attack mitigation. Compared The general procedure of a chain-based PoS minter can be
to a PoW miner whose chance to propose a block is pro- summarized by Algorithm 4. Unlike PoW, PoS does not hinge
portional to its brute-force computation power, the chance to on wasteful hashing to generate blocks. A minter can solve the
propose a block for a PoS miner is proportional to its stake hashing puzzle only once for a clock tick. Since the hashing
value. From the economics point of view, PoS moves a miner’s puzzle difficulty decreases with the minter’s stake value, the
opportunity cost from outside the system (waste of computa- expected number of hashing attempts for a minter to solve the
tion power and electricity) to inside the system (loss of capital puzzle can be significantly reduced if her stake value is high.
and investment gain) [95]. Because of the lack of real min- Therefore, PoS avoids the brute-force hashing competition that
ing, we often refer to a PoS miner as a validator, minter, or a would occur had PoW been used, thus achieving a significant
stakeholder for PoS’s close resemblance to investing in capital reduction of energy usage.
markets. 1) Peercoin and Nxt: Both Peercoin [6] and Nxt [96] gener-
We identify four classes of PoS protocols: chain-based ally follow Algorithm 4. Their major difference lies in how the
PoS, committee-based PoS, BFT-based PoS, and delegated stake is valued. Stake value is initially proportional to stake
PoS (DPoS). Chain-based PoS inherits many of the compo- quantity. To ensure the profitability of small stakeholders, a
nents of the Nakamoto consensus protocol such as information stake valuation scheme can be used to adjust the value of an
propagation, block validation, and block finalization (i.e., unused stake as time passes. Peercoin uses the coin age metric
longest-chain rule), except that the block generation mech- for stake valuation, which lets the value of a stake appreciate
anism is replaced with PoS. Committee-based PoS leverages linearly with time since the deposit. At the end of a block
a multiparty computation (MPC) scheme to determine a com- cycle, the value of the winner’s stake returns to its base value.
mittee to orderly generate blocks. BFT-based PoS combines To avoid stakeholders from locking in a future block by delib-
staking with BFT consensus which guarantees deterministic erately waiting long, stake appreciation only continues for 90
finality of blocks. DPoS employs a social voting mechanism days and stays flat since then. As a result, the chances of small
that elects a fixed-size group of delegates for transaction val- stakeholders to generate a block are supplemented with time
idation and blockchain consensus on behalf of the voters. value that encourages them to stay participated even if they
Popular examples for each PoS class are listed in Fig. 7. have not generated a block for a long time.

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1448 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

Algorithm 4: Chain-Based PoS General Procedure Bentov’s PoA works as follows. At the beginning of block
(Peercoin, Nxt) cycle k, an empty block header EBk is generated according
1 Join the network by connecting to known peers;
to the PoW rule and propagated across the network. After
2 Deposit in the stake pool;
receiving EBk , a stakeholder computes the N-tuple vector seed
3 Start BlockGen();
S as follows:
 
/* Main loop */ Sj = hash hash(EBk )|hash(Bk −1 )|SFj for j = 1, . . . , N
4 while running do
Bk −1 is the previous block, SF is a N-tuple of fixed suffix
5 (Same with Nakamoto’s protocol except that block
values. N is a predefined value that should not be too large.
validation should include PoS check.)
6 end
Then S is used as the input for FTS to compute the pseudo-
/* PoS-based block generation random sequence of stakeholders pSeq, which is also a N-
*/
7 Function BlockGen():
tuple. Every stakeholder in pSeq needs to sign the block and
8 Pack up transactions and prepare a block header broadcast the signature; the last stakeholder in pSeq wraps up
context C containing the transaction Merkle tree the block by including transactions and the N signatures and
root and other essential blockchain information; broadcasts the final block Bk to the network. All stakeholders
/* PoS hashing puzzle in pSeq shares the reward of Bk with the PoW miner of EBk .
*/
9 Set up a clock (whose tick interval is a constant) and To avoid name conflict with proof of authority in later
check for the following condition per clock tick: sections, we refer to Bentov’s PoA as PoAct.
Security Analysis: Chain-based PoS can tolerate up to 50%
Hash(C |clock_time) < target × stake_value of all stakes being maliciously controlled. And since every
token can be staked, the fault tolerance further generalizes to
wherein more preceding zero bits in target indicate
50% of all tokens in the network. If colluding attackers control
a higher mining difficulty per unit of stake value;
more than 50% of stakes, they can grow their malicious chain
10 return new block;
faster than the others and carry out a double-spending attack,
11 end
which is analogous to the 51% attack in PoW blockchains.
However, from the economic perspective, PoS attackers have
lower incentives to do so because of the capital loss risk.
In comparison, Nxt does not appreciate stake value con- As staking is recorded in the form of transaction scripts, the
tinuously across block cycles like what Peercoin does. This blockchain users can retrieve the staking records according to
is because the latter’s coin age metric may lower the attack which the consensus protocol can legally issue punishment to
cost—attackers can just invest a small amount of stakes and violators, such as nullifying stakes and disbarring the violators
keep attempting to generate blocks until they succeed, which from participating in the future staking process.
is especially unfair to big stakeholders who perform honestly.
Instead, Nxt requires the stake value appreciate only within B. Committee-Based PoS
one block cycle and be reset to the base value once the block Chain-based PoS still relies on hashing puzzles to gen-
cycle ends. Without coin age, Nxt addresses the monopoliza- erate blocks. As an alternative mechanism, committee-based
tion problem from the incentive angle. First, stakes in Nxt are PoS adopts a more orderly regime: determining a commit-
not actively managed by stakeholders; they are essentially the tee of stakeholders based on their stakes and allowing the
account balances—the more tokens held in its account, the committee to generate blocks in turns. A secure multiparty
higher the chance the stakeholder will win the right to gen- computation (MPC) scheme is often used to derive such a
erate a block. Second, total token supply is determined at the committee in the distributed network. MPC is a genre of dis-
beginning and block rewards only come from transaction fees, tributed computing in which multiple parties beginning with
which effectively aligns a stakeholder’s revenue with its val- individual inputs shall output the same result [98]. The MPC
idation work. As a result, all stakeholders have the incentive process in the committee-based PoS essentially realizes the
to honestly validate transactions since it is the only way to functionality that takes in the current blockchain state which
accumulate wealth. includes the stake values from all stakeholders, and outputs
2) Bentov’s PoA: Compared to Peercoin and Nxt, a pseudo-random sequence of stakeholders (we call it the
Bentov et al.’s proof of activity (PoA) [97] is a hybrid leader sequence) which will subsequently populate the block-
PoW-PoS adaptation of the Bitcoin protocol that utilizes an proposing committee. This leader sequence should be the same
algorithm called follow-the-satoshi (FTS) to involve staking. for all stakeholders and those with higher stake values may
FTS works as follows: 1) Use a pseudo-random function (PRF) take up more spots in the sequence. A general procedure for a
to locate an atomic piece of token (e.g., satoshi in Bitcoin, stakeholder of committee-based PoS is shown in Algorithm 5.
wei in Ethereum) in the token universe; 2) If the atomic piece In this algorithm, the CommitteeElect() functionality can also
belongs to stakeholder A, then output A. With the input being be implemented in a privacy-preserving way with verifiable
a sequence of random seeds, FTS outputs a pseudo-random random function (VRF) [99] in that only the stakeholder itself
sequence of stakeholders such that the chance for any stake- knows if it gets elected into the committee.
holder to be in it is proportional to the volume of tokens owned Well-known committee-based PoS schemes include
by the stakeholder. Bentov’s chain of activity (CoA), Ouroboros, Snow White,

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1449

Algorithm 5: Committee-Based PoS General Procedure

/* Joining network and staking */
1 Join the network by connecting to known peers;
2 Deposit in the stake pool;
/* Main loop */
3 while running do
/* Committee election */
4 if new block cycle then
5 Participate in CommitteeElect();
6 Check BlockGenSeq for my turns;
7 end Fig. 8. PVSS-based slot leader sequence generation in Ouroboros. Secrets
/* Block proposing & broadcast */ generated by electors at the beginning of the commit phase eventually form
8 if my turn to generate block then the random seed string. All electors shall go through FTS and obtain the same
slot leader sequence at the end.
9 Collect transactions and generate block;
10 Write block to blockchain;
11 Broadcast block to the network;
12 end known as publicly verifiable secret sharing (PVSS), as is
/* Longest-chain&validation rule shown in Fig. 8. In the commit phase, elector Ei broadcasts
*/
13 if block is received & is valid & extends the longest a commitment message that includes a random secret. In
chain then the reveal phase, Ei broadcasts an opening message that
14 Write block into blockchain; reveals the previously sent secret. In the recovery phase every
15 Relay blocks to other committee members; elector verifies that commitments and openings match and
16 end then form a seed string with the revealed secrets. All electors
17 end have the same seed string and shall obtain the same slot
/* PoS-based committee election leader sequence after executing FTS. As we shall see next,
*/
18 Function CommitteeElect(): Ouroboros’ one-slot-one-leader arrangement entails stringent
19 Fetch the current blockchain state and the stake network synchrony, and the PVSS-based leader selection may
information of all participants; use them as the expose the elected leaders to targeted attacks.
MPC input; 3) Ouroboro Praos: Ouroboros Praos was proposed by
20 Participate in the MPC that produces BlockGenSeq, a David et al. [101] in 2017 to address two security concerns of
pseudo-random sequence of block generation Ouroboros. First, Ouroboros requires stringent network syn-
opportunities; chrony for slot leaders to use their allocated slots precisely,
21 return BlockGenSeq; which is vulnerable to desynchronization attacks. In compar-
22 end ison, Ouroboros Praos is designed for partially synchronous
networks wherein a maximum delay of Δ slots is allowed
for message delivery, albeit Δ is unknown to electors. This
is achieved by allocating empty slots that help electors to re-
and Ouroboros Praos. These protocols and Algorand (see synchronize to the network and allowing a slot to have multiple
Section VI-C) were developed concurrently by academics slot leaders. Second, Ouroboros is susceptible to adaptive cor-
around 2017 and share many common traits. ruption against slot leaders. Since the leader sequence for the
1) Bentov’s CoA: Bentov et al.’s CoA [100] was proposed next epoch is known to all network participants, an attacker
in 2016 partially based on Bentov’s PoA. It follows the main may target and try to corrupt slot leaders ahead of their block
routine in Algorithm 5 in that each nominated stakeholder proposing. In comparison, Ouroboros Praos employs a locally
gets to generate its own block. CoA first leverages a MPC executed verifiable random function (VRF) [99] that allows
process to generate a string S of N random bytes. Then only the elector herself to know her block proposing slots
S is fed to a FTS algorithm that outputs a pseudo-random for the next epoch, which are verified by the correspond-
sequence BlockGenSeq. All parties should output the same ing VRF proofs. Compared to Ouroboros’ PVSS-based leader
BlockGenSeq, which is then used to coordinate the generation selection, the VRF scheme saves much of the communica-
of the next N blocks. tion overhead at the cost of local cryptographic computation.
2) Ouroboros: Ouroboros was developed by Similar schemes are also used in contemporary protocols such
Kiayias et al. [8] in 2017 and has been used as the as Snow White and Algorand.
consensus protocol for cryptocurrency Cardano. Ouroboros Because of its reduced synchrony requirement and the
divides the physical time into fixed-time epochs and each privacy-preserving nature of the VRF scheme, Ouroboros
epoch is subdivided into N slots, each can be used by only Praos does not limit the size of consensus participants and
one slot leader to generate a block for the network. For allows for a flexible committee. Ouroboros Praos also adopts
each epoch, stakeholders with enough stake can become key-evolving signatures (KES) to counter posterior corrup-
electors, who will collectively elect slot leaders (i.e., the tion and provide forward security, which we will elaborate
committee) for the next epoch through a MPC procedure in Section VI-E.

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1450 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

4) Snow White: Snow White was developed by Algorithm 6: BFT-Based PoS General Procedure
Daian et al. [9] in 2017. It is a PoS protocol specifi- 1 Join the network by connecting to known peers;
cally designed to accommodate the sporadic participation 2 Start BlockGen();
model in which nodes can switch online/offline arbitrarily. /* Main loop */
Similar to the committee-based PoS schemes above, Snow 3 while running do
White employs a MPC procedure to decide the block /* Block proposing & broadcast */
proposing committee, each of which is issued an eligibility 4 if BlockGen() returns block then
ticket privately. For each epoch, every stakeholder takes the 5 Add block to its tempBlockSet;
current blockchain (including staking information) as input 6 Broadcast block to the network;
and output the committee for the next epoch. Specially, Snow 7 end
White executes a modified version of the sleepy consensus /* Block validation */
protocol [102], an asynchronous consensus protocol that 8 if block is received & is valid then
ensures the consensus safety in case of sporadic participation 9 Add block to its tempBlockSet;
and committee reconfiguration. Compared to contemporary 10 Relay block to the network;
schemes such as Ouroboros, Ouroboros Praos and Algorand, 11 end
this feature enables Snow White to work under harsh network /* BFT consensus layer */
conditions with frequent disconnections and volatile message 12 if new consensus epoch then
delays. Moreover, Snow White uses a checkpointing scheme 13 Perform BlockFinBFT() on tempBlockSet;
to finalize earlier history that protects the blockchain from 14 Write the winning block to blockchain;
posterior corruption attack [97] and adaptive key selection 15 Clear tempBlockSet;
attack. 16 end
Security Analysis: In spite of having an orderly block 17 end
proposing scheme, committee-based PoS still adheres to the /* PoS-based block generation */
longest chain rule for probabilistic finality. So long as fewer 18 Function BlockGen():
than 50% stakes are held by the malicious party, the hon- 19 Elect a block proposer, whose success rate is
est parties can safely maintain the longest chain. Meanwhile, proportional to stake value;
the expansion of the committee may lead to deterioration in 20 Propose block;
network connectivity which can result in a significant drop 21 return block;
in protocol performance and desynchronization of block pro- 22 end
posal. The round-based committee election process with a /* BFT-based block finalization */
predetermined round duration (e.g., Ouroboros’ fixed timeslot) 23 Function BlockFinBFT():
also faces scalability problems, as large committee sizes may 24 Participate in a BFT consensus that finalizes one
lead to never ending consensus cycles due to the excessive winning block out of tempBlockSet;
communication overhead. To mitigate such risks, the dura- 25 return the winning block;
tion of a communication round can be extended sufficiently 26 end
to ensure that all broadcast messages are delivered before the
participants proceed to the next round. This however leads to
longer transaction conformation latency and lower throughput.
A more straightforward approach is limiting the committee Aside from the general procedure, a checkpointing mech-
size by imposing a minimum stake requirement for the com- anism can be used to seal the finality of the blockchain (not
mittee members. For example, Cardano, the cryptocurrency shown in Algorithm 6). As a result, the longest-chain rule
platform that deploys Ouroboros, mandates that every com- can be safely replaced by the most-recent-stable-checkpoint
mittee member should own no less than 2% of total tokens in rule for determining the stable main chain. Popular BFT-based
circulation. This effectively limits the committee size to 50, PoS blockchain protocols include Tendermint, Algorand, and
safeguarding an efficient consensus process. Casper FFG. DPoS protocols such as EOSIO also use BFT
consensus for block finalization within delegates.
1) Tendermint: Tendermint was developed by Kwon [12]
C. BFT-Based PoS and Buchman [103] in 2014 and currently used in Cosmos
Chain-based PoS and committee-based PoS largely follow Hub network [104]. It is the first public blockchain project
the Nakamoto consensus framework in that the longest-chain to incorporate a BFT consensus layer and takes inspiration
rule is still used to provide probabilistic finality of blocks. from the DLS protocol [28] and PBFT [27]. Tendermint works
In comparison, BFT-based PoS (or hybrid PoS-BFT) incorpo- in consensus cycles. Each cycle involves a multi-round BFT
rates an extra layer of BFT consensus that provides fast and consensus process to finalize one block. Each round con-
deterministic block finalization. Algorithm 6 shows the gen- sists of three phases: Propose, Prevote, Precommit. Specially,
eral procedure of BFT-based PoS at every participant. Block in the Propose phase a validator is designated by a deter-
proposing can be done by any PoS mechanism (round-robin, ministic algorithm as the block proposer in a round-robin
committee-based, etc.) as long as it injects a stable flow of fashion such that validators are chosen with frequency pro-
new blocks into the BFT consensus layer. portional to the value of their deposited stakes. A validator

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1451

continues iterating the three-phase rounds until one block Algorithm 7: Casper FFG
receives more than 2/3 of Precommits. The validator then 1 Deposit in the stake pool;
broadcasts Commit votes for the block and listens for other /* Main loop */
validators’ Commit votes. When a block receives more than 2 while running do
2/3 of Commit votes, it will be finalized in blockchain. As 3 (Block proposing and block validation are the same
long as more than 2/3 of validators of each round are hon- as in Algorithm 6, except that blocks are attached to
est, Tendermint can achieve consensus safety. On the other BlockTree rather than stored in a temporary set.)
hand, because Tendermint selects block proposers determinis- /* BFT consensus layer */
tically, the future block proposers are susceptible to targeted 4 if new consensus epoch then
attacks (e.g., DDoS). Tendermint addresses this risk by deploy- 5 Identify valid checkpoint blocks and attach them
ing sentry nodes which act as proxies of block proposers and to CheckPointTree;
never reveal the IP addresses of the latter [105]. Notably, 6 Participate in CheckPointVote() w.r.t.
since Tendermint decouples the PoS mechanism from the CheckPointTree, which returns CPs , CPt ;
BFT layer, a validator’s stake value does not add weight 7 Mark CPs finalized and CPt justified;
to its consensus votes. For this reason, Tendermint is often 8 end
considered an early effort on applying BFT consensus to 9 end
blockchain. /* Staked checkpoint voting */
Tendermint also features an equal-sharing-style incentive 10 Function CheckpointVote():
mechanism instead of winner-takes-all. For every block height, 11 Broadcast a vote for a source-target checkpoint pair
the block reward is distributed among the block proposer and in CheckPointTree;
validators from whom the proposer received Commit votes. 12 Check received votes against the slashing rules and
However, fairness may be impaired if Commit votes are not then evaluate them by signer’s deposited stake;
delivered in time before the next cycle, as is demonstrated by 13 if pair CPs , CPt ’s votes cover more than 2/3 of
Amoussou-Guenou et al. [106]. total deposited stakes then
2) Algorand: Algorand is a cryptocurrency system 14 return CPs , CPt ;
developed by Gilad et al. [13] at MIT CSAIL in 2017. 15 end
It employs committee-based PoS for block proposing and 16 end
Byzantine agreement for block finalization. First, similar to
Ouroboros Praos’ block proposer election mechanism, the
election of Algorand’s block proposing committee is done by
a VRF scheme called cryptographic sortition which sorts can- while strong synchrony is required for consensus liveness
didates according to the amount of coins they own. Only those when kicking off the recovery protocol for resolving forks.
with rankings above a threshold are admitted into the commit- 3) Casper FFG: Casper FFG was first envisioned by
tee for the next block cycle. Every individual user can check Zamfir [107] in 2015 and formally presented by Buterin and
privately if it is in the committee. At each user i, cryptographic Griffith [14] in 2017. It is a light-weight PoS consensus
sortition outputs an eligibility proof signed by the user’s pri- layer built on top of Ethereum’s current PoW-based block
ep
vate key σsk i
showing that it is truly a committee member. proposing mechanism (Ethash). Casper FFG slightly deviates
ep
σski is broadcast to the network along with the new block from Algorithm 6 for that it directly incorporates PoS into
proposed by user i. Upon receiving the block, other users can block finalization. Algorithm 7 shows the general procedure of
verify the proof via user i’s public key pki . Casper FFG for each validator. Newly generated and received
On top of the cryptographic sortition-based block proposing blocks are attached to the BlockTree, which is similar to the
scheme, Algorand relies on a Byzantine agreement protocol tree data structure used by the GHOST rule. The actual con-
called BA for block finalization. BA reduces the consensus sensus subject, however, is the CheckPointTree, which is a
problem to binary Byzantine agreement: either agreeing on a subtree of BlockTree. Specifically, for every consensus epoch
proposed block or an empty block. In the ideal case where (100 in BlockTree’s height or 1 in CheckPointTree’s height),
strong network synchrony is assumed, the committee follows every validator broadcasts to peers a vote for a block as the
BA to exchange votes on proposed blocks so that they will checkpoint. The height of the block in BlockTree must be divis-
decide a final block, or an empty block if no blocks pass ible by 100. The vote consists of a justified source checkpoint
the eligibility proof check. In a weakly synchronous network CPs and its height h(s), a target checkpoint CPt and its height
where block propagation and message exchange among com- h(t) (h(s) < h(t)), and the validator’s signature S. All votes are
mittee members can suffer from uncertain delays, BA outputs broadcast to the network and are weighted by the signer’s stake
tentative blocks if none of the proposed blocks can be final- value. If the source-target checkpoint pair CPs , CPt is voted
ized, which results in a fork. To resolve the forks of tentative by validators who possess more than 2/3 of total deposited
blocks, Algorand periodically runs a recovery protocol to stakes, then CPt is justified and CPs is finalized. All blocks
accept a tentative block if there is any. Specially, the recov- between CPs and CPt are finalized as well. Casper FFG relies
ery protocol needs to be invoked by a synchronized committee. on two so called Casper Commandments for ensuring consen-
Therefore, according to the authors [13], weak synchronony is sus safety: 1) validator must not cast two distinct votes for
sufficient for consensus safety during BA’s routine operation the same checkpoint height, and 2) validator must not cast a

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1452 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

new vote whose source-target span is within that of its existing

vote. Violators are subject to slashing rules including forfeit-
ing stakes and temporarily banning from staking. Since every
vote is signed with the validator’s private key and received by
peer validators, Casper FFG can conveniently detect violators
and enforce the slashing rules.
The current smart contract implementation of Casper FFG
Fig. 9. Illustration of the delegation process in DPoS. Small stakeholders
is documented in EIP 1011 [70]. A stakeholder becomes a par- vote for delegates with their stakes and the most voted delegates form the
ticipating validator by depositing a stake in the dedicated smart consensus group.
contract, which encodes Casper FFG and can be accessed via
Ethereum transactions. Notably, Casper FFG is the preamble
consensus group are also called delegates. The election of del-
project of Casper Correct-by-Construction (Casper CBC), the
egates is called the delegation process, and a general example
PoS protocol family that will be used by Ethereum 2.0 to
is shown in Fig. 9. In the actual case, the delegation pro-
complete the transition to pure PoS [108].
cess and the soliciting of votes may involve outside incentives.
To further improve performance and scalability, Ethereum
And the delegation process may turn out to be an interesting
2.0 also plans to combine PoS with sharding [109]. In a nut-
socioeconomic phenomenon.
shell, all Ethereum 2.0 participants are divided into shards.
Generally, an aspiring delegate needs to attract enough
Each shard runs a blockchain instance via a consensus scheme
votes from normal token holders. This is often accomplished
not limiting to PoS. On the top level, the main chain, known
by offering a popular application and building up reputation
as the “beacon chain”, will be maintained by a group of
through propaganda campaigns. By casting a vote to a dele-
known validators via a Casper CBC protocol. Each valida-
gate via a blockchain transaction, a token holder entrusts the
tor is randomly assigned to a shard as the shard manager and
delegate with its own stake. As a result, the delegate harvests
periodically commits a digest of the shard chain to the main
the stake voting power from her voters and acts as their proxy
chain. The parallelism of sharding and the energy efficiency
in the consensus process. A token holder can switch vote to
of PoS can theoretically scale up both transaction throughput
another delegate via a new delegation transaction. Take EOSIO
and network size. Nonetheless, the sharding scheme is still
for example, the EOSIO protocol mandates that anyone can
an ongoing work and faces several challenges before being
be a delegate and solicit votes, but only those who ascend to
harmonized with Casper CBC. They include the increased
top 21 join the consensus group, among whom the right of
take-over risk related to small shard size, the difficulty in
block proposal is equally shared. EOSIO employs a pipelined
coordinating inter-shard communication and token transfer.
PBFT-style consensus scheme to finalize the proposed blocks
Security Analysis: BFT-based PoS’s consensus fault toler-
across the 21 delegates [112]. Specially, the physical time is
ance varies among the three above-mentioned implementa-
divided into slots and the 21 delegates take turns to propose
tions. In Tendermint, although block proposers are determined
a block in a round-robin fashion. At each slot when a del-
based on PoS, all validators have the equal weight in the con-
egate proposes a block, the consensus scheme goes through
sensus process. Therefore Tendermint tolerates up to 1/3 of
pre-commitment and commitment phases and decides on the
Byzantine validators. In comparison, Algorand and Casper
fate of the proposed block. Because of the small consensus
FFG tolerate up to 1/3 of maliciously-possessed stakes. In
group size and orderly PBFT-style procedure, every new valid
Algorand, if an attacker owns more than 1/3 of total tokens,
transaction can be near-instantly propagated to the consensus
then chance is high that more than 1/3 of the elected com-
group and finalized in the blockchain.
mittee members are compromised by the attacker, leading to
To enforce transaction validation and consensus safety,
consensus failure of BA. In Casper FFG, if an attacker owns
DPoS’s incentive mechanism is designed to encourage hon-
more than 1/3 of total deposited stakes and dominates the com-
est delegation and consensus participation. Every delegate
munication within the network, the compromised validators
receives a daily vote-reward proportional to the votes she has.
can vote on conflicting checkpoints without getting punished.
Once ascending to the consensus group, delegates also receive
Since a typical BFT consensus protocol can incorporate a
block rewards for validation work.
checkpointing mechanism to ensure deterministic finality of
Security Analysis: Assuming BFT is used by the consensus
blocks, costless simulation attacks can be naturally avoided
group for block finalization, which is recommended since the
(to introduce in Section VI-E).
group size is limited, DPoS can tolerate 1/3 of delegates being
malicious. For example, EOSIO can tolerate at most 6 out of
D. Delegated PoS (DPoS) 21 delegates being malicious. In the real world they may not
wish to misbehave or collude at all, since all delegates have
DPoS can be seen as a democratic form of committee-
revealed their identities to voters and would be scrutinized for
based PoS in that the committee (consensus group) is chosen
any misconduct.
via public stake delegation. It is currently used by BitShares
2.0 (2015) [110], Lisk (2016) [111], EOSIO (2017) [10],
and Cosmos [104]. DPoS was designed to control the size E. Vulnerabilities of PoS
of the consensus group so that the messaging overhead of Although heralded as the most promising mechanism to
the consensus protocol remains manageable. Members of the replace PoW, PoS still faces several vulnerabilities.

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1453

1) Costless Simulation: Costless simulation is a major vul- rewards. If the blockchain network is not incentivized by block
nerability of non-BFT-based PoS schemes, especially chain- rewards, the attackers can still deploy a similar long-range
based PoS in which PoS is used to simulate the would-be scheme called stake-bleeding attack [116] as long as transac-
PoW process. Costless simulation literally means any player tion fees exist. That is, the attackers can accumulate significant
can simulate any segment of blockchain history at the cost amount of wealth by collecting most of historical transaction
of no real work but speculation, as PoS does not incur fees through the malicious chain. Through either scheme, once
intensive computation while the blockchain records all stak- the malicious chain overtakes the main chain, it is released to
ing history. This may give attackers shortcuts to fabricate public and becomes the new main chain.
an alternative blockchain. The four subsequent vulnerabil- While zero transaction fees can counter stake-bleeding
ities, namely nothing-at-stake, posterior corruption attack, attacks, general long-range attacks (and costless simulation
long-range attack, and stake-grinding attack are all based on as a whole) can be resolved by checkpointing, a more rad-
costless simulation. ical measure. Checkpointing is widely used in BFT protocols
2) Nothing-at-Stake: Nothing-at-stake is the first identified to ensure the finality of system agreements and safely discard
costless simulation problem that affects chain-based PoS. It older records. For permissionless blockchains (the main venue
is also known as “multi-bet” or “rational forking” problem. for chain-based PoS), however, checkpointing can undermine
Unlike a PoW miner, a PoS minter needs little extra effort decentralization, as the finality of checkpoints always requires
to validate transactions and generate blocks on multiple com- the endorsement from certain authoritative entities.
peting chains simultaneously. This “multi-bet” strategy makes 5) Stake-Grinding Attack: Generally, the block gen-
economical sense to PoS minters because by doing so they eration competition in Nakamoto-style blockchain with
can avoid the opportunity cost of sticking to any single chain. proof-of-X block proposal is a pseudo-random process that
Consequently if a significant fraction of nodes perform the a higher X (e.g., work, stake) yields a higher probability of
“multi-bet” strategy, an attacker holding far less than 50% of winning the competition. However, unlike PoW in which
tokens can mount a successful double spending attack [113]. pseudo-randomness is guaranteed by the brute-force use of
Nothing-at-stake problem can be practically solved by penal- a cryptographic hash function, PoS’s pseudo-randomness
izing whoever multi-bets, such as forfeiting part of or all their is influenced by extra blockchain information—the staking
stakes. However the penalties could still be reversed if the history. Malicious PoS minters may take advantage of costless
attacker eventually succeeds in growing a malicious chain. simulation and other staking-related mechanisms to bias the
3) Posterior Corruption: Dubbed by Bentov et al. [97] as randomness of PoS in their own favor, thus achieving higher
“bribing attack” in 2014, posterior corruption is another attack winning probabilities compared to their stake amounts [8].
utilizing costless simulation against PoS. The key enabler of For example, in chain-based PoS blockchains such Peercoin,
posterior corruption is the public availability of staking his- at a certain historical point of the blockchain, attackers
tory on the blockchain, which includes stakeholder addresses may iterate through different block headers and increase the
and staking amounts. An attacker can attempt to corrupt the probability of generating a valid block with their stakes [117].
stakeholders who once possessed substantial stakes but little at For committee-based and BFT-based PoS schemes that
present by promising them rewards after growing an alternative decouple the election of block proposers from block genera-
chain with altered transaction history (we call it a “malicious tion, stake-grinding attacks can be mitigated by ensuring the
chain”). When there are enough stakeholders corrupted, the PoS pseudo-randomness with a secure block proposer elec-
colluding group (attacker and corrupted once-rich stakehold- tion scheme that involves minimal local information.
ers) could own a significant portion of tokens (possibly more Examples include Ouroboros, Ouroboros Praos, and
than 50%) at some point in history, from which they are able Algorand.
to grow an malicious chain that will eventually surpass the 6) Centralization Risk: PoS faces a similar wealth central-
current main chain. Since posterior corruption is only possi- ization risk as with PoW. In PoS the minters can lawfully
ble because the private/public keys are fixed for blockchain reinvest their profits into staking perpetually, which allows
participants, key-evolving cryptography (KEC) [114] can be the one with a large sum of unused tokens become wealth-
applied so that the past signatures cannot be forged by the ier and eventually reach a monopoly status. When a player
future private keys. Ouroboros Praos [101] currently adopts owns more than 50% of tokens in circulation, the consen-
KEC for this purpose. Alternatively, as is in Snow White [9] sus process will be dominated by this player and the system
and Casper FFG [14], checkpointing can be used to finalize integrity will not be guaranteed. Take Ethereum’s Casper FFG
the ledger and eliminate the possibility of posterior corruption. for example, the proposed PoS scheme is built upon the cur-
4) Long-Range Attack: Coined by the Ethereum founder rent PoW system, of which the cryptocurrency ethers can be
Buterin [115], long-range attack can be viewed as the ulti- directly used for staking. This gives initial advantages to those
mate form of costless simulation. It foresees that a small group who have already accumulated huge wealth during Ethereum’s
of colluding attackers can regrow a longer valid chain that PoW operation. Potential countermeasures against monopo-
starts not long after the genesis block. Because there were lization in PoS mainly come from the incentive mechanism
likely only a few stakeholders and a lack of competition at and economic perspective. In addition to the stake valuation
the nascent stage of the blockchain, the attackers can grow scheme that improves the winning chances of small stake-
the malicious chain very fast and redo all the PoS blocks (i.e., holders (see Section VI-A), we can use off-chain factors to
by costless simulation) while claiming all the historical block complicate the staking process (EOSIO for example) and

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1454 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

impose taxation on the blocks generated by large stakeholders, out in a trusted execution environment (TEE), which is an iso-
to name a few. lated memory area that provides integrity and confidentiality
to the program running inside, against a compromised hosting
platform. Specially, the program enclosed in a TEE is called
VII. OTHER E MERGING B LOCKCHAIN C ONSENSUS
an “enclave”. Intel SGX [120] and Arm TrustZone [121] are
M ECHANISMS AND P ROTOCOLS
the two major TEE solutions. Among other utilities, TEE pro-
The majority of contemporary blockchain consensus proto- vides an integrity proof of enclave program through remote
cols make use of established schemes including PoW, PoS, attestation, which essentially helps the network establish trust
and BFT. There are numerous other promising proposals for on consensus participants.
specific application scenarios, many of which are still con- Taking Hyperledger Sawtooth for example, the PoET pro-
ceptual and cover just one or two of the five blockchain tocol works in two phases for every participating node i:
consensus protocol components. In this section we present five 1) TEE setup: Node i first obtains the PoET protocol
of such proposals, namely proof of authority (PoA), proof program from a trusted source and instantiates the pro-
of elapsed time (PoET), proof of TEE-stake (PoTS), proof gram on its SGX machine wherein the random back-off
of retrievability (PoR), Ripple consensus protocol/algorithm routine runs inside an enclave. The trusted program gen-
(RCPA). A comprehensive review of two types of DAG- erates a signing key pair PKi , SKi for node i and
based protocols, namely blockDAG and txDAG, are also starts the attestation process which results in sending an
provided. attestation report to the network. The attestation report
contains the public key PKi and the enclave measure-
A. Proof of Authority (PoA) ment signed by the Intel Enhanced Privacy Identification
Proof of authority was coined by Ethereum co-founder (EPID) private key inside the enclave. Other nodes in the
Gavin Wood as an alternative to PoW and PoS. It is cur- network will validate the node i’s hardware authenticity
rently deployed in Ethereum’s Rinkeby (2017) and Kovan through Intel Attestation Service (IAS) and validate the
(2017) testnet, and POA Network (2018) [11]. In a nut- attestation report before accepting node i.
shell, PoA is a special case of PoS in that a validator stakes 2) Participating in consensus: The consensus process is
with its identity instead of monetary tokens. To qualify as a similar to Nakamoto except for block generation and val-
PoA validator in the consensus group, a participant needs to idation. For each block cycle, node i waits for a period
go through a mandatory certification process to build up its dictated by the random back-off routine running in the
authority. It generally involves having the unique identity ver- enclave before producing a new block. The enclave then
ified, demonstrating the ability to contribute consistently to generates a certificate of back-off completion signed
the consensus, and making all certification documents pub- by node i’s private key SKi which is broadcast to the
licly available. The consensus group should be stable and network along with the new block. Upon receipt of the
small in size, and publicly scrutinized so that users can entrust new block, other nodes validate the block content and
the consensus group for reliable transaction processing and the back-off completion certificate with node i’s public
blockchain curation. If a validator shows incompetence in such key PKi . A block shall be appended to the blockchain
tasks or misbehaves, it will be discredited by users and peer if it passes validation and the finalization rule.
validators. While PoET was initially proposed to substitute the PoW
Security Analysis: The fault tolerance of a PoA blockchain for block proposal without touching on the longest-chain rule,
depends on the consensus protocol used by the consen- the usage of hardware-assisted public key cryptography actu-
sus group. Besides BFT protocols with 1/3 fault toler- ally enables the use of more efficient BFT algorithms for
ance threshold, Nakamoto-style protocols such as Parity’s block finalization. A hybrid PoET-BFT scheme is currently
AuthorityRound (AuRa) [118] can also be used to tolerate used by Sawtooth PBFT [122], a sub-project of Hyperledger
up to 50% of colluding validators. Featured by its small Sawtooth.
but trusted consensus group, PoA is a good example of Security Analysis: PoET can tolerate up to 50% TEE nodes
trading decentralization for security and performance. To being malicious. Since every TEE node runs the same ran-
prevent validators from collusion, they are required to operate dom back-off routine in its enclave, a player can shorten
independently and constantly monitored by users. its expected back-off time by running multiple TEE nodes,
which is susceptible to Sybil attacks. If more than 50% of
TEE devices collude or are controlled by an attacker, they can
B. Proof of Elapsed Time (PoET) ultimately win the block race and keep extending the mali-
PoET was proposed by Intel as an alternative mining mech- cious chain. Therefore, PoET is most suited for permissioned
anism in 2016 and subsequently used in the Hyperledger blockchains, where every participant is authenticated and runs
Sawtooth family [119]. Instead of undergoing the hashing- one TEE node.
intensive mining, PoET simulates the time that would be For Hyperledger Sawtooth, Intel is the sole TEE hard-
consumed by PoW mining. That is, every node randomly ware vendor and attestation service provider, which poses a
backs off for an exponentially distributed period of time before single point of risk to the network. The validity of remote
announcing its block. To ensure that the local time truly attestation depends on the integrity of SGX implementation
elapses, PoET requires the back-off mechanism to be carried and the availability of IAS. Recent attacks such as cache

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1455

attacks [123], Foreshadow [124] and Foreshadow-NG [125] Participants with more segments stored have higher probability
have demonstrated the ability to extract the EPID private of winning the lottery and thus being eligible to generate a
key from hardware exploiting side channels and speculative block. All PoR challenges are stored in the new block and
execution, posing a security threat at the hardware level. verified by the whole network. Permacoin also implements a
signature scheme to discourage participants from outsourcing
C. Proof of TEE-Stake (PoTS) the storage task. Aside from PoR, Permacoin inherits Bitcoin
for other consensus components.
PoTS is another protocol harmonizing TEE and blockchain
Compared to PoW, PoR has two economical advantages.
consensus. It was first proposed by Li et al. [126] in 2016
First, file storage consumes far less energy than brute-force
and formalized by Andreina et al. [127] in 2019. A PoTS
mining, and storage space as a resource can be recycled.
node i follows the same setup procedure as in PoET to boot-
Second, PoR can be repurposed for meaningful storage tasks.
strap a TEE enclave, generate the signing key pair SKi , PKi ,
For example the target dataset can be some extremely large
and attest the setup to the network. Instead of simulating the
but useful public dataset. In fact, the latter advantage is not
would-be elapsed time of PoW mining, the enclave program
seen in any other proof-of-X schemes.
of PoTS is akin to Algorand’s cryptographic sortition scheme
Security Analysis: Since the block winning rate of a par-
that randomly selects a committee according to the stake dis-
ticipant is proportional to its local storage space, PoR can
tribution. Every node in the committee is eligible to propose
tolerate up to 50% of gross storage being held up by the
a new block for the coming block cycle. To prove the block
malicious party. Although this still can trigger an arm race
proposal eligibility to the network, the block includes the eligi-
ep of storage resources, it downplays the efficacy of ASICs and
bility proof signature σSK , which is produced by the enclave
i encourages a wider variety of mining participants. Meanwhile,
program of the block generating node i. Once other nodes
the 50% threshold depends on the randomness of the central
receive this block, they validate the block content as well as
ep dealer’s job. To ensure the diversity of lottery tickets across
signature σSK using node i’s public key PKi . The longest-
i all participants and increase the randomness of the lottery,
chain rule is then used to determine whether to accept this
the target dataset should be large enough so that participants
block into the blockchain.
stores almost non-overlapping segments. This assumption can
Security Analysis: PoTS can tolerate up to 50% of all
be undermined if the dealer chooses a dataset not large enough
stake value at TEE nodes being maliciously controlled, the
or deliberately distributes overlapping segments.
same as the fault tolerance of chain-based or committee based
PoS. Compared to PoET, the incorporation of staking gives
PoTS higher robustness against Sybil attacks, which implies E. Ripple Consensus Protocol/Algorithm (RCPA)
its applicability to permissionless blockchains. Furthermore,
RCPA was proposed by Schwartz et al. [130] in 2014 as
the security offered by public key cryptography and TEE-
the underlying protocol for Ripple, a global payment and gross
certified execution of committee selection helps PoTS counter
settlement network operated by the Ripple company. Unlike
the stake-bleeding and stake-grinding attack. The single point
public blockchains such as Bitcoin and Ethereum, Ripple treats
of risk in TEE hardware vendor still exists.
individual transactions as the ledger’s atomic items, similar to
a transaction log.
D. Proof of Retrievability (PoR) In Ripple network, only validator nodes can participate in
PoR was originally proposed by Juels and Kaliski, Jr., [128] consensus. We call a validator node “node” for simplicity.
in 2007 as a cryptographic building block for a semi-trusted Nodes collect transactions from clients and propose them to
distributed archiving system. The core feature of PoR is to peer nodes for consensus. In initialization, every node estab-
allow a file owner to check if its online files or file frag- lishes a unique node list (UNL) which identifies the nodes it
ments are securely stored and retrievable through a challenge- can trust and directly exchange messages with. A UNL rela-
response protocol. The retrievability of a target file F at a tionship is reciprocal. We call a group of nodes that are fully
remote node ni can prove ni indeed spends the required connected by UNL relationships a UNL clique.
amount of storage resources on F. Because of the space The operation of RCPA at one node is shown in
requirement behind retrievability, PoR is also known as proof Algorithm 8. RCPA runs in epochs, each of which finalizes a
of space. certain set of transactions into the ledger. Every epoch involves
In the role of a consensus protocol, PoR was first used by multiple rounds of transaction filtering. The ledger is marked
the cryptocurrency Permacoin, proposed by Miller et al. [129] “closed” after the final round. Specially, the yes-vote threshold
in 2014. It was designed as a mining-free alternative to PoW. of the final round THMaxRound = 80%, which is designed to
First, a central dealer publishes a target dataset F and computes cope with the network connectivity assumption that any two
the digest of F (the Merkle hash tree root of all segments of UNL cliques UNLi , UNLj must be at least 20% overlapped,
F). Then each participant stores some random segments of F i.e., sharing at least 15 max(|UNLi |, |UNLj |) inter-clique UNL
per its storage capability, and computes the digest of these relationships. In an ideal environment, as long as MaxRound
segments. For every block cycle, the dealer initiates a lottery is large enough, all valid transactions proposed by non-faulty
game with a random puzzle. Then every participant derives a nodes should eventually surpass the 80% yes-vote threshold.
lottery ticket consisting of a fixed number of PoR challenges Security Analysis: RCPA imitates a relaxed DLS protocol
from its locally stored segments, public key, and the puzzle. with an artificial BFT bound of 1/5. It further requires no more

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1456 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

Algorithm 8: RPCA (validator Node) this subsection we focus on blockDAG and defer the latter
1 Joining Ripple network as a validator; type to the next subsection.
/* Main loop In a blockDAG, every vertex contains a collection of trans-
*/
2 for new epoch do actions which is similar to the block concept in blockchain.
3 Collect valid transactions (new or leftover from What sets blockDAG apart from blockchain is that every
previous epochs) ⇒ CandidateSet; block can be hash-pointed to multiple parent blocks. This
4 for r = 1 → MaxRound do leads to a situation that every new block can be appended
5 Broadcast CandidateSet to UNL peers; to the DAG with considerable flexibility on how many and
6 After receiving transactions from UNL peers, add which parents to point to. This parent-selecting conundrum is
them to CandidateSet and broadcast a vote on commonly regarded as the major challenge for DAG-based
the veracity (yes/no) of every transaction; consensus schemes and pertains to the system’s transac-
7 After receiving votes from UNL peers, discard tion processing capability and security against Sybil and
transactions from CandidateSet whose double-spending attacks. Next we introduce two concurrently
yes-votes fall short of a threshold THr proposed blockDAG schemes, SPECTRE and PHANTOM,
(THMaxRound = 80%); with a focus on the parent-selection mechanism.
8 end 1) SPECTRE: Proposed by Sompolinsky et al. [133]
9 The remaining transactions in CandidateSet are in 2016, SPECTRE is one of the first well-documented
accepted into the ledger; blockDAG proposals. SPECTRE requires any node who wants
10 end to mine a new block to find all blocks of zero in-degree (i.e.,
“tips”) in the DAG and hash-point the new block header to
these tips before starting the PoW mining for the new block.
The node broadcasts the newly mined block to the network.
than 1/5 of nodes are faulty in every UNL clique in order to Every node initiates a recursive voting procedure to determine
ensure overall network consensus. Compared to PBFT that the order of any two blocks in the current DAG. This recur-
achieves 1/3 Byzantine fault tolerance with O(N 2 ) message sive procedure eventually results in a pairwise ordering over
complexity in a fully connected network, RPCA’s 1/5 fault the blockDAG. Every new block should be incremental to the
tolerance bound trades for a lower connectivity requirement past pairwise ordering effort. This pairwise ordering scheme
and thus lower message complexity per block cycle, which is essentially allows SPECTRE to decide between two conflict-
O(MK 2 ) = O(NK ) where K is the clique size and M = N/K ing blocks (i.e., containing transactions that spend the same
is the number of cliques. Therefore Ripple demonstrates the UXTO).
possibility of trading fault tolerance for better performance 2) PHANTOM: PHANTOM [134] is a concurrent
when a certain level of trust is assumed. On the down side, blockDAG proposal of SPECTRE by the same authors. One
RCPA’s multi-round broadcast scheme among a UNL clique notable weakness of SPECTRE is that the pairwise ordering
and the quick convergence of votes require high synchrony of blocks may not extend to a fully linear ordering. This leads
among clique members. This impairs Ripple’s decentralization to SPECTRE’s weak liveness (i.e., only supports naturally
capability in practical settings. chronological transactions) and an increased risk of balancing
Ripple’s current customers are primarily established corpo- attacks in that conflicts may not be solved. In contrast,
rations and financial institutions. Possible reasons include the PHANTOM realizes fully linear ordering of transactions and
above-mentioned synchrony requirement and that the 1/5 fault blocks in the DAG via the following algorithm. Every node
tolerance can be too restrictive for low-trust environments. searches the blockDAG for the largest k-cluster of blocks. k
Interestingly, Stellar [131], originally a fork project of the denotes the node degree in the cluster, and is a predefined
Ripple, has shifted to federated Byzantine quorum systems security parameter that rarely k or more honest blocks are
(FBQS) for a loose synchrony requirement on participants and created simultaneously. The k-cluster is regarded as honest
achieves the 1/3 BFT bound [132]. and all blocks within are linearly ordered. The transactions
covered by the cluster are then validated in the new order.
Notably, the largest 0-cluster case is equivalent to the
F. BlockDAG-Based Consensus Protocols longest-chain rule of Nakamoto consensus. The authors also
Starting from 2016 there have been increasing interests in argues that PHANTOM can be utilized alongside SPECTRE
non-linear ledger structures for the aim of better performance, for more flexible consensus performance, as the two ordering
among which directed acyclic graph (DAG) has received the schemes are complimentary to each other.
most attention. Consensus schemes with DAG ledger structure Security Analysis: Though with an innovative blockDAG
mark a significant divergence from Nakamoto’s blockchain ledger structure and a carefully designed ordering scheme
design. Their key insight is that transaction throughput should for finality, SPECTRE and PHANTOM inherit other proto-
not be limited by a restrictive consensus object, such as a col components from Nakamoto’s, including PoW-based block
linearly growing chain of blocks with fixed time intervals. proposal, gossip-based information propagation, validity check
Instead, the influx of transactions should drive the ledger on PoW and transactions. Therefore, the two blockDAG based
expansion. There are two types of DAG ledgers: block-based schemes can tolerate up to 50% of maliciously controlled
DAG (blockDAG) and transaction-based DAG (txDAG). In computing power. On the performance side, blockDAG-based

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1457

Tangle does not reward block miners with cryptocurrency nor

charge transaction fees.
When multiple conflicting tips (i.e., double-spending) are
detected by a user, only one can be valid. In this case the user
resorts to a tip-selection scheme to choose one that yields the
highest acceptance probability in the long term. Other conflict-
ing tips are considered invalid and then orphaned. Tangle cur-
rently employs a Markov-chain Monte Carlo (MCMC) based
Fig. 10. An example of IOTA Tangle’s DAG structure. Every new transaction scheme to estimate the long-term acceptance probabilities of
(hollow green) needs to approve two unapproved transactions (“tips”, hollow conflicting tips.
blue) and becomes a new tip. If only one tip is available, choose an approved When there are more than two non-conflicting tips available
transaction for the other. The arrow direction symbolizes a user’s tip selection
behavior. (i.e., multiple valid choices), the user chooses two tips accord-
ing to a weight based strategy, which works as follows. Every
transaction is assigned an initial weight, which is proportional
(discrete values) to the PoW effort spent on this transaction.
schemes can theoretically support arbitrary throughput capac-
The user chooses two tips with the highest weights. If the
ity, only to be capped by network bandwidth and nodes’ pro-
user only possesses a subgraph of the DAG, it performs two
cessing speed. On the downside, the increased parent-selection
weighted random walks from the beginning of the subgraph to
flexibility may expose more attack surfaces to adaptive attack-
decide two tip choices [136]. The weights of a tip transaction
ers (such as the balancing attack against SPECTRE), which is
and its preceding transactions along the lineage of approvals
still an ongoing research topic. Alternatively, BlockDAG can
in the DAG shall accumulate by the weight of the approving
be designed to incorporate a specific blockchain as a main
transaction. As a result, as time passes the DAG ledger will
chain, reflecting a similar idea as the GHOST rule. Conflux,
look like a cascade of transactions that advances toward the
a blockDAG scheme recently proposed by Li et al. [86],
direction of the highest accumulative weight. The MCMC-
resorts to the GHOST rule for the finalization of a pivot chain,
based scheme, the highest-accumulated-weight strategy, and
which is used as the reference for partitioning the blockDAG
the weighted random walk algorithm can be regarded as the
into chronological order. This scheme yields high transaction
DAG version of longest-chain rule, and essentially contribute
throughput but also higher confirmation latency.
to Tangle’s tamper-resistance and probabilistic finality.
Theoretically, Tangle’s DAG data structure can boost IOTA’s
transaction capacity to millions per second, or unbounded.
G. TxDAG-Based Consensus Protocols This is due to the DAG’s native support for branches: when
Compared to blockDAG, txDAG further breaks the shackles multiple valid tips are present, a new transaction just chooses
of block. Since different blocks in a blockDAG can still hold two to approve, while leaving the remaining tips to other
overlapped transactions, it takes extra bandwidth and process- new transactions. As a result, the more new transactions are
ing power to solve conflicts. In txDAG, every vertex represents generated, the more likely a tip gets approved, which can
a unique transaction and diverging branches from a vertex shall accommodate more new transactions. In practice, Tangle’s
hold disjoint transactions. This conveniently avoids the con- transaction capacity is still capped by link-/physical-layer
flict resolution effort as in blockDAG and effectively frees up communication bandwidth.
more processing power at each node and allows for higher 2) Byteball: Byteball was proposed by Churyumov [137] in
transaction throughput, only to be capped by network band- 2016 and currently used in the Obyte cryptocurrency. Byteball
width. On the other hand, the blockless design of txDAG also features three major differences from Tangle: arbitrary tip
leads to more challenges especially regarding to the conver- number, a main chain (MC) for tip selection, a fixed wit-
gence and effective management of ledger. Next we introduce ness group for DAG consensus and finalization. Every vertex
three txDAG schemes: IOTA Tangle, Byteball, and Nano. v is assigned a main chain index (MCI), which refers to the
1) IOTA Tangle: IOTA is a blockchain initiative designed height of the closest MC vertex that has a directed path to
for machine-to-machine micro payments in the IoT setting. v. Whenever a node wants to attach a new transaction to a
Tangle, its underlying consensus protocol, was formalized by tip, the tip should be chosen based on its validity and MCI.
Popov [135] in 2016. An example of Tangle’s DAG is shown in Meanwhile, the MC is determined by the collective effort of
Fig. 10. To append a new transaction to the DAG, a user needs the witness group and the network. Byteball’s witness group
to approve (i.e., validate) two unapproved transactions (tips) of consisting of 12 reputable entities decides the next vertex of
the DAG in order to submit a new transaction. If there is only MC. The participation of witnesses in the blockDAG helps
one tip available, the user chooses an approved transaction assign a witness level to any candidate vertex. The one with
instead. The user attaches the hashes of the two chosen trans- the higher witness index is attached to MC.
actions to the new transaction and works on a PoW puzzle. The To mitigate Sybil attacks and spams, Byteball collects a
proof is broadcast along with the new transaction. Therefore, storage fee for every byte of transaction content (both header
every vertex in the DAG has an out-degree of two and contains and payload) recorded in the txDAG. These fees, also known
a PoW proof. The two-tip rule also serves as the incentive as commissions, are paid to witnesses for their honest contri-
mechanism for honest participation. For this reason, IOTA bution. Therefore, the witnesses are essentially the consensus

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1458 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

participants that work towards Byteball’s operation safety. VIII. C OMPARISON AND D ISCUSSION
Their revealed identities and small population contributes Tables III, IV compare the protocols that we have discussed
to deterministic finality and efficient consensus, but also an so far from three aspects: five-component framework compo-
increased risk of targeted DoS attack. sition, fault tolerance, and transaction processing capability.
3) Nano: Nano was proposed by LeMahieu in 2014, for- The latter includes maximum throughput and transaction con-
mally presented in 2018 [138], and is currently used by the firmation latency. For some consensus protocols, not all the
namesake cryptocurrency. Compared to Tangle and Byteball’s five components are specified in the white paper. Protocols
txDAG ledger, Nano has a more refined ledger structure which designed for permissioned blockchains (e.g., BFT-SMR, PoET,
is built upon parallel blockchains. Nano’s txDAG can be char- PoTS) often do not specify incentive mechanism; proto-
acterized as a block-lattice structure. Every node runs a local cols that were initially proposed to substitute PoW (e.g.,
blockchain that is not entangled with the others. Notably, PoA, PoET, PoR) inherit other components from Nakamoto’s
we call it “blockchain” for the consistency with the whitepa- protocol by default.
per [138], though every block is actually a single transaction. The fault tolerance capability of a consensus protocol
A normal transaction is fulfilled by two transactions: a send largely depends on the block finalization mechanism. For
transaction at the sender’s blockchain and a receive transaction example, the 50% bound (of computing power or stake value)
at the receiver’s blockchain. PoW is attached to transactions applies to all protocols that inherit the probabilistic finality
for anti-spamming. When an account is detected double- property from Bitcoin; protocols with BFT-style block final-
spending a transaction received by another node (i.e., a fork), ization typically achieve 33% fault tolerance and guarantee
the receiver initiates a voting procedure wherein each vote is deterministic finality. In hybrid schemes, the 33% fault toler-
weighted by the voter’s account balance (i.e., stake). ance is usually coupled with the block proposal mechanism or
A key insight of Nano’s block-lattice based txDAG is that a preexisting identity scheme. In Hybrid PoW-BFT and BFT-
forks and other faulty transactions only affect the accounts ref- based PoS, each node’s voting weight in the BFT consensus
erenced in the said transactions. In other words, the resolution stage is augmented by its block proposing capability. This is
of forks does not hamper the processing of transactions from achieved by either linking a player’s opportunity of partic-
unaffected accounts. This property allows Nano to provide sta- ipation in BFT consensus to the PoX process (e.g., Hybrid
ble and fast transaction confirmation. On the downside, the PoW-BFT, Tendermint), or directly weighting a player’s vote
stake-weighted voting scheme requires high synchrony among in the BFT consensus by the player’s stake value (e.g.,
nodes and may not scale well in network size. Algorand, Casper FFG). In other hybrid schemes such as PoA-
Security Analysis: For Tangle, since PoW is enforced for BFT and PoET-BFT, the PoX process is purposed for identity
transaction generation, probabilistic finality is guaranteed as management and thus the fault tolerance threshold is 33% of
long as the honest nodes control more than 50% of gross identities. DAG-based protocols generally achieves probabilis-
computing power. Byteball’s consensus safety relies on the tic finality (except Byteball) and 50% fault tolerance of either
majority consensus of the 12 witnesses. Since Nano resorts to computing power, consensus participants, or token wealth.
a stake-weighted scheme for fork resolution, its fault tolerance The statistics on transaction processing capability were
is capped by 50% of tokens. In terms of network decentral- fetched from either the simulation result in protocol white
ization, we consider Tangle the most desirable design among paper or documented experiment. The throughput metric mea-
the three txDAG schemes because it does not require a dedi- sures the maximum TPS a protocol can handle, and is only
cated identified group or a synchronized voting mechanism to precise to the scale of magnitude, i.e., sub-ten, tens, hundreds,
ensure consensus finality. Nonetheless, the current version of or thousands. The confirmation latency metric estimates time
Tangle’s MCMC-based tip-selection is susceptible to parasite for a submitted transaction to be finalized in the blockchain.
chain attack, as is documented in [135]. An attacker can grow We observe that protocols with probabilistic finality tend
a parallel chain from some early point all the way to the cur- to have higher confirmation latency (typically more than 1
rent DAG height, with intermittent connections to the DAG. minute), and high throughput is often accompanied by low
An attacker may need significantly less than 50% of network confirmation latency.
computing power to succeed, as the malicious chain may carry We are also interested in another performance metric—
far fewer transactions than the main DAG. To address this scalability in network size, which measures how well a
issue, Tangle currently relies on a centralized checkpointing consensus protocol can maintain its transaction capacity when
scheme to periodically confirm past transactions. The IOTA network size grows. Given the difficulty of performing large-
community plans to improve the MCMC-based tip-selection scale experiments on actual blockchain networks, the scala-
scheme in hope of obtaining the 50% fault tolerance in a truly bility results are either fetched from the simulation study in
decentralized fashion. protocol white paper or based on our speculation on the current
Snowflake-Avalanche [139], a consensus protocol family network status. It is worth noting that transaction through-
proposed by Cornell Team Rocket, provides an alternative put and scalability in network size are often recognized as
to Tangle’s tip selection problem. Specially, the txDAG-based two integral parts in scalability evaluation of a blockchain
Avalanche protocol builds upon a hierarchy of leaderless BFT system [3], [18], [140].
schemes, namely Snowflake and Snowball, for conflict resolu- Fig. 11 illustrates performance of consensus protocols with
tion during parent transaction selection. Interested readers are respect to transaction throughput and scalability in network
referred to the whitepaper [139] for more details. size along with suitability for permissioned or permissionless

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1459

TABLE III
A C OMPARISON OF B LOCKCHAIN C ONSENSUS P ROTOCOLS

blockchains. For protocols with BFT-style block finalization mechanism that only achieves probabilistic finality. Their
mechanism to achieve thousands of TPS, the network size transaction throughput is usually capped by a hundred TPS
should be small, typically around several hundred. Meanwhile, for security reasons. Generally, protocols illustrated farther
protocols that work for large-scale public networks are pre- to the top right in Fig. 11 tend to achieve better overall
dominantly permissionless and employ a block finalization performance and scalability. However the security implication

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1460 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

TABLE IV
A C OMPARISON OF DAG-BASED C ONSENSUS P ROTOCOLS

PoW-BFT, committee-based PoS are designed for permis-

sionless scenarios but rely on an election mechanism for
maintaining a stable consensus group, of which the identities
may be revealed for public supervision. DAG-based protocols
are designed with the aim of scaling up in participant count
and thus suited for permissionless networks.

IX. O N D ESIGNING B LOCKCHAIN C ONSENSUS P ROTOCOL

The rich variety of blockchain initiatives often confounds
novice protocol designers. In this section we offer a suc-
cinct tutorial that hopefully helps protocol designers form
reasonable objectives and avoid pitfalls.

A. The Paradigm Shift in Protocol Design

In the early days of blockchain development, consensus pro-
Fig. 11. Comparing different blockchain consensus protocols on transaction tocol designs were often coupled with designer’s ingenuity and
throughput and scalability in network size. Note that for comparison purposes, heuristics. Anticipating that the increasing number of partic-
we consider DAG-based schemes as wide-sense blockchain protocols.
ipants would lead to more block contentions and blockchain
forks in Bitcoin, Nakamoto designated the longest-chain rule
for block finalization and cautiously fixed the average block
of such superiority, exemplified by Bitcoin-NG and DAG- interval to ten minutes for consensus security [1]. Litecoin [72]
based protocols, is subject to constant scepticism and attracts and Ethereum [71] adopted shorter block intervals for faster
ongoing research effort. transaction settlement. Observing the energy inefficiency of
As for the suitability for permissioned or permission- Bitcoin and the financial value of unused tokens, Peercoin
less blockchains, we stress that protocols that need a stable pioneered the PoS mechanism which could substitute PoW
consensus group with participation control and identifica- with far less energy consumption [6]. Yet its stake valu-
tion are suitable for permissioned blockchains. These proto- ation scheme seemed to be heuristically designed. These
cols include PBFT, HoneyBadgerBFT, PoET-BFT, PoA-BFT, early-day initiatives also commonly lacked sufficient secu-
and RPCA. In comparison, protocols including Nakamoto, rity analysis, which were often scrutinized by researchers and
Nakamoto-GHOST, chain-based PoS, Bitcoin-NG, Algorand, practitioners [74], [79], [96].
and Tangle are specifically designed for large-scale permis- Later blockchain consensus protocols, especially those
sionless blockchains. Meanwhile DPoS, Tendermint, hybrid proposed after 2016, have started to take inspirations from the

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1461

established research of distributed computing, cryptography,

and trusted computing. For example, HoneyBadgerBFT [16],
BEAT [17], Algorand [13] extend reliable broadcast and
Byzantine agreement to blockchain scenarios. Committee-
based PoS protocols, such as Ouroboros [8], Snow White [9],
Bentov’s CoA [100], make use of MPC for the management
of consensus committee and block proposal. PoET [119] and
PoTS [127] leverage trusted execution environment (TEE) for
secure block proposal and mining substitution. Furthermore,
some proposals incorporate innovative cryptographic primi-
tives for enhancing privacy of network participants. Zero-
knowledge proof (ZKP) and ring signatures are used by
Zerocash [141] and Monero [142] to construct privacy-
preserving transactions that hide essential transaction val-
ues and sender-receiver addresses; Algorand and Ouroboros Fig. 12. Illustration of the security-decentralization-scalability trilemma.
Praos [101] use cryptographic sortition and VRF for the
PoS-based election of consensus committee without revealing
participant’s stake value. The privacy of consensus partici-
pants in large-scale permissionless blockchains is still a fresh that use Nakamoto consensus, the probabilistic finality and
research topic. mandatory multi-block confirmation give rise to permission-
Besides increased sophistication in design, new protocol less access and higher scalability in network size. Meanwhile,
proposals are often accompanied by formal security anal- a shorter block interval yields higher transaction throughput
ysis, via security frameworks such as the random oracle but also leads to higher risk of 51%-attack [73]. For DAG-
model [143] and universal composibility [144]. In summary, based protocols, the security implications associated with their
This paradigm shift has brought the design and analysis of scalability with both network size and throughput are not well
blockchain consensus protocols into formal scientific research, studied and remain an ongoing research.
echoing Cachin and Vukolić [19] that blockchain design A protocol designer should anticipate the security impli-
should follow the rigor established by prevailing wisdom. cations of a blockchain network’s decentralization profile. A
more decentralized network tends to be less synchronized,
owing to the increased diversity of geographic locations and
B. The Security–Decentralization–Scalability Trilemma sparsity of connections. On one hand, the increased geographic
Observing the existence of various blockchain consensus diversity makes censorship by one suppressing regime more
protocols, we stress that the design of consensus protocol challenging, which enhances the system’s liveness. On the
should seek a balance between three objectives: security, other hand, the reduced synchrony implies that inter-player
decentralization, and scalability. communications are less bounded by delay requirements. This
• Security: refers to the blockchain’s consensus security contributes to the heterogeneity of network connections and
in the presence of malicious players and anti-censorship allows better connected players to gain unfair advantages,
capability. The two concepts correspond to the safety and which potentially impairs consensus security of the network.
liveness property in classical distributed consensus. Take protocols with the gossiping rule and longest-chain rule
• Decentralization: refers to the decentralization profile for example, the heterogeneity of network connections gives
of the blockchain network, which is normally associ- well-connected nodes a communication advantage of dissemi-
ated with geographic diversity, connectivity pattern, and nating new blocks faster in the network than the less-connected
synchrony of networked nodes. ones, effectively enhancing the former’s winning chance in
• Scalability: means two-fold: the system needs to remain blockchain fork races. As a result, in a sparsely connected
secure and efficient with rising transaction throughput as network with one well-connected adversary, the adversary may
well as larger network size. Scalability is often considered need significantly less than 50% of mining power to commit
as a broader concept of system performance. a double-spending attack.
Fig. 12 sketches the relationships and trade-offs between the Last but not least, a protocol designer should be aware that
three objectives. the tradeoff between decentralization and scalability depends
For most blockchain consensus protocols especially those on the practical needs. For example, Bitcoin was designed
tailored for financial application, security is always the top to operate in a weakly synchronized network and there is
priority. Meanwhile, security level can be practically traded no enforceable criterion for message delivery and timeout.
for system’s scalability. Lower security requirement gives rise As a result Nakamoto consensus protocol needs to rely on
to more scalable protocol design. For classical BFT protocols, best-effort mining and long block intervals to achieve the
lower fault tolerance threshold (the “f ” parameter) leads to security against double spending, at the price of low trans-
fewer consensus rounds [25], [55] or less communication per action throughput. In comparison, BFT-based protocols are
round [27], effectively alleviating message complexity caused designed for permissioned networks where every participant
by large network sizes. For many public blockchain networks operates with revealed identity and the overall network is

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1462 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

small and well-connected and with enforceable time-out mech- performance analyses, and discussion on protocol design pro-
anisms. This enables the network to achieve higher transaction vided in this survey can help researchers and developers
throughput. On the flip side, the high dependence on network grasp the fundamentals of blockchain consensus protocols and
connectivity and synchony for throughput brings high mes- facilitate future protocol design.
saging complexity and network management overhead. When
the network grows in size and inevitably becomes sparse, ACKNOWLEDGMENT
message relaying can be a major burden for each participant The authors would like to thank Dr. Christian Cachin, Dr.
which potentially leads to jammed communication channel and Yonggang Wen for their constructive comments on this paper.
stalled consensus process. Therefore, we argue that under a
certain security premise, increased need for network connec- R EFERENCES
tivity and synchrony leads to higher transaction throughput but
[1] S. Nakamoto. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
lower scalability with network size. Accessed: Apr. 7, 2019. [Online]. Available: https://bitcoin.org/bitcoin.
pdf
[2] Global Bitcoin Nodes Distribution. Accessed: Apr. 7, 2019. [Online].
C. Protocol Composability Available: https://bitnodes.earn.com/
The discussions above demonstrate that there is never a one- [3] K. Croman et al., “On scaling decentralized blockchains,” in Proc. Int.
Conf. Financial Cryptography Data Security, 2016, pp. 106–125.
fits-all blockchain consensus protocol. The existence of hybrid [4] VISA Fact Sheet, VISA Inc., San Francisco, CA, USA, 2019. [Online].
consensus protocols highlights the possibility to cherry-pick Available: https://usa.visa.com/dam/VCOM/global/about-visa/
individual protocol components to fulfill specific application documents/visa-fact-sheet-july-2019.pdf
[5] Bitcoin Energy Consumption Index, Digiconomist. Accessed: Nov.
needs. Sawtooth [119], a Hyperledger project featuring the uti- 29, 2019. [Online]. Available: https://digiconomist.net/bitcoin-energy-
lization of trusted hardware for PoET-based block proposal, consumption
has the flexibility of plugging in different block finaliza- [6] S. King and S. Nadal. (Aug. 2012). PPcoin: Peer-to-Peer Crypto-
Currency With Proof-of-Stake. [Online]. Available: https://bitcoin.
tion schemes—Raft for crash fault tolerance and PBFT for peryaudo.org/vendor/peercoin-paper.pdf
Byzantine fault tolerance. Similarly, POA Network [11] uses [7] I. Eyal, A. E. Gencer, E. G. Sirer, and R. Van Renesse, “Bitcoin-NG:
PoA for block proposal and has opted for HoneyBadgerBFT A scalable blockchain protocol,” in Proc. NSDI, 2016, pp. 45–59.
[8] A. Kiayias, A. Russell, B. David, and R. Oliynykov, “Ouroboros: A
for block finalization to achieve best performance under provably secure proof-of-stake blockchain protocol,” in Proc. Annu.
asynchronous network conditions. Int. Cryptol. Conf., 2017, pp. 357–388.
Besides block proposal and finalization, the choice of [9] P. Daian, R. Pass, and E. Shi, “Snow white: Robustly reconfigurable
consensus and applications to provably secure proof of stake,” in Proc.
information propagation mechanism largely depends on the Int. Conf. Financ. Cryptography Data Security, 2019, pp. 23–41.
underlying network topology. In a public blockchain network [10] (2018). EOS.IO Technical White Paper V2. [Online]. Available:
where gossiping is the default information propagation https://github.com/EOSIO/Documentation/blob/master/Technical
WhitePaper.md
method, broadcast can be used among a small set of identified [11] (2018). POA Network Whitepaper. [Online]. Available: https://github.
nodes for better efficiency [3]. The block validation mecha- com/poanetwork/wiki/wiki/POA-Network-Whitepaper
nism is associated with the block proposal mechanism and [12] J. Y. Kwon. (2014). TenderMint: Consensus Without
Mining. [Online]. Available: https://cdn.relayto.com/media/files/
takes the current blockchain as input. The incentive mecha- LPgoWO18TCeMIggJVakt_tendermint.pdf
nism is aimed for promoting honest execution of the former [13] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich,
tasks. It needs to account for off-chain factors as well, such “Algorand: Scaling Byzantine agreements for cryptocurrencies,” in
Proc. ACM 26th Symp. Oper. Syst. Principles, 2017, pp. 51–68.
as the long-term system sustainability, financial stability, and [14] V. Buterin and V. Griffith, “Casper the friendly finality gadget,” 2017.
subtle security issues [115], [116], [117]. [Online]. Available: arXiv:1710.09437.
The composability of blockchain consensus protocol also [15] E. Androulaki et al., “Hyperledger fabric: A distributed operating
system for permissioned blockchains,” in Proc. ACM 13th EuroSys
demonstrates the feasibility of progressive protocol improve- Conf., 2018, p. 30.
ment, in that one individual protocol component is updated [16] A. Miller, Y. Xia, K. Croman, E. Shi, and D. Song, “The honey badger
at a time instead of overhauling the entire protocol. This is of BFT protocols,” in Proc. ACM SIGSAC Conf. Comput. Commun.
Security (CCS), 2016, pp. 31–42.
particularly important for large-scale established blockchain [17] S. Duan, M. K. Reiter, and H. Zhang, “BEAT: Asynchronous BFT made
systems in which any protocol change requires network-wide practical,” in Proc. ACM SIGSAC Conf. Comput. Commun. Security
consensus and significant joint effort. (CCS), 2018, pp. 2028–2041.
[18] M. Vukolić, “The quest for scalable blockchain fabric: Proof-of-work
vs. BFT replication,” in Proc. Int. Workshop Open Problems Netw.
X. C ONCLUSION Security, 2015, pp. 112–125.
[19] C. Cachin and M. Vukolić, “Blockchain consensus protocols in the
In this survey we provided a summary of classical fault- wild,” in Proc. 31st Int. Symp. Distrib. Comput. (DISC), 2017,
tolerance consensus research, a five-component framework for pp. 1–16.
[20] S. Bano et al., “Consensus in the age of blockchains,” 2017. [Online].
a general blockchain consensus protocol, and a comprehensive Available: arXiv:1711.03936.
review of blockchain consensus protocols that have gained [21] W. Wang et al., “A survey on consensus mechanisms and mining
great popularity and potential. We analyzed these protocols strategy management in blockchain networks,” IEEE Access, vol. 7,
pp. 22328–22370, 2019.
with respect to fault tolerance, performance, vulnerabilities [22] Y. Xiao, N. Zhang, J. Li, W. Lou, and Y. T. Hou, “Distributed consen-
and highlighted their use cases. Notably, many of these pro- sus protocols and algorithms,” in Blockchain for Distributed Systems
tocols are still under development and are subject to major Security. Hoboken, NJ, USA: Wiley, 2019, p. 25.
[23] M. Belotti, N. Božić, G. Pujolle, and S. Secci, “A vademecum on
changes at the time of writing. We hope the five-component blockchain technologies: When, which and how,” IEEE Commun.
framework, classification methodology, protocol abstractions, Surveys Tuts., vol. 21, no. 4, pp. 3796–3838, 4th Quart., 2019.

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1463

[24] H. Attiya, A. Bar-Noy, and D. Dolev, “Sharing memory robustly in [52] G. Bracha, “Asynchronous Byzantine agreement protocols,” Inf.
message-passing systems,” J. ACM, vol. 42, no. 1, pp. 124–142, 1995. Comput., vol. 75, no. 2, pp. 130–143, 1987.
[25] L. Lamport, R. Shostak, and M. Pease, “The Byzantine generals [53] M. Ben-Or, “Another advantage of free choice (extended abstract):
problem,” ACM Trans. Program. Lang. Syst., vol. 4, no. 3, pp. 382–401, Completely asynchronous agreement protocols,” in Proc. 2nd Annu.
1982. ACM Symp. Principles Distrib. Comput., 1983, pp. 27–30.
[26] H. Attiya and J. Welch, Distributed Computing: Fundamentals, [54] M. O. Rabin, “Randomized Byzantine generals,” in Proc. 24th Annu.
Simulations, and Advanced Topics, vol. 19. Hoboken, NJ, USA: Wiley, Symp. Found. Comput. Sci. (SFCS), 1983, pp. 403–409.
2004. [55] G. Bracha, “An asynchronous [(n − 1)/3]-resilient consensus protocol,”
[27] M. Castro and B. Liskov, “Practical Byzantine fault tolerance,” in Proc. in Proc. 3rd Annu. ACM Symp. Principles Distrib. Comput., 1984,
OSDI, vol. 99, 1999, pp. 173–186. pp. 154–162.
[28] C. Dwork, N. A. Lynch, and L. J. Stockmeyer, “Consensus in the
[56] M. Ben-Or, B. Kelmer, and T. Rabin, “Asynchronous secure com-
presence of partial synchrony,” J. ACM, vol. 35, no. 2, pp. 288–323,
putations with optimal resilience,” in Proc. 13th Annu. ACM Symp.
1988.
Principles Distrib. Comput., 1994, pp. 183–192.
[29] M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility of
distributed consensus with one faulty process,” J. ACM, vol. 32, no. 2, [57] R. Canetti and T. Rabin, “Fast asynchronous Byzantine agreement with
pp. 374–382, 1985. optimal resilience,” in Proc. 25th Annu. ACM Symp. Theory Comput.,
[30] M. Pease, R. Shostak, and L. Lamport, “Reaching agreement in the 1993, pp. 42–51.
presence of faults,” J. ACM, vol. 27, no. 2, pp. 228–234, 1980. [58] C. Cachin, K. Kursawe, F. Petzold, and V. Shoup, “Secure and efficient
[31] B. Alpern and F. B. Schneider, “Defining liveness,” Inf. Process. Lett., asynchronous broadcast protocols,” in Proc. Annu. Int. Cryptol. Conf.,
vol. 21, no. 4, pp. 181–185, 1985. 2001, pp. 524–541.
[32] L. Lamport, “Time, clocks, and the ordering of events in a distributed [59] C. Cachin and S. Tessaro, “Asynchronous verifiable information dis-
system,” Commun. ACM, vol. 21, no. 7, pp. 558–565, 1978. persal,” in Proc. 24th IEEE Symp. Rel. Distrib. Syst. (SRDS), 2005,
[33] L. Lamport, “Using time instead of timeout for fault-tolerant distributed pp. 191–201.
systems,” ACM Trans. Program. Lang. Syst., vol. 6, no. 2, pp. 254–280, [60] A. Mostéfaoui, H. Moumen, and M. Raynal, “Signature-free asyn-
1984. chronous Byzantine consensus with t < n/3 and o(n 2 ) messages,”
[34] F. B. Schneider, “Implementing fault-tolerant services using the state in Proc. ACM Symp. Principles Distrib. Comput., 2014, pp. 2–9.
machine approach: A tutorial,” ACM Comput. Surveys, vol. 22, no. 4, [61] J. Baek and Y. Zheng, “Simple and efficient threshold cryptosystem
pp. 299–319, 1990. from the gap Diffie–Hellman group,” in Proc. IEEE Glob. Telecommun.
[35] F. Cristian, H. Aghili, R. Strong, and D. Dolev, Atomic Broadcast: From Conf. (GLOBECOM), vol. 3, 2003, pp. 1491–1495.
Simple Message Diffusion to Byzantine Agreement, T. J. Watson, Ed. [62] V. Shoup and R. Gennaro, “Securing threshold cryptosystems against
Yorktown Heights, NY, USA: Int. Bus. Mach., 1986. chosen ciphertext attack,” in Proc. Int. Conf. Theory Appl. Cryptograph.
[36] G. Bracha and S. Toueg, “Asynchronous consensus and broadcast Techn., 1998, pp. 1–16.
protocols,” J. ACM, vol. 32, no. 4, pp. 824–840, 1985. [63] J. Yin, J.-P. Martin, A. Venkataramani, L. Alvisi, and M. Dahlin,
[37] X. Défago, A. Schiper, and P. Urbán, “Total order broadcast and “Separating agreement from execution for Byzantine fault tolerant
multicast algorithms: Taxonomy and survey,” ACM Comput. Surveys, services,” in Proc. ACM SIGOPS Oper. Syst. Rev., vol. 37, 2003,
vol. 36, no. 4, pp. 372–421, 2004. pp. 253–267.
[38] T. D. Chandra and S. Toueg, “Unreliable failure detectors for reliable [64] C. Decker, J. Seidel, and R. Wattenhofer, “Bitcoin meets strong con-
distributed systems,” J. ACM, vol. 43, no. 2, pp. 225–267, 1996.
sistency,” in Proc. 17th Int. Conf. Distrib. Comput. Netw., 2016,
[39] B. M. Oki and B. H. Liskov, “Viewstamped replication: A new pri- p. 13.
mary copy method to support highly-available distributed systems,”
in Proc. 7th Annu. ACM Symp. Principles Distrib. Comput., 1988, [65] Bitcoin Wire Protocol 101. (2019). Bitcoin Developer Network.
pp. 8–17. [Online]. Available: https://bitcoindev.network/bitcoin-wire-protocol/
[40] B. Liskov and J. Cowling, “Viewstamped replication revisited,” [66] Ethereum Wire Protocol. (2019). Ethereum Foundation. [Online].
Comput. Sci. Artif. Intell. Lab., MIT, Cambridge, MA, USA, Rep. Available: https://github.com/ethereum/devp2p/blob/master/caps/eth.
MIT-CSAIL-TR-2012-021, 2012. md
[41] L. Lamport, “The part-time parliament,” ACM Trans. Comput. Syst., [67] K. Wüst and A. Gervais, “Do you need a blockchain?” in Proc. IEEE
vol. 16, no. 2, pp. 133–169, 1998. Crypto Valley Conf. Blockchain Technol. (CVCBT), 2018, pp. 45–54.
[42] L. Lamport, “Paxos made simple,” ACM SIGACT News, vol. 32, no. 4, [68] R. C. Merkle, “A digital signature based on a conventional encryp-
pp. 18–25, 2001. tion function,” in Proc. Conf. Theory Appl. Cryptograph. Techn., 1987,
[43] D. Ongaro and J. K. Ousterhout, “In search of an understandable con- pp. 369–378.
sensus algorithm,” in Proc. USENIX Annu. Tech. Conf. (USENIX ATC), [69] J. Poon and T. Dryja. (2016). The Bitcoin Lightning Network:
2014, pp. 305–319. Scalable Off-Chain Instant Payments. Accessed: Apr. 7, 2020. [Online].
[44] M. Abd-El-Malek, G. R. Ganger, G. R. Goodson, M. K. Reiter, and Available: https://www.bitcoinlightning.com/wp-content/uploads/2018/
J. J. Wylie, “Fault-scalable Byzantine fault-tolerant services,” ACM 03/lightning-network-paper.pdf
SIGOPS Oper. Syst. Rev., vol. 39, no. 5, pp. 59–74, 2005. [70] EIP 1011: Hybrid Casper FFG. Ethereum Improvement Proposals
[45] J. A. Cowling, D. S. Myers, B. Liskov, R. Rodrigues, and L. Shrira, (EIPs). Accessed: Apr. 7, 2019. [Online]. Available: https://eips.
“HQ replication: A hybrid quorum protocol for Byzantine fault tol- ethereum.org/EIPS/eip-1011
erance,” in Proc. 7th Symp. Oper. Syst. Design Implement., 2006, [71] G. Wood, “Ethereum: A secure decentralised generalised transaction
pp. 177–190. ledger,” vol. 151, Zug, Switzerland, Ethereum, Yellow Paper pp. 1–32,
[46] R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. Wong, “Zyzzyva: 2014.
Speculative Byzantine fault tolerance,” ACM SIGOPS Oper. Syst. Rev., [72] Litecoin Official Website. Litecoin Foundation. Accessed: Apr. 7, 2019.
vol. 41, no. 6, pp. 45–58, 2007. [Online]. Available: https://litecoin.org/
[47] J.-P. Martin and L. Alvisi, “Fast Byzantine consensus,” IEEE Trans.
[73] C. Decker and R. Wattenhofer, “Information propagation in the bitcoin
Depend. Secure Comput., vol. 3, no. 3, pp. 202–215, Aug. 2006.
network,” in Proc. IEEE 13th Int. Conf. Peer-to-Peer Computing (P2P),
[48] G. S. Veronese, M. Correia, A. N. Bessani, and L. C. Lung, “Spin
2013, pp. 1–10.
one’s wheels? Byzantine fault tolerance with a spinning primary,”
in Proc. 28th IEEE Int. Symp. Rel. Distrib. Syst. (SRDS), 2009, [74] J. A. Garay, A. Kiayias, and N. Leonardos, “The bitcoin backbone
pp. 135–144. protocol: Analysis and applications,” in Proc. Annu. Int. Conf. Theory
[49] A. Clement, E. L. Wong, L. Alvisi, M. Dahlin, and M. Marchetti, Appl. Cryptograph. Techn., 2015, pp. 281–310.
“Making Byzantine fault tolerant systems tolerate Byzantine faults,” in [75] I. Abraham and D. Malkhi, “The blockchain consensus layer and BFT,”
Proc. NSDI, vol. 9, 2009, pp. 153–168. Bull. EATCS, vol. 3, no. 123, pp. 10–17, 2017.
[50] R. Guerraoui, N. Knežević, V. Quéma, and M. Vukolić, “The next [76] VisaNet: The Technology Behind Visa, Visa Inc. Accessed: Apr. 7,
700 BFT protocols,” in Proc. 5th Eur. Conf. Comput. Syst., 2010, 2019. [Online]. Available: https://usa.visa.com/dam/VCOM/download/
pp. 363–376. corporate/media/visanet-technology/visa-net-booklet.pdf
[51] A. N. Bessani, “(BFT) state machine replication: The hype, the virtue, [77] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg, “Eclipse attacks
and even some practice,” in Proc. EuroSys, 2012, pp. 22–49. [Online]. on bitcoin’s peer-to-peer network,” in Proc. USENIX Security Symp.,
Available: http://www.di.fc.ul.pt/∼bessani/publications/T1-bftsmr.pdf 2015, pp. 129–144.

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
1464 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 22, NO. 2, SECOND QUARTER 2020

[78] A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, [103] E. Buchman, “TenderMint: Byzantine fault tolerance in the age of
and S. Capkun, “On the security and performance of proof of work blockchains,” Ph.D. dissertation, Eng. Syst. Comput., Univ. Guelph,
blockchains,” in Proc. ACM SIGSAC Conf. Comput. Commun. Security, Guelph, ON, Canada, 2016.
2016, pp. 3–16. [104] Cosmos SDK Documentation—Validators Overview, Tendermint Inc.,
[79] I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining is San Francisco, CA, USA, 2019. [Online]. Available: https://hub.
vulnerable,” in Proc. Int. Conf. Financial Cryptography Data Security, cosmos.network/master/validators/overview.html
2014, pp. 436–454. [105] Tendermint Documentation: Sentry Node, Tendermint Inc.,
[80] A. Sapirshtein, Y. Sompolinsky, and A. Zohar, “Optimal selfish mining San Francisco, CA, USA, 2019. Accessed: Apr. 7, 2019.
strategies in bitcoin,” in Proc. Int. Conf. Financial Cryptography Data [Online]. Available: https://tendermint.com/docs/spec/p2p/node.
Security, 2016, pp. 515–532. html#sentry-node
[81] D. Gutteridge. (2018). Japanese Cryptocurrency Monacoin Hit by [106] Y. Amoussou-Guenou, A. Del Pozzo, M. Potop-Butucaru, and
Selfish Mining Attack. [Online]. Available: https://www.ccn.com/ S. Tucci-Piergiovanni, “Correctness and fairness of TenderMint-core
japanese-cryptocurrency-monacoin-hit-by-selfish-mining-attack/ blockchains,” 2018. [Online]. Available: arXiv:1805.08429.
[82] A. E. Gencer, S. Basu, I. Eyal, R. van Renesse, and E. G. Sirer, [107] V. Zamfir. (2015). Introducing Casper the Friendly Ghost.
“Decentralization in bitcoin and Ethereum networks,” in Proc. [Online]. Available: https://blog.ethereum.org/2015/08/01/
Financial Cryptography Data Security Conf., 2018, pp. 439–457. introducing-casperfriendly-ghost.
[83] D. Kondor, M. Pósfai, I. Csabai, and G. Vattay, “Do the rich get richer? [108] Casper Proof of Stake Compendium, Ethereum Found., Zug,
An empirical analysis of the bitcoin transaction network,” PLoS ONE, Switzerland, 2019. [Online]. Available: https://github.com/ethereum/
vol. 9, no. 2, 2014, Art. no. e86197. wiki/wiki/Casper-Proof-of-Stake-compendium
[84] Y. Sompolinsky and A. Zohar, “Secure high-rate transaction processing [109] Sharding Introduction R&D Compendium, Ethereum Found., Zug,
in bitcoin,” in Proc. Int. Conf. Financial Cryptography Data Security, Switzerland, 2019. [Online]. Available: https://github.com/ethereum/
2015, pp. 507–527. wiki/wiki/Sharding-introduction-R&D-compendium
[85] Wave-NG Protocol, Wave Platform. Accessed: Oct. 14, 2019. [Online]. [110] Bitshares 2.0 Documentation. (2015). The BitShares Organization.
Available: https://docs.wavesplatform.com/en/waves-environment/ [Online]. Available: http://docs.bitshares.org/bitshares/index.html
waves-protocol/waves-ng-protocol.html [111] Liskś Consensus Algorithm. Accessed: Apr. 7, 2019. [Online].
[86] C. Li, P. Li, W. Xu, F. Long, and A. C.-C. Yao, “Scaling Nakamoto Available: https://lisk.io/documentation/lisk-protocol/consensus
consensus to thousands of transactions per second,” 2018. [Online]. [112] D. Larimer. (2018). DPOS BFT—Pipelined Byzantine Fault
Available: arXiv:1805.03870. Tolerance. [Online]. Available: https://medium.com/eosio/
[87] M. K. Reiter, “A secure group membership protocol,” IEEE Trans. dpos-bft-pipelined-byzantine-fault-tolerance-8a0634a270ba
Softw. Eng., vol. 22, no. 1, pp. 31–42, Jan. 1996. [113] J. Martinez. (2018). Understanding Proof of Stake: The Nothing
[88] L. Luu, V. Narayanan, K. Baweja, C. Zheng, S. Gilbert, and at Stake Theory. [Online]. Available: https://medium.com/coinmonks/
P. Saxena. (2015). SCP: A Computationally-Scalable Byzantine understanding-proof-of-stake-the-nothing-at-stake-theory-1f0d71bc027
Consensus Protocol for Blockchains. [Online]. Available: https://www. [114] M. Franklin, “A survey of key evolving cryptosystems,” Int. J. Security
weusecoins.com/assets/pdf/library/SCP Netw., vol. 1, nos. 1–2, pp. 46–53, 2006.
[89] Sharding FAQs: On Sharding Blockchains, Ethereum Foundation. [115] V. Buterin. (2014). Ethereum Foundation. [Online]. Available: https://
Accessed: Oct. 14, 2019. [Online]. Available: https://github.com/ blog.ethereum.org/2014/05/15/long-range-attacks-the-serious-problem-
ethereum/wiki/wiki/Sharding-FAQ with-adaptive-proof-of-work/
[90] E. Kokoris-Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, and [116] P. Gaži, A. Kiayias, and A. Russell, “Stake-bleeding attacks on proof-
B. Ford, “Enhancing bitcoin security and performance with strong con- of-stake blockchains,” in Proc. IEEE Crypto Valley Conf. Blockchain
sistency via collective signing,” in Proc. 25th USENIX Security Symp. Technol. (CVCBT), 2018, pp. 85–92.
(USENIX Security), 2016, pp. 279–296. [117] Grinding Attack on Proof of Stake, Ethereum Found., Zug,
[91] E. Syta et al., “Keeping authorities ‘honest or bust’ with decentralized Switzerland, 2019. Accessed: Apr. 7, 2019. [Online]. Available:
witness cosigning,” in Proc. IEEE Symp. Security Privacy (SP), 2016, https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs#
pp. 526–545. how-does-validator-selection-work-and-what-is-stake-grinding
[92] R. Pass and E. Shi, “Hybrid consensus: Efficient consensus in the per- [118] Aura—Authority Round—WiKi, Parity Tech Documentation. Accessed:
missionless model,” in Proc. 31st Int. Symp. Distrib. Comput. (DISC), Apr. 7, 2019. [Online]. Available: https://wiki.parity.io/Aura
2017, pp. 1–16. [119] Hyperledger Sawtooth Project. (2018). The Linux Foundation. [Online].
[93] R. Pass and E. Shi, “FruitChains: A fair blockchain,” in Proc. ACM Available: https://www.hyperledger.org/projects/sawtooth
Symp. Principles Distrib. Comput., 2017, pp. 315–324. [120] V. Costan and S. Devadas, “Intel SGX explained,” IACR Cryptol. ePrint
[94] J. Long and R. Wei, “Scalable BFT consensus mechanism through Archive, Rep. 2016/086, 2016.
aggregated signature Gossip,” in Proc. IEEE Int. Conf. Blockchain [121] Introducing ARM Trustzone, ARM Ltd., Cambridge, U.K., 2018.
Cryptocurrency (ICBC), 2019, pp. 360–367. [Online]. Available: https://developer.arm.com/technologies/trustzone
[95] A. Poelstra. (2014). Distributed Consensus From Proof of Stake [122] Hyperledger Sawtooth RFC. (2018). The Linux Foundation. [Online].
is Impossible. Accessed: Apr. 7, 2019. [Online]. Available: https:// Available: https://github.com/hyperledger/sawtooth-rfcs/blob/master/
download.wpsoftware.net/bitcoin/old-pos.pdf text/0019-pbft-consensus.md
[96] (2014). NXT Whitepaper Revision 4, NXT Community. [123] F. Brasser et al., “Software grand exposure: SGX cache attacks
[Online]. Available: https://www.dropbox.com/s/cbuwrorf672c0yy/ are practical,” in Proc. 11th USENIX Workshop Offensive Technol.
NxtWhitepaper_v122_rev4.pdf (WOOT), 2017, pp. 4–7.
[97] I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld, “Proof of activ- [124] J. Van Bulck et al., “Foreshadow: Extracting the keys to the Intel SGX
ity: Extending bitcoin’s proof of work via proof of stake [extended kingdom with transient out-of-order execution,” in Proc. 27th USENIX
abstract]y,” ACM SIGMETRICS Perform. Eval. Rev., vol. 42, no. 3, Security Symp. (USENIX Security), 2018, pp. 991–1008.
pp. 34–37, 2014. [125] O. Weisse et al., “Foreshadow-NG: Breaking the virtual memory
[98] T. Rabin and M. Ben-Or, “Verifiable secret sharing and multiparty pro- abstraction with transient out-of-order execution,” USENIX Assoc.,
tocols with honest majority,” in Proc. 21st Annu. ACM Symp. Theory Berkeley, CA, USA, Rep. LIRIAS2089352, 2018.
Comput., 1989, pp. 73–85. [126] W. Li, S. Andreina, J.-M. Bohli, and G. Karame, “Securing
[99] S. Micali, M. Rabin, and S. Vadhan, “Verifiable random functions,” in proof-of-stake blockchain protocols,” in Proc. Data Privacy Manag.
Proc. IEEE 40th Annu. Symp. Found. Comput. Sci., 1999, pp. 120–130. Cryptocurrencies Blockchain Technol., 2017, pp. 297–315.
[100] I. Bentov, A. Gabizon, and A. Mizrahi, “Cryptocurrencies without proof [127] S. Andreina, J.-M. Bohli, G. O. Karame, W. Li, and G. A. Marson,
of work,” in Proc. Int. Conf. Financial Cryptography Data Security, “PoTS-a secure proof of TEE-stake for permissionless blockchains,”
2016, pp. 142–157. IACR Cryptol. ePrint Archive, Rep. 2018/1135, 2018.
[101] B. David, P. Gaži, A. Kiayias, and A. Russell, “Ouroboros praos: [128] A. Juels and B. S. Kaliski, Jr., “PORS: Proofs of retrievability for large
An adaptively-secure, semi-synchronous proof-of-stake blockchain,” files,” in Proc. 14th ACM Conf. Comput. Commun. Security, 2007,
in Proc. Annu. Int. Conf. Theory Appl. Cryptograph. Techn., 2018, pp. 584–597.
pp. 66–98. [129] A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz, “Permacoin:
[102] R. Pass and E. Shi, “The sleepy model of consensus,” in Proc. Int. Repurposing bitcoin work for data preservation,” in Proc. IEEE Symp.
Conf. Theory Appl. Cryptol. Inf. Security, 2017, pp. 380–409. Security Privacy (SP), 2014, pp. 475–490.

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.
XIAO et al.: A SURVEY OF DISTRIBUTED CONSENSUS PROTOCOLS FOR BLOCKCHAIN NETWORKS 1465

[130] D. Schwartz et al., “The ripple protocol consensus algorithm,” vol. 5, Ning Zhang (Member, IEEE) received the Ph.D.
San Francisco, CA, USA, Ripple Labs Inc., White Paper, 2014. degree from Virginia Tech in 2016. He was
[131] D. Mazieres. (2015). The Stellar Consensus Protocol: A Federated with an industry as a Cyber Engineer and a
Model for Internet-Level Consensus. [Online]. Available: http:// Technical Lead for over ten years. He is cur-
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.696.93&amp= rently an Assistant Professor with the Department
&rep=rep1&amp=&type=pdf of Computer Science and Engineering, Washington
[132] C. Cachin and B. Tackmann, “Asymmetric distributed trust,” 2019. University in St. Louis. His research focus is system
[Online]. Available: arXiv:1906.09314. security, which lies at the intersection of security,
[133] Y. Sompolinsky, Y. Lewenberg, and A. Zohar, “SPECTRE: A fast and embedded systems, and computer architecture and
scalable cryptocurrency protocol,” IACR Cryptol. ePrint Archive, Rep. software.
2016/1159, 2016.
[134] Y. Sompolinsky and A. Zohar, “PHANTOM: A scalable blockDAG
protocol,” IACR Cryptol. ePrint Archive, Rep. 2018/104, 2018.
[135] S. Popov. (2016). The Tangle. [Online]. Available: http://www.
descryptions.com/Iota.pdf Wenjing Lou (Fellow, IEEE) received the Ph.D.
[136] Tangle Tip Selection. IOTA Foundation. Accessed: Apr. 7, 2019. degree in electrical and computer engineering from
[Online]. Available: https://docs.iota.org/docs/the-tangle/0.1/concepts/ the University of Florida in 2003. From 2003 to
tip-selection#in-depth-explanation-of-the-tip-selection-algorithm 2011, she was a Faculty Member with the Worcester
[137] A. Churyumov. (2016). ByteBall: A Decentralized System for Storage Polytechnic Institute. She has been a Professor with
and Transfer of Value. [Online]. Available: https://byteball.org/Byteball. Virginia Tech since 2011. From 2014 to 2017, she
pdf was the Program Director of the U.S. National
[138] C. LeMahieu. (2018). Nano: A Feeless Distributed Cryptocurrency Science Foundation, where she was involved in the
Network. [Online]. Available: https://nano.org/en/whitepaper Networking Technology and Systems Program and
[139] Team Rocket. (2018). Snowflake to Avalanche: A Novel Metastable the Secure and Trustworthy Cyberspace Program.
Consensus Protocol Family for Cryptocurrencies. Accessed: Oct. Her current research interests focus on privacy pro-
14, 2019. [Online]. Available: https://pdfs.semanticscholar.org/85ec/ tection techniques in networked information systems and cross-layer security
19594046bbcfe12137c7c2e3744677129820.pdf enhancement in wireless networks by exploiting intrinsic wireless networking
[140] C. Natoli, J. Yu, V. Gramoli, and P. Esteves-Verissimo, “Deconstructing and communication properties.
blockchains: A comprehensive survey on consensus, membership and
structure,” 2019. [Online]. Available: arXiv:1908.08316.
[141] E. B. Sasson et al., “ZeroCash: Decentralized anonymous pay-
ments from bitcoin,” in Proc. IEEE Symp. Security Privacy, 2014,
pp. 459–474. Y. Thomas Hou (Fellow, IEEE) received the Ph.D.
[142] S. Noether, “Ring signature confidential transactions for Monero,” degree from the NYU Tandon School of Engineering
IACR Cryptol. ePrint Archive, Rep. 2015/1098, 2015. (formerly, Polytechnic University) in 1998. In 2002,
[143] R. Canetti, O. Goldreich, and S. Halevi, “The random oracle method- he joined Virginia Tech, Blacksburg, VA, USA,
ology, revisited,” J. ACM, vol. 51, no. 4, pp. 557–594, 2004. where he is currently a Bradley Distinguished
[144] R. Canetti, “Universally composable security: A new paradigm for Professor of electrical and computer engineer-
cryptographic protocols,” in Proc. 42nd IEEE Symp. Found. Comput. ing. From 1997 to 2002, he was a Member
Sci., 2001, pp. 136–145. of Research Staff with Fujitsu Laboratories of
America, Sunnyvale, CA, USA. He has over 250
papers published in the IEEE/ACM journals and
conferences. He holds five U.S. patents. He has
authored/coauthored two graduate textbooks Applied Optimization Methods
for Wireless Networks (Cambridge University Press, in 2014) and Cognitive
Yang Xiao (Student Member, IEEE) received Radio Communications and Networks: Principles and Practices (Academic
the B.S. degree from the School of Electrical Press/Elsevier, in 2009). His current research focuses on developing innovative
and Information Engineering, Shanghai Jiao Tong solutions to complex science and engineering problems arising from wireless
University and the M.S. degree from the Electrical and mobile networks, and wireless security. His papers were recognized by
Engineering and Computer Science Department, five Best Paper Awards from the IEEE and two Paper Awards from the ACM.
University of Michigan, Ann Arbor. He is cur- He was named an IEEE Fellow for contributions to modeling and optimization
rently pursuing the Ph.D. degree with the Bradley of wireless networks. He was/is on the editorial boards of a number of IEEE
Department of Electrical and Computer Engineering, and ACM Transactions and journals. He is the Steering Committee Chair of
Virginia Tech, supervised by Prof. W. Lou. His the IEEE INFOCOM Conference and a member of the IEEE Communications
research interests lie in network security, blockchain, Society Board of Governors. He is also a Distinguished Lecturer of the IEEE
and IoT security. Communications Society.

Authorized licensed use limited to: Mepco Schlenk Engineering College. Downloaded on August 10,2023 at 19:01:58 UTC from IEEE Xplore. Restrictions apply.