基于备选投票机制的低时延PBFT改进研究

吴晓彤，柳平增

（山东农业大学信息科学与工程学院，山东泰安271018）

0 概述

随着比特币等数字加密货币的日益普及，区块链正逐渐成为一种新的去中心化基础架构和分布式计算范式［1］。目前，区块链已经引起了政府部门、互联网企业和金融机构的广泛关注和高度重视［2］，其去中心化、公开透明、共同维护、时序性、可编程等特点，除了适合构建可编程的金融系统和货币系统之外，还能为中心化机构存在的数据存储不安全、低效率、高成本等问题提供解决方案［3-5］。共识算法是区块链技术的核心要素，也是近年来分布式系统研究的热点，其主要作用是解决拜占庭将军问题，也是确保分布式系统各节点数据一致性的关键，直接影响着区块链的交易处理能力、可扩展性和安全性［6-7］。

在目前常用的共识算法中，较为经典的算法有PoW［8］、PoS［9］、Paxos［10］、Raft［11］、PBFT［12］等。不同算法都有各自的特点和优势，其中，实用拜占庭容错算法（Practical Byzantine Fault Tolerance，PBFT）算法由于能够解决拜占庭问题且相对高效而被广泛应用。但由于PBFT 算法通信开销高，吞吐量和性能较低，且采用的是C/S 架构，不能适应P2P 网络，无法动态感知节点数目的变化［13-14］，因而其应用受到了诸多的限制。许多学者在共识策略［15-17］、一致性协议［18-19］、方法创新［20-21］、区块链结构［22］等方面对PBFT算法进行了改进，以期使算法具有更高的动态性和更低的时延。但该算法应用于一些交易量和信息量大的领域时，仍存在共识时延高、动态性差、吞吐量、性能较低等问题，因此，设计一个低时延、高效率、高吞吐量的共识算法，是亟待解决的问题。

本文针对PBFT 算法存在的不足，提出一种基于备选投票机制的低时延共识算法PBFT，通过引入候补节点集合和投票选举机制，降低算法达成共识所需的时延，提高算法的吞吐量和动态性。

1 实用拜占庭容错算法

PBFT 算法由CASTRO 和LISKOV 于1999年提出，该算法主要针对系统中存在的作恶节点向系统中的其他节点发送错误消息，扰乱整个系统正常运行的问题，从根本上解决了拜占庭问题，并将拜占庭容错算法复杂度从指数级降低到了多项式级O（N2）。实用拜占庭算法在保证系统安全性和可靠性的前提下提供了（n-1）/3 的容错性，即允许系统有不多于1/3 的节点失效或者作恶。

PBFT 共识算法要求节点共同维护一个状态，所有节点采取的行动一致。因此，需要运行3 类基本协议，即一致性协议、检查点协议和视图更换协议。一致性协议主要通过共识过程中的预准备、准备和确认3 个阶段来保证全网节点保存数据的一致性。若在共识过程中主节点在一段时间内都不能完成客户端的请求或某节点检测出主节点作恶或宕机，则会触发视图更换协议以更换出现故障的主节点。周期性地检查点协议则是将系统中的服务器同步到某一个相同的状态，系统会设置一个checkpoint 的时间点，在这个时刻可以定期地处理日志、节约资源并及时纠正服务器状态。

1.1 PBFT 算法的一致性协议

PBFT 算法的一致性协议是该算法的核心部分，能够保证各节点数据的一致性。如图1所示，其中，副本0 是主节点，副本3 是失效节点，c 是客户端。

图1 PBFT 算法共识过程Fig.1 Consensus process of PBFT algorithm

PBFT 算法具体流程如下：

1）客户端发起消息请求

客户端c 向主节点0 发送消息请求，格式为：

其中，REQUEST 为消息名称，o 为请求的具体操作，t 为请求时客户端追加的时间戳，c 为客户端标识。

2）预准备阶段

主节点会发起对应的预准备消息给网络中的副本节点，预准备消息包头结构体定义为：

