一种可插拔共识协议框架模型、共识协议及其实现方法

技术领域

本发明涉及分布式账本技术领域，特别是涉及分布式账本技术中共识协议的开发与实现。

背景技术

共识协议被视为分布式账本技术的核心价值，它详细规定了系统内部节点的交互、打包交易与验证、区块锻造、数据路由与转发、记账人选举与账本维护等规则集合，对分布式账本技术通证经济的奖励模型设计，系统的交易处理能力，稳定性与扩展性具有决定性的影响。

随着分布式账本技术的发展，越来越多的共识协议被提出，这里对主流共识协议进行简单分类，如表1所示：

表1.共识协议分类

每种共识协议都是基于不同问题解决的角度和理论依据提出来的，因而具备自身的特点和缺点。现有技术中没有关于现有以及不断涌现的种类繁多的共识协议背后的本质分析，也没有抽象出一套统一的共识协议框架。因此无法通过定义不同的规则集合将现有和未来的共识协议进行统一，通过参数的定义决定使用具体的共识协议的实现，以实现一种可插拔的统一的共识协议框架，也就没有根据框架建立的共识协议，无法形成统一的解决问题的角度。

发明内容

有鉴于此，本发明的目的在于提供一种本发明提出一种可插拔共识协议框架模型、共识协议及其实现方法，其中框架模型是基础，通过定义不同的规则集合将现有和未来的共识协议进行统一，通过参数的定义决定使用具体的共识协议的实现，以实现一种可插拔的统一的共识协议框架。进而实现了共识协议 FBFT。

本发明的目的在于提出一种可插拔的共识协议框架模型，包括三部分，分别为：成员管理，角色管理和共识管理，三个部分形成的一个循环称为一轮，一轮就是一次共识协议运行的完整过程，通过所述三个部分，决议在一轮中达成明确的结果，即通过或者不通过，一旦达成所述明确的结果，所述框架模型再次运行成员管理，开始新的一轮共识过程，所述三个部分均支持参数配置定义策略，通过不同的参数配置，实现不同的共识协议。

优选的，所述成员管理负责每一轮参与成员节点的管理，包括：节点的加入和退出，节点成员列表，对于成员的管理通过定义不同的参数字段实现不同的策略，所述策略包括但不限于：Solo策略以及DPOS策略，定义所述Solo策略，则管理节点成员中仅存在当前节点；定义所述DPOS策略，则管理节点从系统合约获取节点成员。

优选的，所述角色管理负责每一轮成员节点角色的管理，包括但不限于：角色分配，更改角色；所述角色管理包括：首先定义当前轮中存在什么角色列表；接着根据角色分配策略对当前成员进行角色分配，最后定义各类角色的奖惩机制，即各个成员根据角色定义执行任务获得的奖励，如果执行失败或者执行过程中出现作恶的情形，如何进行惩罚，所述角色管理的所述角色列表，角色分配策略以及奖惩机制均可通过参数配置进行定义。

优选的，所述共识管理负责每一轮节点之间如何就一个或多个提议达成共识，即共识算法，所述共识算法与所述角色管理强相关，即所述角色管理中角色的定义来自于所述共识管理所提供的共识算法；所述共识管理中定义的共识算法规定了不同角色之间交互的行为，即通信协议。

本发明的目的还在于提供一种基于所述可插拔的共识协议框架模型建立的共识协议FBFT(Fast Byzantine Fault Tolerance)，包括：

共识协议FBFT的所述成员管理定义为：委托投票，即节点间通过委托的方式投票竞选进入成员列表，成员列表在每一轮共识协议执行过程均更新一次，以当时的投票情况为准，并且按序排列；所述角色管理首先定义两类角色，即锻造者和见证者，锻造者用于搜集交易和锻造区块，见证者用于对区块进行验证和签名，见证区块的产生，角色分配规则根据块高与成员个数的关系确定锻造者，每一轮仅存在一名锻造者，其余节点为见证者；所述共识管理定义简化的拜占庭协议作为共识算法，即由锻造者发起提议，该提议附带锻造者的签名，随后锻造者将提议广播给所有见证者，见证者收到提议后，将提议保存本地的临时队列中，并独立对提议进行验证，验证通过后添加自己的签名，将签名和提议的摘要返回给锻造者，如果未通过验证，则不给锻造者返回任何消息，仅保存提议，当锻造者收不少于三分之二的回复后，锻造者将搜集所有回复的签名，然后附带提议的摘要，哈希和签名集合给所有见证者，见证者收到消息后确认签名个数不少于成员个数的三分之二，则将该提议所包含的块加签名集合写入数据库；至此，一轮共识协议结束，系统紧接着进入下一轮，如此进行下去。

