CN114499890A - 联盟链中基于节点分组的Raft PBFT两阶段共识机制 - Google Patents

Abstract

本发明涉及两阶段共识机制技术领域，且公开了联盟链中基于节点分组的Raft PBFT两阶段共识机制，包括以下步骤：1)Raft节点分组、Leader节点生成；2)PBFT节点生成，节点间采用多对多的通信模式，在节点的选择上做了相应的筛选，得到该阶段两类节点；3)Raft层各个分组的节点负责收集来自客户端的交易，并将交易聚集至分组代理节点；4)进入PBFT共识阶段，对交易进行快速验证并达成共识，并由分组代理节点分发至各个Raft分组；5)Raft分组验证分组代理节点转发的区块并开启分组共识阶段。该联盟链中基于节点分组的Raft PBFT两阶段共识机制，通过PBFT共识阶段检查区块，通过Leader节点检查PBFT共识阶段打包的区块，以提高区块链系统的安全性。

Description

联盟链中基于节点分组的Raft PBFT两阶段共识机制

技术领域

本发明涉及两阶段共识机制技术领域，具体为联盟链中基于节点分组的RaftPBFT两阶段共识机制。

背景技术

区块链作为一种新兴的分布式技术，自诞生之日起就得到了广泛应用，其去中心化特性减少了对受信机构和第三方的依赖，可以很好解决数据被篡改的问题，增强数据的共享性，区块链的核心技术包括共识机制、分布式存储、智能合约以及密码学，作为一种按时间顺序存储数据的数据结构，为了保证所有的诚实节点维护一致的区块链数据，共识机制已成为区块链技术研究的重要方向，根据区块链系统应用场景的不同，一般分为公链、私有链和联盟链，公有链的去中心化程度最高，任何节点都可以加入，如比特币、以太坊和莱特币等，联盟链一般由个人、公司或组织组成，节点必须经过联盟链中的节点成员管理服务确认并批准后，才能加入联盟链网络，私有链去中心化程度最低，一般由个人或单个组织创建。

PoX系列的公有链中常用的共识算法通过引入代币并提高交易打包的成本来达成共识，比如，PoW(Proof of Work)[3]–[5]引入代币，并通过奖励代币激励节点进行耗时的复杂运算，同时，运算结果能被其他节点快速验证，以耗用的时间、设备和能源作为担保成本，确保节点间达成共识，相较于PoW共识，PoS(Proof of Stake)[6]，[7]根据每个节点拥有的代币量和持有的时间，通过算法比例降低节点的验证验算难度，从而缩短共识时间然而，由于PoS要求每一个节点都参与竞争，导致区块链网络的吞吐量成为PoS的瓶颈，DPoS(Delegated Proof of Stake)[3]选取部分节点作为代表负责记账，可以加快处理速度并降低能耗，不同于公有链，联盟链中的节点由达成协议的个人、公司或组织构成，共同参与管理联盟链。相较于代币，联盟链更需要高吞吐量、低资源消耗和高安全性以满足业务需求，而公有链中常用的PoX共识机制的吞吐量低，无法满足联盟链的实际应用场景的需求，因此，设计高效安全的联盟链共识机制迫在眉睫。

现有的联盟链项目，如HyperLeger Fabric采用PBFT[8]，[9]共识机制，通过所有节点共同执行三阶段的共识过程来保证共识的安全性，然而，当节点数量增多时，为了保证区块链系统的一致性，网络中各个节点的通信次数和数据传输量将显著增加，造成吞吐量的大幅度下降，Coco采用Paxos[10] 共识机制，作为一种基于消息传递的共识机制，与PBFT相比，具有更低的共识成本和更高的吞吐量，但因为其逻辑分工复杂，不适用于大量节点的联盟链场景，FISCO BCOS采用Raft[11]共识机制与Paxos相比，其目标是提供更清晰的逻辑分工，算法易于理解，但Raft和Paxos都面临无法处理恶意节点作恶的情况，因此，提出改进的联盟链共识机制，针对现有共识机制吞吐量低、安全性不足、共识成本高等问题，故而提出一种基于节点分组的Raft PBFT两阶段共识机制来解决上述问题。

发明内容

(一)解决的技术问题

针对现有技术的不足，本发明提供了联盟链中基于节点分组的Raft PBFT 两阶段共识机制，具备优化交易传播路径，降低区块链系统的共识时延等优点，解决了现有共识机制吞吐量低、安全性不足、共识成本高的问题。

(二)技术方案

为实现上述目的，本发明提供如下技术方案：联盟链中基于节点分组的 RaftPBFT两阶段共识机制，包括以下步骤：