其中，PRE-PREPARE 为消息名称，v为视图编号，d 为信息摘要，n为节点编号，m 为客户端发送的消息。若通过验证，副本节点会确认预准备消息进入到准备阶段。

3）准备阶段

副本节点i向所有副本节点发送准备消息：

若节点i收到了超过2f+1 个不同共识节点的PRE-PREPARE 和PREPARE 消息并验证通过，将进入确认阶段。

4）确认阶段

进入确认阶段后的节点向其他副本节点广播确认消息＜COMMIT，v，n，D（m），i＞，其中，D（m）为副本节点签名集合。所有的副本节点会对接收的广播消息进行验证，当节点i接收到2f+1 个确认消息并满足相应条件后，则代表式（4）成立，此时每个副本节点向客户端发送回复，进入回复阶段。

5）回复阶段

当算法进入到回复阶段时，共识集合中的节点i会给一个最终的反馈消息给客户端，消息格式定义为：

其中，REPLY 为消息名称，v为视图编号，t 为时间戳，c 是客户端，i是节点编号，r 是节点i的回复。

若客户端收到f+1 个相同的REPLY 消息，则说明客户端发起的请求已经达成全网共识。

1.2 PBFT 算法的视图切换协议

若某个副本节点i检测出主节点拜占庭错误或者宕机时，则启动视图切换协议，将视图编号v变更为v+1，同时不再接受除检查点（checkpoint）、视图切换（view-change）和新视图（new-view）外的其他消息请求。

此时，副本节点i会向其他节点广播视图更换消息：

其中，VIEW-CHANGE 为消息名称，v为视图编号，n是检查点编号，C是检查点消息集合，i是节点编号，P是当前副本节点未完成请求的PRE-PREPARE和PREPARE 消息集合。

通过公式p=vmod |R|计算得到主节点p（R为主节点的编号），当主节点p收到2f个来自其他副本节点的有效的视图更换消息后，节点p向其他副本节点广播新视图消息＜NEW-VIEW，v+1，V，O＞，其中，V 是节点接收到的视图更换消息，O 为主节点重新发起的未完成的预准备消息。当副本节点收到主节点的新视图消息后，若验证通过，进入v+1 视图开始O中的预准备处理流程。

1.3 PBFT 算法的优点与不足

实用拜占庭算法PBFT 是解决拜占庭将军问题的算法，能够针对性地解决共识当中出现的拜占庭问题，同时算法允许不超过1/3 的作恶节点存在，在节点数适中的情况下可以高效地完成共识。对于一些以企业、政府为代表的联盟链来说，PBFT 共识算法是较好的选择，但是该算法在目前的区块链技术中仍然存在以下不足：

1）视图切换协议的不足

在主节点出现拜占庭节点的情景下，实用拜占庭共识算法PBFT 必须进行算法的视图切换，但是，算法在视图切换过程中，对于当前区块链中已有的签名区块的数量，即区块高度的变量没有加以考虑，这样就会使得在共识超时情况下视图切换效率低下，直接导致算法在实际情况中的网络通信开销加大，增加了系统的数据交换开销，同时也失去了视图切换时的随机性，这对于算法性能是有影响的。

2）区块链共识节点动态性支持不够

在区块链分布式系统中，所有共识节点的行为通常都是随机的、动态的，在区块链网络中有加入也有退出。原始的实用拜占庭容错算法，在最初设计时主要是为了解决拜占庭将军问题，对于节点动态变化的问题并没有考虑得很周到，因此，算法无法支持节点动态加入或退出网络，这样容易导致在节点出现变化后无法快速进行处理，以及拜占庭的节点无法及时替换的问题。

2 PBFT 算法改进

针对原始PBFT 算法的不足，本文提出一种低时延的共识算法IPBFT。首先增设候补集合节点，用于选举产生新的备用主节点，并对视图切换协议进行优化，在提高共识效率的同时实现节点的动态增删；然后将算法的主节点选取方式改进为投票选举机制，优化主节点选取机制，在提高视图切换效率的基础上同时减少拜占庭节点的数量，从而提高系统效率。