优选的，所述见证者和锻造者启用定时器避免锻造者造假或意外离线以及见证者超时未回复。

优选的，所述共识协议FBFT的入口为成员管理，从成员管理获取节点成员列表，随后根据角色管理管理定义的角色类型和角色分配策略将节点分为锻造者和验证者，最后根据所述的简化的拜占庭算法，节点成员之间进行协议交互，对提议内容进行确认，确认后进入下一轮。

优选的，所述共识协议FBFT还包括采用超时同步机制，所述超时同步机制分为超时机制以及同步机制两部分，所述超时机制防止锻造者和验证者网络拥塞，所述同步机制使各节点之间的状态快速达成一致。

本发明的目的还在于提供一种共识协议的实现方法，包括：

步骤101，START从成员管理模块获取成员列表；

步骤102，角色管理模块为成员分配角色，角色定义为producer和witness；

步骤103，如果角色为producer，则搜集交易，锻造区块，验证后添加自己签名信息，然后封装成proposal消息广播给其他节点，同时启动一个定时器 timeoutResponse，等待witness返回的response消息，producer在超时时间 timeoutResponse内等待witness返回的response消息，如果超时前收到不少于三分之二成员的response回复，停止定时器体timeoutResponse，同时将搜集到的response消息中来自各witness的签名集合取出，组装成commit消息，发送给其他节点，并写下该区块，再次进入Producer，进行新一轮的区块锻造；

步骤104，如果验证失败，则进行搜集交易，打包区块的操作；

步骤105，如果在超时时间内未收到不少于三分之二成员的response恢复，停止定时器timeoutResponse，同时将搜集到的response消息中来自各witness 的签名集合取出，组装成commit消息，发送给其他节点，本地不写入区块，再次进入Producer，进行新一轮的区块锻造。

优选的，对于witness，其操作流程包括：

步骤1001，启动一个定时器timeoutProposal，用来等待producer的proposal 消息；若timeoutProposal超时，封装changeViewReq消息，广播给其他witness，跳转到CHANGE_VIEW流程，所述CHANGE_VIEW流程防止producer意外离线或作恶，同时也避免超过三分之一的witness节点掉线，所述 CHANGE_VIEW流程等待changeViewReq请求，当收到超过三分之二的 changeViewReq请求，则跳转到START，重新获取成员和进行角色分配；若收到来自producer的proposal消息后，取消定时器timeoutProposal，然后独立的对proposal消息进行验证，验证通过后对proposal进行签名，并将签名信息与proposal的摘要打包成commit消息，发送给producer；

步骤1002，同时启动定时器timeoutCommit，等待producer的commit消息；若timeoutCommit超时，封装changeViewReq消息，广播给其他witness，跳转到CHANGE_VIEW；如果proposal验证失败，则不做任何操作；同时，当witness收到producer的commit消息后，将commit中的签名信息取出，赋值给block，重新对block进行验证，如果验证通过，则跳转到WITNESS，继续启动定时器，等待producer的消息；验证失败，无操作。

采用本发明的有益效果是：

抽象出一套统一的共识协议框架，即通过成员管理，角色管理和共识管理，决议在一轮中达成明确的结果(通过或者不通过)，一旦达成，该框架再次运行成员管理，开始新的一轮共识过程，通过定义不同的规则集合将现有和未来的共识协议进行统一，通过参数的定义决定使用具体的共识协议的实现，以实现一种可插拔的统一的共识协议框架，该框架的三个部分均支持参数配置定义策略，通过不同的参数配置，实现不同的共识协议。

根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。

附图说明

后文将参照附图以示例性而非限制性的方式详细描述本发明的一些具体实施例。附图中相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解，这些附图未必是按比例绘制的。本发明的目标及特征考虑到如下结合附图的描述将更加明显，附图中：

图1为根据本发明实施例的抽象共识协议框架模型组成部分结构图；

图2为根据本发明实施例的可插拔的共识协议框架模型原理框架图；

