CN108769163A - 联盟链共识达成方法、设备及计算机可读存储介质 - Google Patents

Abstract

本发明公开了一种联盟链共识达成方法，该方法包括：侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件；在当前共识轮次满足预设的联盟链共识算法所对应的共识达成条件时，获取所述当前共识轮次的已共识信息；获取已有的联盟链参与机构信息，根据所述当前共识轮次的已共识信息和已有的联盟链参与机构信息，调用预设的共识增强合约，以判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件；若是，则判定所述当前共识轮次的共识达成。本发明还公开了一种联盟链共识达成设备和一种计算机可读存储介质。本发明能够实现对基于联盟链场景下的多机构共识方案进行增强，从而满足某些业务场景的共识要求。

Description

联盟链共识达成方法、设备及计算机可读存储介质

技术领域

本发明涉及区块链技术领域，尤其涉及联盟链共识达成方法、设备及计算机可读存储介质。

背景技术

联盟链是一种应用于机构间的区块链，其各个节点通常有与之对应的实体机构组织，如银行、保险、证券、商业协会等，各机构组织组成利益相关的联盟，共同维护区块链的健康运转。

现有技术中，联盟链大多沿用区块链中较为常见的共识算法，如PBFT(PracticalByzantine Fault Tolerance，拜占庭容错)算法和RAFT算法(一种分布式一致性算法)，以达成联盟链中各个节点之间的共识。

然而，在现有的区块链共识算法模型中，无论是PBFT或是RAFT的算法模型，都是假定参与共识的节点功能是对等的，即节点是不会具有特殊的业务性质，这种假定前提导致在联盟链中的共识并不能满足一些业务场景的实际需求。例如：在一个10(3f+1＝10，f代表PBFT模型中的恶意节点个数)个节点组件的联盟链场景中，使用PBFT共识算法进行共识，这10个节点分别由A，B，C三个机构持有，A机构有4个节点，B机构有3个节点，C机构有3个节点；根据PBFT的性质，达成共识只需要7个节点就足够了(2f+1＝7)，因为PBFT对于所有节点都是平等的，所以只需要10个节点中的任意7个达成共识即可，如果一次投票中的7个节点全部都是A机构和B机构的节点，那么就相当于C机构没有参加共识但是共识还是通过了，这种情况无法满足某些业务层面上的共识要求。

发明内容

本发明的主要目的在于提出一种联盟链共识达成方法、设备及计算机可读存储介质，旨在实现对基于联盟链场景下的多机构共识方案进行增强，从而满足某些业务场景的共识要求。

为实现上述目的，本发明提供一种联盟链共识达成方法，所述联盟链共识达成方法包括如下步骤：

侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件；

在当前共识轮次满足预设的联盟链共识算法所对应的共识达成条件时，获取所述当前共识轮次的已共识信息；

获取已有的联盟链参与机构信息，根据所述当前共识轮次的已共识信息和已有的联盟链参与机构信息，调用预设的共识增强合约，以判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件；

若是，则判定所述当前共识轮次的共识达成。

优选地，所述侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件的步骤包括：

当预设的联盟链共识算法为拜占庭容错PBFT共识算法时，判断当前共识轮次中，所述PBFT共识算法是否处于commit阶段；

若是，则判定当前共识轮次满足所述PBFT共识算法所对应的共识达成条件。

优选地，所述侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件的步骤包括：

当预设的联盟链共识算法为非拜占庭容错RAFT共识算法时，判断当前共识轮次中，所述RAFT共识算法的Leader是否处于心跳收集阶段且至少收集到RAFT集群中超过半数的心跳；

若是，则判定当前共识轮次满足所述RAFT共识算法所对应的共识达成条件。

优选地，所述侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件的步骤之前，还包括：

创建用于达成多机构共识的共识增强合约；

接收设置指令，根据所述设置指令在所述共识增强合约中设置相应的共识增强条件。

优选地，所述获取所述当前共识轮次的已共识信息的步骤包括：

获取当前共识轮次中，由联盟链各节点发送的共识包；

识别发送所述共识包的节点所属的机构，以生成已参与共识的机构列表并进行缓存；