2.1 改进思路与符号表示

本文按照图2所示的优化流程对PBFT 算法进行改进。

图2 PBFT 算法优化流程Fig.2 Optimization procedure of PBFT algorithm

1）以R1表示共识集合，以R2表示候补集合，定义R1集合为：

其中，R1表示共识集合总节点数，f表示共识结合中最多的拜占庭错误节点数。R1的节点数量根据实际应用系统中错误节点的数量而定。

候补集合中包括了从共识集合中出现拜占庭错误的替换节点和区块链系统中新加入的节点，在算法中，定义R2集合为：

同理，R2的节点数量根据实际应用系统中错误节点的数量而定。

2）当首次共识开始时定义一个值v1，与视图编号v不同，v1用于视图切换时主节点的选取，其初始值设置为：

其中，v是首次共识的视图编号数值，且每当视图成功切换一次，v1都相应的增加1，表示视图已切换。

3）当主节点发生拜占庭错误时，考虑到主节点选取的随机性和恶意节点的不可重复性，IPBFT 算法在主节点选取的定义中增加了一个区块高度参数h，计算公式为：

为提高视图切换的效率，规定主节点的选取在候补集合中进行，因此，主节点p的选取与R2有关。该公式结合投票选举的机制避免了拜占庭节点重复当选为主节点，同时公式的随机性也能够更好地使算法支持节点的动态性。

2.2 具体改进

对PBFT 算法的改进包括增设候补集合和加入投票选举机制两个方面。

1）通过增设候补集合以实现节点的动态变化。

（1）将所有的节点分为两个节点集合：一个是共识节点集合，集合功能为参加区块链中的共识过程；另一个是候补节点集合，若共识集合中主节点拜占庭或有节点退出，则由候补集合中选出的信任节点替换上，在实现节点动态替换的同时减小替换所需的时延。共识集合中的拜占庭错误节点，也将会被淘汰进入到候补节点集合中，信任节点的选取方式使用的是基于投票的选举机制。

（2）优化视图切换协议以简化共识过程。

①IPBFT 算法对视图切换协议进行了优化，当主节点发生拜占庭错误时，算法会丢弃未完成的共识提案历史信息，重新选取主节点，并提醒客户端发送与未完成提案相同的请求，然后进行共识。由于视图切换后会丢弃未完成的消息提案重新开始共识，一方面可以省去新主节点向其余节点广播新视图消息NEW-VIEW、收集之前未完成的预准备和准备消息的共识过程，可减少一部分网络开销，另一方面还能保证主节点广播的消息顺序正确。

②视图切换完成后，将共识节点所处的视图编号v初始化为0，v1数值增加1，从而保证即使出现视图切换，消息依然能在保证视图编号一致的基础上进行广播共识而不影响候补集合进行下一个备用主节点的选取。

③共识过程中确认阶段的作用，一方面是为了保证视图消息顺序和视图编号一致，另一方面是防止主节点出错而导致产生的集群状态不一致。IPBFT 算法首先可以保证在视图切换完成后，所有共识节点所处的视图编号和收到广播的消息顺序一致，其次可保证新的主节点为候补集合中节点所信任的非作恶节点，作恶的概率非常小。在这样的双重保障下，IPBFT 算法可以优化掉确认阶段的共识过程，共识过程由三阶段共识变成了两阶段，从而优化掉确认阶段的通信，提高整个共识达成的效率，减少系统的通信开销。IPBFT算法的共识过程如图3所示。其中，4 表示候补集合选举出的信任节点，等待视图切换时将拜占庭节点替换下来，除此之外不做任何操作。

图3 IPBFT 共识过程Fig.3 Consensus process of IPBFT algorithm

2）加入投票选举机制。

（1）投票选举整体思想及原理

IPBFT 共识算法使用基于投票的选举机制作为主节点的选取方式，在共识集合中，当主节点出现拜占庭错误或有节点退出时，算法将共识集合中的相应节点替换掉，使用候补集合中通过选举机制产生的新节点作为候补节点补增到共识集合节点中。