1)Raft节点分组、Leader节点生成，考虑到自动随机地为节点分组而无需人为干预，同时避免因节点分布不均导致部分分组通信压力大的问题。设计基于Hash环的分组机制；

2)PBFT节点生成，考虑到PBFT共识中，节点间采用多对多的通信模式，导致参与共识的节点数增多时，共识时延急剧上升，因此在节点的选择上做了相应的筛选，得到该阶段两类节点：分组代理节点和主记账节点；

3)首先，在分组交易聚集阶段，Raft层各个分组的节点负责收集来自客户端的交易，并将交易聚集至该节点所在组的分组代理节点；

4)随后，进入PBFT共识阶段，PBFT层汇总各个分组代理节点的交易，对交易进行快速验证并达成共识，并由分组代理节点分发至各个Raft分组；

5)最后，Raft分组验证分组代理节点转发的区块并开启分组共识阶段，并在分组共识结束后通知客户端交易已上链，至此，两阶段共识结束。

进一步，所述节点映射：实现将节点映射到Hash环上，其中节点编号通过式(1)获得，式(1)：

H_n＝Hash(P+T_n+R)

式(1)中，H_n表示节点映射到Hash环上的Hash值，P表示区块链节点的IP地址，Tn表示当前时间戳，R表示随机数。

进一步，所述Leader节点生成：考虑到分组中节点的通信距离，优化Raft 共识中Leader节点的选举方式，采用通信距离排行算法维护一组通信距离由大到小排序的Leader节点队列，组内通信距离低的节点将被优先作为Leader 节点，以提高分组的吞吐量。

进一步，所述分组代理节点：通过比较Raft的节点分组中各节点间的通信距离，通过聚类从分组中选出节点分组间通信距离最短的节点作为分组代理节点，以优化PBFT共识阶段节点间的通信距离。

进一步，所述主记账节点：每轮PBFT共识过程中，有且仅有一个主记账节点，主记账节点通过式(2)获取节点号，其中I_p表示当前主记账节点的编号，V表示视图大小(用于记录PBFT中主记账节点的工作周期)，N_p表示PBFT 共识阶段中的节点个数，式(2)：

I_p＝(V+1)mod N_p

进一步，所述Raft共识阶段-分组交易聚集阶段包括以下步骤：

1)Raft共识阶段中各个分组的节点(包括Leader节点和Normal节点) 接收来自客户端的交易；

2)Normal节点根据自身与分组内的Leader节点和分组代理节点的映像间的通信距离，选择通信距离更短的传播路径；

3)如果d>l+r，Normal节点将选择传播路径1-2，既Normal节点先转发交易至Leader节点，再由Leader节点转发交易至分组代理节点的映像；

4)如果d<l+r，Normal将选择传播路径3，即Normal节点直接转发至分组代理节点的映像，其中，d表示Normal节点和Proxy节点间的通信距离，l 表示Leader节点和Normal节点间的通信距离，r表示Leader节点和Proxy 节点间的通信距离。

进一步，所述PBFT共识阶段包括以下步骤：

1)各分组代理节点将交易转发至PBFT共识阶段的主记账节点；

2)主记账节点在出块间隔Δt后，将收集到的交易打包成区块，签名并广播至PBFT共识阶段的其他节点，随后，各节点将对区块和数字签名进行检查，以保证区块的真实性和有效性，若检查无误，将更新区块当前的共识阶段，随后对区块追加签名并继续广播区块至其他节点，区块的共识阶段共包含PrePrepare、Prepare和Commit三个阶段；

3)当区块的共识阶段处于Commit阶段并检查无误后，分组代理节点将转发数字签名集合和区块至Raft分组的Leader节点，随后进入分组共识阶段。

进一步，所述Raft共识阶段-分组共识阶段包括以下步骤：

1)节点分组中的Leader节点在接收到分组代理节点的映像发送的区块后，将验证区块的签名内容是否正确；

2)如果缺少签名或签名错误，Leader节点将向MMS(Member Management Service)举报分组代理节点，其中，MMS成员管理服务为联盟链的一部分，负责证书的颁发和成员的管理；

3)如果验证签名通过，Leader节点将向所在分组的其它节点广播区块，随后，在接收到分组内一半及以上节点的确认消息后，确认区块上链并通知客户端。

(三)有益效果

与现有技术相比，本发明提供了联盟链中基于节点分组的Raft PBFT两阶段共识机制，具备以下有益效果：