将所述已参与共识的机构列表作为所述当前共识轮次的已共识信息。

优选地，所述判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件的步骤包括：

判断所述已参与共识的机构列表中是否存在预设的联盟链参与机构；

若是，则判定所述已共识信息满足所述共识增强合约所规定的共识增强条件。

优选地，所述将所述已参与共识的机构列表作为所述当前共识轮次的已共识信息的步骤之前，还包括：

统计所述已参与共识的机构列表中各机构发送共识包的节点数量并进行缓存；

所述将所述已参与共识的机构列表作为所述当前共识轮次的已共识信息的步骤包括：

将所述已参与共识的机构列表和统计的所述节点数量作为所述当前共识轮次的已共识信息。

优选地，所述判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件的步骤包括：

判断所述已参与共识的机构列表中是否存在预设的联盟链参与机构；

若所述已参与共识的机构列表中存在预设的联盟链参与机构，则判断所述预设的联盟链参与机构中，发送共识包的节点数量是否达到预设值；

若所述预设的联盟链参与机构中，发送共识包的节点数量达到预设值，则判定所述已共识信息满足所述共识增强合约所规定的共识增强条件。

此外，为实现上述目的，本发明还提供一种联盟链共识达成设备，所述联盟链共识达成设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的联盟链共识达成程序，所述联盟链共识达成程序被所述处理器执行时实现如上所述的联盟链共识达成方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有联盟链共识达成程序，所述联盟链共识达成程序被处理器执行时实现如上所述的联盟链共识达成方法的步骤。

本发明提供的联盟链共识达成方法，通过在共识流程中调用预设的共识增强合约，能够实现在现有的联盟链共识算法上增加新的规则判断，使得整个联盟链的共识流程不仅仅需要满足现有的联盟链共识算法，还需要满足共识增强合约中指定的规则才能达成机构间的最终共识，从而本发明能够满足一些特定场景下的机构间的共识达成需求。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的终端结构示意图；

图2为本发明联盟链共识达成方法第一实施例的流程示意图；

图3为图2中步骤S10的细化步骤示意图；

图4为图2中步骤S10的另一细化步骤示意图；

图5为本发明联盟链共识达成方法第二实施例的流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例的主要解决方案是：侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件；在当前共识轮次满足预设的联盟链共识算法所对应的共识达成条件时，获取所述当前共识轮次的已共识信息；获取已有的联盟链参与机构信息，根据所述当前共识轮次的已共识信息和已有的联盟链参与机构信息，调用预设的共识增强合约，以判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件；若是，则判定所述当前共识轮次的共识达成。

现有技术中，联盟链大多沿用区块链中较为常见的共识算法，如PBFT算法和RAFT算法，以达成联盟链中各个节点之间的共识，然而，这些共识算法并不能满足联盟链中一些业务场景的实际需求。

本发明提供的联盟链共识达成方法，通过在共识流程中调用预设的共识增强合约，能够实现在现有的联盟链共识算法上增加新的规则判断，使得整个联盟链的共识流程不仅仅需要满足现有的联盟链共识算法，还需要满足共识增强合约中指定的规则才能达成机构间的最终共识，从而本发明能够满足一些特定场景下的机构间的共识达成需求。

如图1所示，图1是本发明实施例方案涉及的硬件运行环境的设备结构示意图。

本发明实施例联盟链共识达成设备可以是服务器、PC机或虚拟机设备。

如图1所示，该设备可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的设备结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及联盟链共识达成程序。

在图1所示的终端中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端(用户端)，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的联盟链共识达成程序，并执行以下操作：

侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件；

在当前共识轮次满足预设的联盟链共识算法所对应的共识达成条件时，获取所述当前共识轮次的已共识信息；

获取已有的联盟链参与机构信息，根据所述当前共识轮次的已共识信息和已有的联盟链参与机构信息，调用预设的共识增强合约，以判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件；

若是，则判定所述当前共识轮次的共识达成。

进一步地，处理器1001可以调用存储器1005中存储的联盟链共识达成程序，还执行以下操作：

当预设的联盟链共识算法为拜占庭容错PBFT共识算法时，判断当前共识轮次中，所述PBFT共识算法是否处于commit阶段；

