摘要
本⽂⾸先对BFT类共识协议按照改进思路分为3⼤类进⾏综述性概览：
针对⽆拜占庭错误场景优化的协议，包括PBFT、Zyzzyva等等；
针对拜占庭错误场景优化的，包括Aardvark、Primer等等；
为公链应⽤⽽优化的协议，包括DPoS+BFT、Zilliqa等等。
本⽂还选⽤PBFT、Zyzzyva、Zilliqa协议，编写程序进⾏实测，主要得到以下结果及技术指导建议:
Zyzzyva和Zilliqa等协议的⽹络通讯量确实⽐PBFT降低很多；
调整PBFT检查点周期对性能没有太⼤影响；⽽调整批量⼤⼩则会较⼤程度上提⾼吞吐量指标、缩短共识时间，不过同时也会加⼤消息量对⽹络造成压⼒； Zyzzyva在其客户端⾜够的情况下，增加批量数会对吞吐量和共识时间等性能指标均有较⼤提升；
虽然增加批量数对Zilliqa等协议都有促进效果，但这也会增加带宽占⽤。在设计共识协议时应综合考虑性能⽬标与⽹络带宽等实际情况。
⽬录
1. 引⾔
2. 主要结论
3. 共识问题及BFT协议简介
3.1 ⼀致性问题及原理
3.2 BFT共识原理及流程简介2012年3月12日
3.3 技术思路分析换⼿率
4. BFT类共识概览
4.1 针对⽆拜占庭错误场景进⾏优化
4.2 很对拜占庭错误场景进⾏优化
4.3 为公链应⽤优化
5. 实测对⽐
5.1 测试⽅案介绍
5.3 场景2：节点异常时的横向⽐较
5.4 场景3：PBFT测试研究
5.5 场景4：Zyzzyva测试研究
5.6 场景5：Zilliqa测试研究
6. 参考资料
1. 引⾔
五常论坛共识协议被许多⼈视为是区块链项⽬的核⼼。⽆论是对区块链平台的交易处理能⼒、扩展性影响还是对通证经济的激励模型设计，共识协议都会产⽣很⼤影响。
共识协议从⼤的⽅⾯可分为⾃⽐特币诞⽣以来产⽣的PoW等中本聪共识协议和拜占庭容错（BFT）类共识协议这两⼤类协议。其中，在计算机科学的分布式系统研究领域已较多研究的BFT类共识协议近年来被越来越多的应⽤于联盟链平台。与此同时，也有越来越多的研发⼯作尝试将BFT应⽤于公链平台。
我们在本⽂中对BFT类协议进⾏了综述性概览分析，并从改进思路上将现有BFT类共识协议分为3⼤类：针对⽆拜占庭错误场景优化的协议、针对拜占庭错误场景优化的协议以及为公链应⽤⽽优化的协议；另外选⽤了PBFT、Zyzzyva、Zilliqa协议，编写程序并运⾏后得到实测对⽐结果，对共识协议的具体设计提供⼀些技术性指导建议。
2. 主要结论
经过研究与测试分析，我们得到以下主要结论及技术建议：
Zyzzyva和Zilliqa等协议的⽹络通讯量确实⽐PBFT降低很多；
对PBFT，调整检查点周期对性能没有太⼤影响；⽽调整批量⼤⼩则会较⼤程度上提⾼吞吐量指标、缩短共识时间，不过同时也会加⼤消息量对⽹络造成压⼒；
Zyzzyva在其客户端⾜够的情况下，增加批量数会对吞吐量和共识时间等性能指标均有较⼤提升；
虽然增加批量数对Zilliqa等协议都有促进效果，但⽹络中消息量也会增加。在设计共识协议时应综合考虑性能⽬标与⽹络带宽等实际情况。
3. 共识问题及BFT协议简介
3.1. ⼀致性问题及原理
计算机世界早已从“单机版”进⼊了“⼤型多⼈在线”的时代，区块链的诞⽣与发展更是让这⼀特性得到了充分的体现。这个过程中不可避免的产⽣了多个计算机之间如何达成⼀致的问题。常见问题包括：
表 1 常见⽹络服务器错误[1]网络安全特警
在已经⼤规模投⼊使⽤中的分布式数据库系统环境中，有可能存在很多的宕机错误。根据CAP原理[2]，Paxos和Raft协议被设计为在牺牲⼀定可⽤性的情况下，解决在节点服务器可能宕机问题的协议[3]。
然⽽这些协议在区块链领域内还不能直接使⽤，因为还有其他更多在区块链领域内可能出现的错误。在表1中这种任意类型错误都可能发⽣的场景中，服务器有可能产⽣原本不应该输出的内容，系统要做好最坏情况的准备。例如，当⼀个服务器向不同的服务器发送截然相反的消息时，那么仅可处理宕机错误Paxos协议就⽆能为⼒了。
这种类型错误，也被称为拜占庭错误，最早由Pease和Lamport在上世纪80年代通过拜占庭将军问题进⾏描述和分析[4][5]。
因此相较于分布式数据库，区块链的对于⼀致性问题的设计和实现要更为复杂，这也是为什么区块链不只是⼀个简单的分布式数据库的原因之⼀。
3.2 BFT共识原理及流程简介
Lamport等⼈在其经典论⽂[4]中除了提出拜占庭将军问题外，也提供了两种解决办法[6][7]。
第⼀种为“⼝头消息”的OM(m)协议，即除了链路上可使⽤加密安全保障外，不允许使⽤任何的加密算法。该协议需要两两之间递归的传递⼤量消息，因此消息复杂度很⾼，为指数级，不太具有可实际操作性。但这⼀算法仍有其很⾼的价值，⾸先是为“实⽤拜占庭容
错”（Practical Byzantine Fault Tolerance）这⼀多项式级别复杂度协议的诞⽣做了⼀个铺垫；另外，其1/3容错节点数量也被证明为是该类算法的理论上限。
⽽第⼆种为“加密消息”的SM(m)协议。该算法与第⼀种不同之处在于使⽤签名算法。每个节点都能产⽣⼀个不可伪造的签名，并可由其他节点进⾏验证。当收到消息后，节点会通过签名来判断及验证该消息是否已收到过。最终不再收到消息后，消息共识结束。它同样假设是在⼀个同步⽹络内进⾏；另
外，签名⾝份体系信息需要在⽹络运⾏前确定，较难实现扩展。Vitalik近期在其博客上发布了⼀篇名为《⼀个99%容错共识的指南》[8]就是根据这⼀协议在区块链实际场景中所作的适应性改造探索[9]。
3.3 技术思路分析
与从⽐特币系统中衍⽣出的中本聪共识不同，BFT类协议基于节点间传递消息对⽹络中提案达成共识。因此⼀般来说消息复杂度较⾼，⽽且节点的加⼊和退出过程需要进⾏特别处理，但⼀旦达成共识则形成确定性结果，⽽不是中本聪共识的概率上的最终⼀致。
嘧霉胺
因此基于以上特性，BFT类共识⽬前在⾦融场景以及联盟链场景中应⽤的更多。不过随着研究的探索推进，⼀些可在公有链场景下使⽤的BFT共识也正在不断研发出来。
4. BFT类共识概览
我们在已有BFT类共识分类[10][11]的基础上，继续对⽬前BFT协议进⾏了梳理。因为BFT协议中的⽆论是⼝头协议还是书⾯协议都不
够“实⽤”，很难在实际场景中直接运⽤。因此后来学术界和业界对BFT协议有了⼤量的改进。按照改进思路的不同，这些协议主要可分为以下3⼤类⽅向：
针对⽆拜占庭错误场景进⾏优化
针对拜占庭错误场景进⾏优化
为公链应⽤⽽做的优化
4.1 针对⽆拜占庭错误场景进⾏优化
此场景假设⼤部分情况下，⽹络中的节点运⾏都正常，拜占庭错误并不经常出现，因此可对这种节点均正常情况下的共识机制进⾏简化或优化。
下⾯我们根据不同的优化⽅法，对这些协议进⾏分项介绍。
4.1.1. 基于协约的⽅法
对BFT协议最为经典的改进主要是以PBFT为代表的基于节点协约⼀致（Agreement）的⽅法。该类协议通常会有⼀个主节点作为⽹络中的枢轴。⽐其他节点相⽐，主节点在共识过程中会发出最主要的作⽤，但通常也会成为系统性能的瓶颈。因为主节点需要将客户端发来的请求排序后发送给所有的备节点。所有节点通过互相通信后达成⼀致，实现安全性（Safety）；⼤多数协议中所有节点也会向客户端回复响应，实现活性（Liveness）。该类协议通常需要3f+1个节点来实现对f个拜占庭节点的容错。
氧化铬实⽤拜占庭容错（Practical Byzantine Fault Tolerance. 简称PBFT）[12]是早期对其进⾏的改进，将BFT的消息复杂度从指数级降低为级别，即具备了可实际使⽤的条件。
图 1 正常情况下的PBFT消息传播过程[12]中朝关系现状
PBFT协议将共识过程分为了5个阶段（如果不算与客户端交互的阶段，则可视为3个阶段）：
Request阶段是客户端发送信息；
在Pre-prepare阶段，主节点接到消息对其签名并分配⼀个唯⼀的序号n并将该消息发送给其他节点；
Prepare阶段：所有备份节点收到主节点发来的PRE-PREPARE消息后，将⼀个包含当前视图号v、消息序号n、消息摘要的PREPARE 信息发给所有其他节点。如果节点收到了2f个以上的PREPARE消息后则进⼊到下⼀阶段并且该消息处于Prepared状态;
Commit阶段：每个节点⼴播⼀个保护当前视图号v、消息序号n的COMMIT消息。当节点收到2f个相同的COMMIT消息并且⼩于序号n的消息都已被执⾏，那么当前消息会被执⾏并被标记为Committed状态;
Reply阶段：所有节点将执⾏结果返回给客户端。
除了以上阶段流程外，协议运⾏过程中还涉及到⼏个重要概念：
⽔位：每个节点在运⾏协议时会设置⼀个处理消息的窗⼝，消息序号在这个区间内的时候才会被处理，例如最⼩序号设为h、最⼤序号为H;
检查点（Checkpoint）：在运⾏提交过程中所有已处于已准备好（Prepared）和已提交状态（Committed）的信息会被记录在内存中。节点会定期（每执⾏k个请求后）记录⼀个稳定的检查点并截断记录，即每执⾏k个请求后，会将⽔位h和H提⾼k个单位;
视图切换（View Change）：但是当节点发现对某个消息的等待超过⼀定时间后，则认为是主节点失效，会发送视图切换（VIEW-CHANGE）消息并开始视图切换的过程;
批量（Batch）：实际执⾏中会采⽤的⼀些优化改进技术，例如批量⽅式，即实际程序并不是对单个提交来每次运⾏协议，⽽是会在以集合形式同时在⽹络中处理，并通过设置批量⼤⼩（Batch Size）的⽅式来控制处理消息的数量。
在设置了以上运⾏机制后，尽管消息复杂度仍然较⾼，PBFT已具备了实际运⾏的可⾏性。之后的许多BFT类协议均在PBFT协议基础上进⾏改进，并将PBFT作为研究对⽐的基准对象。
Chain协议。Chain协议[13]采⽤了⼀个和其名称很相似的链条式传播路径[14]。从主节点开始，每⼀次传播时即加⼊该节点的摘要信息。当客户端较多时，Chain通常会⽐PBFT、Zyzzyva等吞吐量更⾼。
图 2 Chain消息传播过程[10]
Ring协议。Ring协议[15]使⽤环形拓扑⽅式来传递消息，即每个节点都有消息的上⼀个发送者和下⼀个接收者，以此⽅式来降低对部分节点分配更多⼯作⽽形成的性能瓶颈问题。对有⽆错误的不同场景，Ring分别采⽤两种运⾏模式：快速模式（Fast Mode）和弹性模式（Resilient Mode），并采⽤ABSTRACT框架进⾏切换[14]。
图 3 快速模式下Ring消息传播过程[15]
BFT-SMaRt协议。BFT-SMaRt[16]与PBFT、UpRight[17]类似，但增强了可靠性、模块化程度、同时还提供了灵活的编程接⼝。
4.1.2 基于Quorum的⽅法
Quorum机制是⼀种分布式系统中常⽤的机制，⽤来保证数据冗余和最终⼀致性的投票算法。其主要思想来源于抽屉原理，常⽤于分布式系统的读写访问控制[18]。
该类共识协议不需要节点间相互通讯，⽽是由节点直接执⾏并响应客户端发来的请求。当受到⾜够数量的响应后，客户端才会将结果最终提交。但是当出现拜占庭错误场景时，通常会花费较⼤的代价来解决。另外，由于缺少对请求的排序机制，Quorum⽅法⽆法处理有竞争（contention）的情况。
Q/U协议。Q/U协议（Query/Update）[19]是⼀个典型的基于Quorum的协议。Q/U没有主节点来为请求排序，⽽是由客户端直接向节点发送请求并由节点反馈结果。它需要5f+1个节点来对f个拜占庭节点容错。
HQ协议（Hybrid Quorum）[20]是另⼀个较为早期和著名的共识协议。正如其名称，HQ综合参考并优化了Q/U协议和PBFT协议：只需要3f+1个节点进⾏容错，并针对没有竞争的情况简化了PBFT节点间通讯。当没有竞争情况下，共识主要分为两个阶段：第⼀阶段是客户端发送请求并收集节点的状态信息；当收到结果表明2f+1个节点状态相同且可以执⾏请求后，开始第⼆阶段信息发送、由节点执⾏请求。⽽如果发现有竞争，则采⽤类似PBFT的解决过程，性能也退化为和PBFT类似。
图 4 HQ的消息传播模式[20]
Quorum协议也是基于Quorum机制的⼀个共识协议[14]，主要没有客户端竞争的⾮异步⽹络⽽进⾏设计，只需要3f+1个节点进⾏拜占庭容错。当没有错误产⽣时，Quorum协议的传播路径和Q/U类似，节点独⽴执⾏请求并⾃⼰维护⼀个执⾏历史记录。当客户端数量较少时，其吞吐量和延迟等性能指标均⽐其他BFT类共识更好。但其缺点也和Q/U类似，⽆法处理客户端有竞争的情况[10]。
4.1.3 基于Speculation的⽅法
在这类协议中，节点不需要通过需要消耗⼤量系统代价的3阶段提交过程即可响应客户端的请求。采⽤了更乐观的策略，节点同意由主节点发出的排序请求并给客户端返回结果。由客户端⽽不是节点来负责考虑⼀致性问题。如果发现不⼀致问题，由客户端负责通知节点回滚⾄⼀致状态。
Zyzzyva协议。Zyzzyva是该类中最典型的⼀个协议[21]。它需要3f+1个节点进⾏拜占庭容错。与基于Agreement的协议类似，Zyzzyva 中的主节点也是将客户端发来的请求排序后转发其他节点。每个节点根据⾃⾝历史记录来执⾏请求并将结果反馈给客户端。客户端根据节点返回的⼀致性结果数量分别执⾏不同的动作。
在没有错误的场景下，Zyzzyva表现⽐PBFT和Q/U等协议要好；但是当有错误时，因为要涉及到和PBFT类似的view change过程，其性能也会急剧下降。
图 5 Zyzzyva的消息传播模式[21]
Zeno协议。Zeno协议[22]在Zyzzyva基础上进⾏修改，将原有的强⼀致性替换为⼀个较弱的最终⼀致性保证。它允许客户端偶尔忽略其他更新，但是当⽹络不稳定时，所有节点的状态需要进⾏合并以达成⼀致。
ZZ协议。ZZ协议[23]同样基于Speculation机制。因其还采⽤了分离处理的机制，也可将其归为“分离处理⼀致性与执⾏请求的阶段”的类别，我们将在后续章节继续介绍。
4.1.4 基于客户端的⽅法
基于客户端的⽅法通过避免节点间通信的⽅式，来避免异常节点对正常节点的攻击、误导或延迟。协议完全依赖于这些客户端的正确性，假设客户端都没有异常、是诚实且在宕机时会被外部所感知的。
OBFT（Obfuscated BFT）协议[24]是这⼀类协议的典型代表。它需要3f+1个节点进⾏容错，但与其他很多BFT协议涉及到节点间通讯不同，OBFT协议中的节点完全不需要关注其他节点并只与客户端联系，因此避免了恶意节点⼲扰其他正常从⽽影响系统性能的问题，不过这也带来了⼀个较强的假设：必须完全信任客户端不会作恶。因此该类协议都存在着较难在实际场景中进⾏应⽤的问题。
图 6 OBFT的消息传播模式[24]
4.1.5 基于可信组件的⽅法
因为FLP不可能性原理（即使⽹络通讯可靠也⽆法在任何场景下都能达到共识[25]），⼀些协议并不使⽤传统的超时等机制⽽是基于外部的可信组件进⾏设计。这些组件也需要被认为是⽆拜占庭错误的，但允许存在宕机等临时性⽆法提供服务的情况[11]。基于以上条件，该类协议可以将容错节点数量从3f+1将为2f+1。
例如，CheapBFT协议[26]。需要基于⼀个叫做CASH的FPGA可信设备，从⽽降低正常情况下协议对
于资源的使⽤。
4.1.6 基于拜占庭锁的⽅法
拜占庭锁是拜占庭协议的扩展，通过利⽤IO绝⼤多数时间⾥不会出现竞争的特性来达到降低服务器响应时间、提⾼吞吐量与扩展性的效果。
这种⽅法最早由Zzyzx协议[27]提出，包括加锁和解锁两个部分。加解锁过程均基于现有拜占庭协议达成对客户端授权的⼀致。当授权完成，则获得锁的客户端可直接进⾏操作，从⽽去掉了主节点排序、节点间通讯等操作，从⽽⼤幅度提⾼吞吐量。但当有多个客户端需要频繁切换时，其性能也会⼤幅下降，因此该协议较为适⽤于客户端不会频繁发⽣变化的情况下。
4.1.7 基于分离⼀致性与执⾏请求的⽅法
还有⼀类改进⽅法是将共识与执⾏提交的过程分开，因为执⾏客户端请求只需要f+1个（当没有拜占庭节点或者客户端可验证结果正确性时）或2f+1个节点（当有可能存在拜占庭节点且客户端不可验证正确性时），因此可将协议的执⾏分为2个部分，⼀部分节点负责⼀致性共识协议，⽽另⼀部分负责执⾏提交，从⽽提⾼吞吐量。
ZZ协议，通过虚拟化技术[23]把节点均正常场景下的执⾏所需节点数量从2f+1降为f+1个。在没有错误
场景时，只通过f+1个节点来执⾏请求，其余服务器在休息状态；⽽当执⾏请求的节点发⽣错误时，客户端通过虚拟化技术快速启动更多的节点来执⾏[11]。
ODRC协议也是将执⾏节点数量将为了f+1，但与ZZ协议不同，它并没有采⽤额外的虚拟化等技术，⽽是在BFT协议过程中的节点达成⼀致后、执⾏请求前增加了⼀个选择执⾏节点的阶段。该阶段根据当前系统状态，选择指定数量的节点执⾏请求[11]。
4.2 针对拜占庭错误场景进⾏优化
上⾯介绍的⼀类协议均是针对没有错误的场景对BFT协议进⾏简化⽽设计，因此当遇到拜占庭错误时，这类协议的性能⼀般都会下降⽐较多，甚⾄很难保证系统活性。⽽另⼀类协议的改进⽬的是为了有效对拜占庭⾏为（甚⾄是⼀些罕见的⾏为）进⾏容错，降低系统在有⽆拜占庭错误这两种场景下的表现差异。主要有以下⼏个⽐较典型的协议。
Aardvark协议。Aardvark协议[28]的通讯过程与PBFT类似，但对许多可能的错误场景设计了适应性机制以保证系统的安全性和活性。这些适应性机制包括：对客户端采⽤混合签名等机制来防⽌客户端作恶；更为积极主动的触发view change过程以避免主节点有拜占庭⾏为；为每个节点设计3f+1个⽹络接⼝（其中1个⽤于其与客户端通信，其余3f个⽤于节点间通讯），以此隔离⽹络通道来防⽌流量攻击。
Prime协议。因为PBFT协议中当主节点作恶的view change过程对性能的影响较⼤，即便主节点不进⾏任何主动作恶，只要在处理排序过程中刻意增加延迟就可以降低系统整体性能表现。Prime协议[29]针对此情况进⾏了改进，在PBFT过程前增加了⼀个预排序的阶段，包括PO Request、PO ACK、PO ARU等阶段。通过这种分析主节点排序时间的⽅式，使得所有节点来监控⽹络表现。因此主节点必须及时将消息发送给其他节点以避免被替换掉。因为引⼊了额外的阶段，Prime在正常场景中的性能要⽐PBFT等协议要低；但在存在错误场景中其表现要⽐其他协议要好。
图 7 Prime消息传播模式[10]
Spinning协议。Spinning协议[30]在PBFT协议的基础上，设计⽤来减轻更换主节点的代价。在正常场景中的，Spinning通讯过程与PBFT相同。不过它没有view change过程，⽽是通过合并操作的⽅式来收集不同节点信息来决定之前视图中的操作是否应在新视图中执⾏。
RBFT协议。Redundant-BFT协议[31]利⽤⽬前所流⾏的多核技术来保障鲁棒性。该协议采⽤与PBFT类似的通讯过程，但在Pre-prepare 阶段前增加了⼀个Propagate阶段。客户端⾸先将消息发送给f+1个节点，这些节点在Propagate阶段相互传递消息以此来保证客户端请求会被所有正常节点接收到。RBFT执⾏f+1个同⼀个协议的多个实例，其中每个实例都对应⼀个在不同物理机器上运⾏的主节点，不过只有被主实例所排序的请求才会被有效执⾏。备份实例运⾏的意义主要在于监测运⾏性能：当发现主实例运⾏缓慢时，备份实例将触发view change过程选择出⼀个新的主实例。
图 8 RBFT的消息传播模式[31]
4.3 为公链应⽤优化
传统PBFT及类似协议，其⾃⾝的特性导致应⽤场景有较多限制，例如消息复杂度随节点数成平⽅级别上升、主节点容易成为系统性能瓶颈、节点列表需要提前固定且节点间相互已知。所以在分布式账本系统中，更多应⽤于联盟链或私有链场景中。
为了适应公有链场景中的⼤规模扩展需求，有不少项⽬进⾏了有益尝试，具体⽅式可主要包括与公链共识结合以及基于密码学机制等两⼤类⽅式。
4.3.1 与中本聪共识结合