1、该联盟链中基于节点分组的Raft PBFT两阶段共识机制，通过在Raft 节点分组中找出最佳的通信节点作为Leader节点并优化交易传播路径，降低区块链系统的共识时延，又通过采用聚类得到节点分组间通信距离最短的节点作为分组代理节点，这些节点在PBFT阶段通过快速验证交易并达成共识，以提高区块链系统的吞吐量，并且，将PBFT拜占庭容错和节点分组中Leader 节点的区块检查机制结合，通过PBFT共识阶段检查区块，通过Leader节点检查PBFT共识阶段打包的区块，以提高区块链系统的安全性。

2、该联盟链中基于节点分组的Raft PBFT两阶段共识机制，本发明设计了PBFT和Raft共识阶段算法，各分组代理节点接收到由Raft分组其他节点转发的交易后，继续将交易转发至PBFT共识阶段的主记账节点，在出块间隔Δt后，由主记账节点执行PBFT共识阶段算法，算法执行完成后，Raft分组的Leader节点执行Raft共识阶段算法处理由分组代理节点的映像转发的、经过PBFT共识后的区块。

附图说明

图1为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构联盟链中两阶段共识机制框架图；

图2为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构节点分组流程图；

图3为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构Raft+PBFT共识机制流程图；

图4为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构分组交易聚集阶段节点的交易传播路径图；

图5为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构不同分组数量下的系统吞吐量示意图；

图6为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构不同分组数量下的系统时延示意图；

图7为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构不同出块间隔下的系统时延示意图；

图8为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构不同节点数量下的系统时延对比示意图；

图9为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构不同节点数量下的CPU消耗率示意图；

图10为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构不同共识机制的CPU消耗率对比示意图；

图11为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构不同出块间隔下的系统吞吐量示意图；

图12为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构不同节点数量下的系统吞吐量对比示意图；

图13为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构不同故障节点数量下的系统吞吐量示意图；

图14为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构不同故障节点数量下的系统时延示意图；

图15为本发明提出的联盟链中基于节点分组的Raft PBFT两阶段共识机制结构容错率比较示意图。

具体实施方式

下面将结合本发明的实施例，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参阅图1-15，联盟链中基于节点分组的Raft PBFT两阶段共识机制，包括以下步骤：

1)Raft节点分组、Leader节点生成，考虑到自动随机地为节点分组而无需人为干预，同时避免因节点分布不均导致部分分组通信压力大的问题。设计基于Hash环的分组机制；

2)PBFT节点生成，考虑到PBFT共识中，节点间采用多对多的通信模式，导致参与共识的节点数增多时，共识时延急剧上升，因此在节点的选择上做了相应的筛选，得到该阶段两类节点：分组代理节点和主记账节点；

3)首先，在分组交易聚集阶段，Raft层各个分组的节点负责收集来自客户端的交易，并将交易聚集至该节点所在组的分组代理节点；

4)随后，进入PBFT共识阶段，PBFT层汇总各个分组代理节点的交易，对交易进行快速验证并达成共识，并由分组代理节点分发至各个Raft分组；

5)最后，Raft分组验证分组代理节点转发的区块并开启分组共识阶段，并在分组共识结束后通知客户端交易已上链，至此，两阶段共识结束。

需要说明的是，节点映射：实现将节点映射到Hash环上，其中节点编号通过式(1)获得，式(1)：

H_n＝Hash(P+T_n+R)

式(1)中，H_n表示节点映射到Hash环上的Hash值，P表示区块链节点的IP地址，Tn表示当前时间戳，R表示随机数，如图2所示，拟将1～9共9 个节点分别划分到A、B、C、D四个分组，节点通过式(1)计算得到Hash值作为节点编号，映射到Hash环上，并从Hash环的0位置逆时针依次将这9 个Hash节点逐个分到这四个分组中，具体来说，首先将节点映射Hash环，从0开始，逆时钟方向，依次得到环上的节点顺序为：3，1，7，9，4，8，6， 2和5，随后，将这些节点依次放入分组到A、B、C、D四个分组中，即：3→ A,0→B,1→C,2→D,5→A,…,6→C，至此，完成节点分组。

同时，Leader节点生成：考虑到分组中节点的通信距离，优化Raft共识中Leader节点的选举方式，采用通信距离排行算法维护一组通信距离由大到小排序的Leader节点队列，组内通信距离低的节点将被优先作为Leader节点，以提高分组的吞吐量。

同时，分组代理节点：通过比较Raft的节点分组中各节点间的通信距离，通过聚类从分组中选出节点分组间通信距离最短的节点作为分组代理节点，以优化PBFT共识阶段节点间的通信距离，这些分组代理节点参与PBFT阶段共识，可以降低共识时延。