若是，则判定当前共识轮次满足所述PBFT共识算法所对应的共识达成条件。

进一步地，处理器1001可以调用存储器1005中存储的联盟链共识达成程序，还执行以下操作：

当预设的联盟链共识算法为非拜占庭容错RAFT共识算法时，判断当前共识轮次中，所述RAFT共识算法的Leader是否处于心跳收集阶段且至少收集到RAFT集群中超过半数的心跳；

若是，则判定当前共识轮次满足所述RAFT共识算法所对应的共识达成条件。

进一步地，处理器1001可以调用存储器1005中存储的联盟链共识达成程序，还执行以下操作：

创建用于达成多机构共识的共识增强合约；

接收设置指令，根据所述设置指令在所述共识增强合约中设置相应的共识增强条件。

进一步地，处理器1001可以调用存储器1005中存储的联盟链共识达成程序，还执行以下操作：

获取当前共识轮次中，由联盟链各节点发送的共识包；

识别发送所述共识包的节点所属的机构，以生成已参与共识的机构列表并进行缓存；

将所述已参与共识的机构列表作为所述当前共识轮次的已共识信息。

进一步地，处理器1001可以调用存储器1005中存储的联盟链共识达成程序，还执行以下操作：

判断所述已参与共识的机构列表中是否存在预设的联盟链参与机构；

若是，则判定所述已共识信息满足所述共识增强合约所规定的共识增强条件。

进一步地，处理器1001可以调用存储器1005中存储的联盟链共识达成程序，还执行以下操作：

统计所述已参与共识的机构列表中各机构发送共识包的节点数量并进行缓存；

将所述已参与共识的机构列表和统计的所述节点数量作为所述当前共识轮次的已共识信息。

进一步地，处理器1001可以调用存储器1005中存储的联盟链共识达成程序，还执行以下操作：

判断所述已参与共识的机构列表中是否存在预设的联盟链参与机构；

若所述已参与共识的机构列表中存在预设的联盟链参与机构，则判断所述预设的联盟链参与机构中，发送共识包的节点数量是否达到预设值；

若所述预设的联盟链参与机构中，发送共识包的节点数量达到预设值，则判定所述已共识信息满足所述共识增强合约所规定的共识增强条件。

基于上述硬件结构，提出本发明联盟链共识达成方法实施例。

参照图2，图2为本发明联盟链共识达成方法第一实施例的流程示意图，所述方法包括：

步骤S10，侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件；

目前区块链根据其组成节点的准入形式的不同，一般分为公有链、联盟链和私有链，本实施例应用于联盟链的应用场景。

在联盟链的语境下，机构指代的是逻辑意义上参与组网区块链的成员，每个机构会提供自己的节点来参与物理意义上的组网，也就是说区块链组网中的多个节点可能归属于同一个机构。从数据角度理解，联盟链是各机构之间都有的数据，他们的数据需要通过共识达到一致。区块链对等网络中的各个节点通过一种算法对一批交易进行确认，并确保所有节点对这批数据具有一致的确认结果，这种算法就是区块链的共识算法。目前区块链中的共识算法根据参与共识的节点是否有作恶的成员可分为拜占庭容错和非拜占庭容错两类，在联盟链中常用的共识算法包括拜占庭容错PBFT算法，以及非拜占庭容错算法RAFT、PAXOS等，其中具体的算法流程可参照现有技术，此处不作赘述。

在本实施例中，需预先部署共识增强合约，该共识增强合约可以理解为对现有共识算法的增强，即在现有的联盟链共识算法达成的前提下，还需满足共识增强合约中设定的共识条件，才能达成联盟链各机构之间的共识。

多机构共识增强功能可以由一个单例组件控制。该单例伴随整个程序的生命周期一直存在，这个单例维护着记录了节点与机构关系的缓存，及当前共识轮次中已经收到的节点信息的缓存，且该单例能够去调用预设的共识增强合约。

具体实施时，首先侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件，其中，当前共识轮次即联盟链当前的共识流程，预设的联盟链算法可以为现有技术中的联盟链共识算法，下面以PBFT算法和RAFT算法为例进行说明。