为提高节点替换的效率，候补集合的选举和共识集合的共识同时进行，即在共识集合正常运行的情况下，候补集合先将下一次视图切换所需要的信任节点选举出来，当共识集合的主节点出现错误时不再进行传统的视图切换过程，而是直接对备用的主节点进行替换，从而减少视图切换时的通信次数。

节点替换完成后，在候补集合内再进行下一次的节点选举，替换下来的拜占庭节点也会一直处于候补集合中，并且被选举为主节点的概率极低；同时，当有节点进入时，首先进入候补集合，节点进入或退出时算法会增加或删除他的投票权。投票选举原理如图4所示。

图4 投票选举原理Fig.4 Voting principle

IPBFT 算法首先实现候补集合与共识集合的联动同步过程，当共识集合的共识过程发生视图切换时，通过消息的广播，同步地通知到候补集合，其次候补集合将广播投票选举的消息，用于共识集合中节点的动态替换。

（2）投票选举流程分析

步骤1候补集合的节点保持与共识集合的心跳，当共识集合中的主节点出现拜占庭错误或有节点退出时，立即在候补集合内广播节点替换的消息，将选举好的信任节点替换到共识集合，在视图切换完成后进行下一次选举行为。

步骤2通过P=（h+v1）mod|R1|选出下一个节点候选人，参与选举的节点向其他所有节点发出参与选举的消息，同时通知集合中所有节点，自己将参与选举；如果该节点非当前共识集合中所需要的节点，则该节点自动放弃，重新选举下一个节点候选人。

步骤3在所有的节点收到该通知消息后，如果同意，则会选举该节点作为获选人；如果不同意，则可以反对，同时也能投票给本身节点；如果一个参选节点同意票选的数量大于或者等于R2/2+1 个，则成功获得称为获选人资格。

步骤4为避免选举算法出现特定情况下的恶性循环选举而最终影响选举的进度，算法规定了每个参选节点不同的唯一超时值。既然超时值是唯一的，那么所有的参选节点发起投票的行为将会成为顺序发起的行为，这样能有效地避免出现所有节点都得票不通过半的情况，节点分先后，最终会有一个唯一的节点获得获选人资格，并作为代表被放入到共识集合节点中，此时投票选举结束。IPBFT 算法选举流程如图5所示。

图5 IPBFT 算法选举流程Fig.5 Voting mechanism procedure of IPBFT algorithm

当投票结束时，会出现两种情况：1）若参与选举的节点中有节点得到超过半数的投票，则节点当选成为新一轮共识的主节点；2）若参与选举的节点都没有得到足够的票数，则视为本次选举失败，选举失败的节点返回候补集合中，此时v1数值加1，重新选取参与选举的主节点，发起进行新一轮的选举。

2.3 IPBFT 算法流程

IPBFT 算法的整体流程如图6所示。

图6 IPBFT 算法流程Fig.6 Procedure of IPBFT algorithm

根据上述算法的设计过程，给出IPBFT 算法的共识过程，如下所示：

算法1IPBFT 算法

输入交易请求

输出共识结果

1.主节点选举成功，视图编号初始化，v1的值增加1。

2.客户端发向主节点P送请求。//请求阶段

3.主节点进行广播预备消息。//预准备阶段

4.1.副本节点对主节点和接收到的提案消息进行验证，若主节点拜占庭错误，则进入视图切换流程，转到步骤1。

4.2.若提案消息验证通过则进入准备阶段，否则丢弃消息重新共识，转到步骤2。

5.1.副本节点进入到准备阶段，广播准备消息，当节点i收到超过2f+1 个不同共识节点的准备消息并验证通过，则回复共识达成信息给客户端。

5.2.否则进行视图切换或丢弃消息重新共识，转到1。//准备阶段

6.客户端在收到了f+1 个回复信息后，认为系统达成了共识，共识结束。

2.4 IPBFT 算法分析