主记账节点：每轮PBFT共识过程中，有且仅有一个主记账节点，主记账节点通过式(2)获取节点号，其中I_p表示当前主记账节点的编号，V表示视图大小(用于记录PBFT中主记账节点的工作周期)，N_p表示PBFT共识阶段中的节点个数，式(2)：

I_p＝(V+1)mod N_p

Raft共识阶段-分组交易聚集阶段包括以下步骤：

1)Raft共识阶段中各个分组的节点(包括Leader节点和Normal节点) 接收来自客户端的交易；

2)Normal节点根据自身与分组内的Leader节点和分组代理节点的映像间的通信距离，选择通信距离更短的传播路径；

3)如果d>l+r，Normal节点将选择传播路径1-2，既Normal节点先转发交易至Leader节点，再由Leader节点转发交易至分组代理节点的映像；

4)如果d<l+r，Normal将选择传播路径3，即Normal节点直接转发至分组代理节点的映像，其中，d表示Normal节点和Proxy节点间的通信距离，l 表示Leader节点和Normal节点间的通信距离，r表示Leader节点和Proxy 节点间的通信距离。

PBFT共识阶段包括以下步骤：

1)各分组代理节点将交易转发至PBFT共识阶段的主记账节点；

2)主记账节点在出块间隔Δt后，将收集到的交易打包成区块，签名并广播至PBFT共识阶段的其他节点，随后，各节点将对区块和数字签名进行检查，以保证区块的真实性和有效性，若检查无误，将更新区块当前的共识阶段，随后对区块追加签名并继续广播区块至其他节点，区块的共识阶段共包含PrePrepare、Prepare和Commit三个阶段；

3)当区块的共识阶段处于Commit阶段并检查无误后，分组代理节点将转发数字签名集合和区块至Raft分组的Leader节点，随后进入分组共识阶段。

Raft共识阶段-分组共识阶段包括以下步骤：

1)节点分组中的Leader节点在接收到分组代理节点的映像发送的区块后，将验证区块的签名内容是否正确；

2)如果缺少签名或签名错误，Leader节点将向MMS(Member Management Service)举报分组代理节点，其中，MMS成员管理服务为联盟链的一部分，负责证书的颁发和成员的管理；

3)如果验证签名通过，Leader节点将向所在分组的其它节点广播区块，随后，在接收到分组内一半及以上节点的确认消息后，确认区块上链并通知客户端。

PBFT共识阶段算法如算法1所示：

算法1说明如下：

(1)算法1中的输入，C来自分组代理节点转发的交易，主记账节点将交易C追加到集合S中，在出块间隔Δt后打包区块并开启共识(第3-9行)；

(2)共识经历PrePrepare和Prepare阶段，此时各分组代理节点先判断区块签名是否合法，若签名不合法则不会为区块签名并丢弃错误的区块(第 22-24行)，若签名合法则对区块签名(第13行)并改变区块当前的共识状态 (第10-14行)，随后向其它分组代理节点广播当前节点验证并签名后的区块 (第19-21行)；

(3)当共识进行到Commit阶段时，节点会先验证区块的签名合法性，在为区块追加当前节点的签名后，将区块转发至该节点所在Raft共识组的 Leader节点(第18行)；

(4)算法的时间复杂度为O(n2)，其中n为参与PBFT共识阶段的节点个数。

Raft共识阶段算法如算法2所示：

算法2说明如下：

(1)Raft共识阶段的Leader节点将发送心跳包向节点所在组的其他节点证明自己并非故障状态(第3行)，并接收除Leader节点外的其它节点对心跳包的回复(第4行)，各个节点在回复Leader的消息中包含了节点的身份，由此，Leader节点可以检查其它节点当前的状态(第5行)，值得注意的是，当发现节点故障后，Leader节点将向MMS发送一份报文，告知本组内的节点故障情况(第5-11行)；

(2)当Raft共识阶段的Leader节点接收到来自所在分组的分组代理节点的映像转发的区块后，将验证区块和附带的数字签名，判断该区块和是否经过了PBFT阶段的共识验证(第8行)；

(3)如果验证失败，可认为当前Raft共识阶段中的分组代理节点存在恶意行为，该共识阶段的Leader节点将打包一份消息<Tc，M，Ic，Ip，Sc> 向MMS举报所分组代理节点(第12-19行)，其中，Tc表示当前时间戳，M表示举报内容，Ic表示当前节点的编号，Ip表示当前组分组代理节点的编号， Sc表示当前节点的签名；