作为一种实施方式，参照图3，图3为图2中步骤S10的细化步骤示意图，上述步骤S10可以进一步包括：

步骤S11，当预设的联盟链共识算法为拜占庭容错PBFT共识算法时，判断当前共识轮次中，所述PBFT共识算法是否处于commit阶段；

若是，则执行步骤S12，判定当前共识轮次满足所述PBFT共识算法所对应的共识达成条件。

当预设的联盟链共识算法为拜占庭容错PBFT共识算法时，根据现有技术中的PBFT共识原理，一致性的确保主要分为预准备(pre-prepare)、准备(prepare)和确认(commit)三个阶段，当PBFT共识算法处于commit阶段时，认为PBFT共识达成。因此，在当前共识轮次的PBFT共识算法处于commit阶段时，即可判定当前共识轮次满足该PBFT共识算法所对应的共识达成条件。

作为另一种实施方式，参照图4，图4为图2中步骤S10的另一细化步骤示意图，上述步骤S10可以进一步包括：

步骤S13，当预设的联盟链共识算法为非拜占庭容错RAFT共识算法时，判断当前共识轮次中，所述RAFT共识算法的Leader是否处于心跳收集阶段且至少收集到RAFT集群中超过半数的心跳；

若是，则执行步骤S14，判定当前共识轮次满足所述RAFT共识算法所对应的共识达成条件。

当预设的联盟链共识算法为非拜占庭容错RAFT共识算法时，根据现有技术中的RAFT共识原理，此时的共识判断节点为RAFT集群中的Leader(领导者)，Leader向集群中的Follower(候选者)发送指令且收集Follower返回的心跳响应。在当前共识轮次的RAFT共识算法的Leader处于心跳收集阶段且至少收集到RAFT集群中超过半数的心跳时，即可判定当前共识轮次满足该RAFT共识算法所对应的共识达成条件。

在当前共识轮次满足预设的联盟链共识算法所对应的共识达成条件时，执行步骤S20，获取所述当前共识轮次的已共识信息；

在当前共识轮次满足预设的联盟链共识算法所对应的共识达成条件时，获取当前共识轮次的已共识信息。具体实施时，可获取当前共识轮次中，由联盟链各节点发送的共识包，然后识别发送共识包的节点所属的机构，以生成已参与共识的机构列表和统计的节点数量并进行缓存，作为当前共识轮次的已共识信息，比如，联盟链参与机构为A机构、B机构和C机构，其中A机构有2个节点，B机构有1个节点，C机构有1个节点，则当前接收到A机构的2个节点，以及B机构的1个节点发送的共识包时，对应的已共识信息可以表示为：已共识机构info＝['A','B']，对应的已共识节点数量num＝[2,1]。

步骤S30，获取已有的联盟链参与机构信息，根据所述当前共识轮次的已共识信息和已有的联盟链参与机构信息，调用预设的共识增强合约，以判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件；

若所述已共识信息满足所述共识增强合约所规定的共识增强条件，则执行步骤S40，判定所述当前共识轮次的共识达成。

其中，联盟链参与机构信息包括联盟链的参与机构和归属于各机构的节点数量，且联盟链参与机构信息根据业务共识场景的不同而不同。比如，在某一业务共识场景中，联盟链参与机构为A机构、B机构和C机构，其中A机构有2个节点，B机构有1个节点，C机构有1个节点，则联盟链参与机构信息可以表示为：机构列表agencyList＝['A','B','C']，对应的机构节点数量agencyCountMap＝{'A':2,'B':1,'C':1}。

在获取到当前共识轮次的已共识信息和已有的联盟链参与机构信息后，进一步调用预设的共识增强合约，以判断该已共识信息是否满足共识增强合约所规定的共识增强条件。

以上述已共识信息info＝['A','B']，num＝[2,1]为例，若共识增强条件为共识必须A机构参与，由于当前共识信息中显示接收到了归属于A机构的节点发送的共识包，因此判定当前共识轮次的共识达成；若共识增强条件为共识必须C机构参与，由于当前共识信息中显示并未接收到归属于C机构的节点发送的共识包，因此判定当前共识轮次的共识未能达成。

