一种面向许可链的可扩展共识方法

技术领域

本发明属于区块链技术领域，涉及一种区块链上进行可扩展共识过程的方法，具体涉及一种面向许可链的可扩展共识方法以及一种基于此共识方法的支持节点失效的区块重发起方法。

背景技术

区块链是一种面向互不可信环境的多方共同维护的分布式账本，具有去中心化、不可篡改、历史数据可追溯等特点。主流的区块链采用分层架构，通用基本架构可分为六层，自底向上分别为数据层、执行层、网络层、共识层、管理层和接口层，其中共识层是保证区块链网络中不同节点维持一致的副本数据，共识是分布式系统中最重要的抽象之一，简单来说就是让所有的节点对某件事情达成一致，在区块链中意味着对链式的区块达成一致。

共识算法在非许可链和许可链上有所区分，不同于非许可链的网络状况和节点未知，需激励机制推进的情形，在许可链场景下，由于节点已知并且不会人为退出较为可控，通常采用拜占庭容错(BFT)或崩溃容错(CFT)算法，该类算法的原理是节点间通过多轮信息交互来达成一致，通常会有一个提议者出块，其他从节点对该区块投票，如果多数通过则系统就对该区块达成共识。此外，在许可链场景下还有一种比较有代表性的即是Raft共识算法。在Raft共识的场景下，一个网络集群代表着一个共识的节点集体，即一主多从，网络集群下的节点分为三种类型，领导者(主节点)、跟随者(从节点)和候选者，集群节点的身份会在三种类型间进行转换。在选主期间(即无领导者作为主节点)，跟随者切换为候选者进行参选投票，赢得大多数票的候选者成为领导者，其他成为跟随者。在有主任期下，即正常的领导者和跟随者角色完成共识任务。目前对于Raft在许可链中的研究主要分为三类，一是拓展应用场景；二是引入信任机制使得Raft能够容忍拜占庭容错；三是重视在许可链中的流程优化与性能提升。然而，目前的研究在Raft可扩展性优化上的工作依然欠缺，导致了在数据全复制的许可链场景中，副本过多，传输区块数据量过大的通信开销问题仍然存在，具体表现为单领导者性能瓶颈、系统负载失衡以及丢失区块造成的带宽资源浪费等问题，影响整体性能。

因此，为了解决上述问题，提高Raft的可扩展性和性能，使其更能适应于许可链场景，有必要提出一种面向许可链的可扩展共识方法。

发明内容

为了解决现有技术存在的不足，本发明的目的是提供一种面向许可链的可扩展共识方法，所述方法基于一种共识算法Draft，实现了对区块共识任务的解耦以及分解后子任务的流程设计，该解耦策略将Raft中领导者承担的高负载任务分解为子任务分配到其他节点上，解决Raft的领导者瓶颈问题，进而提升了许可链的可扩展性和性能。本发明中所有的流程均在一个网络集群内。

本发明以提高许可链吞吐性能为目标，针对现有技术的缺失，提出一种面向许可链的可扩展共识方法。在Draft共识流程中，本发明通过对许可链区块共识任务的分析，其实所有节点真正达成共识的是区块顺序，区块数据与区块顺序在逻辑层面是可分离的，因此对区块共识任务进行解耦，将其分解为将其分解为区块数据复制子任务和区块顺序共识子任务，将区块数据复制子任务交由从节点完成，主节点仅负责区块顺序共识子任务，避免单点瓶颈问题，从而提高区块处理速度，提高系统吞吐量。

本发明提出了一种面向许可链的可扩展共识方法Draft，所述方法具体包括以下步骤：

步骤1：区块共识任务解耦，将一个完整的区块分解为唯一标志该区块的DHash和包含元信息和交易序列的区块数据(Block Data)，分别对应区块顺序共识子任务和区块数据复制子任务；

步骤2：将区块数据复制子任务交由从节点负责，从节点完成区块复制后通知主节点对该区块进行共识；

步骤3：主节点根据区块复制情况发起区块顺序共识子任务，对相应区块日志进行共识排序，最终提交并由各节点执行。