(4)如果验证成功，则将区块广播给该Raft共识阶段中的其他节点(第20-22行)；

(5)算法的时间复杂度为O(n)，其中n为节点分组内的节点个数。

需要对算法1和算法2说明的是，其初始化流程主要包含三个部分：节点分组、Leader节点生成和分组代理节点生成，分别对应节点分组算法：算法3)、通信距离排行算法：算法5以及分组代理节点生成算法：算法4。

首先，调用节点分组算法进行节点分组，并检查各个分组的节点数，如果节点分组内的节点数小于Qr，则重新分组，直至各节点分组内的节点数大于等于Qr。

其次，调用通信距离排行算法评价分组中各节点间的通信距离，在Raft 共识分组中按通信距离由小到大维护一组节点栈，取通信距离最短的节点作为节点分组的Leader节点。

最后，调用分组代理节点生成算法评价各分组间的通信距离，并将节点分组间通信距离最短的节点设置为分组代理节点，这些分组代理节点负责汇总Raft分组的交易并进行PBFT共识阶段共识。

算法3、算法4以及算法5如下：

节点分组算法：算法3如下：

算法3说明如下：

(1)算法3旨在获得节点的分组链表，其中，区块链节点被平均且随机的存储在链表节点中，每一个链表节点表示一个分组；

(2)对于分组个数Ng，通过式(1)将各个分组映射到Hash环上(第6-9 行)，同时，考虑到分组数量过少时引起的数据倾斜问题，本文将Nv个虚拟节点映射到Hash环上，来解决这一问题(第10-15行)；

(3)对于节点个数Vn，通过式(2)将它们映射到Hash环上(第16-19行)。随后，通过顺时针的方式为节点匹配分组(第21行)，并将匹配结果存储在 Gs中(第22行)；

(4)节点数过少会引起分组不合理，即某个分组中的节点数量少于Qr。通过对分组结果进行检查(第25行)，如果分组不合理则继续分组，直到满足分组要求则退出循环并返回分组结果(第27-35行)。

分组代理节点生成算法：算法4如下：

算法4说明如下：

(1)作为算法4的输入，Gs来自算法3，首先，算法4通过使用迭代的方式遍历节点组合(第5-19行)，值得注意的是，考虑到节点分组的个数，即Gs的链表长度未知，算法4采用栈结构来记录当前迭代的深度(第4行)；

(2)对于每组节点组合n，通过计算节点间的平均通信延迟(第20行)，找出通信延迟最低的节点组合Nd作为算法的返回值(第21-26行)。

通信距离排行算法：算法5如下：

算法5的说明如下：

(1)作为算法5的输入，Sg源自算法3的Gs，包含单个节点分组中的所有节点信息；

(2)算法5通过遍历节点间的通信距离(第3-11行)，计算各节点在分组内的平均通信距离(第12行)，并将结果追加到Ns中(第13行)；

(3)将Ns按通信距离从小到大的顺序排列，并存储Ns至全局变量，最后选择Ns中通信距离最短的节点作为算法的输出。

试验例对比：本发明设置与主流的联盟链项目Hyperledger Fabric的PBFT[9]共识机制和RBFT[34]共识机制进比较，从共识时延、资源消耗、吞吐量和容错性四个方面进行实验对比。

(1)共识时延

共识时延D被定义为区块链系统开始处理客户端发送的交易，至交易在区块链中被打包成区块并达成共识的时间，如式(4)所示：

D＝T_s–Tb

其中T_s表示区块链系统开始处理交易的时间，T_b表示交易被打包至区块并达成共识的时间。

和资源消耗、吞吐量和容错性实验不同，针对共识时延，本发明设置单个客户端，在10min内每15s向区块链系统发送一次交易并记录区块链系统处理该请求的共识时延，将系统运行3min后稳定的时延数据的平均值作为系统的共识时延。

(2)资源消耗

区块链中各个节点达成共识的过程中，需要消耗大量的CPU、内存等资源，如比特币系统，采用PoW共识机制，在达成共识的过程中需要消耗大量的CPU 资源进行验证验算，并通过提供工作量证明达成共识，本发明将区块链进程对CPU 的消耗率作为区块链系统的资源消耗，如式(5)所示：

式(5)中，R_b％表示共识机制消耗系统CPU资源的百分比，R_a表示共识机制启动前计算机系统的CPU处理能力基准，R_c表示共识机制启动后计算机系统的CPU处理能力基准，实验将共识开始前5min的系统CPU处理能力基准的平均值作为R_a。

