基于联盟链PBFT的BRaft共识算法.pdf

第 22卷 第 9期2023年 9月Vol.22 No.9Sept.2023软 件 导 刊Software Guide基于联盟链PBFT的BRaft共识算法白尚旺，达泓宇，高改梅，刘春霞，党伟超（太原科技大学 计算机科学与技术学院，山西 太原 030024）摘要：针对联盟链共识算法不能同时实现低时延、高吞吐量、高安全性的问题，提出适用于联盟链的可容错Raft共识算法BRaft（PBFT-Raft）。BRaft利用RSA签名解决拜占庭Leader节点篡改日志的问题，并在PBFT算法三段协议的基础上，引入标识位W，解决拜占庭Follower节点恶意响应Leader节点的问题，确保在拜占庭节点发送错误消息的情况下日志项依然能够被正确提交。实验结果表明，BRaft在保证算法可理解性和共识效率的同时，提高了算法安全性。关键词：Raft算法；PBFT算法；拜占庭节点；数字签名；标识位DOI：10.11907/rjdk.222261开 放 科 学（资 源 服 务）标 识 码（OSID）：中图分类号：TP311 文献标识码：A文章编号：1672-7800（2023）009-0132-06BRaft Consensus Algorithm Based on Consortium Chain PBFTBAI Shangwang，DA Hongyu，GAO Gaimei，LIU Chunxia，DANG Weichao（School of Computer Science and Technology，Taiyuan University of Science and Technology，Taiyuan 030024，China）Abstract：Aiming at the problem that the current alliance chain consensus algorithm cannot achieve low latency，high throughput，and high security at the same time，a fault-tolerant Raft consensus algorithm suitable for alliance chain-BRaft（PBFT-Raft）is proposed.BRaft used digital signature to solve the problem of Byzantine leader node tampering with logs，and based on the three-stage agreement of PBFT algorithm，it introduced the flag W，which solve the problem of Byzantine follower node maliciously responding to leader node，and ensure that the error message sent by Byzantine node can be prevented.In this case，the log entry can still be submitted correctly.The experimental results show that BRaft improves the security of the algorithm while ensuring the comprehensibility and consensus efficiency of the algorithm.Key Words：Raft algorithm；PBFT algorithm；Byzantine node；digital signature；identification bit0 引言2008年，中本聪首次提出比特币，数字货币进入了新篇章1。在比特币创始论文中，区块链被定义为一种数据结构，其实质是一个由区块构成的去中心化的链式账本，每个区块按时间顺序表示用户之间的事务传输。区块链具有去中心化、不可篡改、匿名性等基本特性2，因此它还可以作为一个分布式网络协议，使彼此不认识的不同参与者之间建立信任关系3，而不涉及任何中心角色或第三方。共识算法作为区块链中的最重要一环，着重解决存在故障时如何协调分布式节点之间的交互，保证各节点所维护的数据副本的一致性，避免出现数据不一致、信息不对称等问题。根据区块链的去中心化程度，可将其划分为公有链、联盟链和私有链。对于不同的区块链，采用的共识算法也不同。以比特币、以太坊为代表的公有链去中心化程度最高，通常采用的共识机制有工作量证明机制PoW（Proof of Work）4、权益证明机制（Proof of Stake，PoS）5、委托权益证明（Delegated proof of stake，DPoS）6。私有链的去中心化程度最低，它的写入权限由个人或某个组织机构所掌握，一般应用于企业内部。以Hyperledger Fabric为代表的收稿日期：2022-10-24基金项目：太原科技大学科研启动基金项目（20192062）；太原科技大学研究生教学改革研究课题（JG2022010）作者简介：白尚旺（1964-），男，硕士，太原科技大学计算机科学与技术学院教授、硕士生导师，研究方向为数据库与软件工程技术、区块链技术；达泓宇（1996-），女，太原科技大学计算机科学与技术学院硕士研究生，研究方向为区块链技术、共识算法；高改梅（1978-），女，博士，太原科技大学计算机科学与技术学院副教授，研究方向为网络安全、区块链技术；刘春霞（1977-），女，硕士，太原科技大学计算机科学与技术学院副教授，研究方向为软件工程、数据库技术、区块链技术；党伟超（1974-），男，博士，太原科技大学计算机科学与技术学院副教授，研究方向为智能计算、区块链技术。本文通讯作者：高改梅。第 9 期白尚旺，达泓宇，高改梅，等：基于联盟链PBFT的BRaft共识算法联盟链去中心化程度介于二者之间，一般由多个机构共同参与管理，并允许授权的节点加入网络。与公有链相比，具有更好的交易速度和安全性，是区块链落地的主要方向。目前，联盟链共识算法主要分为拜占庭容错（Byzantine Fault Tolerance，BFT）共识算法7和非拜占庭容错共识算法两类。BFT算法的核心就是在存在恶意节点的情况下，保证其余正常节点间能够达成共识。常用的BFT共识机制主要有实用拜占庭容错（Practical Byzantine Fault Tolerance，PBFT）8、联邦拜占庭容错（Federal Byzantine Fault Tolerance，FBFT）9和投机拜占庭容错（Speculative Byzantine Fault Tolerance，SBFT）10共识机制，但这类共识算法普遍存在通信复杂度较高的问题。非拜占庭容错共识算法是建立在对所有节点的信任机制上，具有低时延、高吞吐量的优势，常见的有Paxos11、Raft12共识算法，但不能容忍拜占庭节点的存在，由此提出一系列共识算法的改进方案。Copeland 等13结合 Raft共识算法和 PBFT 共识算法的优点提出 Tangaroa 共识算法，该算法在日志复制的过程中添加了哈希函数，确保在有恶意节点攻击的情况下仍能保持安全性，但是该算法无法容忍多个拜占庭节点的联合攻击。Martino等14在Tangaroa共识算法的基础上提出一种新型高性能或可扩展性的BFT共识算法Scal-ableBFT，可用于实现大规模的高性能许可私有链。黄冬艳等15提出一种基于Raft集群的拜占庭容错共识算法RBFT，将节点进行分组，组内采用Raft共识机制，而每组的Leader节点重新构成一个管理组实行PBFT算法。该算法较好地融合了Raft共识效率高和PBFT拜占庭容错性能好的特点，但需要引入大量的监督节点。本文在分析Raft算法的不足后，通过对已有拜占庭算法进行研究，使用RSA签名以防止节点身份伪造和消息篡改，解决在共识过程中Leader节点作恶的问题。同时，在PBFT算法三段协议的基础上引入标识位W保证算法的一致性，实现Raft算法在日志复制过程中的拜占庭容错，目的在于提高Raft算法安全性的同时又保证比PBFT更低的算法复杂度。1 相关工作1.1PBFT共识算法PBFT共识机制将原始拜占庭容错共识算法的通信复杂度从指数级降到了多项式级，共识效率得到明显提高。PBFT算法中的核心概念有3个部分：视图（view）、副本（replica）、角色（primary，backups）。视图表示当前系统的全局状态，副本表示系统中所有参与共识的节点，而在每个视图中，副本的角色又分为两类：主节点（primary）和备份节点（backups）。假设系统中的恶意节点数为f，PBFT需要满足总节点数至少为3f+1。算法的共识过程如图1所示。PBFT的具体执行步骤如下：请求阶段，客户端向主节点发送请求；预准备阶段，主节点在收到客户端发出的请求后，先检查请求的合法性，若合法，主节点将此消息写入本地日志然后进入预准备阶段，并向其他副本节点广播预准备消息；准备阶段，副本节点在收到消息后先确认消息的正确性，若正确就进入准备阶段，并向其他副本节点广播准备消息，同时将预准备消息和准备消息写入本地日志；确认阶段，当一个节点在一段时间内接收到 2f个以上的准备消息，就发送确认消息给所有副本节点；应答阶段，副本节点接收到2f个来自其他节点的确认消息后，验证消息的一致性，并向客户端返回应答消息。客户端收到2f+1个应答消息，表明共识完成。1.2Raft共识机制Raft算法是 Paxos 算法的改进，是从多副本状态机的角度提出，用来对多副本状态机的日志复制进行管理16。一个Raft群集中有若干个成员节点，这些节点有3种角色：领导者（Leader）、参与者（Candidate）和跟随者（Follower），并由Leader统一管理。（1）Leader。Leader由Candidate通过领导者选举协议选举产生，用于接收客户端的请求，并将客户端请求对应的日志项追加到自己的日志中，然后转发给Follower进行复制，当日志复制到大多数节点时，Leader将发送请求给Follower进行日志提交。（2）Follower。Follower接收并复制由Leader同步的日志。在Leader广播可以提交日志后，提交日志。（3）Candidate。在 Leader 选举过程中由 Follower 过渡为Leader的临时状态。参与共识的节点之间通过异步远程过程调用（RPC）进行交互，调用请求主要分为以下两种：RequestVoteRPC：用来进行投票请求，包含 Candidate节点的当前任期、日志中最后一条日志项的索引和任期等17，接收到请求的Follower通过验证当前Candidate节点提供的任期号，选取最优 Leader，避免拜占庭 Leader节点丢弃日志或对日志任意排序。AppendEntriesRPC：用来进行日志复制，包含领导者id、领导者当前任期term、新附加的日志项、前一个条目在Leader 日志中的索引 prevLogIndex、任期 prevLogterm 以及提交索引commitIndex。应答确认准备预准备请求 主节点副本节点?副本节点2 副本节点3客户端Fig.1PBFT consensus process图1PBFT共识过程 1332023 年软 件 导 刊1.2.1领导者选举图2描述了3种不同状态节点之间的关系。当服务器启动时，所有节点初始状态为Follower。经过一段随机时间后，Follower节点当前任期加一，然后转变为Candidate节点，Candidate节点首先给自己投票，随后将RequestVote请求发送给 Follower 节点以获取唯一投票。当 Candidate 节点接收到大多数选票时，转变为Leader节点18。收到投票请求的 Follower 节点首先会检查 Candidate最后一条日志项的任期号，只有在发出 RPC 的 Candidate的日志项具有的任期号比它本地保存的日志项的任期号更大，或者在任期号相同但具有比它更大的索引值时，Follower才会将他们的选票授予该节点。1.2.2日志复制日志是由日志项组成，日志项是一种包含用户指定的数据、索引值、Leader节点任期的数据格式。如图3所示，首先，客户端向 Leader 节点发送需要执行的请求；其次，Leader节点在收到客户端请求后会将带有客户端命令的日志项追加到自己的日志中，并向 Follower 节点发送 AppendEntriesRPC，进行日志复制。收到AppendEntriesRPC请求的Follower节点首先将自身最新条目与RPC中的条目进行比较。如果两个日志项具有相同的索引和任期，Follower会将接收到的新的日志项附加到其日志并将AppendEntriesRPC发送给Leader，表示复制成功。当Leader在收到集群中大多数Follower复制成功的响应后，将此日志项标记为已提交。日志项中的指令交由状态机执行，并将结果反馈给客户端。2 BRaft共识算法在 Raft 算法中，日志是否提交由 Leader 节点判断，Leader节点在向所有 Follower节点复制日志项时，如果收到一定数量 Follower节点的响应，Leader将日志项中的指令交由状态机执行，并在未来的心跳消息或者日志复制消息中广播给 Follower节点。但在拜占庭环境下，Leader节点可以发送错误消息给Follower节点，Follower节点可以在没有将日志项添加至日志列表时恶意响应Leader，以误导Leader收到了一定数量的响应。由此可知，仅依赖Leader无法确保日志项被正确复制，进而无法确保算法安全性。BRaft通过对客户端的消息进行数字签名以防止拜占庭节点作恶。在Follower节点对Leader的消息进行验证之后，算法在结合PBFT的三段协议的基础上引入标识位W，确保在拜占庭节点作恶的情况下日志项依然能够被正确提交。这样，不仅减少了Follower节点作恶的可能性，并且相比于PBFT算法的准备和确认阶段，节点之间不再需要额外通信，理论上提高了日志追加的时效。2.1前提与假设假设BRaft集群中一共包含n个节点，f个拜占庭节点BRaft算法需要满足式（1）以确保算法的容错能力。n 3f-2 (Leader为拜占庭节点)n 3f+1 (Leader为正常节点)（1）在共识过程中，节点存在宕机或者作恶的可能性，BRaft的容错能力分两种情况：当 Leader节点为拜占庭节点，Follower集群节点数为n-1，Follower节点中存在的拜占庭节点数为f-1，如果n-1-（f-1）个节点已经达成共识，来自 f-1 个拜占庭节点的决策不会影响正常节点的决策（n-1-（f-1）-（f-1）f-1），由此可知BRaft集群节点总数需要满足n3f-2；当Leader节点为正常节点时，Follower集群节点数为n-1，Follower节点中存在的拜占庭节点数为f，如果n-1-f个节点已经达成共识，来自f个拜占庭节点的决策不会影响正常节点的决策（n-1-f-ff），此时BRaft集群节点总数需要满足n3f+1。2.2签名验证BRaft 通过 RSA 数字签名作为消息被篡改的检测机制，且在算法运行过程中，所有的共识节点均拥有客户端的公钥PK。在签名过程中，首先，客户端对原文进行Hash运算，得到摘要M，并使用客户端私钥SK对摘要M进行加密，形成数字签名D；然后，将原文和数字签名一同发送给Leader，Leader节点在收到客户端发来的数字签名及原文后，会将自身信息与客户端消息打包一起发给Follower节点，Follower节点在收到数字签名后，先用客户端公钥 PK对摘要进行解密，确定是客户端消息之后，再用同样的Hash算法对原文计算摘要值，判断Leader是否对消息进行篡改。clientLeaderFollowerFollowerFollower1.请求5.返回3.日志复制 Fig.3Log copy process图3日志复制过程Follower CandidateLeader超时，开始选举超时，触发选举收到大多数选票发现新的Leader节点发现更高任期的Leader节点Fig.2Raft state transitions图2Raft状态转换 134第 9 期白尚旺，达泓宇，高改梅，等：基于联盟链PBFT的BRaft共识算法在 Follower 节点对客户端消息验证之后，BRaft 结合PBFT三段协议的思想，并通过标识位W保持在拜占庭环境节点的一致性，即每一个Follower节点存在一个标识位W（0表示验证不通过，1表示验证通过），每个标识位的初始状态为 0。当 Follower节点经过验证之后的标识位 c为1，且有 2f+1个 c发生变化且值的总和至少为 f+1时，可以证明Leader为正常节点。当Follower节点经过验证之后的标识位 c 为 0，Follower 集群中当有 2f-1 个标识位发生变化，且这2f-1个c值的总和至多为f-1时，证明Leader节点为拜占庭节点，此时系统重新进行选举。算法1 签名验证算法输入：客户端公钥PK、数字签名D、消息X，标识位Wi输出：VALID、INVALID1.function verify（PK，D，X，Wi）2.N=decrypt（PK，D）/通过客户端公钥 PK 对签名 D 进行解密3.P=hash（X）4.IF（N=P）5.Wi=16.FOR（i=1；i2f+1；i+）7.count1+=Wi8.9.IF（count1f+1）10 RETURN VALID11.12.ELSE 13.Wi=014.FOR（i=1；i2f-1；i+）15.count2+=Wi16.17.IF（count2f-1）18.RETURN INVALID19.2.3共识过程BRaft将共识过程分为4个阶段：提出区块、验证区块、更新区块和应答阶段。具体共识过程如图4所示。（1）提出区块。Leader 节点收集客户端请求sig，并验证请求的合法性，若不合法，直接丢弃，若合法，Leader节点将客户端请求对应的日志项追加到自己的日志中，并在Client-Request的基础上加上领导者id、领导者当前任期term、前一个日志项在Leader日志中的索引prevLogIndex、任期prevLogterm，形成，并广播给其他Follower节点。（2）验证区块。当Follower节点i收到来自Leader节点的请求后，验证以下条件：通过Verify（PK，D，X）验证Leader节点是否篡改客户端消息；验证新附加的日志项的任期号term是否大于等于Follower本身的任期号；验证本地日志的 prevLogIndex位置处的日志项与对应的 prevLogterm 是否匹配。如果以上条件都满足，则 Follower 节点 i 接受来自 Leader 节点的 Prepare-Request 请求。此时，标识位 Wi为 1，并向 Leader 节点发送。（3）更新区块链。当 Leader节点收到 2f+1个 Follower节点发来的时，且这2f+1个Wi值的总和至少为f+1，可以证明Follower节点已经做好准备进行日志复制。此时 Leader节点广播给集群中的所有Follower节点。（4）应答。Follower 节点收到后根据条件在本地追加收到的日志项，响应追加结果。当Leader节点在收到2f+1个应答结果时，表示共识已完成。Leader将日志项中的指令交由状态机执行，随后将处理结果返回给客户端并通过心跳消息通知Follower节点执行已提交的日志项。3 算法分析BRaft算法作为 Raft的改进算法，需要在存在恶意节点的情况下，保证算法的安全性和活性，下文将对以上两点进行具体分析。3.1安全性安全性是指所有坏的事情不会发生，BRaft算法的安全性体现在两方面：Leader节点选举阶段的安全性和日志复制阶段的安全性。在Leader选举阶段，BRaft通过心跳触发Leader选举。Leader节点会定期向 Follower节点发送心跳消息（包含在AppendEntriesRPC中），以证明节点的正常运行。如果Follower节点在一段时间内没有收到Leader的心跳，就会在一段随机时间之后转换为 Candidate 节点，触发新一轮的选举。Candidate 节点向其余 Follower 节点发送 RequestVote请求，以获取唯一投票。RequestVote请求包含当前节点最后一条日志项的任期和索引，只有发出投票请求的Candidate节点的任期及索引比将要进行投票的Follower节点更高时，Follower才会将他们的选票授予该节点，以此保证整个选举过程的安全性。在日志复制阶段，BRaft算法保留了 Raft算法的日志结构，通过数字签名实现消息篡改检测和防止身份伪造，并依赖PBFT三段协议保证共识的一致性，保证了拜占庭LeaderFollower1Follower2Follower3提出区块验证区块更新区块应答Fig.4BRaft consensus process图4BRaft共识过程 1352023 年软 件 导 刊节点存在情况下日志仍能够被正确提交。BRaft修改了状态机提交需要1/2节点同意的前提，当Leader节点为拜占庭节点，在容错范围f (n+2)/3内，可以保证BRaft的安全性。当 Leader 节点为正常节点时，在容错范围f (n-1)/3内，可以保证BRaft算法的安全性。3.2活性活性（Liveness）是分布式共识算法的另一重要属性，是指所有好的事情一定发生。BRaft算法保证在任何时刻算法均具备可用性，它是单Leader的拜占庭容错算法，即任意时刻BRaft需要存在一个可用的Leader。当Leader节点是正常节点时，算法始终遵循算法正常的日志复制逻辑运行，当Leader节点为拜占庭节点时，将篡改后的日志项发给其余Follower节点，Follower节点在收到日志项后，通过数字签名可以发现日志项被篡改，拒绝将日志项添加到其日志列表中，并转换为 Candidate 状态，发起新一轮的Leader选举。此时，之前被篡改的日志项并未在集群中达成共识，而发起投票的Candidate在获得一定数量投票后，成为新一轮的Leader，BRaft集群即恢复正常运行状态，上述整个过程仅耗费了一次 Leader选举耗时，BRaft算法保持着极高的活性。4 实验与分析4.1实验环境在实际运行环境中，节点间的通信均通过RPC实现，对外提供完全一致的接口。实验环境相关软硬件信息如表1所示，节点IP地址如表2所示。4.2吞吐量吞吐量指区块链每秒钟处理交易的数量，吞吐量越高代表算法在单位时间能处理的交易越多，性能越好。在相同实验环境下，对Raft、BRaft和PBFT算法进行数据吞吐量测试。测试过程采用Jmater工具，通过设置不同线程数模拟多个客户端向Leader节点发送Request消息，最后随机选取10组数据进行比较。由于BRaft算法在日志复制过程中存在对消息签名的解密验证，比Raft算法的数据吞吐量低10%左右，但与PBFT算法相比，数据吞吐量提高1/4左右，因而BRaft在性能上仍有很大优势，如图5所示。BRaft共识算法在保证其他条件不变的情况下，分别测试了5节点、10节点、15节点、20节点下的数据吞吐量。节点数量和数据吞吐量的关系如图 6所示。实验结果表明，随着节点数量的增加，BRaft的数据吞吐量所受到的影响较小，是因为BRaft算法在Raft算法原有共识逻辑的基础上，拥有比PBFT更低的通信复杂度。4.3时延时延是衡量拜占庭容错的分布式共识算法的另一个重要指标，时延标识了单个请求从被客户端发送开始直至客户端收到响应所需要的时间，包括客户端发送请求、网络传输、日志复制和客户端接收响应五阶段所需时间。图 7为 Raft、BRaft和 PBFT 算法针对不同数量的客户端请求达成共识所需时间。节点数目固定（n=5），在客户端请求数量从5递增至1 000的过程中，Raft和BRaft所需达成共识的时间均呈线性增长趋势，且当客户端请求数量等于1 000时，Raft需要4 732 ms达成共识，BRaft算法需要7 749 ms达成共识，PBFT需要9 237 ms。虽然，BRaft应用Table 1Experimental environment configuration information表1实验环境配置信息软硬件操作系统处理器内存版本Microsoft Windows 10Intel（R）Core（TM）i5-8250U CPU 1.60GHz 1.80 GHz8GBTable 2Node IP address表2节点IP地址节点编号012181920IP地址：端口127.0.0.1：8000127.0.0.1：8001127.0.0.1：8002127.0.0.1：8018127.0.0.1：8019127.0.0.1：802051015201.01.52.02.53.03.54.0数据吞吐量/sec节点个数/个 Raft BRaft PBFTFig.6The relationship between the number of nodes and data throughput图6节点数量与数据吞吐量关系123456789100246810数据吞吐量/sec试验次数/次 Raft BRaft PBFTFig.5Throughput图5吞吐量 136第 9 期白尚旺，达泓宇，高改梅，等：基于联盟链PBFT的BRaft共识算法数字签名和哈希算法，它们对性能的损耗存在一定影响，但与PBFT算法相比，达成共识的时间有了一定提升。如图 8所示，W 标识位的使用增加了 Follower节点响应Follower节点请求的额外开销，但减少了Follower节点反馈错误消息给Leader的可能性，且相比于PBFT这种需要各节点之间相互进行通信的共识过程而言，算法的通信复杂度更低，且本身计算并不复杂，网络传输耗时可以忽略。5 结 语本文选取非拜占庭共识算法Raft作为研究对象，针对拜占庭Leader节点篡改客户端消息的问题，采用RSA数字签名作为消息的检验机制，同时在结合PBFT的三段协议的基础上引入标识位W，实现Raft算法在日志复制过程中的拜占庭容错，确保在拜占庭节点发送错误消息的情况下日志项依然能够被正确提交，很好地融合了 Raft 高效和PBFT可容错的特点。经过改进的 BRaft共识算法相较于PBFT共识算法通信复杂度更低，并在保证算法的可理解性和共识效率的同时，提高了算法安全性。但是本文算法还存在一些问题，如在领导者选举阶段无法选择最优Leader，以及对拜占庭节点无法进行动态删除、修改等操作，未来可针对这些问题加以重点研究。参考文献：1 LIU Y Z，LIU J W，ZHANG Z Y，et al.Overview on blockchain consensus mechanismsJ.Journal of Cryptologic Research，2019，6（4）：395-432.刘懿中，刘建伟，张宗洋，等.区块链共识机制研究综述 J.密码学报，2019，6（4）：395-432.2 TAN M S，YANG J，DING L，et al.Review of consensus mechanism of blockchain J.Computer Engineering，2020，46（12）：1-11谭敏生，杨杰，丁琳，等.区块链共识机制综述 J.计算机工程，2020，46（12）：1-11.3 FU X，WANG H M，SHI P C.A survey of blockchain consensus algorithms：mechanism，designand applicationsJ.Science China Information Sciences，2021，64（2）：96-110.4 YUAN Y，NI X C，ZENG S，et al.Blockchain consensus algorithms：the state of the art and future trends J.Journal of Automatica Sinica，2018，44（11）：2011-2022.袁勇，倪晓春，曾帅，等.区块链共识算法的发展现状与展望 J.自动化学报，2018，44（11）：2011-2022.5 MECHANIC Q.Proof of stakeEB/OL.https：/bitcointalk.org/index.php？topic=27787.6 LARIMER D.Delegated proof-of-stake consensus EB/OL.https：how.bitshares.works/en/master/technology/dpos.html.7 COWLING J，MYERS D，LISKOV B，et al.HQ replication：a hybrid quorum protocol for Byzantine fault tolerance C/Proceedings of the 7th Symposium on Operating Systems Design and Implementation，2006：177-190.8 CASTRO M，LISKOV B.Practical Byzantine fault tolerance and proactive recoveryJ.ACM Transactions on Computer Systems，2002，20（4）：398-4619 MAZIERES D.The stellar consensus protocol：a federated model for Internet-level consensusEB/OL.https：/tools.ietf.org/html/draft-mazieres-dinrg-scp-04.10 GUETA G G，ABRAHAM I，GROSSMAN S，et al.SBFT：a scalable and decentralized trust infrastructureC/Proceedings of the 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks，2019：568-580.11 LAMPORT L.The part-time parliament J.ACM Transactions on Computer Systems，1998，16（2）：133-169.12 ONGARO D，OUSTERHOUT J K.In search of an understandable consensus algorithmC/Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference，2014：305-320.13 COPELAND C，ZHONG H.Tangaroa：a Byzantine fault tolerant raftD.California：Stanford University，2016.14 MARTINO W.Kadena：the first scalable，high performance private blockchain EB/OL.http：/kadena.io/docs/Kadena-ConsensusWhitePaperAug2016.pdf.15 HUANG D Y，LI L，CHEN B，et al.RBFT：a new Byzantine fault-tolerant consensus mechanism based on Raft cluster J.Journal on Communications，2021，42（3）：209-219.黄冬艳，李浪，陈斌，等.RBFT：基于Raft集群的拜占庭容错共识机制J.通信学报，2021，42（3）：209-219.16 JIANG Y，LYU R Z.Overview of blockchain consensus algorithms J.Journal of Jiamusi University（Natural Science Edition），2021，39（2）：132-137.姜义，吕荣镇.区块链共识算法综述 J.佳木斯大学学报（自然科学版），2021，39（2）：132-137.17 HARIDI S，KROLL L，CARBONE P.Lecture notes on leader-based sequence Paxosan understandable sequence consensus algorithm DB/OL.https：/arxiv.org/abs/2008.13456.18 MATTHEW A L B，DUNCAN P A，ADRIAN F.Graft：general purpose raft consensus in Elixir C/Proceedings of the 20th ACM SIGPLAN International Workshop on Erlang，2021：2-14.（责任编辑：孙 娟）020040060080010000200040006000800010000达成共识时间/ms客户端数量/个 PBFT BRaft RaftFig.7Consensus time for different numbers of client request图7不同数量客户端请求达成共识时间123456789100.00.10.20.30.40.50.60.70.8耗时/s试验次数/次 BRaft PBFTFig.8Time consuming to discover malicious nodes图8发现恶意节点耗时 137