不难理解，通过设置不同的共识增强条件，可以实现如下一些特定业务场景的共识控制：

1、每家机构必须具备平等的投票权，投票权和投入节点数量无关。比如商户间构建积分通用联盟链的场景，要求多数商户都参与(达成共识)才能成立。

2、共识必须由联盟链中的所有机构参与，谁都不能缺席。比如存证场景，必须提供证据的，第三方鉴证、仲裁机构都要参加。

3、共识过程有些机构必须参加，有些机构可选参加。比如某个场景，司法机构的签名必须存在，否则共识不能达成。

4、和1不同，机构之间并非完全平等，每个机构具备不同的投票权重，但是不采用节点数表示，而是由签名的加权值表示，比如机构A虽然只投出一票，但是权重为3，机构B一票的权重为2，机构C的权重为1。例如银行机构间的共识，通过银行占资比例的多少作为投票权重。

需要说明的是，在区块落盘后(即预设的联盟链共识算法的共识达成后)，区块中会记录共识算法流程中的参与节点的签名。因为节点可以伪造一个区块绕过共识流程发起攻击(不经过共识流程就落盘)，所以当从其他节点同步过来一个区块时，为防止攻击节点伪造区块发起攻击，需要校验该区块中的节点签名是否满足共识增强条件。即在区块同步时，既需要校验其签名是否满足预设的联盟链共识算法要求，还需要调用共识增强合约来校验待同步区块是否满足共识增强合约所规定的共识增强条件，如此能够保证同步过来的区块是合法的，从而提高了联盟链的安全性。

本实施例提供的联盟链共识达成方法，通过在共识流程中调用预设的共识增强合约，能够实现在现有的联盟链共识算法上增加新的规则判断，使得整个联盟链的共识流程不仅仅需要满足现有的联盟链共识算法，还需要满足共识增强合约中指定的规则才能达成机构间的最终共识，从而本实施例能够满足一些特定场景下的机构间的共识达成需求。

进一步地，参照图5，图5为本发明联盟链共识达成方法第二实施例的流程示意图。基于上述图2所示的实施例，在步骤S10之前，还可以包括：

步骤S50，创建用于达成多机构共识的共识增强合约；

步骤S60，接收设置指令，根据所述设置指令在所述共识增强合约中设置相应的共识增强条件。

在本实施例中，在共识增强合约中设置相应的共识增强条件可以通过共识增强合约提供的接口实现，通过接口的设置可以实现对共识增强条件进行灵活地设置、添加和修改，从而实现对规则的灵活控制。其中设置的共识增强条件包括但不限于：参与共识的机构必须包括一个或多个特定的机构、一个或多个特定的机构参与投票的节点必须达到预设数量、一个或多个特定的机构占总投票数量的百分比不得低于预定值，等等。

在一实施方式中，用户可填写的共识增强合约的接口设计如下：

以4个节点构成联盟链举例，其中A机构2个节点，B机构1个节点，C机构1个节点。

在这个模板中：

父类ConsensusControlAction会提供两个成员变量bytes32[]publicagencyList和mapping(bytes32＝>uint)public agencyCountMap，分别代表当前系统中应该具备的机构列表agencyList和这些机构应该有的数量，用于表示已有的联盟链参与机构信息。比如在一业务共识场景中，联盟链参与机构为A机构、B机构和C机构，其中A机构有2个节点，B机构有1个节点，C机构有1个节点，则agencyList＝['A','B','C']，agencyCountMap＝{'A':2,'B':1,'C':1}；

control函数代表规则，用户通过编写这个规则来根据输入参数判定true或false来决定是否满足自己的业务共识规则，参数bytes32[]info代表已经收到的机构的列表，uint[]num代表已经收到的共识包中这些机构分别的个数(与info是对应关系)。比如当前触发这次判定的时候，收到了3个共识包，其中2个是A机构的，1个是B机构的，那么info＝['A','B']，num＝[2,1]；

init代表刚部署该合约时触发的回调；

beforeAdd代表注册新节点时，可以通过这个函数处理是否可以让这个节点加入，比如需要限制每个机构的最大节点数量；