图3为根据本发明实施例的FBFT共识协议的实现方法流程图。

具体实施方式

为了使得本发明能够针对其发明要点更加明显易懂，下面将结合附图和实例对本发明作进一步的说明。在下面的描述中阐述了很多细节和具体实例，提供这些实例是为了能够更透彻地理解本发明，并且能够将本发明完整形象地传达给本领域的技术人员。虽然本发明能够以很多不同于此的描述的其它方式实施，但是本领域技术人员可以在不违背本发明内涵的情况下做相应的推广，因此本发明不受下面公开的具体实例及具体附图所限制。

分析各种主流共识协议，如以太坊，EOS，其背后的本质是一致的，可以分为三部分，即确定成员，分配角色，共识过程，下面详细描述。

如图1所示，“确定成员”即限定参与一次共识的成员列表；“分配角色”则是根据定义的规则集合对列表中的成员分配角色，首先需要定义有什么角色，角色的定义是依据接下来“共识过程”需要来定义的，每种角色在共识过程中将表现为不同的行为；共识过程则是不同角色之间按照既定的算法和协议进行通信，并最终对某一个或多个问题达成一致的过程。

以EOS共识协议为例进行分析，“确定成员”在该共识协议中即为在候选超级节点集合中按照得票情况选取21个节点；“分配角色”首先定义角色内容，根据“共识过程”的算法了定义记账人和验证人两种角色，记账人负责搜集交易，锻造区块并广播区块，验证人负责验证区块并签名背书；接着，进行角色分配， EOS按照126s为一个周期，每个周期内节点之间按照网络协商的顺序以6s的时间片进行轮转分配确定记账人和验证人，每轮分配仅存在唯一的一个记账人，其他节点为验证人；“共识过程”定义了共识策略，即共识算法，每一轮算法执行中记账人打包交易，锻造区块后签名，广播给验证人，验证人验证后签名，将签名结果返回给记账人，记账人收到超过2/3的验证人确认回复后，该区块进入不可逆状态。

通过EOS共识协议分析可知本抽象模型具有一定的普适性，基于该模型，本发明提出一种可插拔的共识协议框架，如图1所示。

该框架分为三部分：成员管理，角色管理和共识管理。首先定义，将图2 所示的一个循环称为一轮，一轮就是一次共识协议运行的完整过程。

“成员管理”负责每一轮参与成员节点的管理，包括：节点的加入和退出，节点成员列表等；对于成员的管理可以通过定义不同的参数字段实现不同的策略，如定义Solo策略，则管理节点成员中仅存在当前节点；定义DPOS策略，则管理节点从系统合约获取节点成员；通过参数配置定义策略能够提升“成员管理”的灵活性。

“角色管理”负责每一轮成员节点角色的管理，包括：角色分配，更改角色等等；“角色管理”首先需要定义当前轮中存在什么角色列表；接着，根据角色分配策略对当前成员进行角色分配，最后，定义各类角色的奖惩机制，即各个成员根据角色定义执行任务获得的奖励，如果执行失败或者执行过程中出现作恶的情形，如何进行惩罚；上述角色列表，角色分配策略，奖惩机制均可通过参数配置进行定义。

“共识管理”负责每一轮节点之间如何就一个或多个提议达成共识，即共识算法。该共识算法一定是和“角色管理”强相关的，即“角色管理”中角色的定义来自于“共识管理”所提供的共识算法；“共识管理”中定义的共识算法规定了不同角色之间交互的行为，即通信协议。

通过上述三个部分，决议在一轮中达成明确的结果(通过或者不通过)。一旦达成，该框架再次运行成员管理，开始新的一轮共识过程。由于该框架的三个部分均支持参数配置定义策略，通过不同的参数配置，实现不同的共识协议，显然，该协议框架具有可插拔的特性。

基于上述共识协议框架，本发明提出一种共识协议FBFT(Fast Byzantine FaultTolerance)，下面详细进行描述。