其中，

步骤1中，区块共识任务解耦为区块顺序共识子任务和区块数据复制子任务；

所述区块顺序共识子任务是指主节点接受从节点完成区块数据复制子任务后发送的DHash日志共识请求，收集到一定数量后对一批DHash日志进行共识，维护所有节点DHash日志序列的一致性，达到最终网络中区块信息一致的目的。

所述区块数据复制子任务是指从节点作为区块数据源节点接受客户端发送的交易请求，本地打包成区块并复制到其他区块数据接收节点的从节点，最后通知主节点对区块DHash日志进行共识，由此来分担主节点的工作，解决单点瓶颈的问题。

所述步骤2进一步包括以下步骤：

步骤2-1：从节点接收客户端发送的交易请求，打包成区块后，作为区块数据源节点发送区块数据给同一网络集群中的其他从节点进行复制；

本发明中仅考虑一个网络集群内部的共识，若涉及分布式集群则使用其他的协议来保证一致性，上述提到的其他节点是指除该点外的所有其他从节点，本步骤中是一个子任务，原来这个任务是主节点来做的，而本发明在这个任务中这个从节点作为子任务中的主节点，也是区块数据源节点，其他的从节点作为区块数据接收节点使用。

步骤2-2：其他从节点作为区块数据接收节点，持久化该区块数据完成复制后回复区块数据源节点；所述持久化是指对收到的区块进行公钥校验和区块检查后，存入本地的区块数据状态表中，表的索引为该区块的DHash，值为区块数据、区块源节点ID等相关状态信息，同时存入到本地存储中，表明已经收到该区块的复制请求。

步骤2-3：区块数据源节点对响应信息进行统计，确认同一网络集群半数以上节点完成复制后，生成DHash日志共识请求，发送给主节点；所述响应信息是指其他节点复制完成区块数据后回复区块数据源节点的信息。

所述步骤3进一步包括以下步骤：

步骤3-1：主节点接收到区块源节点发送的共识发起请求后，将区块DHash日志加入本地日志序列，确定区块序列，向同一网络集群内其他从节点发送请求；

步骤3-2：其他从节点收到请求后复制区块日志进行持久化，再向主节点回复确认信息，所述持久化是指将这一批区块日志DHash及其序列存入本地存储中，表明已经收到这批区块的共识请求。

步骤3-3：主节点收到半数以上的回复后，提交该区块并发起执行请求，其他从节点进行执行，最终区块上链成功。

本发明还提出了一种基于Draft的支持节点失效的区块重发方法，通过该方法让遗忘区块重新进入共识流程，避免存储和带宽资源的浪费,其方法包括如下步骤：

步骤I：网络集群内的所有节点通过定时器对区块定时检查，根据实际情况进行处理；对于确认是遗忘区块的区块启动重发起流程；

网络集群中的每个节点都会有个本地区块数据状态表，记录该区块的相关信息，DHash，是否提交之类的内容，重发方法会对每个区块信息设置一个定时器，然后检查这个区块超时后的状态(丢弃，等待，提交)来判断是否重发起。

步骤II：网络集群内的所有节点对于重发起区块进行判断，根据实际情况决定重发起流程由哪个节点，从Draft共识的哪个阶段开始执行，最终完成区块重发起任务。

针对上述步骤I和II中的可能出现的情况以及处理方式进行进一步阐述，说明如下：

(1)DHash日志和DHash日志序列对应且已被标记为提交，则该区块已完成共识任务，此时取消该定时器。

(2)DHash日志和DHash日志序列对应但未被标记为提交，根据Raft的规则，该DHash依然有被覆盖的风险，此时节点对该区块重新设置定时器，等待相同的时间后，重新检查该区块DHash日志的提交情况，如果主节点未崩溃，则正常提交，转向处理(1)；若此时主节点崩溃，发生换主，如果换主后区块DHash日志被覆盖，则转向处理(3)。

(3)DHash日志和DHash日志序列不对应，但从节点本地具有该区块DHash日志(换主)，说明大部分节点已经持久化该区块，此时该节点直接向当前的主节点发送一个DHash共识请求，并重新设置定时器，等待该区块被提交。