beforeDel代表节点退出时，可以通过这个函数处理是否可以让这个节点退出，比如规则为某个机构必须在时才能通过，那么这个函数可以限制这个机构至少要有一个节点在区块链中才行，否则这条链就无法共识了。

修改规则即重新编写control、init、beforeAdd、beforeDel这几个函数，并重新部署。

通过上述接口设计，用户可以对共识增强合约中的共识增强条件进行灵活地添加、删除和修改。

进一步地，基于上述的实施例，提出本发明联盟链共识达成方法第三实施例。

在本实施例中，步骤S20可以包括：获取当前共识轮次中，由联盟链各节点发送的共识包；识别发送所述共识包的节点所属的机构，以生成已参与共识的机构列表并进行缓存；将所述已参与共识的机构列表作为所述当前共识轮次的已共识信息。

具体实施时，获取当前共识轮次中由联盟链各节点发送的共识包，由于共识包中包括其发送节点的签名，因此可以通过解析签名来识别发送共识包的节点所属的机构。比如当解析某一共识包，得到该共识包是由联盟链参与机构信息中的A机构发送的，即将A机构加入至已参与共识的机构列表中，如此解析所有的共识包后，将该已参与共识的机构列表作为当前共识轮次的已共识信息，比如当接收到的共识包均来自于A机构和B机构的节点时，对应的已共识信息可表示为：info＝['A','B']。

对应地，所述判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件的步骤可以包括：判断所述已参与共识的机构列表中是否存在预设的联盟链参与机构；若是，则判定所述已共识信息满足所述共识增强合约所规定的共识增强条件。

其中，预设的联盟链参与机构可以为一个或多个，具体可根据实际业务需求灵活设置，比如某一业务场景要求C机构必须参与共识，则可以将C机构设置为必须的共识机构。如果上述已参与共识的机构列表中存在预设的联盟链参与机构，即判定已共识信息满足共识增强合约所规定的共识增强条件。

进一步地，在将所述已参与共识的机构列表作为所述当前共识轮次的已共识信息的步骤之前，还可以包括步骤：统计所述已参与共识的机构列表中各机构发送共识包的节点数量并进行缓存；此时可以将所述已参与共识的机构列表和统计的所述节点数量作为所述当前共识轮次的已共识信息。

比如当解析某一共识包，得到该共识包是由联盟链参与机构信息中的A机构发送的，即将A机构加入至已参与共识的机构列表中，如此解析所有的共识包后，统计已参与共识的机构列表中各机构发送共识包的节点数量并进行缓存，然后将该已参与共识的机构列表和统计的所述节点数量作为当前共识轮次的已共识信息，比如当前收到了3个共识包，其中2个是A机构的，1个是B机构的，则对应的已共识信息可表示为：info＝['A','B']，num＝[2,1]。

对应地，所述判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件的步骤可以包括：判断所述已参与共识的机构列表中是否存在预设的联盟链参与机构；若所述已参与共识的机构列表中存在预设的联盟链参与机构，则判断所述预设的联盟链参与机构中，发送共识包的节点数量是否达到预设值；若所述预设的联盟链参与机构中，发送共识包的节点数量达到预设值，则判定所述已共识信息满足所述共识增强合约所规定的共识增强条件。

其中，预设的联盟链参与机构及其发送共识包的节点数量可以根据实际业务需求灵活设置，比如某一业务场景要求C机构必须参与共识，且C机构中必须至少有2个节点参与投票，则可以将C机构设置为必须的共识机构，且C机构发送共识包的节点数量必须大于或等于2。如果上述已参与共识的机构列表中存在预设的联盟链参与机构，且预设的联盟链参与机构中，发送共识包的节点数量达到预设值，即判定已共识信息满足共识增强合约所规定的共识增强条件。

通过上述方式，实现了对现有的联盟链共识算法的增强，满足了一些特定场景下的机构间的共识达成需求。

本发明还提供一种联盟链共识达成设备。

本发明联盟链共识达成设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的联盟链共识达成程序，所述联盟链共识达成程序被所述处理器执行时实现如上所述的联盟链共识达成方法的步骤。