为满足实际场景中的应用，同时满足算法高共识效率的要求，IPBFT 算法是基于部分同步状态的基础上进行应用的，即节点发出的消息，虽然会有延迟，但是最终会到达目标节点。这是由于本文算法确保了每一个节点都有不同的超时值，在允许一定延迟的情况下，达成节点间的共识，保证了节点共识的效率。例如当主节点的发送时间超过了此超时值，即视为主节点出错，此时执行IPBFT 算法的视图切换协议，进行后续的过程。结合候补集合以及备选投票机制，IPBFT 共识算法中存在以下优点：

1）算法将共识的过程从普通的三阶段优化为两阶段，在达成共识的基础上缩短了共识所需的时延和通信次数，极大地降低了系统的网络开销，共识的效率较原始PBFT 算法相比有明显提高。

2）当共识集合中出现主节点i拜占庭错误时，会使用候补集合中选举的信任节点进行替换，这样可以避免进行主节点的更换时出现多余网络通信的现象，而且还能使节点可以动态地增删，同时也避免了拜占庭错误节点i被第2 次或者多次的重复选为主节点，导致视图不断切换和系统的共识性能波动下降的情况。

3）当出现视图切换时，候补集合会将选好的信任节点替换到共识集合，同时共识集合的拜占庭错误节点也会替换到候补集合，如此替换下去，将会减少共识集合中的拜占庭节点数量，这样能够有效降低系统共识过程中的视图切换的概率，减小共识开销，保持系统的高效运行。

3 实验与结果分析

本文在算法的测试环节，使用基于docker 的容器技术，将区块链共识节点的运行配置和代码都装载在docker 虚拟容器中，系统对每个容器的资源分配内容为2 GB，节点的代码在容器中运行分配的CPU 的资源分配为5%，同时内存给每个节点运行时的内存的分配也为5%左右，使容器能够发挥其优点。所有的虚拟区块链节点的运行会相对独立，同时运行具有隔离性，实验环境信息如表1所示。

表1 实验环境信息Table 1 Experimental environment information

3.1 IPBFT 算法共识时延实验

共识时延是指从交易提交到交易完成之间所消耗的时间，是衡量共识算法运行速度的重要指标，较低的共识时延可使交易可以快速得到确认，区块链安全性更高，同时也能变得更为实用。测试的共识时延为区块完成一次共识过程的时间，用公式定义时延为：

其中，Tcomplete表示区块确认完成的时间，Tsubmit表示提案开始的时间。

为验证IPBFT 算法在实际应用中低时延的特点，对IPBFT 算法与原始PBFT 算法进行对比。在每次进行信息交易时进行一次节点的动态替换，用来模拟例如共识过程中节点替换的现象，同时保证7 个共识节点，测试在相同出块间隔内，系统发送1 000 条交易量下的对照实验，实验测试30 次，实验结果如图7所示。可以看出，在同一个网络环境中，以节点数量相同且传输的交易信息数据大小相同为前提，IPBFT 算法由于增设了候补集合，省去了大部分视图切换和更换节点产生的信息收集的过程，且省去了确认阶段，所需的共识时延要低于原始PBFT算法。单次共识所需的平均时延仅为380 ms 左右，证明在实际应用中，即使需要在短时间内处理大量的信息，且加上网络请求和数据传输的时延，整个系统的时延情况也能有良好的表现。

图7 共识时延对比Fig.7 Consensus delay comparison

3.2 IPBFT 算法吞吐量性能实验

吞吐量指的是在单位时间内完成的交易的数量，一般用TPS 来表示，TPS 公式为：

其中，Δt为出块所用的时间，TΔt为出块时间内完成的交易数量。

对上述的两种算法进行吞吐量的对比实验。由于吞吐量的大小与交易量及节点的数量有关，因此本次实验将分为两组独立的实验。