(3)吞吐量

吞吐量被定义为区块链系统每秒可处理的交易数量，如式(6)所示：

式(6)中，T_o表示区块链系统的吞吐量，G表示单个区块内客户端的交易量，t表示打包单个区块花费的时间。

(4)容错性

容错性被定义为区块链系统在正常运行状态下，系统能容忍的最大故障节点个数，如式(7)所示：

式(7)中，F_m表示区块链系统的容错性，N表示当前区块链系统中的节点总数，F_c表示当前系统的故障节点个数，通过在实验过程中依次增加故障节点的个数，观察区块链系统中吞吐量和时延的变化。

实验参数设置如表1所示，需要注意的是，因为节点分组内的Raft共识的最大容错率为(Q_r-1)/2，故节点分组内至少需要3个节点参加Raft共识， PBFT的最大容错率为(Q_p-1)/3，故PBFT共识阶段至少需要4个节点。

表1参数设置

5.2实验分析

(1)最优节点分组数分析

为了获得最佳的节点分组数，分别设置分组数为4组至8组，通过观察不同分组数量下24个节点和50个节点的吞吐量和时延，以获得最佳分组数，吞吐量的实验结果如图5所示，时延的实验结果如图6所示，随着分组数量的增加，区块链系统的吞吐量逐渐降低，时延住逐渐增高，当节点分组数为4 时，区块链系统的时延和吞吐量最佳，因此后续实验均在此分组数下进行。

(2)共识时延(时延)

令区块链系统的出块间隔Δt分别为10s、20s、40s、80s、100s、120s；取每种出块间隔下，系统运行5min后稳定的10组数据的平均值，作为该出块间隔下系统的共识时延，系统的共识时延随着出块间隔Δt的变化如图7所示，随着Δt的增加，时延持续上升，值得注意的是，Δt在40s以内保持小幅度增加，当Δt超过40s时，时延增长加快。

如图8所示，Raft+PBFT两阶段共识机制随着节点数量的增加，时延也在逐步增大，其中，PBFT共识机制的时延增长较剧烈，从24个节点至70个节点，PBFT的时延增幅达到45％，相比较RBFT和PBFT共识机制的时延，Raft+PBFT 两阶段共识机制有着较低的共识时延，在70个节点的情况下，相比较RBFT 共识机制降低了34％的时延，相比较传统PBFT共识机制，本发明方法降低了 80％的时延。

(3)资源消耗

本专利提出方法的CPU消耗率随着节点个数增加的变化如图9所示，令区块链系统的出块间隔Δt分别为10s、20s、40s。同时，分别模拟24-70个区块链节点，并观察在不同出块间隔Δt下，区块链共识的CPU消耗率，当节点数量增加时，CPU消耗率缓慢上升，其中，出块间隔Δt为40s时，区块链系统的CPU消耗率最低。

各共识机制的CPU消耗率对比如图10所示，本发明提出的共识机制和 RBFT的CPU消耗率均低于PBFT。

值得注意的是，由于引入了分组代理节点和Raft共识阶段节点交易传播路径的选择方案，导致两阶段共识机制的CPU消耗率略高于RBFT，但在时延和吞吐量方面取得显著提升，故我们认为两阶段共识机制相比较PBFT和RBFT，拥有较优的CPU消耗率。

(4)吞吐量

系统吞吐量随着出块间隔Δt的变化，如图11所示，令区块链系统的出块间隔Δt分别为10s、20s、40s、60s、80s、100s和120s；同时，分别模拟24、30和40个区块链节点，取每种出块间隔下，系统运行5min后稳定的10组数据的平均值，作为该出块间隔下系统的吞吐量，Δt从10s增长到40s 时，系统吞吐量随着出块间隔的增长而增长；当Δt从40s增长到120s左右时，吞吐量随着Δt的增加而降低。

不同节点数量下的系统吞吐量对比如图12所示，本专利提出的共识机制的系统吞吐量要远远高于其它区块链共识机制，在节点数量为70的情况下，相比较RBFT共识机制约有55％的吞吐量提升，相比较PBFT共识机制约有640％的吞吐量提升，同时，当节点数量从24变化到70，系统吞吐量的增长率为 200％左右，比RBFT共识机制的增长率高出约12.5％，比PBFT共识机制高出约 147％，因此，相较于传统的区块链共识机制，本发明共识机制具有较好的可扩展性，且更适用于对系统吞吐量要求较高的联盟链场景。

(5)容错性

系统出块间隔Δt分别设置为10s、20s和40s，分别模拟24、30和40 个节点，依次增加系统中故障节点的数量，观察对应故障节点数量下的系统吞吐量和共识时延。

