AlphaBlock: An Evaluation Framework for Blockchain Consensus Protocols
Haitao Xiang, Zhijie Ren, Ziheng Zhou, Ning Wang, Hanqing Jin
AAlphaBlock: An Evaluation Framework for BlockchainConsensus Protocols
Haitao Xiang [email protected] Institute, University ofOxfordOxford, UK
Zhijie Ren
VeChainShanghai, [email protected]
Ziheng Zhou
VeChainShanghai, [email protected]
Ning Wang [email protected] Institute, University ofOxfordOxford, UK
Hanqing Jin [email protected] Institute, University ofOxfordOxford, UK
ABSTRACT
Consensus protocols play a pivotal role to balance security andefficiency in blockchain systems. In this paper, we propose an eval-uation framework for blockchain consensus protocols termed asAlphaBlock. In this framework, we compare the overall perfor-mance of Byzantine Fault Tolerant (BFT) consensus and NakamotoConsensus (NC). BFT consensus is reached by multiple rounds ofquorum votes from the supermajority, while NC is reached by ac-cumulating credibility with the implicit voting from appendingblocks. AlphaBlock incorporates the key concepts of Hotstuff BFT(HBFT) and Proof-of-authority (PoA) as the case study of BFT andNC. Using this framework, we compare the throughput and latencyof HBFT and PoA with practical network and blockchain configu-rations. Our results show that the performance of HBFT dominatesPoA in most scenarios due to the absence of forks in HBFT. More-over, we find out a set of optimal configurations in AlphaBlock,which sheds a light for improving the performance of blockchainconsensus algorithms.
CCS CONCEPTS • Computer systems organization → Dependable and fault-tolerant systems and networks ; •
Networks → Network Proto-cols.
KEYWORDS
Blockchain, Blockchain Performance, Byzantine Fault Tolerant,Nakamoto Consensus, Pareto frontier
Blockchain technology is one of the most significant innovations inrecent years that may disrupt many industries. As a decentralizedand unchangeable ledger that is jointly maintained by untrustedparties without a globally trusted intermediary, it promises integrity,transparency and resilience that are critical to many economic ac-tivities [2]. Although obtaining its cognition from Bitcoin [24], ithas gained attention in more than the financial industry. In govern-ment [29], patent [12], voting [1] and real estate [27], blockchaintechnology serves as an attractive alternative to current centralizedintermediaries with huge trust costs. The main obstacle lying before the wide adoption of blockchaintechnology is its unsatisfactory performance and poor scalability ascompared to its traditional counterparts. This difficult tradeoff be-tween system performance and intermediary trustworthiness stopsmost businesses interested in blockchain technology. Therefore itis crucial to find out the features and properties that bottleneckthe system performance and scalability. Among the features, theconsensus protocol is a critical one. A consensus mechanism guar-antees that all honest nodes will eventually agree on a consistencyledger in asynchronous and untrusted networks.Currently, two types of mainstream consensus protocols prevail.One is Nakamoto Consensus (NC) originated from Bitcoin [24], inwhich the consensus of a proposed block is not definitive, but prob-abilistic. More precisely, the probability that there exists anotherhonest node agreeing on a conflicting block drops proportionallyto the number blocks appending to it. Then, a block is seen as“confirmed” when this probability is lower than a predeterminedsecurity parameter. For instance, Bitcoin confirms a block whenthere are five blocks appending to it.The other is Byzantine Fault Tolerant (BFT), in which the con-sensus is reached through multiple rounds of quorum vote, wherea block is guaranteed to reach absolute consistency in the asyn-chronous network when it receives votes from the supermajority(more than 2/3 of the nodes) two or three times [8, 32]. It is worthnoting that NC can be used in either permissioned or permission-less networks. In permissioned networks, the number of honestnodes should be more than 50% of the population. In permissionlessnetworks, a proof of the possession of a certain resource should beincluded in each block and the honest nodes should be in possessionof more than 50% of that resource. BFT algorithms, on the otherhand, are mostly used in permissioned network where the numberof adversaries is less than 1/3 of the population.Both consensuses have their merits and disadvantages. BFT algo-rithms like [8] are shown to achieve consensus with higher through-put and lower latency in small networks, yet quorum votes are in-volved in dampening system performance. NC algorithms [24, 30],on the other hand, does not require quorum votes which is complexin communication. Hence, it is usually believed to achieve higherthroughput and lower latency in large practical networks. Recently,new BFT algorithms, like those in [18, 22, 32], are proposed for a r X i v : . [ c s . D C ] J u l onference’17, July 2017, Washington, DC, USA Haitao Xiang, Zhijie Ren, Ziheng Zhou, Ning Wang, and Hanqing Jin blockchains with a relatively large network and good performanceunder laboratory settings. The design logic of BFT and NC differsin various features including the quorum votes, and these featuresall affect system performance.Given the different design logic of the two consensuses, re-searchers and practitioners will question which consensus is bettergiven a certain network condition and blockchain application. Prac-tically, by “different network conditio” we mean different networkdelay, bandwidth and byzantine ratio. By “better” we mean greaterthroughput and less latency. Therefore, it is desirable to have aframework to compare the performance of two protocol under apractical and general setting.In literature, there are various evaluation frameworks that com-pare the performance of blockchain systems. Gervais et al. [17]propose a framework to compare different Proof-of-Work (PoW)blockchains. In this framework, the performance of a blockchainis measured by its throughput when a certain security level is ob-tained under the optimal adversary attack. Dinh et al. [11] proposeBLOCKBENCH to evaluate the throughput, latency and securityof private blockchains. They compare the performance of threemajor blockchains: Parity, Ethereum and Hyperledger Fabric. Theyfound that these state of the art blockchain systems fall behind atraditional database system for business-level workloads. Cromanet al. [9] propose a framework to measure the economic cost ofdifferent PoW systems. However, none of the above works evermake the quantitative comparison across the NC and BFT consen-suses, needless to say formulating the two consensuses within onecoherent framework.In this paper, we present AlphaBlock, an evaluation frameworkto compare the performance of NC and BFT in practice. Criticalfeatures of the two consensuses, especially those affecting the per-formance of the blockchain in practical network scenarios, are mod-elled, including quorum communication, fork rate, empty block,the interval between blocks, block broadcast etc. Moreover, thesefeatures are all translated into two key performance indicators:throughput and latency. We show how network delay, bandwidth,and the ratio of the adversaries could affect the performance of bothconsensuses. Eventually, we give recommendations and generalprinciples on the selection and the configuration of consensus invarious networks. NC lays the critical foundation for not only Bitcoin [24], but alsoother mainstream cryptocurrency designs like Litecoin [19] andEthereum [30], which promises a bright future of decentralized pay-ment and financial system [20]. However, with its wide adoption,the concerns over its bottlenecks are getting louder. The concernof undesirable performance is partially resolved with leader selec-tion based algorithms like [14, 21] or graph-based protocol likePHANTOM [26].The problem of BFT is proposed in the 1980s by Lamport et al. in[23] and has been extensively studied before blockchain was born[3, 6, 8]. Essentially, BFT consensus can be categorized into state-machine replication protocols [25] that finds majority consensus inthe presence of malicious agents, which naturally meets the demandof blockchain. Therefore, a lot of BFT based systems were proposed, like Tendermint [22], Algorand [18], Casper FFG [7] and BEAT [13].Classical BFT algorithms like PBFT [8] are criticized for its poorscalability [28], namely, an O( N ) message complexity, which isnot suitable for blockchains in large networks. Several blockchainapplication-oriented BFT algorithms like Algorand, Tendermintand Hotstuff BFT (HBFT)[32] have reduced the average messagecomplexity per transaction in a normal consensus process to O( N ) ,which is identical to NC algorithms. In particular, Hotstuff BFT alsoachieves optimal responsiveness and O( N ) message complexity forview change, which makes it similar in form to NC algorithms.In the next subsection, we will briefly introduce Proof-of-Authority(PoA) algorithm and HBFT algorithm, which is an NC algorithm anda BFT algorithm, respectively. In each subsection, we will summa-rize performance-related factors from 3 levels: network, blockchainand protocol, which will motivate the proposition of our evaluationframework. PoA is a type of permissioned NC algorithms that are used byblockchains like Parity and VeChain . In this paper, we proposea simple PoA algorithm which is merely a permissioned versionof PoW. Firstly, we assume that honest nodes have a consistentview of Global Standard Time (GST) and the time is divided intorounds with a predetermined duration. Then, associated with eachblock, rather than a hash preimage proving the computation workconducted by the block proposer, a proof proving that the block isproposed by an authorized node which is in charge of proposingblock in that round is provided.The block will be broadcast to the network through gossip pro-tocol. When each node receives a block, it should first validate theblock before broadcast it and append it to its blockchain. Invalidblock, i.e., blocks including invalid transactions or proposed by theincorrect or unauthorized nodes, will not be broadcast. A maliciousnode may create a fork, i.e., more than one valid block in a round.Then, honest nodes should apply the “longest chain rule” to de-termine the valid chain and the valid block. It is guaranteed thathonest nodes could eventually reach consensus if blocks could besynchronized in a round and honest nodes are more than 50% ofthe network. In HBFT, in each round, a leader is selected according to a prede-termined schedule. When a block is proposed by the leader, theleader will broadcast the block to the whole network and all nodesshould send their votes with their signature to the leader to partici-pate in the consensus process. When 2 f agree with votes from thenetwork are received, a quorum consensus (QC) is reached. Here, f is number of the adversaries and 3 f + ≤ N holds. In HBFT, athree-phase commitment approach will be used to reach consensusfor this block. More specifically, a block is only confirmed whenit reaches QC for 3 times. In this paper, we consider the chainedHBFT proposed in [32], where the three-phase commitment schemeis pipelined in a chain. More precisely, in each round, a block is Proof-of-Authority Chains - Wiki Parity Tech Documentation:https://wiki.parity.io/Proof-of-Authority-Chains lphaBlock: An Evaluation Framework for Blockchain Consensus Protocols Conference’17, July 2017, Washington, DC, USA proposed with 2 f + f votes could be collected with high probability. As in the background, our framework should consist of a moduleto describe network properties, a module to describe blockchainproperties, and a protocol module that accommodates both BFT andNC consensuses. We first introduce factors in the three modules,and define throughput and latency by these factors. Then we intro-duce the evaluation framework (AlphaBlock), which is essentiallya system with a block proposing leader and a block validating &confirming committee. We simulate the AlphaBlock multiple timesto obtain its average throughput and latency. We also fit BFT andNC into the framework in this section.
In this section, we introduce key concepts relating to our Alph-aBlock.
Number of nodes N is the number of agents in the blockchainsystem. Committee size C is the number of agents of the block commit-tee. The committee is used to validate and confirm a block. In BFT,the committee size C = N , namely the whole network needs toreach consensus in validating a block. In NC, a block is validated in-dividually and C =
0, namely no consensus is needed in validatinga block. In AlphaBlock, C can take any integer value between 0 and N , which enable framework to accommodate more consensusesother than BFT and NC. Byzantine ratio α is the ratio of malicious nodes in the blockchainsystem. The malicious nodes will play to dampen the system per-formance and lower the system safety. To measure the performanceof a system, we consider the case with the worst behaviour ofmalicious nodes. Therefore, when a block proposing node is mali-cious, we assume it will try to create a fork when we compute forkrate, and it will try to create an empty block when we computeprobability of empty block, or conversely block rate. Byzantine number f is the number of the malicious nodes,and given α and N , we have f = ⌈( N − ) α ⌉ . Endorsement size d is the minimum number of committeemembers needed to validate a block. In BFT, d = f , namely theleader has to collect at least d votes or signatures to validate a blockin a round. In NC, no committee is needed to validate a block, so d =
0. Another choice of C is also permissible in AlphaBlock. Effective Bandwidth B width is the overall network bandwidthdetermined by B width = data sizetime to broadcast data to the whole network . (1) Communication network G ( N , p , D , B width ) is a randomly con-nected graph with parameters • N nodes; • the linkage probability p ; • the delay factor D ; • the effective bandwidth of the network B width ;In AlphaBlock, we assume the communication delay τ betweenlinked nodes is lognormal with mean 0 and variance D , and mes-sages propagate along the path with the shortest delay. Block size B size is the maximum number of transactions a blockcan hold. Since we are interested in the system theoretical perfor-mance, in the AlphaBlock workflow we assume each time a blockis proposed, it contains B size transactions. Message size M size is the size of a message. We define the mes-sage as information other than block, because the propagation ofthese information is dominated by network latency rather thanbandwidth. Security level ϵ is a maximal acceptable level of the probabilitythat an inconsistency occurs in a system. Here, an inconsistencymeans that two honest nodes agree on different blocks. It seems thatAlphaBlock is unfair for BFT in the sense that the consistency inBFT is definitive. However, as it is commonly believed that a smallenough ϵ is secure enough and NC and BFT are indistinguishablyused in many blockchain applications, it is reasonable to directlycompare the performance of NC and BFT giving a small ϵ . Simulation rounds SR is the number of rounds of simulationof AlphaBlock to compute the system performance. Block interval B interval is the time interval between two blocks.It is subject to three factors: block broadcast time (BBT), committeecommunication time (CCT), and blockhead broadcast latency (BBL).The BBT is the time needed to broadcast the block to the wholenetwork, expressed as:BBT = B size / B width . (2)The CCT is consensus-based. In BFT and all AlphaBlock with a non-zero endorsement committee, it takes 1 round of communicationfor the leader to collect votes and send out collected votes, and thetime is delay dominant, so approximately two times the d th delay.CCT C > = × d th delay from leader to committee . (3)In NC, it does not require committee communication, soCCT C = = . (4)The BBL is the biggest delay of block broadcast, so it is the maximumof delay from the leader to all N member nodes.BBL = max ( delay from leader to N members ) . (5)Putting together, we have B interval = max ( BBT , CCT , BBL ) . (6) Fork rate F rate is the probability of fork. In AlphaBlock, a forkemerges when the leader and no less than d committee members onference’17, July 2017, Washington, DC, USA Haitao Xiang, Zhijie Ren, Ziheng Zhou, Ning Wang, and Hanqing Jin Table 1: Worst case attack on liveness
Case Leader Committeemember ProbabilityCase 1 Malicious ≥ α Case 2 Good < d ( − α )× Hygcdf ( C − d + , N − , N × α , C ) are malicious. Therefore F rate = Pr ( fork ) = α × Hygcdf ( d | N − , N α − , C ) . (7)where Hygcdf ( X | M , K , Y ) is the cumulative distribution functionof hypergeometric distribution as follows:Hygcdf ( X | M , K , Y ) = (cid:213) ≤ x < X (cid:0) Kx (cid:1) (cid:0) M − KY − x (cid:1)(cid:0) MY (cid:1) . (8)Interestingly, equation 7 holds in both BFT and NC. In BFT, the forkrate is 0, so equation 7 applies. In NC, the fork rate is α , so equation7 applies as well. Block rate B rate is the probability of successfully proposing ablock in a round, which requires no compromise on liveness. Wecompute block rate by considering the worst case attack on liveness,as shown in Table 1, which means when a committee could eithercreate a fork or empty round, it would choose an empty round.Therefore B rate = ( − α ) × ( − Hygcdf ( C − d + | N − , N × α , C )) . (9)Interestingly, equation 9 holds in both BFT and NC. In BFT, theblock rate is 1 − α , so equation 9 applies. In NC, the fork rate is1 − α , equation 9 applies as well. Committee rate C rate is the proportion of bandwidth used bycommittee communication. C rate = × M size × M size + × B size , (10)where CC means committee communication. In BFT, C rate is non-zero but small. In NC, C rate is 0. Bandwidth efficiency B eff is how efficiently the bandwidth isused for the transmission of the eventual confirmed transactions.Two relevant factors: fork will waste bandwidth, and committeecommunication will also occupy bandwidth. For simplicity, wefirst consider the scenario that the malicious leader and committeewill create exactly one fork when they have the chance to do so,and consider other scenarios in Subsection 4.4. Subtracting thetwo factors will give net block propagating bandwidth. Therefore,bandwidth efficiency goes as follows: B eff = ( − F rate ) × ( − C rate ) . (11) Confirmation number K is the number satisfying ( F rate ) K ≤ ϵ , (12)where ϵ is the security level.Note that the confirmation of HBFT and PoA are very different asthe consensus types and the synchronous assumptions are different.However, the performance of both algorithms are compared directlyregardless of their consensus. Hence, in a practicality perspective, we simply use “double standards” on the confirmation, accordingto their own confirmation rules in each consensus algorithm. K = (cid:26) ⌈ log ϵ / log F rate ⌉ , PoA3 , HBFT . (13) We are interested in the throughput and latency of the blockchainsystem.
Throughput T is evaluated as transactions per second, andit is originally concerned with number of transactions within ablock interval. However, due to forks, empty blocks, and waste ofbandwidth due to committee communication, the throughput atsecurity level ϵ is adjusted as follows: T = B size B interval × B rate × B eff . (14) Latency L is evaluated as average time delay to confirm a trans-action. it is originally concerned with number of appending blocks K needed to confirm a block, which is originally equivalent to num-ber of block intervals. However, due to empty rounds, K needs tobe adjusted by block rate, so the latency at security level ϵ is asfollows: L = KB rate × B interval . (15) With key concepts defined, we propose the evaluation framework,namely AlphaBlock, which is able to accommodate to both PoAof NC and HBFT of BFT. AlphaBlock loop over the following fiveparts adapted from [31]: Initialization; block proposal; informationpropagation; block validation; block finalization. • Initialization . A communication network G ( N , p , D , B width ) is set according to 3.1.1, in which there are a proportion of α malicious or byzantine nodes. At the beginning of eachround, A leader is randomly selected to propose a block,which matches PoA and HBFT. A committee of size C israndomly selected to validate a block, and at least d endorse-ments are needed to validate a block. In HBFT, C = N , d = f .In PoA, C = , d = • Block Proposal . In a round, the leader proposes a block,in which B size transactions are added by the leader. Theprobability that selected leader happens to be malicious is α .If the leader is malicious, it may create an empty block, andthe probability of a non-empty block is block rate B rate . Themalicious leader may also create a fork, and the probabilityof a fork is fork rate F rate . Note B rate and F rate apply to bothHBFT and PoA as explained in key concepts. • Information propagation . When a block is proposed bythe leader, the leader will send the block to the whole net-work using gossip, which takes time the bigger of broadcasttime BBT and BBL. Meanwhile the leader communicate withthe committee to confirm the block, which takes time CCT.Note BBT, BBL and CCT are explained in block interval ofkey concepts and all accommodated to HBFT and PoA. There-fore, the block propagation time BBT, the block broadcast lphaBlock: An Evaluation Framework for Blockchain Consensus Protocols Conference’17, July 2017, Washington, DC, USA (a) Block size (b) Network delay factor D (c) Alpha α Figure 1: BFT vs. NC latency as a function of block size, network delay, and Byzantine ratio. latency BBL, and the back-and-forth of committee communi-cation time CCT should all be smaller than or equal to blockinterval to ensure successful propagation. • Block validation . After Each node receiving the block, Al-phaBlock will need to implement R rounds of votes to vali-date the block. When the block is validated, it is appendedto the blockchain, and the round starts over. In each round,at least d votes must be collected to validate the block, oth-erwise the block will be nullified and the round will fail. InHBFT, a node will agree the proposed block by signing itand sending the signed vote to the leader. The leader willcollect at least 2 f signatures sent by other nodes, wrap themup, and broadcast the wrapped collected signatures to thewhole network. Nodes then add the received wrapped signa-tures into the block before appending the block to its localblockchain; In PoA, it will take R = • Block confirmation . To confirm a transaction in a block,It requires K − K is protocol based. In HBFT, K =
3, namely ittakes 3 rounds of votes from the super-majority to achievedefinitive consensus. In PoA, K =
5, and it only guaranteesa probabilistic consensus with a security level of ϵ .We present the above idea in Algorithm 1. As a simplified version,instead of validating a block, we compute the exact probability of ablock being validated and compute variables regardless of the valid-ity of the round. This is reasonable because the variables computedwithin and without a valid round only differ with respect to theByzantine ratio, but the communication network is assumed sym-metric with respect to being Byzantine. The schematic workflowgoes as in Algorithm 1: AlphaBlock accommodates more protocols than HBFT and PoA. Itis interesting to find some optimal protocols in this framework bychanging controllable parameters. In terms of throughput and la-tency, we can figure out these optimal protocols by the throughput-latency frontier in the sense that the throughput cannot be im-proved without compromising latency and vice versa. The frontieris a strong guidance of future blockchain system design.
Algorithm 1:
Committee based consensus algorithm
Input:
A random connected graph G ( N , p , D , B width ) ; Ablockchain model Ch ( u , r = ) , where r is the u is the index of the leader in round r thatsucceeds to generate a block; parameter C , d , α , ϵ , B size , SR . Output: ( T ( C , d , B size ) , L ( C , d , B size )) , namelyThroughput-Latency pair as a function of C , d , and B size . for i = to SR do Com = randint ( N , C + ) ; // (Initialization) r = com ( ) , broadcast block B r to com ( j ) , j = , ... C ; // (proposal) com ( j ) vote or not to the leader r ; // (propagation) Broadcast to all N nodes to append B r to Ch ( u , r ) , r = r +
1; ; // (validation, confirmation)
Compute the variables in Section3 . T and L end compute expected block interval B interval and committee rate C rate ;compute T and L with expected B interval and C rate ; return T , L More accurately, we are interested in optimising the throughputand latency of a system by choosing proper parameters ( C , d , B size ) from a certain feasible set D . If we denote by T ( C , d , B size ) and L ( C , d , B size ) the throughput and latency of the system with param-eters ( C , d , B size ) , then the problem can be formulated asmin − T ( C , d , B size ) , min L ( C , d , B size ) , ( C , d , B size ) ∈ D . (16)The solution of this two-objective optimisation can be defined by Pareto Dominance . Given y = (− t , l ) and y = (− t , l ) then y is said to Pareto Dominate y (namely y ≺ Pareto y ), iff ∀ i ∈ , y i ≤ y i and ∃ j ∈ , y j < y j . (17)and the set of all optimal solutions to the problem is described asthe Pareto Frontier , which is defined as P ( Y ) = { y ′ ∈ Y : { y ′′ ∈ Y : y ′′ ≺ Pareto y ′ , y ′′ (cid:44) y ′ } = ∅} . (18)Namely, Pareto Frontier is the set in which no other points outsidethe set can Pareto dominate any point in the set. We find the Paretofrontier by Algorithm 2. onference’17, July 2017, Washington, DC, USA Haitao Xiang, Zhijie Ren, Ziheng Zhou, Ning Wang, and Hanqing Jin Algorithm 2:
Frontier identification algorithm
Input:
Y=(-T,L)
Output:
Pidx ,namely Index for Pareto Frontier of Y. [ , idx ] = sort ( T , ′ ascend ′ ) ; for i = to length(idx) do [ I ] = f ind ( L == min ( L ( idx ( i : end ))) , ) ; Lidx ( i ) = I ; end Lidx = unique ( Lidx ) ; [ , idx ] = sort ( L , ′ ascend ′ ) ; for i = to length(idx) do [ I ] = f ind ( T == min ( T ( idx ( i : end ))) , ) ; Tidx ( i ) = I ; end Tidx = unique ( Tidx ) ; Pidx = intersect ( Lidx , Tidx ) return Pidx
In this section, unless otherwise specified, we use the baselineparameter setting specified in Table 2 . Furthermore, the Byzantineratio is assumed to be 0.1, which is mild. The security level ϵ is takenso that the confirmation number K of PoA is 5. We first choose thenumber of agents to be N =
101 as seen in VeChain and Libra .The connection probability p is taken to be 0.06, which is typicalto model internet [5]. The network delay parameter is fitted fromthe data in [15]. The message size is approximated from [16]. Thebandwidth is a mild assumption adapted from [9]. The block size isassumed from typical data of Bitcoin [16]. In this subsection, we focus on the latency of HBFT and PoA withdifferent values of block size, network delay and Byzantine ratio,respectively. We take the block size B size ∈ { , , ... } ×
40, thenetwork delay D ∈ { . , . , . } , and the byzantine ratio α ∈{ . , . , . } . We show the dependence of the latency on thesethree variables and the comparison between HBFT and PoA by ournumerical experiments shown in Figure 1.In the left panel of Figure 1, we can see that the latency of bothconsensus protocols remain flat when the block size stays below1000, and start to rise after the block size exceeds 1000. This phe-nomenon can also be seen from the definition of the latency, inwhich the block size plays it role through the block interval definedas the maximum value among B size / B width , the committee commu-nication, and the blockhead broadcast. This maximum will increasetogether with the increasing of block size only when the blocksize is big enough, in which case the increasing is a linear style.Furthermore, with the bigger confirmation number K , the slope ofthis increasing for PoA should be bigger, and this is also shown inFigure 1. By the definition of latency, block size only affects latencythrough block interval, the behavior of latency regarding blocksize results from block interval. In fact, the flat region is mainlydue to the block interval setting that takes maximum from threevariables as in key concepts. When block size is smaller than around https://libra.org/en-US/white-paper/?noredirect=en-US K .The middle panel of Figure 1 shows that the latency is increas-ing in the networkdelay factor D for both HBFT and PoA. Thismonotonicity can also be explained by the block interval. For agiven block size, a bigger network delay factor D will result in abigger blockhead broadcast and a bigger committee communica-tion, which pushes the latency higher. While our figure shows thatthis increasing relation is strict, it is true only for big block sizeaccording to our explanation here.The right panel of Figure 1 shows that latency is increasing inByzantine ratio for both HBFT and PoA. For PoA, this monotonicitycomes from the increasing confirmation number K decreasing blockrate, as implied in Equation (9) and (13). While for HBFT, thismonotonicity comes only from the decreasing block rate. Therefore,it is natural that PoA has a greater slope of the increasing thanHBFT, which is also confirmed in Figure 1.Compare the latency between HBFT and PoA in all three panelsin Figure 1, we can find that HBFT has less latency than PoA, andwe interpret this comparison mainly by the higher confirmationnumber K of PoA. While this conclusion contradicts the commonbelief that BFT performs poorer than PoA when the block size issmall. The key argument in this common belief is that BFT hasa heavier committee communication overhead. This argument istrue for traditional BFT whose communication overhead is O( N ) .While for HBFT, the communication overhead is reduced to O( N ) ,and hence the argument does not apply. In this subsection, we study the throughput of HBFT and PoA asa function of the block size, the network delay and the Byzantineratio. We take the block size B size ∈ { , , ... } ×
40, the networkdelay factor D in the set D ∈ { . , . , . } , and the Byzantine ratio α ∈ { . , . , . } . Our experimenal results are shown in Figure 2.To understand implications of these figures, we need the followingtheorem, whose proof is deferred to Appendix.Theorem 4.1. As the block size B size → ∞ ,Throughput of PoAThroughput of HBFT → ( − α ) . In fact, the limit in Theorem 1 is the ratio of 1 − Fork rate betweenthe two consensuses, and we know the fork rate of PoA is α , whileit is 0 for HBFT.In Figure 2a, we can see that the throughput of both consensusprotocols increase linearly when the block size is below 1000, andthen remain flat after the block size exceed 1000. We can examinethis phenomenon by the definition of the throughput as in (13), inwhich the block rate B rate is a constant, the bandwidth efficiency B eff is very close to the constant value 1 − F rate . So the throughputis approximately a linear function of B size . As explained in theSubsection 4.1, the block interval remains a constant when When lphaBlock: An Evaluation Framework for Blockchain Consensus Protocols Conference’17, July 2017, Washington, DC, USA Table 2: parameter setup α ϵ N p
Networkdelayfactor D Message size M size Bandwidth B width Block size B size −
101 0.06 0.1 0.1 KB 1 MB/s 2000 tx/block (a) Block size (b) Network delay factor D (c) Alpha α Figure 2: HBFT vs. PoA throughput as a function of block size, network delay, and Byzantine ratio.Figure 3: HBFT vs. PoA throughput-latency plot across different byzantine ratio α and network delay factor D , and the blocksize range from 40 to 4000. onference’17, July 2017, Washington, DC, USA Haitao Xiang, Zhijie Ren, Ziheng Zhou, Ning Wang, and Hanqing Jin the block size is below 1000, and increases linearly otherwise. Thisshows the dependence of the throughput on the block size. Withthe flat property and the limit in Theorem 1, we can conclude thatthe throughput of PoA is lower than that of HBFT when the blocksize is big. This conclusion can also be interpreted in another way:when the blockchain system is dominated by bandwidth bottleneck,PoA throughput will be smaller than HBFT throughput.Figure 2b shows then moving of throughputs when the networkdelay factor D changes. We can see that both throughputs aredecreasing in D . The reason is similarly due to changes in theblock interval, as analyzed in the last subsection. Moreover, we cansee from the figure that BFT throughput is more sensitive to thenetwork delay. This is consistent with the comparison of the blockintervals. The committee communication is 0 in PoA, but it can bethe dominating factor among the three factors involved in the blockinterval, which makes the throughput of HBFT more sensible.In Figure 2c, we can see that throughput of both HBFT and PoAare decreasing in the Byzantine ratio α . This can be confirmed bythe fact that both the block rate and the fork rate are decreasing in α . In all three panels of Figure 2, we find that HBFT has betterthroughput than PoA. Although this is not an unconditional con-clusion, we are confident that it holds for most practical settings ofparameters. Throughputs and latencies are studied separately in the last twosubsection. In this subsection, we check these two measures jointlyfor PoA and HBFT in different settings. In Figure 3, we present thejoint performance on throughtputs and latencies for PoA and HBFTwith different parameter settings. In all 9 settings of parameters,we find that HBFT dominates PoA in the sense that HBFT hashigher throughput and lower latency. In this dominance, the higherfork rate of PoA plays a key role, which pushes up the latencyand pulls down the throughput. Furthermore, in all cases, whenthe throughput is pushed up, the latency stays approximately flatbefore some critical value of throughput, and then spikes up a littlebit the value. For a throughput-latency curve, we call the point onthe curve with the critical throughput as the turning point (Tpt) ofthe curve. A Tpt is informative to measure the performance of aconsensus protocol, in which its throughput and latency indicatethe bottleneck values of the protocol. In all 3 × • Tpt’s throughputs for both HBFT and PoA decrease in α . Thisnaturally arise from the block rate in bandwidth efficiency.The difference between the Tpt’s throughputs of HBFT andPoA increases in α because of the difference in their forkrates. • Tpt’s throughput for both PoA and HBFT remains almost un-changed in the network delay factor D . This means that thenetwork delay has little impact on the bottleneck throughputof either system. • Tpt’s latency for PoA increases in α , but remains unchangedfor HBFT, so their difference increases in α . This phenome-non can be confirmed by the fact that the fork rate for HBFTdoes not depend on α , but it equals α for PoA. We conclude Figure 4: HBFT vs. PoA throughput-latency plot across dif-ferent byzantine ratio α and networkdelay factor D , and theblock size range from 40 to 4000. that the Byzantine ratio affects the bottleneck latency forPoA only. • Tpt’s latency for PoA and HBFT increases in the network de-lay factor D . This is natural given the fact that a greater delayleads to a greater block interval in general. The difference be-tween the two Tpt’s latencies increases in the network delayfactor D , which is due to the greater confirmation number K of PoA compared with that of HBFT. In the previous subsections, we showed that the performance ofPoA is dominated by HBFT in all numerical experiments. Althoughthe communication overhead hurts the performance of HBFT, thebandwidth wasted by forks in PoA bites on the performance ofPoA. In our experiments, the minimal fork rate is 0 .
1, which is highenough to make HBFT outperform PoA. In practice, if the maliciousnodes use different strategies, the fork rate can vary in a widerrange. For instance, on the one hand, by introducing economicpenalty, the fork rate in Bitcoin is only 0 . ( , ) ,and find that the PoA will dominate HBFT when the fork rate isless than 0 . .
001 in Figure 4. By this comparison, we conclude that PoA canbe a better choice if the fork rate can be pressed low by introducingsome discouraging on forks.
In our previous numerical experiments, the number of nodes is setto be a relatively small number N =
101 for the convenience ofour experiments. In practice, HBFT and PoA are deployed on muchlarger systems. To make sure that our comparison still makes sense lphaBlock: An Evaluation Framework for Blockchain Consensus Protocols Conference’17, July 2017, Washington, DC, USA
Figure 5: HBFT vs. PoA throughput-latency plot with N = , byzantine ratio α = . and network delay D = . , andthe block size range from 20 to 4000. HBFT no longer domi-nates PoA under this circumstance.Figure 6: All AlphaBlock throughput-latency plot, withHBFT, PoA and frontier points highlighted in a large system, we set N = Finally, let us zoom out of the comparison between HBFT and PoA,and go to find better systems in AlphaBlock in terms of throughputand latency. The variables we can choose here are committee size C , endorsement size d and block size B size . We show in figure 6the throughput-latency performance of AlphaBlock systems withdifferent choices of the three variables above. In this figure, wehighlight those for HBFT, PoA, and those on the Pareto frontierwho has the highest throughput with a certain level of latency or the lowest latency with a certain level of throughput. It may not bepossible to achieve some throughput-latency on the Pareto frontier,but we can sense the performance of a system by its difference tothe Pareto frontier. This paper proposes a general framework termed as AlphaBlockto evaluate consensus protocols for blockchain. We compare theperformance of Byzantine Fault Tolerance (BFT) and NakamotoConsensus (NC), and we take Hotstuff-BFT (HBFT) and Proof-of-Authority (PoA) as two specific examples. In comparison, we findthat HBFT outperforms PoA in most practical settings, which con-trasts the common belief. This out-performance can be reversed ifthe fork rate in PoA can be reduced sufficiently by some discour-agement on forks. We also identify the Pareto-optimal choices ofcommittee size C , endorsement size d and block size B size in theframework of AlphaBlock, which provides a direction for improvingthe performance of blockchain consensus algorithms. Proof of Theorem 4.1:
For both protocols, when B size → ∞ , we have B interval → B size B width and C rate → T = B size B interval × B rate × B eff . (19)So when B size → ∞ , we have T → B width × B rate × ( − F rate ) . (20)Since the block rate is 1 − α for both protocals, we have T ( PoA ) T ( HBFT ) → ( − F rate ) PoA ( − F rate ) H BFT = − α , (21)where T ( PoA ) and T ( HBFT ) are the throughputs of PoA and HBFTrespectively. REFERENCES [1] Ittai Abraham and Dahlia Malkhi. 2016. BVP: Byzantine vertical paxos.
DistributedCryptocurrencies and Consensus Ledgers (DCCL) (2016).[2] Shehar Bano, Alberto Sonnino, Mustafa Al-Bassam, Sarah Azouvi, Patrick Mc-Corry, Sarah Meiklejohn, and George Danezis. 2019. SoK: Consensus in the ageof blockchains. In
Proceedings of the 1st ACM Conference on Advances in FinancialTechnologies . 183–198.[3] Michael Ben-Or, Boaz Kelmer, and Tal Rabin. 1994. Asynchronous secure com-putations with optimal resilience. In
Proceedings of the thirteenth annual ACMsymposium on Principles of distributed computing . ACM, 183–192.[4] Iddo Bentov, Ariel Gabizon, and Alex Mizrahi. 2016. Cryptocurrencies WithoutProof of Work. In
Financial Cryptography and Data Security , Jeremy Clark, SarahMeiklejohn, Peter Y.A. Ryan, Dan Wallach, Michael Brenner, and Kurt Rohloff(Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 142–157.[5] Stefano Boccaletti, Vito Latora, Yamir Moreno, Martin Chavez, and D-U Hwang.2006. Complex networks: Structure and dynamics.
Physics reports
Informationand Computation
75, 2 (1987), 130–143.[7] Vitalik Buterin and Virgil Griffith. 2017. Casper the friendly finality gadget. arXivpreprint arXiv:1710.09437 (2017).[8] Miguel Castro, Barbara Liskov, et al. 1999. Practical Byzantine fault tolerance. In
OSDI , Vol. 99. 173–186.[9] Kyle Croman, Christian Decker, Ittay Eyal, Adem Efe Gencer, Ari Juels, AhmedKosba, Andrew Miller, Prateek Saxena, Elaine Shi, Emin Gün Sirer, et al. 2016.On scaling decentralized blockchains. In
International conference on financialcryptography and data security . Springer, 106–125. onference’17, July 2017, Washington, DC, USA Haitao Xiang, Zhijie Ren, Ziheng Zhou, Ning Wang, and Hanqing Jin [10] Christian Decker and Roger Wattenhofer. 2013. Information propagation in thebitcoin network. In
IEEE P2P 2013 Proceedings . IEEE, 1–10.[11] Tien Tuan Anh Dinh, Ji Wang, Gang Chen, Rui Liu, Beng Chin Ooi, and Kian-Lee Tan. 2017. Blockbench: A framework for analyzing private blockchains. In
Proceedings of the 2017 ACM International Conference on Management of Data .1085–1100.[12] Antonio M DiNizo Jr. 2018. From Alice to Bob: The Patent Eligibility of Blockchainin a post CLS Bank World.
Case W. Res. JL Tech. & Internet
Proceedings of the 2018 ACM SIGSAC Conference on Computerand Communications Security . 2028–2041.[14] Ittay Eyal, Adem Efe Gencer, Emin Gun Sirer, and Robbert Van Renesse. 2016.Bitcoin-NG: A scalable blockchain protocol. In . USENIX Association, 45–59.[15] Adem Efe Gencer, Soumya Basu, Ittay Eyal, Robbert Van Renesse, and Emin GünSirer. 2018. Decentralization in bitcoin and ethereum networks. In
InternationalConference on Financial Cryptography and Data Security . Springer, 439–457.[16] Evangelos Georgiadis. 2019. How many transactions per second can bitcoinreally handle? Theoretically.
IACR Cryptology ePrint Archive
Proceedings of the 2016 ACM SIGSAC conference on computerand communications security . 3–16.[18] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zel-dovich. 2017. Algorand: Scaling byzantine agreements for cryptocurrencies. In
Proceedings of the 26th Symposium on Operating Systems Principles . 51–68.[19] Martin Haferkorn and Josué Manuel Quintana Diaz. 2014. Seasonality andinterconnectivity within cryptocurrencies-an analysis on the basis of bitcoin,litecoin and namecoin. In
International Workshop on Enterprise Applications andServices in the Finance Industry . Springer, 106–120.[20] Gur Huberman, Jacob Leshno, and Ciamac C Moallemi. 2019. An economicanalysis of the bitcoin payment system.
Columbia Business School Research Paper
AnnualInternational Cryptology Conference . Springer, 357–388.[22] Jae Kwon. 2014. Tendermint: Consensus without mining.
Draft v. 0.6, fall
1, 11(2014).[23] Leslie Lamport, Robert Shostak, and Marshall Pease. 1982. The Byzantine generalsproblem.
ACM Transactions on Programming Languages and Systems (TOPLAS)
Bitcoin: A peer-to-peer electronic cash system . TechnicalReport. Manubot.[25] Fred B Schneider. 1990. Implementing fault-tolerant services using the statemachine approach: A tutorial.
ACM Computing Surveys (CSUR)
22, 4 (1990),299–319.[26] Yonatan Sompolinsky and Aviv Zohar. 2018. PHANTOM: A Scalable BlockDAGProtocol.
IACR Cryptology ePrint Archive
Blockchain: digitally rebuilding the real estate industry . Ph.D.Dissertation. Massachusetts Institute of Technology.[28] Marko Vukolić. 2015. The quest for scalable blockchain fabric: Proof-of-work vs.BFT replication. In
International workshop on open problems in network security .Springer, 112–125.[29] Mike Wons. 2017. Digital Transformation in Government, The Illinois BlockchainInitiative. In
NASCIO Enterprise Architecture & Governance Committee MonthlyConference Call .[30] Gavin Wood et al. 2014. Ethereum: A secure decentralised generalised transactionledger.
Ethereum project yellow paper
IEEE CommunicationsSurveys & Tutorials (2020).[32] Maofan Yin, Dahlia Malkhi, Michael K Reiter, Guy Golan Gueta, and Ittai Abra-ham. 2019. Hotstuff: Bft consensus with linearity and responsiveness. In