实验1将两种算法的共识节点数量固定为7 个，对各算法在相同出块间隔内，系统分别发送1 000、1 500、2 000、2 500、3 000、3 500、40 00 条交易量下的吞吐量进行30 次测试，将这30 次的结果取平均值作为实验的结果，如图8所示。可以看出，随着交易量的逐渐增多，在节点的处理能力范围内，每种算法的吞吐量也会随之增加。但当交易量超过3 000 条，此时的交易请求超过了节点的处理能力范围，导致了线程的堵塞，吞吐量呈下降趋势。但从总体来看，IPBFT 算法的吞吐量仍高于原始PBFT 算法。

图8 不同交易量下吞吐量对比Fig.8 Throughput comparison under different transaction volumes

实验2将每种算法的交易量固定为1 000 条，对各算法在共识节点数量分别为4、7、10、13、16、19、22、25 个情况下的吞吐量进行30 次测试，将这30 次的结果取平均值作为实验的结果，如图9所示。可以看出，随着节点数量的增多，两种算法的吞吐量都呈下降趋势，但IPBFT 算法的吞吐量仍高于原始的算法。

图9 不同节点数量下吞吐量对比Fig.9 Throughput comparison under different numbers of nodes

综上，IPBFT 算法具有更高的吞吐量，能够在相同时间内处理更多的交易事务，使区块链溯源系统具有更高的共识效率。

3.3 IPBFT 算法共识通信次数实验

为了验证IPBFT 算法的通信次数，对两种算法在共识过程的通信次数进行实验对比。为便于理解，首先计算IPBFT 算法和原始PBFT 算法的通信次数。

1）原始PBFT 算法通信次数

由于原始PBFT 算法中需要经过三阶段的共识过程和视图切换过程，假设共识节点数量为n，那么共识过程中的预准备阶段需要主节点将消息发送给所有副本节点，所需通信次数为（n-1）次。准备阶段中副本节点间互相通信，需要（n-1）2次通信次数。而确认阶段每个节点需要向除自己外的节点发送消息，所需通信次数为n（n-1）次。综上，共识过程的总通信次数N为：

在视图切换过程中，每个副本节点需要广播视图变更消息，需要（n-1）2通信次数；接着主节点发送新视图消息给所有副本节点，消耗（n-1）次通信次数；考虑到系统发生视图切换存在着一定概率。因此，视图切换过程的总通信次数M为：

其中，z为出现视图切换的概率（0≤z≤1），z会随着节点数量的增加而增长。综上，原始PBFT 算法所需要的总通信次数C为：

2）IPBFT 算法通信次数

IPBFT 算法由于共识阶段省去了确认阶段，所需通信次数为n（n-1）次；优化视图切换协议省去了主节点广播新视图消息的环节，且主节点的选取是在候补集合中进行，由于候补集合节点数量为（n-1）/3，因此所需要的通信次数为z｛［（n-1）/3］-1｝2次。综上，IPBFT 算法的总通信次数C为：

3）通信次数对比

将两种算法的通信次数进行对比，在没有出现视图切换的情况下，两个算法通信次数比值为：

由上式可知，算法在没有出现视图切换的情况下IPBFT 的通信次数为原始PBFT 算法的一半，极大地减少了系统的网络通信开销。

在视图出现切换时，2 个算法通信次数比值为：

将n取不同的节点数量，z取从0 到1 的所有情况，得到如图10所示的图形化界面。

图10 通信次数比值三维曲面图Fig.10 Three dimensional surface graph of communication degree ratio

由图10 可以看出：随着节点的增加，在视图切换概率取不同值的情况下，通信次数比值Q都高于2，即IPBFT 算法的通信次数将始终低于原始PBFT算法通信次数的一半，且随着概率z的逐渐升高，两个算法的通信次数比值也越来越大，证明了IPBFT 算法在共识切换所需的通信次数要远小于原始算法。

这里解释两个特殊情况：

（1）当共识集合节点数为4 时，候补集合中的节点数量为1，此时该节点就是下一次视图切换的主节点，因此，不需要进行选举过程，IPBFT 算法视图切换所需的通信次数为0，此时比值Q为3 并达到了最大值。但此时出现视图切换的概率为100%，在实际应用中一个可行的区块链系统不允许视图切换概率大于50%的情况发生，所以，此情况下比值Q虽然较大，但是没有实用价值。