如图13所示，在故障节点数量保持在15个以内时，三种出块间隔下的系统吞吐量仍维持较好的表现，当故障节点数量超过15，三种出块间隔下的系统吞吐量都呈现急剧下降趋势，由此可知，在节点数为24个的情况下，当故障节点数保持在15个以内时，系统的吞吐量可以维持在较好的水平。

系统时延随故障节点增加的变化如图14所示，在出块间隔Δt被设置为 10s，故障节点数保持在15个以内时，系统时延依旧稳定在一个较低的范围，当故障节点数量超过15，公示时延急剧上升，值得注意的是，相比较出块间隔被设置为10s和20s，在出块间隔被设置为40s时，因为出块间隔变大导致每个区块内包含的交易的数量增加，随着故障节点的数量上升，共识时延和吞吐量会出现一定幅度的波动，但整体上仍保持在较合理的范围，同时，当故障节点数量超过15个时，同样呈现出系统时延急剧上升且吞吐量迅速下降的趋势。

由图13-14可知，本专利共识机制最多可容纳的故障节点数为15个，通过容错率计算公式Fm＝Fc/N，计算得出该共识机制的容错率约为60％，如图15 所示，PoW、PoS、DPoS、PBFT、RCP和Raft共识机制的容错率均来自官方，相比较这些主流区块链共识机制，本发明提出的共识方案拥有更高的容错性，因此，本发明共识机制具有高安全性。

本发明的有益效果是：

1、该联盟链中基于节点分组的Raft PBFT两阶段共识机制，通过在Raft 节点分组中找出最佳的通信节点作为Leader节点并优化交易传播路径，降低区块链系统的共识时延，又通过采用聚类得到节点分组间通信距离最短的节点作为分组代理节点，这些节点在PBFT阶段通过快速验证交易并达成共识，以提高区块链系统的吞吐量，并且，将PBFT拜占庭容错和节点分组中Leader 节点的区块检查机制结合，通过PBFT共识阶段检查区块，通过Leader节点检查PBFT共识阶段打包的区块，以提高区块链系统的安全性。

2、该联盟链中基于节点分组的Raft PBFT两阶段共识机制，本发明设计了PBFT和Raft共识阶段算法，各分组代理节点接收到由Raft分组其他节点转发的交易后，继续将交易转发至PBFT共识阶段的主记账节点，在出块间隔Δt后，由主记账节点执行PBFT共识阶段算法，算法执行完成后，Raft分组的Leader节点执行Raft共识阶段算法处理由分组代理节点的映像转发的、经过PBFT共识后的区块。

实施方式举例

电脑配置：Ubuntu20.04六十四位操作系统，Intel Core i5处理器， CPU2133MHz，16GB内存，环境配置：将多个节点部署在虚拟机中，通过将节点映射到虚拟机的不同的端口，模拟节点的分布式运行环境，实验平台的软件运行环境为Ubuntu20.04/Golang14.4，在Ubuntu20.04环境中搭建一个联盟链网络，网络采用基于节点分组的Raft+PBFT两阶段共识机制，各区块链节点间的延迟在200ms以内，同时，区块链中的每个节点都向客户端提供访问服务，即每个区块链节点都可以接受来自客户端的请求，通过客户端程序访问联盟链网络，观察并记录区块链系统的交易处理延迟、区块产生时间、吞吐量和容错率，并与主流的联盟链共识机制进行比较分析，针对资源消耗、吞吐量和容错性实验，因为联盟链中的每一个节点都可以接受来自客户端的交易，为每一个区块链节点设置了一个客户端请求程序，同时，客户端请求程序每隔50ms向对应的区块链节点发送一份交易，共识完成后，区块将通过 BoltDB[35]持久化到本地存储，其中，持久化到本地的区块中，包括单次共识的交易数量和处理时间，实验将系统运行5mi n后稳定的10组数据的平均值作为实验数据。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

Claims (8)

1.联盟链中基于节点分组的Raft PBFT两阶段共识机制，其特征在于，包括以下步骤：

1)Raft节点分组、Leader节点生成，考虑到自动随机地为节点分组而无需人为干预，同时避免因节点分布不均导致部分分组通信压力大的问题，设计基于Hash环的分组机制；

2)PBFT节点生成，考虑到PBFT共识中，节点间采用多对多的通信模式，导致参与共识的节点数增多时，共识时延急剧上升，因此在节点的选择上做了相应的筛选，得到该阶段两类节点：分组代理节点和主记账节点；