首先，FBFT的“成员管理”定义为：委托投票，即节点间通过委托的方式投票竞选进入成员列表，成员列表在每一轮共识协议执行过程均更新一次，以当时的投票情况为准，并且按序排列；“角色管理”首先定义两类角色，即锻造者和见证者，锻造者顾名思义搜集交易和锻造区块，见证者对区块进行验证和签名，见证区块的产生。角色分配规则根据块高与成员个数的关系确定锻造者，每一轮仅存在一名锻造者，其余节点为见证者。“共识管理”定义了共识算法，即一种简化的拜占庭协议，即由锻造者发起提议，该提议附带锻造者的签名，随后锻造者将提议广播给所有见证者；见证者收到提议后，将提议保存本地的临时队列中，并独立对提议进行验证，验证通过后添加自己的签名，将签名和提议的摘要返回给锻造者；如果未通过验证，则不给锻造者返回任何消息，仅保存提议；当锻造者收不少于三分之二的回复后，锻造者将搜集所有回复的签名，然后附带提议的摘要，哈希和签名集合给所有见证者，见证者收到消息后确认签名个数不少于成员个数的三分之二，则将该提议所包含的块加签名集合写入数据库；至此，一轮共识协议结束，系统紧接着进入下一轮，如此进行下去；当然，为了避免锻造者造假或意外离线以及见证者超时未回复，见证者和锻造者都会启用定时器。

具体实现过程如图3所示，图3详细描述了FBFT共识协议的实现方法流程图，协议的入口是成员管理，从成员管理获取节点成员列表，随后根据角色管理管理定义的角色类型和角色分配策略将节点分为锻造者和验证者，最后根据本专利所提出的简化的拜占庭算法，节点成员之间进行协议交互，对提议内容进行确认，确认后进入下一轮。其中，增加了超时同步机制，超时机制是为了防止锻造者和验证者网络拥塞，同步机制是为了使各节点之间的状态快速达成一致。

下面针对上述流程首先采用伪代码进行描述：

首先，START从成员管理模块获取成员列表，随后角色管理模块为成员分配角色，角色定义为producer和witness；如果角色为producer，则搜集交易，锻造区块，验证后添加自己签名信息，然后封装成proposal消息广播给其他节点，同时启动一个定时器timeoutResponse，等待witness返回的response消息；如果验证失败，则重新进行搜集交易，打包区块的操作，如表2所示；producer 在超时时间timeoutResponse内等待witness返回的response消息，如果超时前收到不少于三分之二成员的response回复，停止定时器timeoutResponse，同时将搜集到的response消息中来自各witness的签名集合取出，组装成commit消息，发送给其他节点，并写下该区块，再次进入Producer，进行新一轮的区块锻造。

表2：producer伪代码

对于witness，如表3所示，首先需要启动一个定时器timeoutProposal，用来等待producer的proposal消息。若timeoutProposal超时，封装 changeViewReq消息，广播给其他witness，跳转到CHANGE_VIEW。若收到来自producer的proposal消息后，取消定时器timeoutProposal，然后对独立的proposal消息进行验证，验证通过后对proposal进行签名，并将签名信息与 proposal的摘要打包成commit消息，发送给producer，同时启动定时器 timeoutCommit，等待producer的commit消息；若timeoutCommit超时，封装changeViewReq消息，广播给其他witness，跳转到CHANGE_VIEW。如果proposal验证失败，则不做任何操作；同时，当witness收到producer的commit 消息后，将commit中的签名信息取出，赋值给block，重新对block进行验证，如果验证通过，则跳转到WITNESS，继续启动定时器，等待producer的消息；验证失败，无操作。

表3：witness伪代码

CHANGE_VIEW的流程的设计是为了防止producer意外离线或作恶，同时也避免超过三分之一的witness节点掉线；该流程等待changeViewReq请求，当收到超过三分之二的changeViewReq请求，则跳转到START，重新获取成员和进行角色分配。

采用本实施例，通过成员管理，角色管理和共识管理，决议在一轮中达成明确的结果(通过或者不通过)，一旦达成，该框架再次运行成员管理，开始新的一轮共识过程，通过定义不同的规则集合将现有和未来的共识协议进行统一，通过参数的定义决定使用具体的共识协议的实现，以实现一种可插拔的统一的共识协议框架，该框架的三个部分均支持参数配置定义策略，通过不同的参数配置，实现不同的共识协议。

虽然本发明已经参考特定的说明性实施例进行了描述，但是不会受到这些实施例的限定而仅仅受到附加权利要求的限定。本领域技术人员应当理解可以在不偏离本发明的保护范围和精神的情况下对本发明的实施例能够进行改动和修改。