(4)DHash日志未加入DHash日志序列，且本地该区块无DHash日志仅有区块数据。如果该节点是区块源节点，保存该区块的复制情况，然后继续区块分发和后续流程；如果该节点并不是区块源节点，此时节点会先向区块源节点发送心跳包探查该节点是否失效，如果未失效则通知该节点继续改区块的流程，如果该节点失效则启动区块重发起机制：首先向集群中其余节点发送查询信息，收集该区块在集群中的数目，然后向未收到区块数据的节点进行补发，当持久化区块的节点达到半数以上后向当前的主节点发送DHash共识请求，并重新设置定时器，等待该区块被提交。

本发明的有益效果包括：本发明实现了一种可扩展共识方法，对区块共识任务分解，通过将区块顺序共识子任务和区块数据复制子任务，将其均衡地分配给主节点和从节点，解决了单点性能瓶颈，提升了可扩展性；本发明实现了节点失效的区块重发方法，通过该方法使得遗忘区块重新进入共识流程，避免存储和带宽资源的浪费。

附图说明

图1是本发明实施例1区块共识任务分解以及映射示例图。

图2是本发明实施例1Draft协议消息交互流程示例图。

图3是本发明实施例1区块数据复制子任务流程示例图。

图4是本发明实施例1Draft相关RPC接口示例图。

图5是本发明实施例2遗忘区块的四种情况示例图。

图6是本发明实施例2区块重发起机制流程示例图。

图7是本发明Draft的吞吐随节点数量增加变化的情况和Raft的比较示意图。

图8(a)和(b)分别为在27个节点的Raft和Draft许可链集群中各节点的通信负载情况示意图。

图9是RF-Chain和DF-Chain在小规模节点集群下的吞吐情况示意图。

图10是本发明RF-Chain和DF-Chain在大规模节点集群下的吞吐情况示意图。

具体实施方式

结合以下具体实施例和附图，对本发明作进一步的详细说明。实施本发明的过程、条件、实验方法等，除以下专门提及的内容之外，均为本领域的普遍知识和公知常识，本发明没有特别限制内容。

在传统的许可链当中，区块共识过程往往采用共识算法，其中较为主流的是Raft及其一系列变种共识算法，但这类算法有一个问题，区块共识过程中，区块数据复制和区块顺序共识均由主节点完成，可能会由于主节点性能瓶颈导致可扩展性差，拖慢了整个集群的吞吐性能。本发明中，为了解决主节点瓶颈问题，从而提升系统的整体性能，将区块共识任务分解，分析得出区块真正共识的内容是区块顺序，因此将区块复制子任务交由从节点去完成，主节点负责区块顺序共识子任务，负载均衡地分配任务，避免单点瓶颈，提高可扩展性。在此基础上还设计了节点失效的区块重发方法，减少了资源浪费。通过这两点提升整个系统的吞吐量。

本发明通过对Raft共识任务进行解耦，基于区块解耦策略给出一种Raft的可扩展优化实现，称其为Draft共识算法，通过这种方法将Raft中领导者承担的高负载任务分解为子任务分配到其他节点上，解决Raft的领导者瓶颈问题。本发明还设计了一种基于Draft的支持节点失效的区块重发机制，通过该机制让遗忘区块重新进入共识流程，避免存储和带宽资源的浪费。

本发明提出的面向许可链的可扩展共识方法如下方所示：

包括以下具体步骤：

步骤1：对区块共识任务进行解耦，将一个完整的区块分解为唯一标志该区块的DHash和包含元信息和交易序列的区块数据(Block Data)，分别对应区块顺序共识子任务和区块数据复制子任务；

步骤2：将区块数据复制子任务交由从节点负责，从节点在本地打包区块并复制到其他节点，然后通知主节点可以对该区块的DHash日志进行共识，包括以下具体步骤：

