A Survey on Consortium Blockchain Consensus Mechanisms
AA Survey on Consortium Blockchain ConsensusMechanisms
Wei Yao , Junyi Ye , Renita Murimi , and Guiling Wang New Jersey Institute of Technology University of Dallas
Abstract.
Blockchain is a distributed ledger that is decentralized, im-mutable, and transparent, which maintains a continuously growing listof transaction records ordered into blocks. As the core of blockchain,the consensus algorithm is an agreement to validate the correctnessof blockchain transactions. For example, Bitcoin is a public blockchainwhere each node in Bitcoin uses the Proof of Work (PoW) algorithmto reach a consensus by competing to solve a puzzle. Unlike a publicblockchain, a consortium blockchain is an enterprise-level blockchain thatdoes not contend with the issues of creating a resource-saving global con-sensus protocol. This paper highilights several state-of-the art solutionsin consensus algorithms for enterprise blockchain. For example, the Hy-perLedger by Linux Foundation includes implementing Practical Byzan-tine Fault Tolerance (PBFT) as the consensus algorithm. PBFT can tol-erate a range of malicious nodes and reach consensus with quadratic com-plexity. Another consensus algorithm, HotStuff, implemented by Face-book’s Libra project, has achieved linear complexity of the authentica-tor. This paper presents the operational mechanisms of these and otherconsensus protocols, and analyzes and compares their advantages anddrawbacks.
In 2008, Satoshi Nakamoto first proposed Bitcoin [1] and ushered in anew chapter for digital currency. The blockchain technology that formsthe foundation of digital currency has continued to receive worldwide in-terest, and blockchain applications now span the spectrum of use casesranging from agriculture, sports, education and government [2]. At theheart of blockchain lies the consensus algorithm, where all nodes on thepublic ledger reach consensus in a distributed, untrusted environment.Thus, the consensus mechanism fundamentally determines the security,availability, and system performance of the entire blockchain system. Thestudy of consensus mechanisms in the blockchain is of great significanceto the scalability of the blockchain, since it determines the transaction a r X i v : . [ c s . D S ] F e b W. Yao et al. processing speed and the security of the blockchain. The consensus mech-anism, then, is of fundamental significance in the widespread adoptionand consequent success of blockchain applications.Since the first whitepaper describing Nakamoto’s vision for Bitcoinwas published in 2008, several variants of cryptocurrencies have been re-leased. Notable among them is Ethereum [3] which introduced the conceptof a smart contract. Smart contracts, which denote contracts in code onthe blockchain, allow for the use of Ethereum as a platform for currencytransactions. While Ethereum and Bitcoin have several notable differ-ences in their architectures, one common aspect of Ethereum and Bitcoinis that they are both public blockchains since any node can join thesenetworks and partake in the network activity.In 2015, the Linux Foundation initiated an open-source blockchainproject called the Hyperledger project [4]. While Bitcoin and Ethereumare opened to the public without any authentication mechanisms, Hyper-ledger is not a public blockchain. Instead, Hyperledger belongs to a classof blockchain solutions called enterprise blockchain, which is specificallydesigned for enterprise-level applications. Enterprise blockchain providesroles and permission for each member who participates in the blockchain.Moreover, Hyperledger eliminates the incentive mechanism presented byBitcoin mining to save energy consumption and achieve better perfor-mance. With blockchain technology development, more and more enterprise-level users have begun to consider using blockchain to meet their busi-ness needs. For example, Walmart has implemented transparency in theirfood supply chain with Hyperledger Fabric, CULedger has institutedfraud-protection for credit unions with Hyperledger Indy, and Kuber-netes uses the Hyperledger Sawtooth to simplify enterprise blockchainadoption [5, 6, 7]. Therefore, the exploration of effective consensus pro-tocols for use in consortium blockchains has developed into a researchproblem of emerging significance.The release of Facebook’s Libra project white paper in 2019 [8] has ledto a new round of cryptocurrency interest, which has attracted widespreadattention from many investors and researchers in blockchain. Among thevarious applications of blockchain technology in the public and privatesectors, one notable application is that of digital governance. In what istouted as Web 3.0, countries around the world have ventured to seize theopportunity of a new round of information revolution using blockchain.The use of blockchain technologies has accelerated the pace of indus-trial innovation and development, and in the process have introduced and
Survey on Consortium Blockchain Consensus Mechanisms 3 modified long-standing policies, laws and public perceptions of blockchaintechnology.The rest of this paper is structured as follows. Section 2 providesan overview of blockchain technology. Section 3 introduces different fam-ilies of consensus protocols and illustrates two Crash Fault Tolerance(CFT)-based consensus mechanisms. Section 4 addresses variants of theByzantine Fault Tolerance (BFT)-based consensus algorithm in consor-tium blockchains. Finally, Section 5 concludes the paper and presentsdirections for future work.
The goal of the consensus protocol in blockchain technology is to achieveconsistency of nodes participating in the distributed ledger. The nomen-clature of blockchain is derived from its architecture; each block is linkedcryptographically to the previous block. Generally speaking, the firstblock of the blockchain is called the genesis block , and each block containsa set of transactions generated in the network at a given time.Blockchain has the following characteristics - decentralization, trust-lessness, openness, immutability and anonymity. First, decentralizationrefers to the absence of a central trusted third party in the network,unlike those found in centralized transactions. Examples of centralizedenvironments include governments, banks, or other financial institutionswhich serve to regulate various aspects of interactions between entities.Trustlessness denotes the lack of formal social constructs for nodes to es-tablish trust-based on prior history, familiarity or a guarantee from a thirdparty. Instead, trust is established through consensus on the ledger. Third,blockchain enables openness and transparency. In public blockchains suchas Bitcoin, which are also called permissionless blockchains, all nodes canjoin and exit at any time, and nodes can obtain the historical ledger dataof the blockchain at any time ranging back to the genesis block. Thefourth defining characteristic of blockchain is the blockchain’s immutabil-ity which ensures that it is tamper-proof. An example of a tamper-proofimplementation is illustrated through Bitcoin’s depth constraints. In Bit-coin, when the ”depth” of the block exceeds 6, it is established that thecontent of the block will not be tampered with [9]. Finally, blockchains en-sure some degree of anonymity. Although Bitcoin is not completely anony-mous, privacy-protection technologies, such as group signatures, ring sig-natures, and zero-knowledge proofs implemented in other blockchain so-lutions [10] can effectively increase user privacy on the blockchain.
W. Yao et al.
State machine replication (SMR) refers tothe existence of a set of distributed nodes that can process and respondto requests from a client . The client can be software or a user and servesto jointly maintain a linearly growing log, with each node agreeing on thecontent of the log [11].In the SMR mode, there is a primary node, and the other nodesare called backups or replicas . The primary node’s identity can change.State machine replication is fault-tolerant, allowing a certain percentageof nodes to fail or suffer from adversary attacks within a tolerable range.SMR needs to satisfy two essential security properties.1. Consistency. All honest nodes end up with the same logs in theiroutput.2. Liveness. A transaction received by an honest node appears in thelogs of all honest nodes after a specific time.
Adversary model
In cryptography terminology, an adversary repre-sents a malicious entity that aims to prevent non-malicious entities fromachieving their goal [12]. An adversary model is a model that imposes aspecific limit on the percentage of computing power or property that anadversary can hold, generally represented by f for the number of adver-saries and n for the total number of nodes in the network. For example,if a BFT algorithm’s adversary model is n = 3 f + 1, it implies that if thealgorithm can tolerate f faulty replicas, the system requires a minimumnumber of n = 3 f + 1 replicas. The basic framework of the blockchain is shown in Figure 1. The frame-work comprises of the infrastructure layer, the network layer, the datalayer, the consensus layer, and the application layer. In the core frame-work, the data layer includes the data blocks, the chain structure, andthe cryptographical mechanisms that are the essential components of theblockchain [13]. The data layer is responsible for blockchain transactionsand implementation mechanisms, as well as related technologies for blockpropagation verification. The consensus layer is mainly a consensus mech-anism represented by algorithms such as Proof of Work (PoW) used inBitcoin, and Proof of Stake (PoS) used in Ethereum. In the applica-tion layer, various application scenarios and cases represented by pro-
Survey on Consortium Blockchain Consensus Mechanisms 5 grammable assets such as currencies and financial instruments, variousscript codes and smart contracts are encapsulated.
Fig. 1.
Blockchain Architecture
Infrastructure Layer
The infrastructure layer contains hardware, net-work architecture equipment, and deployment environment for a blockchainsystem such as virtual machine and docker container.
Network Layer
The blockchain’s network layer includes the blockchainsystem’s node organization method and propagation verification mecha-nisms of the transaction and the block. A newly generated block can onlybe recorded in the blockchain after it has passed the verification.Blockchains use P2P networks and are connected via a flat topology.Network nodes generally have the characteristics of equality, distribution,and autonomy. Each node in the P2P network undertakes node discovery,connection establishment, block synchronization, transaction broadcast-ing and verification, and block propagation and verification. After the new
W. Yao et al. node is connected to the network, it establishes reliable connections toother nodes through the Transmission Control Protocol (TCP) three-wayhandshake. Once the connection is established, the new node continuouslyreceives broadcast messages from the connected node and store the un-known nodes’ address information from the connected node by broadcastmessage. Since the broadcast message from a node includes the informa-tion of all its connected nodes, eventually the new node can establishconnections with all nodes in the blockchain [14]. With the establishmentof the connection, the new node also synchronizes the block informationfrom connected nodes. It can then start to work as a fully functional nodeto submit and verify transactions if the information of all blocks has beensynchronized to the new node [14].When a new block is successfully generated, the node that generatedthe block will broadcast the block to other nodes in the network forverification. After a node receives the new block information, it verifiesthe block through a list of criteria. For instance, some of the criteria usedin the verification process of a block in Bitcoin include the block hash,block timestamp, hash of the previous block and hash of the Merkle Root[15]. If the block is verified to be invalid, it will be rejected. Otherwise,the new block will be appended after the preceding block is found on thechain.From the network layer’s design principles, it is clear that blockchainis a typical distributed big-data technology. The entire network’s data isstored on completely decentralized nodes. Even if some nodes fail, as longas there is still a functioning node, the data stored in the blockchain canbe fully recovered without affecting the subsequent blocks. The differencebetween this blockchain model and the cloud storage model is that theformer is an entirely decentralized storage model with a higher level ofstorage capacity, while the latter is based on a centralized structure withmultiple storages and data backup functionalities.
Data Layer
The data in this layer is recorded through the blockchainstructure, as shown in Figure 2. The data layer realizes the requirementsof traceability and non-tampering. Any data in the blockchain system canbe tracked through this chain ledger [16].For example, in Bitcoin, each data block comprises of a block headerand a block body containing a packaged transaction, shown in Figure3. The block header contains information such as the current systemversion number, the hash value of the previous block, the difficulty targetof the current block, the random number, the root of the Merkel tree of
Survey on Consortium Blockchain Consensus Mechanisms 7
Fig. 2.
An example of chain structure in blockchain [17] the block transaction, and the timestamp [1]. The block body includesmany verified transactions and a complete Merkel tree composed of thesetransactions [18]. The Merkle tree is a binary tree, where the bottomlayer corresponds to the content of the leaf node. Each leaf node is thehash value of the corresponding data. Two neighboring leaves unite toperform a hash computation that becomes the content of the upper-levelnode. A recursive form of these computations forms the content of theroot node. Based on the Merkle tree’s particular date structure, any datamodification that happens in the leaf node will be passed to its parentnode and will propagate all the way to the root of the tree. The data inthe block body constitutes the central part of the blockchain ledger. TheMerkel tree formed by these transactions generates a unique Merkel rootand stores it in the block header. The block header data is double-SHA256hashed to get the hash value of the block [19].
Consensus Layer
The consensus layer forms the core of the consensusprocess used to determine the validity of the block data by the highlydecentralized nodes. The main consensus mechanisms are Proof of Work(POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), andPractical Byzantine Fault Tolerance (PBFT), which have been the back-bone of scalable solutions in blockchain technology. A particular economicincentive model used to encourage nodes to participate in the blockchain’ssecurity verification work is only used in an incentive mechanism-basedalgorithm, such as PoW.
W. Yao et al.
Fig. 3.
An example of a block in Bitcoin [20]
Application Layer
The application layer encapsulates various scriptcodes, smart contracts, Decentralized Applications (DApps) and Appli-cation Programming Interfaces (APIs).1.
Script . A script is essentially a set of instruction lists attached toa Bitcoin transaction. Bitcoin uses a simple, stack-based, left-to-rightscripting language. Bitcoin transactions are verified through two scripts:locking script and unlocking script. The locking script specifies theconditions for spending the output of this transaction, and the out-put of this transaction can only be spent if the conditions of the lock-ing script are met. The unlocking script corresponds to the lockingscript, a script that meets the transaction cost conditions. If a nodereceives transaction data, it runs locking scripts and unlocking scriptsto check whether the transaction is valid, before accepting it [1]. Thelocking and unlocking of scripts provides flexible transaction controlin Bitcoin. The Bitcoin script system does not have complex loops andflow control, and it is not Turing-complete. A Turing-complete sys-tem means that a program written in this system can find a solution,and there is no limitation on time-consumption and memory usage.The Bitcoin script is not Turing-complete, because it has no condi-tional statements, cannot execute loops, and does not produce recur-sion. To improve the flexibility and scalability of the scripting system,Ethereum proposes a Turing-complete scripting language, which al-
Survey on Consortium Blockchain Consensus Mechanisms 9 lows users to construct smart contracts and decentralized applicationsflexibly based on Ethereum [21].2.
Smart Contract . The emergence of blockchain technology has re-defined smart contracts. Smart contracts are event-driven, statefulcomputer programs running on a replicable shared blockchain dataledger that can actively or passively process data and manage variouson-chain smart assets. Smart contracts are embedded programmaticcontracts that can be built into any blockchain data, transaction, tan-gible or intangible asset. Thus, smart contracts create software-definedsystems, markets, and assets that can be programmatically controlled.Smart contracts provide innovative solutions for issuing, trading, cre-ating, and managing traditional financial assets and play an essentialrole in asset management, contract management, and regulatory en-forcement in social systems.3.
DApp . A DApp is defined as an application that runs on a distributednetwork, where participants’ information is securely protected (andpossibly anonymous) and decentralized through network nodes. ADApp in the blockchain generally meet the following three conditions.(a) The application normally is open-source, and most of them canrun autonomously rather than controlled by a single entity. Alldata and records should be stored on the blockchain through somecryptographic technologies.(b) The application generates tokens through a set of criteria andallocates partial or whole tokens. Any user who contributes is re-warded with tokens paid by the application.(c) The application can improve and adjust its protocols based onbusiness requirements, but all changes have to be agreed upon bythe majority of users.4.
APIs . Blockchain provides documented APIs in the application layerfor development, thus allowing DApps and third-party applicationsthe ability to handle smart contracts and retrieve data from the blockchainplatform.The infrastructure layer, network layer, data layer, and consensuslayer can be envisioned as the blockchain’s underlying virtual machine,and the application layer comprises the business logic, algorithms, andapplications built on the blockchain virtual machine, as shown in Figure4.
Fig. 4.
Five layers model to virtual machine model
Blockchain networks can be classified as public, consortium or privateblockchain in order of decreasing degrees of openness available for partic-ipation by nodes, as shown in figure 5. Here, we provide a brief overviewof the three architectures.
Fig. 5.
Public, Consortium, and Private Blockchain Survey on Consortium Blockchain Consensus Mechanisms 11
Public blockchain
The public blockchain is also referred to as a permis-sionless blockchain, since any node can enter and exit the network freely.The public chain is the earliest and most widely used blockchain architec-ture. Bitcoin is the most widely known example of the public blockchain[22]. Every participant in the blockchain can view the entire ledger data inthe public blockchain, and any public blockchain participant can freely ex-ecute transactions with other nodes on the public chain. Further, anyoneon the public chain can participate in the blockchain consensus processfor mining, i.e. any node can decide exactly which blocks should be addedto the blockchain and participate in recording the current network status.Thus, the public chain is a completely decentralized blockchain. Users ofthe public chain can participate anonymously without registration andcan access the blockchain network and view data without authorization.Additionally, any node can choose to join or exit the blockchain networkat any time [23]. The public chain uses cryptography-related technologiessuch as digital signatures, hashing [24], symmetric/asymmetric keys [25],and Elliptic Curve Digital Signature Algorithm (ECDSA) [26] to ensurethat transactions cannot be tampered with. Economic incentives such astransaction fees and rewards are adopted so that the consensus node ismotivated to participate in the consensus process, which in turn servesto maintain the security and effectiveness of the decentralized blockchainsystem. The consensus mechanism in the public chain is generally PoW(Bitcoin) or PoS (Ethereum). Under the PoW mechanism, nodes competefor the right to confirm a transaction and getting the associated rewardsthrough computing power, while under the PoS mechanism, users com-pete for these rights through collecting resources. Section 2.4 elaborateson the different families of consensus protocols.
Private blockchain
The private blockchain is also known as the permis-sioned blockchain, and is only used in private organizations or institutions[27]. Unlike public blockchains, private blockchains are generally not opento the outside world and are only open to individual individuals or insti-tutions. Data read and write permissions on the private blockchain andblock accounting rights are allocated under the rules established by pri-vate organizations. Specifically, each node’s writing rights in the privatechain system are allocated by the organization, and the organization de-cides how much information and data is open to each node according tothe specific conditions of the actual scenarios. The private chain’s value ismainly to prevent internal and external security attacks on data and pro-vide users of the private chain with a safe, non-tamperable, and traceable system. From the above description, it can be seen that the private chainis not a completely decentralized blockchain. Instead, there is a certaindegree of centralized control. Compared with public chains, private chainssacrifice complete decentralization in exchange for increased transactionspeed.
Consortium blockchain
The consortium blockchain is a hybrid archi-tecture comprising of features from both public and private blockchains.A consortium blockchain is also a permissioned blockchain, in which par-ticipation is limited to a consortium of members to participate; each nodemight refer to a single organization or institution in the consortium. Thenumber of nodes in a consortium blockchain is determined by the size ofthe pre-selected participants in the blockchain. For example, suppose afinancial blockchain is designed for a consortium of thirty financial insti-tutions. In that case, the maximum number of nodes in this consortiumblockchain is thirty, and the number of nodes required to reach the con-sensus depends on which consensus algorithm the consortium blockchainuses. The consortium chain accesses the network through the gateways ofmember institutions. The consortium chain platform generally providesmembers’ information authentication, data read and write permission au-thorization, network transaction monitoring, member management, andother functions. Each member can have permissions assigned by the con-sortium to access the ledger and validate the generation of blocks. Thewell-known Hyperledger project is an example of a consortium blockchain.Since there are relatively few nodes participating in the consensus pro-cess, the consortium blockchain generally does not use the PoW miningmechanism as the consensus algorithm. Consortium chains’ requirementsfor transaction confirmation time and transaction throughput are verydifferent from those of public chains.The following Table 1 shows a comparison between the three differenttypes of blockchain.
In this section, we will provide a brief overview of the different types ofconsensus algorithms. There are two ways in which consensus algorithmsmay be classified.One way of classifying consensus algorithms is by the approach ofmaking a final decision to reach a consensus. We call this first categoryas proof-based consensus algorithms, since a node in this category has to
Survey on Consortium Blockchain Consensus Mechanisms 13
Table 1.
Comparison of three blockchain networks
Property Public Private ConsortiumInfrastructure
Highly Decentralized. Distributed. Decentralized.
Permission
Permissionless. Permissioned. Permissioned.
Governance Type
Public. Consensus is man-aged by a single node. Consensus is man-aged by a consortiumof participants.
Validator
Any node or miner. A set of authorizednodes. A set of authorizednodes.
TransactionsThroughout
Low ( ≤
100 TPS). High ( >
100 TPS) High ( >
100 TPS)
NetworkScalability
High. Low. Medium.
Example
Bitcoint, Ethereum. Quorum, SoluLab. HyperLedger, Ten-dermint, CordaR3. compete with other nodes and prove it is more qualified to commit trans-actions. PoW [1], PoS [28], PoA [29], PoET [30], and PoSpace [31] arealgorithms in this group. The other category is that of voting-based al-gorithms since the commitment depends on which committed result winsthe majority of votes. Paxos [32], Raft [33], PBFT [34], RFBT [35], RPCA[36], SCP [37], Tendermint [38], and HotStuff [39] belong to this category.Figure 6 shows the classification of blockchain consensus algorithms byworking mechanism. The first group of consensus is proof-based, whilethe second group is voting-based.The second way of classifying consensus algorithms is by the designprinciple of fault tolerance. Nodes can suffer from non-Byzantine error(Crash Fault), which is exemplified by situations where the node failsto respond. Alternatively, nodes can forge or tamper with the informa-tion and respond maliciously, causing Byzantine errors (Byzantine Fault).Thus, consensus algorithms may be classified as being designed for CrashFault Tolerance (CFT) or Byzantine Fault Tolerance (BFT). It is impor-tant to note that this classification method only focuses on the original de-sign principle; most BFT-based consensus algorithms can tolerate eithercrash fault or Byzantine fault. Since the design principle of algorithmsin the previous proof-based family is very different from fault tolerance,those proof-based families will be excluded in this classification.Paxos [32], Raft [33], and Zab [40] belong to the category of CFT-based consensus algorithm. A collection of variants of PBFT [34] algo-rithms, such as RBFT [35], SBFT [41], BFT-SMART [42], DBFT [43],
Fig. 6.
Classification of Blockchain Consensus Algorithm by mechanism Survey on Consortium Blockchain Consensus Mechanisms 15 and HotStuff [39], are in the category of BFT-based consensus algorithm.Another collection of consensus algorithms in the same category usesByzantine Federated Agreement (BFA) [37] for voting, such as RPCA[36] and SCP [37]. Figure 7 shows a classification of blockchain consensusalgorithm by fault tolerance.
Fig. 7.
Classification of Blockchain Consensus Algorithm by Fault Tolerance
Section 3 presents CFT algorithms, and Section 4 presents BFT algo-rithms.
CFT consensus algorithms only guarantee a blockchain’s reliability andresiliency to blockchain node failure. Also known as non-Byzantine errors,6 W. Yao et al.
CFT consensus algorithms only guarantee a blockchain’s reliability andresiliency to blockchain node failure. Also known as non-Byzantine errors,6 W. Yao et al. node failures can be caused by failed hardware, crashed processes, brokennetwork, or software bugs. CFT can not address scenarios where maliciousactivities are involved, referred to as Byzantine errors. When nodes in ablockchain intentionally and maliciously violate consensus principles, e.g.,tampering with data, a CFT algorithm can not guarantee the systemreliability. Thus, CFT consensus algorithms are mainly used in closedenvironments such as enterprise blockchains. Current mainstream CFTconsensus algorithms include the Paxos algorithm and Raft. The latter isa derivative of the former and is a simplified consensus algorithm designedto be more suitable for industry implementation than the original Paxos.
Paxos [32] is a fault-tolerant consensus algorithm based on message pass-ing in a distributed system. The Paxos algorithm divides nodes into threeroles: proposer , acceptor , and learner . Each role corresponds to a processon the node, and each node can have multiple roles simultaneously.A proposer is responsible for proposing a proposal and for awaitingresponses from acceptors. An acceptor is responsible for voting on theproposal. A Learner is informed of the proposal’s result and follows theresults, but it does not participate in voting.A proposal consists of a key-value pair formed by a proposal numberand a value. The proposal number ensures the proposal’s uniqueness, andthe value represents the content of the proposal itself. A value of Chosen indicates that the proposal has been selected. When more than half ofthe acceptors approve a proposal, the proposal is considered Chosen.The Paxos algorithm meets the constraints of saf ety and liveness ,which are described below. • Safety ensures that the decision is correct and not ambiguous. Thesafety constraint has the following requirements. Only the value pro-posed by the proposer can be chosen. Further, only one decision valuecan be chosen, and the process can only obtain those values that areactually chosen. • Liveness guarantees that the proposal will be completed within a lim-ited time. The value proposed by the proposer cannot be learned untilit has been chosen.The Paxos algorithm’s consensus process begins with a proposer, whoputs forward a proposal to win the support of the majority of acceptors.When a proposal proposed by a proposer receives more than half of the
Survey on Consortium Blockchain Consensus Mechanisms 17 approval of acceptors, the proposer sends the result to all nodes for con-firmation. In this process, if the proposer fails due to a crash, it can besolved by triggering the timeout mechanism. If the proposer happens tofail every time a new round of proposals is proposed, then the system willenter a livelock status and never reach an agreement [44].The Paxos algorithm execution is divided into two phases shown infigure 8. In the
PREPARE phase,the proposer sends a prepare requestwith a proposal number to more than half of the acceptors in the network.The purpose of this initial transmission of the proposal number is to testwhether the majority of acceptors are prepared to accept the proposal.After receiving the proposal, the acceptor will always store the largestproposal number it has received. When an acceptor receives a prepare request, it will compare the currently received proposal’s number andthe saved largest proposal number. If the received proposal number isgreater than the saved maximum proposal number, it will be accepted andincluded in a message called promise , which it returns as the responseto the proposer. The internally saved largest proposal number is updatedsimultaneously and the acceptor will promise not to accept any proposalwith a number less than the proposal number that is currently received.
Fig. 8.
Paxos two phases.[45]
In the
ACCEPT phase, if the proposer receives more than half ofthe responses as promise messages, it will broadcast an accept requestwith the proposal. This accept request consists of a proposal number andthe value that the node would like to propose. Note that if the responsemessage received by a proposer does not contain any proposal, the valueis determined by proposer itself. However, if the response message re- trieved by the proposer contains a proposal, the value will be replaced bythe value in the response that contains the largest proposal number. Af-ter the acceptor receives the accept request, if it finds that the proposalnumber in the accept request is not less than the maximum proposalnumber promised by the acceptor, it will accept the proposal and updatethe accepted maximum proposal. If a majority of acceptors accept theproposal, then the proposed value is chosen , which means the cluster ofall proposers and acceptors has reached consensus.In the n = 2 f + 1 model, Paxos can tolerate f crashing nodes andimplements a consensus algorithm based on message-passing. Paxos isfault-tolerant only for for crashed nodes, not for Byzantine nodes. Thisis because a Byzantine node can always try and find out a number largerthan the current maximum proposal number, either to mess up othernodes’ efforts to reach a consensus or to force other nodes to accept itsproposed incorrect value. Raft [33], formally known as the Raft Consensus Algorithm, is moti-vated by Paxos. Raft is designed for ease of understandability and imple-mentability for industry applications. Its core idea is that servers startfrom the same initial state and execute a series of command operations inthe same order. The goal of Raft is to achieve a consistent state. There-fore, Raft uses the log method for synchronization, which is a consistentalgorithm for managing replicated logs.The Raft algorithm divides nodes into three mutually-convertible roles: leader , f ollower , and candidate . There can be at most one leader in theentire cluster. The minimum size of a cluster is five nodes. The leader isresponsible for receiving client requests, managing replication logs, andmaintaining communication with followers.Initially, all servers are followers. A follower, passively responds to theRemote Procedure Call (RPC) requests from the leader. Followers do notcommunicate with each other since they are passive nodes. A followeris responsible for responding to log replication requests from the leaderand responding to election requests from candidate nodes. If a followerreceives a request from the client, the follower forwards it directly to theleader.In Raft, a candidate is responsible for initiating election voting. If theleader goes down due to a crash or loses network connectivity, one ormore nodes will change their role from follower to candidate and initiatesan election to elect a new leader. Once a candidate node wins an election, Survey on Consortium Blockchain Consensus Mechanisms 19 its status is changed from candidate to leader, and it still has a chanceto convert back to a candidate if a new leader is elected but then fails.Figure 9 shows how the three roles change states.
T erm in the figure isrepresented by a continuously increasing number. Each round of electionis a term, and each term elects only one leader.
Fig. 9.
Server states. [33]
The Raft algorithm consensus process runs in two phases. The firstphase is the leader election, triggered by a heartbeat mechanism. A leadersends a heartbeat message to all followers periodically, to maintain itsauthority. If a follower does not receive the heartbeat message for a periodof time, denoted by election timeout , it switches to the candidate roleand starts a leader election process since it is determined that the leaderhas failed [33]. Then, it increases its current term, canvasses for itself,sends RequestVoteRPC to other servers, and waits for the following anyof the following three situations to occur:1. A candidate wins the election. This implies that the candidate haswon more than half of the server votes, and it will become a leader.2. A candidate loses the election, which means another server has wonmore than half of the votes and has received the corresponding heart-beat, thereby leading to the candidate becoming a follower.3. If no one wins the election, after a randomized timeout, the electionis re-initiated and the term increases.The second phase is the log replication phase, where the leader acceptsthe client’s request, updates the log, and sends a heartbeat to all followers.Consequently, all followers synchronize the leader’s log.
In 1982, Leslie Lamport, Robert Shostak, and Marshall Pease proposedthe Byzantine Generals problem [46]. The Byzantine Generals problem isdescribed as follows. Suppose there are several Byzantine armies camp-ing outside an enemy city, and each army is commanded by a general.The generals can only communicate with each other by dispatching amessenger who carries messages [46]. After observing the enemy’s situa-tion, they must agree on an identical plan of action. However, there aresome traitors among these generals, and these traitors will prevent loyalgenerals from reaching an agreement. The generals should legislate an al-gorithm to guarantee that all loyal generals reach a consensus, and that asmall number of traitors will not cause a loyal general to adopt the wrongplan.Let v ( i ) represent the information sent by the i -th general. Each gen-eral draws up a battle plan based on v (1), v (2), · · · , v ( n ), where n is thenumber of generals. The problem can be described in terms of how a com-manding general sends an order to his lieutenants. Therefore, the problemwill be transformed into the following Byzantine General P roblem : Acommander sends an order to his n − • IC
1. All loyal lieutenants obey the same order. • IC
2. If the commander is loyal, then each loyal lieutenant must obeyhis orders.The above IC IC m traitors and the totalnumber of generals is less than 3 m + 1, the Byzantine generals problemhas no solution.An example of the Byzantine generals problem is shown in Figure10. Here, the commander and Lieutenant 1 are loyal, and Lieutenant 2is a traitor. The commander sends an attack order to all lieutenants.Lieutenant 2 is a traitor, and he/she deceives Lieutenant 1 by sendinga tampered message called ”retreat”. Since Lieutenant 1 does not knowwhether the commander or Lieutenant 2 is a traitor, he/she cannot judgewhich message includes the correct information and thus, cannot reach aconsensus with the loyal commander. Survey on Consortium Blockchain Consensus Mechanisms 21
Fig. 10.
Byzantine General Problem with three participants and one traitor (lieu-tenant) [46]
In another case shown in Figure 11, the two lieutenants are loyal, andthe commander is a traitor. The commander sends different orders to thetwo lieutenants. Lieutenant 2 conscientiously delivered the informationof the commander to Lieutenant 1. Lieutenant 1 can not judge whichinformation is correct, resulting in two loyal lieutenants not reaching aconsensus.
Fig. 11.
Byzantine General Problem with three participants and one traitor (comman-der) [46]
If there are m traitors and the total number of generals n is less than3 m + 1, the Byzantine generals problem has no solution. Unlike CFTproblems that deal with crashes or failures, a Byzantine fault, named af-ter Byzantine generals problem, is caused by malicious nodes who maysend incorrect information to prevent other nodes from reaching consen- sus. In distributed systems, the Byzantine Generals problem translatesto the inability in maintaining consistency and correctness under certainconditions.Lamport proposed a BFT algorithm to solve the Byzantine generalsproblem in exponential time O ( n f ) if the adversary mode is n = 3 f + 1[46]. This original BFT algorithm is computationally expensive to imple-ment, and a practical BFT algorithm is introduced in the next section. Practical Byzantine Fault Tolerance (PBFT) is a consensus algorithmbased on state machine replication [34]. As a state machine, services arereplicated in different nodes of a distributed system. Each copy of thestate machine saves the state of the service and the operations it imple-ments. This algorithm can ensure the system’s regular operation whenthe proportion of nodes with errors does not exceed a third of the totalnumber of nodes. The idea is to let every node receive a message askingabout the content of the message received by other nodes.The adversary mode of PBFT is n = 3 f + 1, and it ensures that thesystem which contains n nodes can reach a consensus if the number offaulty nodes f does not exceed 1/3 of n . In the PBFT algorithm, thereis one primary node out of n nodes, and other backup nodes called repli-cas. The PBFT consensus mechanism reaches a consensus through threephrases: pre - prepare , prepare , and commit . Another important mech-anism in the PBFT algorithm is view-change. When the primary nodefails, and cannot process the data request within a specified time, otherreplicas initiate a view-change, and the new primary node starts to workafter the conversion is successful.The processe of reaching consensus in the PBFT algorithm is as fol-lows:1. Propose. The client uploads the request message m to the nodes inthe network, including the primary node and replicas.2. Pre-prepare. The primary node receives the request message m up-loaded by the client, assigns to it the message sequence number s , andgenerates the pre-prepare message (cid:104) P RE - P REP ARE, H ( m ) , s, v (cid:105) ,where H ( m ) is a one-way hash function and v represents the viewat that time instant. The view v is used to record the replacement ofthe primary node. If the primary node changes, the view v is incre-mented by one. The message sender uses its private key to implementthe digital signature before sending it. The primary node sends thepre-prepare message to replicas. Survey on Consortium Blockchain Consensus Mechanisms 23
3. Prepare. Once replica nodes receive the pre-prepare message from theprimary node, the replica nodes verify H ( m ) to ensure they havenot received other messages before view v and sequence s . After theverification is passed, the replica nodes calculate the prepare message (cid:104) P REP ARE, H ( m ) , s, v (cid:105) and broadcast it to the entire network. Ifthe number of valid prepare messages received by a replica node isgreater than or equal to 2 f + 1 (including its own prepare message),then the replica node will generate a prepared certificate. This impliesthat it is prepared to move to the next phase.4. Commit. If the replica node collects 2 f + 1 prepare messages andgenerates the prepared certificate in the prepare phase, it will broad-cast the commit message (cid:104) COM M IT, s, v (cid:105) to other replica nodes andstore the message m in the local log for processing. If the number ofvalid commit messages received by a replica node is greater than orequal to 2 f + 1 (including its own commit message), then the replicawill generate a committed certificate which means the message hassuccessfully committed.5. Reply. Once a node (either primary node or replica) receives 2 f + 1valid commit messages from the replicas and the primary, it will sendthe committed certificate as a reply of the message m to the client. Fig. 12.
PBFT algorithm process [47]
PBFT contains a checkpoint mechanism for discarding messages ina garbage-collection approach. Each request message is assigned a spe-cific sequence number s . This functions as a checkpoint for s , which isa state reached after the request s is executed. Any checkpoint that has no less than 2 f + 1 nodes generating the committed certificate is a stablecheckpoint . For example, let the sequence number corresponding to mes-sage m be 106. If no less than 2 f + 1 nodes generate the committedcertificate of message m , then the serial number 106 becomes the stablecheckpoint after the commit phase. Thus, the replica can reduce storagecosts by clearing the data before the stable checkpoint.The stable checkpoint also plays a crucial role in PBFT’s view-changeprotocol. View-change protocol provides liveness through a mechanismto ensure that the cluster keeps working when the primary node fails.To avoid waiting indefinitely, a replica starts a timer when it receivesa request. View changes are triggered if the replica has not received aresponse from the primary node after a timeout. PBFT’s view-changeprotocol works as follows:1. Broadcast view-change messages. For replica i , suppose the timer ex-pires in view v . The current stable checkpoint is S ∗ , and C is definedto be a set of 2 f + 1 valid checkpoint messages for S ∗ . U is a set ofmessages with sequence number greater than S ∗ and contains a validpre-prepare message. Node i broadcasts the view-change message: vc i : (cid:104) V IEW - CHAN GE, v + 1 , S ∗ , C , U , i (cid:105) to all replica nodes.2. View-change confirmation. The backup node verifies the legality ofthe received view-change message for view v + 1. An acknowledgemessage is then sent to the new primary node for view v + 1 once theverification is processed.3. Broadcast new view. For node j ’s view-change message vc j , if the newprimary p receives 2 f acknowledge messages for view v + 1, then vc j is considered valid. Primary node p broadcasts the new view message: (cid:104) N EW - V IEW, v + 1 , V , U ∗ (cid:105) to all other replicas, where V is a set ofvalid view-change messages plus the view-change message for v + 1which is sent by p . The term U ∗ denotes a set of numbers, whichcontains the sequence number of the latest stable checkpoint, and thehighest sequence number in prepare message.PBFT uses Message Authenticated Codes (MACs) [48] to facilitateinter-node authentication. In the authentication process, both the mes-sage and its digest are generated through a specific hash function. A pairof session keys between the two nodes is used to calculate the MAC of themessage. The session key is generated through a key exchange protocoland dynamically replaced. PBFT achieves the consistency and activityof state machine replication. The message communication complexity is O ( n ) if there is a non-malicious primary node which works without fail- Survey on Consortium Blockchain Consensus Mechanisms 25 ure. Otherwise, it rises to O ( n ) if the primary node fails (processingview-change protocol). The Redundant Byzantine Fault Tolerance (RBFT) algorithm [35] is avariation of PBFT proposed in 2013 that uses a multi-core architectureto improve its robustness.The RBFT requires the same adversary mode, i.e. n = 3 f + 1 nodes,as PBFT. Each node runs f + 1 PBFT protocol instances [35] in paral-lel. Only one of these instances is the master instance, while the otherinstances are backup instances. Each instance has its own n replicas; andin f +1 instances, each node has at most one primary in each. An overviewof this parallel architecture is shown in Figure 13. Fig. 13.
An overview of RBFT components [35]
As shown in the figure 14, RBFT uses a communication process simi-lar to PBFT in the consensus protocol phase but adds a propagate phasebefore the pre-prepare phase. This ensures that a request will eventuallybe sent to the next phase by all the correct nodes. To guarantee correct-ness, RBFT requires that f + 1 PBFT instances receive the same clientrequest. However, when a node receives a request from the client, it doesnot directly run it on its f + 1 instances, but forwards the request mes-sage to each other. If a node receives 2 f + 1 requests from client, it willeventually send the request to f+1 instances, and move to the next phase.This 3-phase process is similar to PBFT [34], and is shown in steps 3, 4,6 W. Yao et al.
As shown in the figure 14, RBFT uses a communication process simi-lar to PBFT in the consensus protocol phase but adds a propagate phasebefore the pre-prepare phase. This ensures that a request will eventuallybe sent to the next phase by all the correct nodes. To guarantee correct-ness, RBFT requires that f + 1 PBFT instances receive the same clientrequest. However, when a node receives a request from the client, it doesnot directly run it on its f + 1 instances, but forwards the request mes-sage to each other. If a node receives 2 f + 1 requests from client, it willeventually send the request to f+1 instances, and move to the next phase.This 3-phase process is similar to PBFT [34], and is shown in steps 3, 4,6 W. Yao et al. and 5 in Figure 14. In the 3-phase process, the RBFT algorithm is alsoperformed by the f + 1 instances when executing the consensus protocol.After execution, the result will be returned to the client through MAC au-thentication messages. When the client receives f + 1 valid and consistentreplies, it accepts these replies as a result. Fig. 14.
RBFT protocol steps [35]
An improvement of RBFT over PBFT is the implementation of amonitoring mechanism and a protocol instance change mechanism to pro-mote robustness. Each node runs a monitoring program to monitor thethroughput of all f +1 instances. If 2 f +1 nodes find that the performancedifference between the master and the best backup instance reaches a cer-tain threshold, then the primary of the master instance is considered as amalicious node [35]. Thus, a new primary is selected or the primary in thebackup instance with the best performance is chosen. It then upgrades thebackup instance to the master instance. Since each node has at most oneinstance of the primary, if the wrong primary of the master instance hasbeen found, all primaries on different instances need to be replaced. Eachnode maintains a counter to record the change information of each in-stance. If a node finds that it needs to change the primary, it will send anINSTANCE CHANGE message with a MAC authenticator to all nodes.After the node receives the incoming INSTANCE CHANGE message, itverifies the MAC, then compares it with its counter. If its counter is larger,then it discards the message. Otherwise, the node checks whether it alsoneeds to send the INSTANCE CHANGE message by comparing the per- Survey on Consortium Blockchain Consensus Mechanisms 27 formance of the master and backup. If 2 f +1 valid INSTANCE CHANGEmessages are received, the counter is incremented by one and this startsthe view-change process as in PBFT. As a result, each instance’s primarygets updated, including the master’s. BFT-SMART [42] is a state machine replication library written in theJava language, designed to tolerate f Byzantine nodes where the totalnumber of nodes is n ≥ f + 1. In BFT-SMART, a state transfer ser-vice is provided to repair a faulty node, re-assign it into the system, andaccess other nodes to obtain replicas’ latest status. To ensure that thesystem can recover stably from errors occurring at the f nodes simulta-neously, the state transfer service stores each node’s operation logs onother disks. Besides, BFT-SMART implemented a reconfiguration ser-vice to add/remove replicas dynamically through a Trusted Third Party(TPP) particular client.The BFT-SMART algorithm divides the nodes into two types: leadernodes and backup nodes, and it has a reconfiguration protocol [49], whichis very similar to the view-change protocol employed in PBFT to handlea leader failure.The consensus process of the BFT-SMART algorithm is based on amodule named Mod-SMaRt [50], with a leader-driven algorithm describedin [51]. There are three phases in the consensus process: P ropose , W rite ,and
Accept , as shown in Figure 15. A leader node is elected from theentire network. Before entering the consensus process, a client sends a
REQU EST message contains the client serial number, digital signature,and operation request content to all nodes and then waits for a response.When the system is in the normal phase (no node fails or has an errorin the system), the leader node first verifies the correctness of the re-ceived
REQU EST message. After the verification is passed, the leadernode accepts the received message, assigns a serial number, and sendsthe
P ROP OSE message to replica nodes. As long as a replica nodeaccepts the message and forwards it, other nodes will also receive andsend the
W RIT E message to all nodes, including itself. When receiving2 f W RIT E messages, the node broadcasts an
ACCESS message to allnodes, including itself. When a node receives 2 f + 1 ACCESS messages,the request is executed. The algorithm stores the content of the series ofrequest operations and the encryption certificate in each node’s log andreplies
ACCEP T to the client simultaneously.
Fig. 15.
BFT-SMART normal phase message pattern [42].
If an error occurs in a node (the number of error nodes are f =( n − /
3) and triggers timeout twice, the algorithm is forced to jump tothe synchronization phase, and the reconfiguration protocol will start tore-elect the leader node. This process and the consensus process can exe-cute simultaneously. When the first timeout is triggered, the
REQU EST request will be automatically forwarded to all nodes because the timeoutmay be triggered by a faulty node that is only sending its response toa part of nodes in the network, instead of sending the response to theentire network. When the second timeout is activated, the node imme-diately enters the next reconfiguration and sends a
ST OP message tonotify other nodes. When a node receives more than f ST OP messages,it will immediately start the next reconfiguration. Once the leader elec-tion is complete, all nodes send a
ST OP DAT A message to the new leadernode. If the leader node accepts at least n − f valid ST OP DAT A mes-sages, it will send a
SY N C message to all nodes. The node that receivesthe
SY N C message will perform the same operation as the leader node toverify whether the leader node has collected and sent valid information.If the leader has been verified as valid, then all other replicas will startto synchronize from the leader.
The Ripple Protocol Consensus Algorithm (RPCA) [36, 52] was proposedin 2014 for use in the Ripple cryptocurrency created by Ripple Labs. The
Survey on Consortium Blockchain Consensus Mechanisms 29
RPCA algorithm uses some pre-configured nodes as validators verifyingand voting on transactions to reach the consensus. After several roundsof voting, if a transaction continues to receive more than a threshold(usually 80%) of votes, the transaction is directly recorded in the ledger.Each node in the system maintains a subset of validators as a list oftrusted nodes named Unique Node List (UNL). In addition to validators,there are also non-validators in the system known as tracking servers.Tracking servers are responsible for forwarding transaction informationin the network and responding to client’s requests, and not participatingin the consensus process. A validator and a tracking server can switchroles. When a tracking server obtains a certain threshold of votes, it canswitch to serving in the role of a validator. If a validator is inactive for along time, it will be deleted from the UNL and it then becomes a trackingserver.The consensus process of the RPCA algorithm is shown in Figure16. The client initiates a transaction and broadcasts it to the network.The validator receives the transaction data, stores it locally, and veri-fies it. Invalid transactions will be discarded, while a valid transactionis integrated into the candidate set of transactions. Each validator peri-odically sends its transaction candidate set as a transaction proposal toother nodes. Once the validator receives the proposal from other nodes,it checks whether the sender of the proposal is on the UNL. If it is not,the proposal is discarded. Otherwise, the validator will store the proposallocally and compare it with the candidate set. The transaction will obtainone vote if it is the same as in the candidate set. Within a certain period[52], if the transaction fails to reach 50% of the votes, it will return tothe candidate set and wait for the next consensus process. If it reaches athreshold denoted by 50% of votes, it will enter the next round and bere-sent as a proposal to other nodes and the threshold will also be raised.As the number of rounds increases, the threshold continues to increaseuntil the transaction reaches 80% or more of the votes, at which pointthe validator writes it into the ledger.In the RPCA algorithm, because the identity of the nodes partici-pating in the consensus (validators) is known, this algorithm reduces thecommunication cost between network nodes and improves consensus ef-ficiency compared with PoW, PBFT, and other algorithms. Since thealgorithm requires 80% or more of the votes to reach a consensus, if ma-licious nodes want to cheat the ledger, they must reach 80% or more inthe UNL to succeed. Thus, RPCA has a better Byzantine fault tolerance
Fig. 16.
Ripple’s RPCA Consensus Algorithm. compares to PBFT, and it is able to guarantee the correctness of thesystem.
Stellar is an open-source blockchain technology, mainly used in distributedfinancial infrastructure. One of the main objectives of SCP is to reducethe cost of financial services such as daily payments between enterprises,cross-border electronic remittances, and asset transactions. SCP, pro-posed by David Mazieres, is a distributed consensus algorithm designedaround state machine replication, and does not require miners but a dis-tributed server network to run the protocol [37].SCP is the first implementation of a consensus protocol called theFederated Byzantine Agreement (FBA), which follows Federated Byzan-tine Fault Tolerance (FBFT). A quorum slice introduced by FBFT refersto the subset of nodes on the network that a given node chooses to trust.A quorum is a set, and each non-faulty member of it contains at leastone quorum slice. The notion of FBA is similar to the UNL in the RPCAalgorithm, since the UNL can be considered as a type of quorum slice.However, unlike the UNL used in Ripple which requires only 80% of the
Survey on Consortium Blockchain Consensus Mechanisms 31 agreement to reach the consensus, in Stellar, the ledger will not updatethe transaction until 100% of nodes in a quorum slice agree on it.There are two mechanisms in the quorum slice model, federated vot-ing and federated leader election. In federated voting, nodes vote on astatement and use a two-step protocol to confirm it. If each quorum ofnon-faulty nodes v intersects each quorum of non-faulty nodes v in atleast one non-faulty node, then v and v are intertwined [53]. It is guaran-teed that intertwined nodes would never approve a conflicting transaction[53]. In federated leader election, the algorithm allows nodes to pseudo-randomly select one or a small number of leaders in the quorum slice. Fig. 17.
Federated voting process [37].
SCP is a global consensus protocol consisting of three interrelatedcomponents - a nomination protocol, a ballot protocol, and a timeoutmechanism. The nomination phase is the initial operation in SCP, and itproposes new values as candidate values to reach an agreement.
N OM IN AT Ex is a statement that states x is a valid candidate consensus value. Eachnode that receives these values votes for a single value among these val-ues. The nomination phase eventually generates the same set of candidatevalues as a deterministic combination of all values on each intact node[53].Once the nomination phase is successfully executed, the nodes enterthe ballot phase. In the ballot phase, federated voting is used to commitor abort the values. An example of the three-step process used in FBA isshown in Figure 17. In the first step of the FBA process, a node v votes fora valid statement a by broadcasting the message. In the second step, v ac-cepts the a if v never accepted a values that contradicts a . If each member of v ’s quorum set claims to accept a , then the fact a is broadcasted again.The statement a is confirmed in the last step if each node in node v ’s quo-rum accepts a and v confirms a . However, there may be a stuck state sincethe node cannot conclude whether to abort or commit a value. SCP usestwo statements P REP ARE and
COM M IT , and a series of numberedballots to avoid stuck votes in the federated voting process. A statement
P REP ARE (cid:104) n, x (cid:105) states that no value other than x was or will ever bechosen in any ballot ≤ n . Another statement COM M IT (cid:104) n, x (cid:105) states thatvalue x is chosen in ballot n . A node has to confirm the P REP ARE (cid:104) n, x (cid:105) statement before voting for the
COM M IT (cid:104) n, x (cid:105) statement. Once the
COM M IT statement has been confirmed, the value x can be output bythe node. SCP provides liveness by using these two statements when thenode thinks a stuck ballot has been committed.The last and important part of SCP is the timeout mechanism. If thecurrent ballot n seems to be stuck, it will cause a new round of federatedvoting to start on a new ballot with a higher counter n + 1.This particular quorum model used in SCP allows the participatingnode to decide quorums, which is the critical difference between FBA andthe previous Byzantine agreement systems introduced in Sections 4.2 - 4.5above. The SCP protocol employing FBA claims no stuck state and canprovide low latency and flexible trust. The HotStuff algorithm proposed by Yin, Abraham, Gueta, and Malkhi[39] improves upon the PBFT. The HotStuff network is a partially syn-chronized network [54] with an adversary model of n = 3 f + 1. It uses aparallel pipeline to process the proposal, which is equivalent to combiningthe preparation and commitment phases of PBFT into a single phase. Theoriginal paper proposes two implementations of HotStuff, namely BasicHotStuff and Chained HotStuff.The Basic HotStuff protocol forms the core of HotStuff, which switchesbetween a series of views. The views switch according to a monotonicallyincreasing number sequence. A unique consensus leader exists within eachview. Each replica node maintains a tree structure of pending commandsin its memory. Uncommitted branches compete, and only one branchin a round will be agreed upon by the nodes. In the HotStuff protocol,branches are committed as the view number grows. Voting in HotStuffuses the cryptographic term QuorumCertif icate (QC), where each viewis associated with a QC that indicates whether enough replicas have ap-proved the view. If a replica agrees with a branch, it signs the branch with
Survey on Consortium Blockchain Consensus Mechanisms 33 its private key, creating a partial certificate [54] to send to the leader. Theleader collects n − f partial certificates, which can be combined into a QC.A view with a QC means that it receives the majority votes of the repli-cas. The leader collects signatures from n − f replicas by using thresholdsignatures [41, 55]. The process of collecting signatures consists of threephases, PREPARE, PRE-COMMIT, and COMMIT phases. Moreover,the entire algorithm consists of five phases, PREPARE, PRE-COMMIT,COMMIT, DECIDE, and FINALLY phases, as shown in Figure 18. Fig. 18.
Consensus in the HotStuff Protocol [56]
1. PREPARE. The leader denoted by the current highest view desig-nated as highQC , initiates a proposal for highQC , encapsulates it intoa PREPARE message with message content m = M SG ( P REP ARE , curP roposal , highQC ), and broadcasts it to all replicas. Replicas willdecide whether to accept the proposal or not, and then return a votewith partial signature to the leader if the proposal is accepted.2. PRE-COMMIT. When the leader receives votes from n − f replicas forthe current proposal curP roposal , it combines them into prepareQC ,encapsulates prepareQC into a PRE-COMMIT message, and broad-casts it to all replicas. The replica votes after receiving the aboveproposal message and returns the vote to the leader.3. COMMIT. When the leader receives the PRE-COMMIT votes from n − f replicas, it merges them into precommitQC , encapsulates a precommitQC into a COMMIT message, and broadcasts them to all replicas. The replica votes after receiving the above proposal mes-sage and returns the COMMIT vote to the leader. To ensure thesafety of the proposal, the replica is locked by setting its lockedQC to precommitQC .4. DECIDE. When the leader receives the COMMIT votes from n − f replicas, it merges them into one commitQC and then uses the DE-CIDE message to broadcast it to all replicas. After receiving this mes-sage, the replica confirms and submits the proposal in the commitQC ,executes the command and returns it to the client. After this, thereplica increases the viewN umber and starts the next view.5. FINALLY. If the system moves to the next view, each copy sends amessage to the next view’s leader with the message m = M SG ( N EW - V IEW, ⊥ , prepareQC ).Figure 18 shows that the processes in each phase of Basic HotStuff arevery similar to each other. A modified version of HotStuff called ChainedHotStuff was proposed [39] to optimize and simplify Basic HotStuff. In theChained HotStuff protocol, the replicas’ votes in the P REP ARE phaseare collected by the leader, and stored in the state variable genericQC .Then, genericQC is forwarded to the leader of the next view, essentiallydelegating the next phase’s (the PRE-COMMIT phase) responsibilitiesto the next view’s leader. Thus, instead of starting its new PREPAREphase alone, the next view’s leader actually executes the PRE-COMMITphase simultaneously. Specifically, the PREPARE phase of view v + 1also acts as the PRE-COMMIT phase of view v . The PREPARE phaseof view v + 2 acts as both the PRE-COMMIT phase of view v + 1 andthe COMMIT phase of view v . The flow of Chained HotStuff is shown inFigure 19. Fig. 19.
Chained HotStuff is a pipelined Basic HotStuff where a QC can serve indifferent phases simultaneously. [39] . Survey on Consortium Blockchain Consensus Mechanisms 35
Figure 19 shows that a node can be in different views simultaneously.Through a chained structure, a proposal can reach a consensus after threeblocks. In other words, it resembles a Three-Chain as shown in figure 20.An internal state converter enables the automatic switching of proposalsthrough genericQC . The chained mechanism in Chained HotStuff reducesthe cost of communication messages and allows pipelining of processing.In the implementation of Chained HotStuff, if a leader fails in obtainingenough QC, then it may appear that the view numbers of a node are notconsecutive. This issue can be solved by adding dummy nodes, as shownin Figure 20, where a dummy node has been added to force v , itself, and v to form a Three-Chain. Fig. 20.
The nodes at views v , v , v form a Three-Chain. The node at view v doesnot make a valid One-Chain in Chained HotStuff. [39]. HotStuff achieves O ( n ) message authentication complexity by improv-ing the distributed consistency algorithm’s efficiency using threshold sig-natures, parallel pipeline processing, and linear view changing. Comparedto PBFT, HotStuff can reach consensus pipelining without a complexview-change mechanism and improves consensus efficiency. The use of different consensus algorithms in enterprise blockchains im-pacts the overall performance of the system. In this section, we compareand summarize the eight consensus algorithms profiled thus far in this pa-per. We compare these algorithms along the lines of the following metrics:the degree of decentralization, scale of use, fault tolerance, performanceefficiency, and resource consumption. • Fault tolerance: Fault tolerance refers to the ability of the consensusalgorithm to tolerate both non-Byzantine faults (CFT) and Byzantinefaults (BFT). Fault tolerance also impact the security of the consensusprotocol.6 W. Yao et al.
The nodes at views v , v , v form a Three-Chain. The node at view v doesnot make a valid One-Chain in Chained HotStuff. [39]. HotStuff achieves O ( n ) message authentication complexity by improv-ing the distributed consistency algorithm’s efficiency using threshold sig-natures, parallel pipeline processing, and linear view changing. Comparedto PBFT, HotStuff can reach consensus pipelining without a complexview-change mechanism and improves consensus efficiency. The use of different consensus algorithms in enterprise blockchains im-pacts the overall performance of the system. In this section, we compareand summarize the eight consensus algorithms profiled thus far in this pa-per. We compare these algorithms along the lines of the following metrics:the degree of decentralization, scale of use, fault tolerance, performanceefficiency, and resource consumption. • Fault tolerance: Fault tolerance refers to the ability of the consensusalgorithm to tolerate both non-Byzantine faults (CFT) and Byzantinefaults (BFT). Fault tolerance also impact the security of the consensusprotocol.6 W. Yao et al. • Performance efficiency: Performance efficiency is measured by theblock generation rate and the number of Transactions Per Second(TPS) that the system can process. Block generation is expressed asthe time required for the entire process starting from the time whentransactions are packaged into blocks up to the time when consen-sus is completed and recorded on the blockchain. TPS represents thetransaction throughput, which is determined by the size of the datablock and the block generation speed. TPS is measured as the numberof transactions in the block divided by the length of time required forthe generation of the current block. The faster the block generationspeed of the algorithm used in the actual system, the greater is thetransaction throughput, and the higher is the algorithm’s performanceefficiency. • Degrees of decentralization: Decentralization does not mean that thereis no central node; rather, it implies there exists a relatively neutralentity that functions as the central node. In a round of reaching con-sensus, the node who decides the recording of transactions on thedistributed ledger is considered as the central node. All other nodeswill keep the data consistent around it. Therefore, we compare thedegree of decentralization of the algorithm according to the recordingnode’s selection rules and the number of selected recording nodes ineach round. • Scalability: The use scale refers to the number of network nodes thatthe algorithm can process in the system. • Resource consumption: Resource consumption refers to the computingpower, memory, input and output, and electricity resources that eachnode needs to consume in the process of reaching a consensus.
In this section, we present a summary of the various consensus algo-rithms presented in this paper (Table 2). The latency property shown inTable 2 is denoted as high, medium or low. High latency is indicated inminutes, medium is in seconds, and low is in milliseconds. These con-sortium blockchain consensus algorithms presented usually have betterperformance on TPS compared to the public blockchain system for thethroughput property. In previous work for throughput comparison [57],high represents TPS that is more than 1,000 TPS, medium denotes TPSbetween 100 and 1,000 TPS, and low denotes throughput less than 100TPS. Typically, the throughput property in public blockchains is in the
Survey on Consortium Blockchain Consensus Mechanisms 37 range of 100 - 1000 TPS, and the consortium blockchain consensus al-gorithms presented in this paper have a TPS that exceeds. We proposethat the measurement method should be redefined, with high represent-ing more than 2,000 TPS, medium denoting TPS between 1,500 to 2,000,and low denoting a throughput that is less than 1,500 TPS.
Table 2.
Comparison of Consortium Consensus Algorithms [57, 58, 59]
Consensus AdversaryTolerance Scalability Latency Throughput Examples ofApplications
Paxos n = 2 f + 1 High Low Medium Google Chubby,ZookeeperRaft n = 2 f + 1 High Low Medium IPFSPBFT n = 3 f + 1 Low Low Low Hyperledger FabricRBFT n = 3 f + 1 High Low High Hyperledger IndyBFT-SMART n = 3 f + 1 High Low High R3 Coda, SymbiontRPCA n = 5 f + 1 High Medium Medium RippleSCP n = 3 f + 1 High Medium Low StellarHotStuff n = 3 f + 1 High Low High Libra Another comparison is regarding the communication complexity ofalgorithms in this paper. The results are shown in Table 3.
Table 3.
Communication Complexity of selected protocols
Consensus Normal Case Leader Failure
Paxos [60] O ( n ) -Raft [33] O ( n ) -PBFT [39] O ( n ) O ( n )RBFT [35] O ( n ) O ( n )BFT-SMART [39] O ( n ) O ( n )RPCA [60] O ( nK ), K is the size of UNL. -SCP [60] O ( nK ), K is the size of quorum. -HotStuff [39] O ( n ) O ( n ) The Paxos algorithm has high performance and low resource consump-tion, which can enable a distributed system to reach consensus when thenumber of normal nodes is greater than half of the total nodes. Paxos’properties make it suitable only for distributed systems with high non-Byzantine fault tolerance. It cannot be used for blockchains that require
Table 4.
Pros and Cons
Consensus Advantages Disadvantages
Paxos High Performance. Cannot tolerant Byzantine failure.Be lack of understandability.Raft High Performance.Improved understandability com-pares to Paxos. Cannot tolerant Byzantine failure.PBFT No tokens.High performance.High security. High communication volume.Low efficiency of operation whenthe number of nodes is too large.RBFT Can rapidly find malicious primarynode. Cannot deal with closed-loop sys-tems. [61]BFT-SMART Implement dynamic addition anddeletion of nodes.High system throughput. Cannot prevent malicious nodesbeing primary node.RPCA High efficiency.High security. Low fault tolerance.More threat to the verificationnodes.SCP Fast transaction speeds.Low transaction costs.Flexible Trust. Can only guarantee safety iftrusted nodes are adequate.HotStuff High performance.Linear complexity for messagecommunication and validation.No complex view-change mecha-nism compared to PBFT. Less implementations. Survey on Consortium Blockchain Consensus Mechanisms 39
Byzantine fault tolerance. Google Chubby [62] is a typical applicationusing the Paxos algorithm, which provides a coarse-grained lock servicefor the file system to store a large number of small files.Like the Paxos algorithm, Raft can enable the distributed system toreach a consensus if more than half of the nodes are non-failure nodes inthe distributed system. However, Raft has one and only one legal leaderin any round of consensus. Since the original objective of proposing is tosimplify the Paxos algorithm’s process and make a more understandableand implementable algorithm compared to Paxos, Raft’s fault tolerance,performance efficiency, degree of decentralization, use scale, and resourceconsumption are very similar to the Paxos algorithm.The PBFT algorithm can tolerate both non-Byzantine errors andByzantine errors simultaneously by sending broadcasts to the entire net-work in each round to reach consensus. This allows each node to partic-ipate in electing the primary node. This mechanism ensures that PBFThas the capabilities to maintain consistency, availability, and anti-fraudattacking. However, with the increase in the total number of nodes, thegrowth ratio of the total number of broadcast messages is quadratic. Thisresults in rapid performance degradation that is faster than linear. There-fore, the PBFT algorithm cannot support public networks since they arelarge-scale. Instead, it is more suitable for consortium blockchain andprivate blockchain.The RBFT algorithm was first proposed for better Byzantine faulttolerance. In earlier BFT algorithms such as PBFT, Prime [63], Aardvark[64], and Spinning [65], if the primary is malicious, the whole system’sperformance is degraded. RBFT proposes a new model: multiple PBFTprotocol instances are executed in parallel using multi-core machines,and only the results of the master instance are executed. Each protocolinstance is monitored for performance and compared with the masterinstance. If a ratio of the performance of the master instance and thebest backup instance is lower than a preselected threshold, the primarynode of the master is considered malicious, and a replacement process isinitiated. If one or more Byzantine faulty nodes exist in the blockchainnetwork, it has been shown that the maximum performance degradationof RBFT is 3%, which is better than other protocols, for instance, Primeis 80%, Aardvark is 87%, and Spinning is 99%.The BFT-SMART algorithm is an improvement to the PBFT algo-rithm. In addition to the implementation of consensus, BFT-SMART alsoprovides state transition and reconfiguration services, addition and dele-tion of nodes in the system, and effectively improves the system’s perfor- mance and efficiency. The Symbiont programming language implementsthe BFT-SMART algorithm, which can reach a throughput of 8000 TPSin a 4-node network cluster, which is in line with the literature’s expectedperformance [42].The advantage of the RPCA algorithm is its relatively high perfor-mance and efficiency. Ripple can generate a block every 3 seconds witha transaction throughput that can reach 1500 TPS. A disadvantage ofRPCA is that the fault tolerance is lower than other PBFT-likely con-sensus algorithms. Since RPCA’s adversary mode is n = 5 f + 1, in orderto tolerate f faulty nodes, the total number of nodes required in RPCAis greater than other algorithms that have adversary mode as n = 3 f + 1.The verification node is pre-configured, and the degree of decentralizationis low. Simultaneously, the reliability of the verification node directly af-fects the operation of the entire network.The SCP algorithm is a new consensus mechanism based on the Feder-ated Byzantine Agreement, and it has four essential attributes: decentral-ized control, flexible trust, low latency, and asymptotic security. Unlikeother BFT protocols, the transaction is not verified by all nodes in SCP. Ifany node in a quorum has verified a transaction, the other nodes will trustthat node and skip the verification process. This mechanism allows SCPto process transactions quickly, rather than other consensus algorithms ina public blockchain. SCP emphasizes maintaining the network’s activity,and instead of choosing nodes, any node can join each other’s trust listfor transactions if it follows the policy. With SCP, the Stellar network iscurrently running approximately 100 nodes [66].HotStuff consensus algorithm summarizes the features from otherBFT-based consensus algorithms such as PBFT and Tendermint [38],and implements a new algorithm with safety, liveness, and responsive-ness. Responsiveness allows the blockchain node to confirm the blocksfast when the network is under a reliable condition; otherwise, it can waitfor more time to confirm if the network condition is limited. Hotstuff canreduce the communication complexity to linear and guarantee responsive-ness by using threshold signatures, three rounds of voting, and a chainedstructure to acknowledge a block [39].In summary, the advantages and disadvantages of the eight consensusalgorithms are listed in Table 4. Survey on Consortium Blockchain Consensus Mechanisms 41
Consensus algorithms lie at the core of blockchain and have become arapidly emerging area of research. This paper summarizes the working ofeight consortium blockchain consensus algorithms: Paxos, RAFT, PBFT,RBFT, BFT-SMART, RPCA, SCP, and HotStuff. We discuss five crucialaspects of the operation of each of these algorithms, namely, fault toler-ance, performance, efficiency, decentralization, resource consumption, andscalability. Our work in this paper lays the groundwork for researchers,developers, and the blockchain community at large to understand thecurrent landscape of consensus technologies. The potential of blockchainto revolutionize use cases in various scenarios from finance to agriculturerelies on the blockchain solution’s ability to achieve a balance betweenthree overarching objectives: scalability, security, and decentralization.The choice of consensus algorithm has an outsize impact on the perfor-mance of blockchain applications. Therefore, ongoing research into thedesign and implementation of consensus algorithms will go a long way inadapting blockchain for diverse applications.
Acknowledgment
The research is partially supported by FHWA EAR 693JJ320C000021. ibliography [1] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System.Cryptography Mailing list at https://metzdowd.com, March 2009.[2] Melanie Swan. Blockchain: blueprint for a new economy. O’Reilly,first edition edition, 2015.[3] Gavin Wood et al. Ethereum: A secure decentralised generalisedtransaction ledger. Ethereum project yellow paper, 151(2014):1–32,2014.[4] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin,Konstantinos Christidis, Angelo De Caro, David Enyeart, Christo-pher Ferris, Gennady Laventman, Yacov Manevich, and et al. Hy-perledger fabric: a distributed operating system for permissionedblockchains. In Proceedings of the Thirteenth EuroSys Conference,page 1–15. ACM, Apr 2018.[5] HyperLedger. Case study: How walmart brought unprecedentedtransparency to the food supply chain with hyperledger fabric, Mar2019.[6] HyperLedger. Case study: How culedger protects credit unionsagainst fraud with hyperledger indy, 2020.[7] HyperLedger. When hyperledger sawtooth met kubernetes - simpli-fying enterprise blockchain adoption, 2020.[8] Libra Association Members. Libra White Paper | Blockchain, Asso-ciation, Reserve, April 2020.[9] Bitcoin Wiki. Help:faq - bitcoin wiki, 2020.[10] Jorge Bernal Bernabe, Jose Luis Canovas, Jose L. Hernandez-Ramos,Rafael Torres Moreno, and Antonio Skarmeta. Privacy-preservingsolutions for blockchain: Review and challenges. IEEE Access,7:164908–164940, 2019.[11] Fred B. Schneider. Implementing fault-tolerant services using thestate machine approach: a tutorial. ACM Computing Surveys,22(4):299–319, Dec 1990.[12] Wikipedia. Adversary (cryptography), Dec 2020. Page Version ID:995747901.[13] Rui Zhang, Rui Xue, and Ling Liu. Security and privacy onblockchain. arXiv:1903.07602 [cs], Aug 2019. arXiv: 1903.07602.[14] Yifan Mao, Soubhik Deb, Shaileshh Bojja Venkatakrishnan, SreeramKannan, and Kannan Srinivasan. Perigee: Efficient peer-to-peer net-
Survey on Consortium Blockchain Consensus Mechanisms 43 work design for blockchains. arXiv:2006.14186 [cs, math, stat], Jun2020. arXiv: 2006.14186.[15] Bitcoin Wiki. Protocol rules - bitcoin wiki, 2020.[16] Hye-Young Paik, Xiwei Xu, H. M. N. Dilum Bandara, Sung UneLee, and Sin Kuang Lo. Analysis of data management in blockchain-based systems: From architecture to governance. IEEE Access,7:186091–186107, 2019.[17] Bitcoin. Block chain — bitcoin, 2009.[18] Michael Szydlo. Merkle tree traversal in log space and time.In International Conference on the Theory and Applications ofCryptographic Techniques, pages 541–554. Springer, 2004.[19] Pham Hoai Luan, Thi Hong Tran, Tri Phan, Duong Le Vu Trung,Duckhai Lam, and Yasuhiko Nakashima. Double sha-256 hardwarearchitecture with compact message expander for bitcoin mining.IEEE Access, 8:1–1, 01 2020.[20] Ying-Chang Liang. Blockchain for dynamic spectrum management.In Dynamic Spectrum Management, pages 121–146. Springer, 2020.[21] Chris Dannen. Introducing Ethereum and Solidity: Foundations ofCryptocurrency and Blockchain Programming for Beginners. Apress,2017.[22] Harald Vranken. Sustainability of bitcoin and blockchains. CurrentOpinion in Environmental Sustainability, 28:1 – 9, 2017. Sustain-ability governance.[23] Dylan Yaga, Peter Mell, Nik Roby, and Karen Scarfone. Blockchaintechnology overview. arXiv:1906.11078 [cs], page NIST IR 8202, Oct2018. arXiv: 1906.11078.[24] C. Dods, N. P. Smart, and M. Stam. Hash based digital signatureschemes. In Nigel P. Smart, editor, Cryptography and Coding, page96–115. Springer Berlin Heidelberg, 2005.[25] S. Chandra, S. Paira, S. S. Alam, and G. Sanyal. A compara-tive survey of symmetric and asymmetric key cryptography. In2014 International Conference on Electronics, Communication andComputational Engineering (ICECCE), pages 83–93, 2014.[26] Don Johnson, Alfred Menezes, and Scott Vanstone. The ellipticcurve digital signature algorithm (ecdsa). International Journal ofInformation Security, 1(1):36–63, Aug 2001.[27] Supriya Thakur and Vrushali Kulkarni. Blockchain and its ap-plications – a detailed survey. International Journal of ComputerApplications, 180(3):29–35, Dec 2017.[28] S. King and Scott Nadal. Ppcoin: Peer-to-peer crypto-currency withproof-of-stake. 2012. [29] VeChain Foundation. Vechain whitepaper, Dec 2019.[30] HyperLedger Sawtooth. Poet 1.0 specification — sawtooth v1.0.5documentation, 2015.[31] Stefan Dziembowski, Sebastian Faust, Vladimir Kolmogorov, andKrzysztof Pietrzak. Proofs of space. Cryptology ePrint Archive,Report 2013/796, 2013. https://eprint.iacr.org/2013/796.[32] L. Lamport. Paxos Made Simple, 2001.[33] D. Ongaro and J. Ousterhout. In search of an understandable con-sensus algorithm. In USENIX Annual Technical Conference, 2014.[34] Miguel Castro, Barbara Liskov, et al. Practical byzantine fault tol-erance. In OSDI, volume 99, pages 173–186, 1999.[35] P. Aublin, S. B. Mokhtar, and V. Qu´ema. RBFT: Redundant Byzan-tine Fault Tolerance. In 2013 IEEE 33rd International Conference onDistributed Computing Systems, pages 297–306, July 2013. ISSN:1063-6927.[36] D. Schwartz, Noah Youngs, and A. Britto. The ripple protocol con-sensus algorithm. 2014.[37] David Mazi`eres. The Stellar Consensus Protocol : A Federated Modelfor Internet-level Consensus, 2015.[38] Jae Kwon. Tendermint: Consensus without mining. Draft v. 0.6, fall,1(11), 2014.[39] Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta,and Ittai Abraham. HotStuff: BFT Consensus in the Lens ofBlockchain. arXiv:1803.05069 [cs], July 2019. arXiv: 1803.05069.[40] F. P. Junqueira, B. C. Reed, and M. Serafini. Zab: High-performancebroadcast for primary-backup systems. In 2011 IEEE/IFIP 41stInternational Conference on Dependable Systems & Networks(DSN), page 245–256. IEEE, Jun 2011.[41] Guy Golan Gueta, Ittai Abraham, Shelly Grossman, Dahlia Malkhi,Benny Pinkas, Michael K. Reiter, Dragos-Adrian Seredinschi, OrrTamir, and Alin Tomescu. Sbft: a scalable and decentralized trustinfrastructure. arXiv:1804.01626 [cs], Jan 2019. arXiv: 1804.01626.[42] A. Bessani, J. Sousa, and E. E. P. Alchieri. State Machine Repli-cation for the Masses with BFT-SMART. In 2014 44th AnnualIEEE/IFIP International Conference on Dependable Systems andNetworks, pages 355–362, June 2014. ISSN: 2158-3927.[43] neo project. dbft 2.0 algorithm, 2014.[44] Wen-Cheng Shi and Jian-Ping Li. Research on consistency of dis-tributed system based on paxos algorithm. In 2012 InternationalConference on Wavelet Active Media Technology and InformationProcessing (ICWAMTIP), page 257–259. IEEE, Dec 2012.
Survey on Consortium Blockchain Consensus Mechanisms 45 [45] Aleksey Charapko, Ailidani Ailijiang, and Murat Demirbas. Bridg-ing paxos and blockchain consensus. In 2018 IEEE InternationalConference on Internet of Things (iThings) and IEEE GreenComputing and Communications (GreenCom) and IEEE Cyber,Physical and Social Computing (CPSCom) and IEEE Smart Data(SmartData), pages 1545–1552. IEEE, 2018.[46] Leslie Lamport, Robert Shostak, and Marshall Pease. The ByzantineGenerals Problem. ACM Transactions on Programming Languagesand Systems, 4(3):20, 1982.[47] Libo Feng, Hui Zhang, Yong Chen, and Liqi Lou. Scalable dynamicmulti-agent practical byzantine fault-tolerant consensus in permis-sioned blockchain. Applied Sciences, 8(10):1919, Oct 2018.[48] Daniel J. Bernstein. The poly1305-aes message-authentication code.In Henri Gilbert and Helena Handschuh, editors, Fast SoftwareEncryption, pages 32–49, Berlin, Heidelberg, 2005. Springer BerlinHeidelberg.[49] Eduardo Alchieri, Fernando Dotti, Odorico M. Mendizabal, and Fer-nando Pedone. Reconfiguring parallel state machine replication.In 2017 IEEE 36th Symposium on Reliable Distributed Systems(SRDS), page 104–113. IEEE, Sep 2017.[50] J. Sousa and A. Bessani. From byzantine consensus to bft statemachine replication: A latency-optimal transformation. In 2012Ninth European Dependable Computing Conference, page 37–48,May 2012.[51] Christian Cachin. Yet another visit to paxos. IBM Research, Zurich,Switzerland, Tech. Rep. RZ3754, 2009.[52] Brad Chase and Ethan MacBrough. Analysis of the XRP LedgerConsensus Protocol. arXiv:1802.07242 [cs], February 2018. arXiv:1802.07242.[53] David Mazi`eres, Giuliano Losa, and Eli Gafni. Simplified scp, Mar2019.[54] T-H Hubert Chan, Rafael Pass, and Elaine Shi. Pala: A sim-ple partially synchronous blockchain. IACR Cryptol. ePrint Arch.,2018:981, 2018.[55] Christian Cachin and Marko Vukoli´c. Blockchain Consensus Proto-cols in the Wild. arXiv:1707.01873 [cs], July 2017. arXiv: 1707.01873.[56] The Ontology Team. Hotstuff: the consensus protocol behind face-book’s librabft, Sep 2019.[57] Mehrdad Salimitari and Mainak Chatterjee. A survey on consensusprotocols in blockchain for iot networks. arXiv:1809.05613 [cs], Jun2019. arXiv: 1809.05613.6 W. Yao et al.