其中，在所述处理器上运行的联盟链共识达成程序被执行时所实现的方法可参照本发明联盟链共识达成方法各个实施例，此处不再赘述。

本发明还提供一种计算机可读存储介质。

本发明计算机可读存储介质上存储有联盟链共识达成程序，所述联盟链共识达成程序被处理器执行时实现如上所述的联盟链共识达成方法的步骤。

其中，在所述处理器上运行的联盟链共识达成程序被执行时所实现的方法可参照本发明联盟链共识达成方法各个实施例，此处不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种联盟链共识达成方法，其特征在于，所述联盟链共识达成方法包括如下步骤：

侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件；

在当前共识轮次满足预设的联盟链共识算法所对应的共识达成条件时，获取所述当前共识轮次的已共识信息；

获取已有的联盟链参与机构信息，根据所述当前共识轮次的已共识信息和已有的联盟链参与机构信息，调用预设的共识增强合约，以判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件；

若是，则判定所述当前共识轮次的共识达成。

2.如权利要求1所述的联盟链共识达成方法，其特征在于，所述侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件的步骤包括：

当预设的联盟链共识算法为拜占庭容错PBFT共识算法时，判断当前共识轮次中，所述PBFT共识算法是否处于commit阶段；

若是，则判定当前共识轮次满足所述PBFT共识算法所对应的共识达成条件。

3.如权利要求1所述的联盟链共识达成方法，其特征在于，所述侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件的步骤包括：

当预设的联盟链共识算法为非拜占庭容错RAFT共识算法时，判断当前共识轮次中，所述RAFT共识算法的Leader是否处于心跳收集阶段且至少收集到RAFT集群中超过半数的心跳；

若是，则判定当前共识轮次满足所述RAFT共识算法所对应的共识达成条件。

4.如权利要求1所述的联盟链共识达成方法，其特征在于，所述侦测当前共识轮次是否满足预设的联盟链共识算法所对应的共识达成条件的步骤之前，还包括：

创建用于达成多机构共识的共识增强合约；

接收设置指令，根据所述设置指令在所述共识增强合约中设置相应的共识增强条件。

5.如权利要求1至4中任一项所述的联盟链共识达成方法，其特征在于，所述获取所述当前共识轮次的已共识信息的步骤包括：

获取当前共识轮次中，由联盟链各节点发送的共识包；

识别发送所述共识包的节点所属的机构，以生成已参与共识的机构列表并进行缓存；

将所述已参与共识的机构列表作为所述当前共识轮次的已共识信息。

6.如权利要求5所述的联盟链共识达成方法，其特征在于，所述判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件的步骤包括：

判断所述已参与共识的机构列表中是否存在预设的联盟链参与机构；

若是，则判定所述已共识信息满足所述共识增强合约所规定的共识增强条件。

7.如权利要求5所述的方法，其特征在于，所述将所述已参与共识的机构列表作为所述当前共识轮次的已共识信息的步骤之前，还包括：

统计所述已参与共识的机构列表中各机构发送共识包的节点数量并进行缓存；

所述将所述已参与共识的机构列表作为所述当前共识轮次的已共识信息的步骤包括：

将所述已参与共识的机构列表和统计的所述节点数量作为所述当前共识轮次的已共识信息。

8.如权利要求7所述的方法，其特征在于，所述判断所述已共识信息是否满足所述共识增强合约所规定的共识增强条件的步骤包括：

判断所述已参与共识的机构列表中是否存在预设的联盟链参与机构；

若所述已参与共识的机构列表中存在预设的联盟链参与机构，则判断所述预设的联盟链参与机构中，发送共识包的节点数量是否达到预设值；

若所述预设的联盟链参与机构中，发送共识包的节点数量达到预设值，则判定所述已共识信息满足所述共识增强合约所规定的共识增强条件。

9.一种联盟链共识达成设备，其特征在于，所述联盟链共识达成设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的联盟链共识达成程序，所述联盟链共识达成程序被所述处理器执行时实现如权利要求1至8中任一项所述的联盟链共识达成方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有联盟链共识达成程序，所述联盟链共识达成程序被处理器执行时实现如权利要求1至8中任一项所述的联盟链共识达成方法的步骤。