步骤2-1：从节点接收客户端发送的交易请求，该节点将其添加到本地的交易池中，等到数量到达区块内容纳交易数目的上限或时间到达出块时间的上限时，从节点开始从交易池中取出交易进行打包，按接收时间排序，计算Merkle根哈希，填充区块头中基本信息。将这些交易打包成区块后，从节点将其封装成请求，作为区块数据源节点发送给同一网络集群中的其他从节点进行复制；

步骤2-2：其他从节点作为区块数据接收节点，在收到该区块后进行检查，确认无误后对区块数据进行持久化，区块数据完成复制后区块数据接收节点回复区块数据源节点；

步骤2-3：区块数据源节点对响应信息进行统计，确认同一网络集群半数以上节点完成复制后，生成DHash日志共识请求，发送给主节点。

步骤3：主节点根据区块复制情况发起区块顺序共识子任务，对相应区块日志进行共识排序，最终提交并由各节点执行，包括以下具体步骤：

步骤3-1：主节点接收到区块源节点发送的共识发起请求后，将区块DHash日志加入本地日志序列，确定区块序列，向其他节点发送AppendDHash RPC请求，该请求接口是主节点负责区块顺序共识子任务的通信接口，发送DHash日志以及一系列验证信息，返回接收其他节点的共识响应信息；

步骤3-2：其他从节点收到请求后复制区块日志进行持久化，再向主节点回复确认信息；

步骤3-3：主节点收到半数以上的回复后，提交该区块并发起执行请求，其他从节点收到执行请求后，如果本地有对应区块直接进行执行，否则去拉取该区块数据再执行，添加到本地的区块链上，最终区块上链成功。

本发明提出了一种基于Draft的支持节点失效的区块重发方法，包括Draft区块定时检查和Draft区块重发起两个环节，当前节点首先通过对本地区块数据状态表的区块进行定时检查，根据设置的定时器是否超时以及涉及的区块的状态是否结束来判断是否需要进行区块重发起，需要则实施区块重发起环节，代码如下方所示：

包括以下具体步骤：

步骤1：网络集群内的所有节点通过定时器对区块定时检查，根据实际情况进行处理，对于确认是遗忘区块的区块启动重发起流程。其大致流程如算法1所示，输入节点ID，获取超时的DHash和区块状态(第4-5行)，后续根据其出现的异常情况来决定后续的操作(第6-28行)，第19行启动区块重启。异常情况在本文的实施例2中罗列。

步骤2：网络集群内的所有节点对于重发起区块进行判断，根据实际情况决定重发起流程由哪个节点，从Draft共识的哪个阶段开始执行，最终完成区块重发起任务。其大致流程如算法2所示，获取节点对象、区块状态和区块源节点ID(第1-3行)，判断该节点是否是区块源节点(第4行)，判断区块任务的状态(第6行)，区块源节点重新执行区块数据复制子任务(第8-22行)，否则向区块源节点请求区块重发起(第25-37行)。实际区块情况的处理在本文的实施例2中罗列。

实施例1

本实施例是对可扩展共识方法执行过程的实例方法，图4是Draft节点交互的相关RPC接口，其中AppendBlock RPC是从节点负责区块数据复制子任务的通信接口，AppendDHashRPC是主节点负责区块顺序共识子任务的通信接口，CanConsensus是从节点将可共识的DHash发送给主节点的的通信接口，Requestvote RPC是Raft原有的选举的通信接口。

首先，如图1所示，是区块共识任务分解后的数据(block data)以及其哈希映射关系(DHash)，任务被分解为区块复制子任务和区块顺序共识子任务，在区块复制子任务中，Block作为该任务下产生的数据进行传输和持久化；在区块顺序共识子任务中，DHash作为日志由主节点确定序列并进行传统的Raft共识。