3)首先，在分组交易聚集阶段，Raft层各个分组的节点负责收集来自客户端的交易，并将交易聚集至该节点所在组的分组代理节点；

4)随后，进入PBFT共识阶段，PBFT层汇总各个分组代理节点的交易，对交易进行快速验证并达成共识，并由分组代理节点分发至各个Raft分组；

5)最后，Raft分组验证分组代理节点转发的区块并开启分组共识阶段，并在分组共识结束后通知客户端交易已上链，至此，两阶段共识结束。

2.根据权利要求1所述的联盟链中基于节点分组的Raft PBFT两阶段共识机制，其特征在于，所述节点映射：实现将节点映射到Hash环上，其中节点编号通过式(1)获得，式(1)：

H_n＝Hash(P+T_n+R)

式(1)中，H_n表示节点映射到Hash环上的Hash值，P表示区块链节点的IP地址，Tn表示当前时间戳，R表示随机数。

3.根据权利要求1所述的联盟链中基于节点分组的Raft PBFT两阶段共识机制，其特征在于，所述Leader节点生成：考虑到分组中节点的通信距离，优化Raft共识中Leader节点的选举方式，采用通信距离排行算法维护一组通信距离由大到小排序的Leader节点队列，组内通信距离低的节点将被优先作为Leader节点，以提高分组的吞吐量。

4.根据权利要求1所述的联盟链中基于节点分组的Raft PBFT两阶段共识机制，其特征在于，所述分组代理节点：通过比较Raft的节点分组中各节点间的通信距离，通过聚类从分组中选出节点分组间通信距离最短的节点作为分组代理节点，以优化PBFT共识阶段节点间的通信距离。

5.根据权利要求1所述的联盟链中基于节点分组的Raft PBFT两阶段共识机制，其特征在于，所述主记账节点：每轮PBFT共识过程中，有且仅有一个主记账节点，主记账节点通过式(2)获取节点号，其中I_p表示当前主记账节点的编号，V表示视图大小(用于记录PBFT中主记账节点的工作周期)，N_p表示PBFT共识阶段中的节点个数，式(2)：

I_p＝(V+1)mod N_p。

6.根据权利要求1所述的联盟链中基于节点分组的Raft PBFT两阶段共识机制，其特征在于，所述Raft共识阶段-分组交易聚集阶段包括以下步骤：

1)Raft共识阶段中各个分组的节点(包括Leader节点和Normal节点)接收来自客户端的交易；

2)Normal节点根据自身与分组内的Leader节点和分组代理节点的映像间的通信距离，选择通信距离更短的传播路径；

3)如果d>l+r，Normal节点将选择传播路径1-2，既Normal节点先转发交易至Leader节点，再由Leader节点转发交易至分组代理节点的映像；

4)如果d<l+r，Normal将选择传播路径3，即Normal节点直接转发至分组代理节点的映像，其中，d表示Normal节点和Proxy节点间的通信距离，l表示Leader节点和Normal节点间的通信距离，r表示Leader节点和Proxy节点间的通信距离。

7.根据权利要求1所述的联盟链中基于节点分组的Raft PBFT两阶段共识机制，其特征在于，所述PBFT共识阶段包括以下步骤：

1)各分组代理节点将交易转发至PBFT共识阶段的主记账节点；

2)主记账节点在出块间隔Δt后，将收集到的交易打包成区块，签名并广播至PBFT共识阶段的其他节点，随后，各节点将对区块和数字签名进行检查，以保证区块的真实性和有效性，若检查无误，将更新区块当前的共识阶段，随后对区块追加签名并继续广播区块至其他节点，区块的共识阶段共包含PrePrepare、Prepare和Commit三个阶段；

3)当区块的共识阶段处于Commit阶段并检查无误后，分组代理节点将转发数字签名集合和区块至Raft分组的Leader节点，随后进入分组共识阶段。

8.根据权利要求1所述的联盟链中基于节点分组的Raft PBFT两阶段共识机制，其特征在于，所述Raft共识阶段-分组共识阶段包括以下步骤：

1)节点分组中的Leader节点在接收到分组代理节点的映像发送的区块后，将验证区块的签名内容是否正确；

2)如果缺少签名或签名错误，Leader节点将向MMS(Member Management Service)举报分组代理节点，其中，MMS成员管理服务为联盟链的一部分，负责证书的颁发和成员的管理；

3)如果验证签名通过，Leader节点将向所在分组的其它节点广播区块，随后，在接收到分组内一半及以上节点的确认消息后，确认区块上链并通知客户端。

Images