（2）当z为0 时，由于没有出现视图切换过程，所以无论节点数量是多少，通信次数的比值Q一致保持在2。

总而言之，IPBFT 算法在通信次数最多的情况下也仅仅为原始PBFT 算法的一半。在实际情况中，算法所处的联盟链出现节点拜占庭的概率非常低，即出现视图切换的概率非常低，所以IPBFT 算法的通信次数可以长时间保持在原始PBFT 算法通信次数的50%。

IPBFT 算法与原始PBFT 算法的通信次数对比结果如图11所示。可以看出，实验结果可以很好地验证上述的结论，随着节点数量的增加，原始PBFT算法的通信次数呈大幅度增长，而IPBFT 算法的通信次数明显低于原始PBFT 的通信次数，且增长略显平稳。

图11 不同节点数量下共识通信次数对比Fig.11 Comparison of consensus communication times under different numbers of nodes

3.4 IPBFT 算法节点选举性能实验

由于IPBFT 算法中加入了选举机制，在此对候补集合中选举的性能进行实验分析，测试在不同节点数量下，候补集合在开始进行选举，到主节点替换完成所需要的时间。实验测试30 次，并取平均值作为结果，如图12所示。

图12 选举机制性能测试结果Fig.12 Performance test result of election mechanism

由图12 可以看出：随着候补集合中节点数量的增加，选举所需要的时间也会随之增多。但总体而言，候补集合中节点选举所需的时间能够保持在可接受的范围内，所花费的网络开销占整个系统开销的比重也微乎其微。实验证明，由于增设了候补集合并采取基于投票的选举机制，IPBFT 算法能够以更高的效率和更低的时延进行主节点的替换，而不影响系统整体的共识过程。

3.5 IPBFT 算法效率实验

效率测试实验是为了测试在系统运行一段时间后，整个共识集合中拜占庭节点的数量。实验将IPBFT 算法和原始PBFT 算法进行对比，首先将2 个算法的共识节点数量初始化为10 个，共识节点中的拜占庭节点数为3 个。IPBFT 算法的候补集合节点数量设置为3 个，候补集合的拜占庭节点数为0 个。实验记录出现视图切换时各集合中拜占庭节点的数量，实验结果如图13所示。

图13 选举机制效率测试结果Fig.13 Efficiency test result of election mechanism

由图13 可以看出：当实验发生3 次共识的视图切换时，IPBFT 算法共识集合的拜占庭节点数从3 个减少到0 个，候补集合中的拜占庭节点数从0 个增加到3 个；而原始的PBFT 算法，不管视图如何切换，共识节点中的拜占庭节点总数都没有发生任何变化。

在这种情况下，原始PBFT 算法拜占庭节点数的数量是不变的，那么发生视图切换的概率也会一直不变，系统的运行状态并不能达到最优。而IPBFT算法共识集合中拜占庭节点的数量会随着视图切换的次数不断下降，直到整个共识集合中没有拜占庭节点，此时系统会保持高效运行。由此可见，当系统运行一段时间后，IPBFT 算法的共识效率会比原始的PBFT 算法的效率高得多。

4 结束语

本文改进传统的PBFT 共识算法，提出一种低时延的共识算法IPBFT。通过增设候补节点集合，在视图切换协议上进行优化，使算法的共识过程简化为两阶段，减少了达成共识的时延。此外，采取基于备选投票机制作为主节点选取的方式，在共识节点进行共识的同时完成候补节点的选举，不仅减少了视图切换过程的节点通信次数，而且还能支持节点的动态变化。实验结果证明了IPBFT 算法的有效性及其低时延、高吞吐量、高共识效率的优点，同时能够较好地支持节点动态的加入或退出。下一步将在不影响算法效率的基础上把拜占庭节点的容错性提升到（n-1）/2，使IPBFT 算法能够适应更大规模的公有链。