其完整的区块共识协议消息交互流程如图2所示，其中C是客户端，P0是主节点，P1、P2、P3、P4是从节点，在图中展现的区块数据复制子任务中，P1是区块源节点。首先客户端发送交易请求到P1，P1收集一些交易后打包成区块，然后调用AppendBlock RPC向其他节点发送区块数据，这些节点接收区块数据写入本地存储，然后返回已持久化该区块的回复。当P1接收到半数以上的确定已持久化的回复时就可以通过CanConsensus RPC向主节点P0发送该区块的DHash。P0收到后得知许可链集群中半数以上的节点都持久化了该DHash的区块数据，则将DHash封装为DHash日志，准备进行raft共识，通过AppendDHash RPC通知其他节点添加该DHash日志到自己的本地DHash日志序列中，其他节点持久化该DHash日志后亦返回确定持久化的回应。当P0接收到半数以上的DHash日志持久化回应后，在下次AppendDHash RPC中通知所有节点可以提交该DHash日志，执行该DHash相关的区块，执行完区块后节点给客户端返回已上链消息。

其中，如图3所示，展示了一个具体的区块数据复制子任务流程示例，图中的许可链集群共有5个节点，其中节点C是主节点，节点A、B、D、E是从节点，其中节点E是当前区块的区块源节点(其他从节点也在执行和节点E相同的流程，图中未显示出来)。图中虚线框的序号标志着三个步骤，客户端发送交易到节点E，节点E打包成区块，复制到A、B、D，其中A、B成功接收到区块数据，持久化区块数据后回复响应。但发送给D的消息丢失，所以E无法得到D的回复。但是根据A、B的响应，E能够确定半数以上的节点(包括自身共3个)已经持久化该区块数据，所以可以继续后续流程，向主节点C发送DHash日志共识请求，主节点C接收到后会启动区块顺序共识子任务，对该DHash日志进行共识。后续节点D会尝试从数据源节点E或相邻节点B中拉取区块数据，最终所有节点会对该区块达成一致。

实施例2

本实施例是基于Draft的支持节点失效的区块重发方法的实例。

首先，如图5所示，展示了一个区块正常的共识流程，以及在这个流程中不同的时间点因某些节点失效导致的异常情况，有如下几种情况：

异常情况1：区块源节点刚打包区块，还未分发区块，或未发送完整的区块数据，此时宕机崩溃。除了该节点外，其他节点都不会持有该区块的数据，所以不会有任何后续流程，交易请求的失败通知与重发将由客户端负责。

异常情况2：区块源节点打包好区块，分发区块到其他节点上，其他节点回复持久化响应，区块源节点尚未发送DHash到主节点就失效，区块被遗忘。不同于异常情况1，此时区块已经被部分节点持久化，可以选择让部分节点丢弃该块，或者让其启动区块重发起机制。

异常情况3：主节点接收到DHash，封装为DHash日志，尚未复制到大多数节点就失效，新的主节点继承后，覆盖了这个DHash日志，其相应的区块被遗忘。不同于异常情况2，此时区块已经被大多数节点持久化，所以此时启动区块重发起机制更为合适。

异常情况4：这种情况是由于Raft一个特殊问题产生的，如果DHash日志的任期并不是当前主节点的任期，即使DHash日志被复制到大多数节点，但此时主节点崩溃，新的主节点继承，依然可能覆盖这个日志。

对于区块失效重发起的流程，如图6所示，当区块的定时器超时后，节点会根据以下情况进行相应的处理：

(1)DHash日志和DHash日志序列对应且已被标记为提交，则该区块已完成共识任务，此时取消该定时器。

(2)DHash日志和DHash日志序列对应但未被标记为提交，根据Raft的规则，该DHash依然有被覆盖的风险，此时节点对该区块重新设置定时器，等待相同的时间后，重新检查该区块DHash日志的提交情况，如果主节点未崩溃，则正常提交，转向处理(1)；若此时主节点崩溃，发生换主，如异常情况4，如果换主后区块DHash日志被覆盖，则转向处理(3)。

(3)DHash日志和DHash日志序列不对应，但从节点本地具有该区块DHash日志(换主)，如异常情况3和4的换主区块DHash日志覆盖，说明大部分节点已经持久化该区块，此时该节点直接向当前的主节点发送一个DHash共识请求，并重新设置定时器，等待该区块被提交。

(4)DHash日志未加入DHash日志序列，且本地该区块无DHash日志仅有区块数据，如异常情况2。如果该节点是区块源节点，保存该区块的复制情况，然后继续区块分发和后续流程；如果该节点并不是区块源节点，此时节点会先向区块源节点发送心跳包探查该节点是否失效，如果未失效则通知该节点继续改区块的流程，如果该节点失效则启动区块重发起机制：首先向集群中其余节点发送查询信息，收集该区块在集群中的数目，然后向未收到区块数据的节点进行补发，当持久化区块的节点达到半数以上后向当前的主节点发送DHash共识请求，并重新设置定时器，等待该区块被提交。

(5)针对异常情况1，这类情况由于还未进入Draft共识流程，因此无法由服务端处理，客户端在请求超时后会重新向另外一个节点发起请求，重新打包区块进入Draft共识流程。

本发明中的Draft主要是针对Raft共识算法进行改进，所以在此与原始Raft进行对比实验，实验说明如图7所示。

如图7中分别测量了两种算法在3,5,7,21,49等节点数量下集群内的吞吐表现，从图中可以看出，Draft的性能在每种节点数量下都是优于Raft的：在节点数为3时是2.14倍，在节点数为5是3.47倍，节点数为21时是12.00，倍节点数为49时是12.26倍，节点数为105时是20.27倍。从图中可以看出，随着节点数增加，两种算法的吞吐都会下降，这是因为许可链是全副本复制，当节点数增加时，这部分网络的开销也随之增长。但Draft受到的影响是小于Raft，即可扩展性优于Raft，从上述的性能对比倍数增加也可以看出，因为Draft使用区块共识任务解耦策略，将区块数据传输的通信负载分摊给所有从节点，充分利用了所有从节点的网络带宽，而raft需要有主节点完成上述任务，导致了单点瓶颈。并且由于其充分利用带宽，在节点增加到一定数量后，可以发现其吞吐逐渐趋向于平稳，这是由于DF-Chain的负载均衡使得瓶颈从原来的主节点单点瓶颈变为网络带宽，因此最终会达到一个稳定值。

图8(a)和(b)展示了在27个节点的Raft和Draft许可链集群中各节点的通信负载情况，为了更准确地测量集群节点的带宽情况，本实验在较为稳定的网络环境下进行，避免了换主情况，节点的最大带宽限制在80MB/s。

在Raft中，主节点承担了大部分区块数据负载开销，从节点仅被动接受区块并返回响应信息，通信负载极度不均衡，导致了整个许可链系统的性能瓶颈。而在Draft中，每个从节点负责区块的复制，从表中也可以看出负载被均匀地分配每个从节点上，充分利用了系统的带宽资源。

本发明Draft共识算法集成在许可链原型系统DF-Chain中与Raft集成的RF-Chain系统对比的相关实验分析，实验说明如图9所示。

图9展示的实验在小规模的节点集群(3,5,7,9)上进行，该实验在“100％读”，“80％读20％写”，“50％读50％写”和“100％写”场景下的交易吞吐情况。

从图9中(a)可以看出，对于“100％读”的交易请求，两种许可链系统实验结果相似，因为读不涉及区块共识过程，仅查询区块链的世界状态即可。但对于有写请求的场景图9中(b)、图9中(c)和图9中(d)下，DF-Chain展现了它的优势，随着节点数量的增加，RF-Chain的单点瓶颈问题愈加严重，其交易吞吐逐渐下降。而DF-Chain比RF-Chain在不同节点数下都有n-1倍以上的性能提升，且最终趋向于一个平稳值。

图10展示的实验在大规模的节点集群(18到108以9为单位递增)上进行，可以看出在大规模节点集群上，RF-Chain的单点瓶颈问题更加明显，DF-Chain仍可以正常运行。

上述数据说明了本发明中由Draft集成的许可链系统具有更高的吞吐性能和更好的可扩展性。

本发明的保护内容不局限于以上实施例。在不背离本发明构思的精神和范围下，本领域技术人员能够想到的变化和优点都被包括在本发明中，并且以所附的权利要求书为保护范围。