CN114048517A - 区块链的双通道共识系统和方法、计算机可读存储介质 - Google Patents

Abstract

一种区块链的双通道共识系统和方法、计算机可读存储介质，通过信用评价划分、选取、调整参与共识组的节点集合，客户端可以通过组播或者广播的方式向共识组节点分通道发送共识请求和待处理的区块数据。共识主节点接收到该共识请求消息以后，在共识副节点中发起共识，向共识副节点发送仲裁请求消息，共识副节点可以根据命名寻址在网络中请求待共识区块数据，就近、灵活获取待验证的共识所需的区块数据；共识副节点根据仲裁请求消息，对待共识区块数据进行仲裁投票，依次完成后续共识流程。选取高可靠节点提高安全性；基于双通道松耦合共识转换与数据分发流程，提高系统的并行度；基于命名寻址降低冗余压力。基于VRF与门限签名投票提升共识活性。

Description

区块链的双通道共识系统和方法、计算机可读存储介质

技术领域

本申请涉及区块链技术领域，具体涉及区块链的双通道共识系统和方法、计算机可读存储介质。

背景技术

分布式系统的共识协议，大致可分为两类，一类是基于数据状态：例如比特币为代表的区块链算法(或者称为中本聪共识)，另一类基于投票：例如经典的 BFT 算法及后续的演进算法PBFF等。分布式共识协议是区块链系统的一个重要组成部分。

在分布式账本系统中，每个节点需要让自身存储的账本跟其他节点存储的账本保持一致，这个过程就是通过共识算法实现的。区块链中目前常见的共识过程有工作量证明机制共识过程、拜占庭容错（Byzantine Fault Tolerance，简称BFT）共识过程、实用拜占庭（Practical Byzantine Fault Tolerance，简称PBFT）共识过程，其除了能够容忍宕机、网络延迟/断开等良性错误，还能够容忍任意类型的恶意攻击。

一个完整BFT共识过程包括多个视图（view），视图也可以称为共识单元，参与共识的各个副本节点轮值“主节点”，每个主节点完成一个共识单元，共识单元之间切换流程复杂。每个视图通常包括多个阶段，例如：每个共识单元可以包括3阶段，分别为预提交（pre-commit）、提交（commit）、决策（decsion）。每次共识单元收集大于预设数量的投票即可。由于BFT共识过程复杂，使得区块数据较大的情况下，通信压力大，共识很难进行下去。

以HotStuff为代表的新一类共识算法，原理上结合了“基于数据状态”与“投票”机制的两类共识协议的特点，既基于树/链式数据结构维护账本/上链数据状态(历史（时间戳在前的）的数据块是已经被共识算法验证并确认正确的数据、不可篡改的分布式可信记账技术方法)，同时也改进了BFT投票类共识算法的上链验证流程。每个共识单元过程采用主节点（Leader）集中处理的方式，收集门限签名，从而达成共识，每个共识单元相对BFT共识过程在保证正确性和安全性的前提下，缩减了共识轮次（基本接近O(n)线性处理复杂度）。

然而，在大规模组网情况下，主节点及副节点依次投票的单元过程中的拟上链数据通信、处理、延时压力较大，区块数据较大的情况下，通信也面临较大压力，共识性能仍然面临带宽、延时、节点离线、连通性不稳定等技术挑战。

发明内容

本申请主要解决的技术问题是区块数据较大的情况下，通信也面临较大压力，共识效率不高共识过程效率不高的问题。

根据第一方面，一种实施例中提供一种区块链的双通道共识系统，包括：多个节点；每个节点属于一种节点类型，所述节点类型包括：主控类型、协调类型、边缘类型；所述主控类型的节点为所述区块链的双通道共识系统初始确定的；所述协调类型的节点和所述边缘类型的节点基于信用度值确定；

所述主控类型的节点接收客户端广播的共识请求消息，所述共识请求消息携带待共识区块数据的名字；

所述主控类型的节点向协调类型的节点发送遴选通知；

所述主控类型的节点接收所述协调类型的节点发送的遴选通知响应，所述遴选通知响应中包含所述协调类型的节点的私钥签名；

所述主控类型的节点基于可验证随机函数对各协调类型的节点的私钥签名进行验证，得到验证结果；

所述主控类型的节点在验证结果为验证通过的情况下，基于各协调类型的节点的信用度值，确定共识节点和候选共识主节点；

所述主控类型的节点向所述共识节点分别发送入选通知，所述入选通知用于指示已被选为共识节点；

所述主控类型的节点通过共识过程完成对候选共识主节点的验证，在对所述候选共识主节点验证通过的情况下，确定候选共识主节点为共识主节点；

所述主控类型的节点向所述共识节点广播所述共识主节点；

所述共识主节点向共识副节点发送仲裁请求消息，所述仲裁请求消息携带待共识区块数据的名字；

所述共识副节点根据所述待共识区块数据的名字，通过命名寻址的通信方式，获取所述待共识区块数据；

所述共识副节点进行签名验证和仲裁投票，并进行门限签名，得到投票结果；

所述共识副节点向所述共识主节点发送所述投票结果；

所述共识主节点根据接收到的各投票结果，得到共识结果，所述共识结果包括：达成共识或者未达成共识。

根据第二方面，一种实施例中提供一种区块链的双通道共识方法，应用于区块链的双通道共识系统，所述区块链的双通道共识系统包括：共识主节点和共识副节点；所述方法包括：

所述共识副节点接收所述共识主节点发送的仲裁请求消息，所述仲裁请求消息携带待共识区块数据的名字；

所述共识副节点根据所述待共识区块数据的名字，通过命名寻址的通信方式，获取所述待共识区块数据；

所述共识副节点进行签名验证和仲裁投票，并进行门限签名，得到投票结果；

所述共识副节点向所述共识主节点发送所述投票结果，以使所述共识主节点根据接收到的各投票结果，得到共识结果，所述共识结果包括：达成共识或者未达成共识。

根据第三方面，一种实施例中提供一种区块链的双通道共识方法，应用于区块链的双通道共识系统，所述区块链的双通道共识系统包括：共识主节点和共识副节点；所述方法包括：

所述共识主节点接收客户端发送的共识请求消息，所述共识请求消息中包含待共识区块数据的名字；

所述共识主节点向所述共识副节点分别发送仲裁请求消息，所述仲裁请求消息携带待共识区块数据的名字，以使所述共识副节点根据所述待共识区块数据的名字，通过命名寻址的通信方式，获取所述待共识区块数据，并进行签名验证、仲裁投票和进行门限签名，得到投票结果；

所述共识主节点接收各共识副节点发送的所述投票结果；

所述共识主节点根据接收到的各投票结果，得到共识结果，所述共识结果包括：达成共识或者未达成共识。

根据第四方面，一种实施例中提供一种区块链的双通道共识方法，应用于区块链的双通道共识系统，所述区块链的双通道共识系统包括：多个节点；每个节点具有所属的节点类型，所述节点类型包括：主控类型、协调类型、边缘类型；所述主控类型的节点为所述区块链的双通道共识系统初始确定的；所述协调类型的节点和所述边缘类型的节点基于信用度值确定；所述方法包括：

所述主控类型的节点接收客户端发送的共识请求消息，所述共识请求消息中包含待共识区块数据的名字；

所述主控类型的节点基于可验证随机函数和所述多个节点分别对应的信用度值，确定共识节点，所述共识节点包括：共识主节点和共识副节点，所述共识节点所属的类型是协调类型或主控类型；其中，节点对应的信用度值根据以下至少一种所述节点的指标确定：计算能力、内存能力、带宽水平、在线稳定性、拜占庭信任度和交互评分信任度；

所述主控类型的节点向所述共识节点分别发送入选通知，所述入选通知用于指示已被选为共识节点；

所述主控类型的节点向所述共识节点广播所述共识主节点，以使所述共识副节点接收所述共识主节点发送的仲裁请求消息，并根据所述待共识区块数据的名字，通过命名寻址的通信方式，获取所述待共识区块数据，进行签名验证和仲裁投票，并进行门限签名，得到共识结果，所述共识结果包括：达成共识或者未达成共识。

根据第五方面，一种实施例中提供一种计算机可读存储介质，所述介质上存储有程序，所述程序能够被处理器执行以实现如上述第二方面-地四方面中任一项所述的方法。

依据上述实施例的区块链的双通道共识系统和方法、计算机可读存储介质， 客户端可以通过组播或者广播的方式向区块链的双通道共识系统中的节点发送共识请求消息。共识主节点接收到该共识请求消息以后，在共识副节点中发起共识，向共识副节点发送仲裁请求消息，共识副节点可以根据待共识区块数据的名字向其他共识节点请求待共识区块数据，距离该共识副节点相对近的且存储了该待共识区块数据的节点可以将待共识区块数据发送给该共识副节点，共识副节点根据仲裁请求消息，对待共识区块数据进行仲裁投票，将投票结果发送给共识主节点，共识主节点根据收到的投票结果，确定共识结果。基于待共识区块数据的名字可以就近获取到待共识区块数据，避免长距离数据传输造成的时延，提高系统的反应速度，同时减少了共识主节点的通信压力，且将共识过程分为数据通道和共识交互通道两个通道同步进行，数据分发过程不影响共识交互过程的进行，提高了共识效率，提高共识的活性，使得本申请实施例提供的方法应用范围更广。另外，由于恶意攻击并不知道共识副节点从何处获取待共识区块数据，因此，无法对待共识区块数据进行篡改，从而避免主节点被网络攻击等造成待共识区块数据被篡改的情况，增加数据获取的随机性，提高系统安全性。

在一些实施例中，通过信用评价划分、选取、调整参与共识组的节点集合，客户端可以通过组播或者广播的方式向共识组节点分通道发送共识请求和待处理的区块数据。共识主节点接收到该共识请求消息以后，在共识副节点中发起共识，向共识副节点发送仲裁请求消息，共识副节点可以根据命名寻址在网络中请求待共识区块数据，就近、灵活获取待验证的共识所需的区块数据；共识副节点根据仲裁请求消息，对待共识区块数据进行仲裁投票，依次完成后续共识流程。选取高可靠节点提高安全性；基于双通道松耦合共识转换与数据分发流程，提高系统的并行度；基于命名寻址降低冗余压力。基于VRF与门限签名投票提升共识活性。

附图说明

图1为本申请实施例提供的一种区块链的双通道共识方法的交互示意图；

图2为本申请实施例提供的一种共识、数据分发双通道工作流程示意图；

图3为本申请实施例提供的一种节点信用度分层管理示意图；

图4为本申请实施例提供的一种区块链的双通道共识方法的交互示意图；

图5为本申请实施例提供的一种区块链的节点信用度值的确定方法的交互示意图。

具体实施方式

下面通过具体实施方式结合附图对本申请作进一步详细说明。其中不同实施方式中类似元件采用了相关联的类似的元件标号。在以下的实施方式中，很多细节描述是为了使得本申请能被更好的理解。然而，本领域技术人员可以毫不费力的认识到，其中部分特征在不同情况下是可以省略的，或者可以由其他元件、材料、方法所替代。在某些情况下，本申请相关的一些操作并没有在说明书中显示或者描述，这是为了避免本申请的核心部分被过多的描述所淹没，而对于本领域技术人员而言，详细描述这些相关操作并不是必要的，他们根据说明书中的描述以及本领域的一般技术知识即可完整了解相关操作。

另外，说明书中所描述的特点、操作或者特征可以以任意适当的方式结合形成各种实施方式。同时，方法描述中的各步骤或者动作也可以按照本领域技术人员所能显而易见的方式进行顺序调换或调整。因此，说明书和附图中的各种顺序只是为了清楚描述某一个实施例，并不意味着是必须的顺序，除非另有说明其中某个顺序是必须遵循的。

本文中为部件所编序号本身，例如“第一”、“第二”等，仅用于区分所描述的对象，不具有任何顺序或技术含义。而本申请所说“连接”、“联接”，如无特别说明，均包括直接和间接连接（联接）。

下面介绍本申请中用到的术语定义。

部分同步模型（Partial Synchronous model）：是指界于同步模型与异步模型之间的一种通信模型。该模型中假设存在一个全局稳定时钟（Global Stabilization Time，简称GST），在GST之前整个系统可能处于异步状态，但是在GST之后，整个系统可以恢复到同步状态。部分同步模型的时序假设比较贴合现实世界中对共识算法的需求，即共识总是可以在同步状态下完成，然而一旦网络出现问题，共识可能会进入一段时间的阻塞，直至网络恢复正常。

一个共识算法能够正确运转的条件：即在一个传统的分布式系统中，一个实用的共识算法需要能够安全地运行在部分同步网络模型中。即需要具备安全性（Safety）和活性（Liveness）。

其中，安全性是指在故障发生时，共识不能产生错误的结果。

其中，活性是指系统一直能持续产生提交，在区块链的语义下，是指共识会持续进行，不会卡住。假如一个区块链系统的共识卡在了某个高度，那么新的交易是没有回应的，也就是不满足活性的要求。活性机制是共识持续推进的关键。

下面简单介绍PBFT共识方法。

为了排除不可靠因素，例如，参与共识的节点有可能是作恶节点，也可能是网络或者节点中断导致最终收不到共识消息，因此需要做视图切换，即副节点轮值当主节点，完成视图，可以在可靠性上加强。

为了在异步系统中，避免并发出了同样高度的提议，比如，多个好人节点在不同地方同时提出正确的提议。

进一步地，为了规避区块链分叉。例如，加上网络分散的原因，所以部分分区的好人节点可能分别接受了不同的争取提议，也就是区块链进行了合理分叉。

包括但不限于上述多种情况，使得PBFT共识过程需要经过复杂的过程，区块数据较大的情况下，通信压力大，共识很难进行下去。

与PBFT、SBFT等传统经典BFT类共识算法不同，Hotstuff采用类似PoW的区块链数据结构，HotStuff基于数据状态（类似比特币区块链结构、保留了基于数据状态的共识，例如PoW的优势），每个视图采用主节点集中式处理，安全性被证明可以独立保障，Hotstuff已经证明了安全性和活性可以解耦。虽然不需要指数级的p2p泛洪通信网络广播开销，但是中心节点压力大，区块数据较大的情况下，共识很难进行下去。

本申请实施例提供的区块链的双通道共识方法，应用于区块链的双通道共识系统，下文将区块链的双通道共识系统简称为区块链系统或者系统。区块链的双通道共识系统包括：共识主节点和共识副节点。其中，共识主节点用于在共识副节点中发起共识过程。共识副节点用于在共识主节点发起共识过程以后，完成共识。

其中，区块链系统可以采用智能生态网络（Intelligent Eco Networking，简称IEN）的作为系统架构框架。

其中，共识主节点可以为一个或多个，共识副节点为多个，本申请中提到的多个是指两个或两个以上。

如果共识主节点为一个，则共识过程有该共识主节点发起，完成共识。

如果共识主节点为多个，该多个共识主节点轮流发起共识过程，从而完成共识。比如，共识副节点可以轮流当共识主节点。

如果共识主节点为多个，多个共识主节点可以并行进行同一个共识单元任务，若其中一个完整的共识进程率先结束，本阶段共识单元任务完成，主控类型的节点通知其它共识主节点停止或作废相关同样的共识单元的进程。 这样既降低了共识主节点是拜占庭错误节点的概率，同时并行也相对加快了按时完成共识单元的成功概率和速度。

可选的，区块链的双通道共识系统还可以包括普通节点，普通节点为不参与共识过程的节点。也就是说区块链的双通道共识系统可以所有节点都参与共识，也可以一部分节点参与共识，另一部分节点不参与共识。

其中，客户端可以与区块链的双通道共识系统连接，用于发送共识区块数据的请求，例如，客户端可以为区块链的双通道共识系统中的任一节点。

本申请实施例提供的一种区块链的双通道共识方法，在共识过程中，基于命名寻址的通信方式将区块数据在数据通道进行传输，共识指令在共识交互通道进行传输，从而在区块数据较大的情况下，基于命名寻址的通信方式，副节点可以通过区块数据的名字就近获取到区块数据，可以减少共识主节点的通信压力，且将共识过程分为数据通道和共识交互通道两个通道同步进行，数据分发过程不影响共识交互过程的进行，提高了共识效率，使得共识方法应用范围更广。

下面以具体的实施例进行详细说明本申请的技术方案。

实施例一：

请参见图1，图1为本申请实施例提供的一种区块链的双通道共识方法的交互示意图，本申请提供的方法应用于区块链的双通道共识系统，该区块链的双通道共识系统可以为上述介绍的区块链的双通道共识系统，本实施例提供的方法包括以下步骤：

步骤101：客户端向共识主节点发送共识请求消息。

其中，共识请求消中包含待共识区块数据的名字，而不携带实际的待共识区块数据。共识请求消息用于指示对待共识区块数据的名字所指示的待共识区块数据进行共识操作。

其中，待共识区块数据可以为待共识后上链的一个或多个数据组成的区块数据，例如待共识区块数据可以为100个待共识后上链的交易数据。

可选的，共识请求消息还包括：共识标识信息和/或序列号，其中，共识标识信息用于请求对待共识区块数据进行共识。

可选的，待共识区块数据的名字包括：客户端的标识信息和待共识区块数据的标识，待共识区块数据的标识包括：区块高度和区块头的哈希值。

步骤102：共识主节点向共识副节点发送仲裁请求消息。

其中，仲裁请求中不直接携带待共识区块数据，而是携带待共识区块数据的名字，本申请中的仲裁请求也可以看做发送的一个区块数据，也可以称为IENBFT数据块。仲裁请求消息用于指示共识副节点根据待共识区块数据的名字，获取待共识区块数据，从而对共识区块数据进行仲裁投票，从而得到共识结果。

步骤103：共识副节点根据待共识区块数据的名字，通过命名寻址的通信方式，获取待共识区块数据。

其中，命名寻址的通信方式，即通过待共识区块数据的名字可以在网络中就近获取到待共识区块数据，缓解中心节点的网络传输压力，也能避免网络延迟。

可以理解，步骤102中的仲裁请求消息通过共识交互通道发送，步骤103中的待共识区块数据通过数据通道发送，两个过程互不干扰，因此，步骤102和步骤103之间的执行没有先后顺序。可以先执行步骤102再执行步骤103，也可以先执行步骤103再执行步骤102，还可以同时执行步骤102和步骤103，本申请对此不作限定。

步骤104：共识副节点进行签名验证和仲裁投票，并进行门限签名，得到投票结果。

其中，投票结果可以包括通过或者不通过。

步骤105：共识副节点向共识主节点发送投票结果。

步骤106：共识主节点根据接收到的各投票结果，得到共识结果。

其中，共识结果包括：达成共识或者未达成共识。

共识主节点可以在收到的投标结果为通过的数量大于或等于预设阈值时，确定达成共识；共识主节点可以在收到的投标结果为通过的数量小于预设阈值时，确定未达成共识。

进一步地，如果达成共识，则该待共识区块数据可以上链；如果未达成共识则该待共识区块数据无法上链。

本实施例，客户端可以通过组播或者广播的方式向区块链的双通道共识系统中的节点发送共识请求消息。共识主节点接收到该共识请求消息以后，在共识副节点中发起共识，向共识副节点发送仲裁请求消息，共识副节点可以根据待共识区块数据的名字向其他共识节点请求待共识区块数据，距离该共识副节点相对近的且存储了该待共识区块数据的节点可以将待共识区块数据发送给该共识副节点，共识副节点根据仲裁请求消息，对待共识区块数据进行仲裁投票，将投票结果发送给共识主节点，共识主节点根据收到的投票结果，确定共识结果。基于待共识区块数据的名字可以就近获取到待共识区块数据，避免长距离数据传输造成的时延，提高系统的反应速度，同时减少了共识主节点的通信压力，且将共识过程分为数据通道和共识交互通道两个通道同步进行，数据分发过程不影响共识交互过程的进行，共识主节点无需进行数据分发这种高负荷的处理任务，只需要完成“相对”轻量的共识交互任务，额外增加的共识开销不多，提高了共识效率，提高共识的活性，使得本申请实施例提供的方法应用范围更广。另外，由于恶意攻击并不知道共识副节点从何处获取待共识区块数据，因此，无法对待共识区块数据进行篡改，从而避免主节点被网络攻击等造成待共识区块数据被篡改的情况，增加数据获取的随机性，提高系统安全性。

在一些实施例中，步骤103具有多种实现方式。

一种可能的实现方式中，在步骤102之后，共识副节点确定自身是否已经存储有待共识区块数据，若没有，则共识副节点通过数据通道获取待共识区块数据。下面以具体的实施例进行详细说明。

在上述实施例的基础上，进一步地，步骤103可以通过如下步骤实现：

步骤103a：共识副节点根据待共识区块数据的名字，判断是否存储待共识区块数据。

若是，则继续执行步骤104。若否，则继续执行步骤103b。

步骤103b：共识副节点通过命名寻址的通信方式，向其他共识节点发送数据获取请求。

其中，其他共识节点包括共识主节点和除共识副节点以外的共识副节点；

步骤103c：共识副节点接收其他共识节点中的目标节点发送的待共识区块数据。

本实施例中，共识副节点接收到共识主节点发送的仲裁请求消息之后，根据待共识区块数据的名字，查看自身是否已经存储了对应的待共识区块数据，如果已经存储了对应的待共识区块数据，则可以继续进行仲裁投票过程，如果并未存储待共识区块数据，则可以通过待共识区块数据的名字，向系统中就近的节点获取该待共识区块数据。

本实施例中，步骤103a-步骤103c可以在步骤102之后执行。

另一种可能的实现方式中，在共识开始之前，共识副节点可以通过数据通道获取到待共识区块数据。下面通过具体的实施例进行详细说明。

在上述实施例的基础上，进一步地，步骤103可以通过如下步骤实现：

步骤1031：共识副节点接收客户端发送的共识请求消息。

步骤1032：共识副节点根据待共识区块数据的名字，通过命名寻址的通信方式，向其他共识节点发送数据获取请求。

其中，其他共识节点包括共识主节点和除共识副节点以外的共识副节点。

其中，数据获取请求用于请求获取待共识区块数据。数据获取请求也可以称为询问数据包。

步骤1033：共识副节点接收其他共识节点中的目标节点发送的待共识区块数据。

本实施例中，客户端在广播共识请求消息时，如果共识副节点收到该共识请求消息，共识副节点可以根据共识请求消息中携带的待共识区块数据的名字，向系统中发送询问数据包，从而就近获取到待共识区块数据。

本实施例中，步骤1031-步骤1033可以在步骤102之前执行。

在上述实施例的基础上，进一步地，数据获取请求中可以携带一些信息，下面介绍数据获取请求携带的一些信息。

数据获取请求中包含：可路由的标识前缀信息和待共识区块数据的名字。

其中，可路由的标识前缀信息用于基于命名寻址指示向区块链中的目标节点发布数据获取请求。

在采用命名寻址的区块链网络中，可路由的标识前缀信息可以以名称指向区块链中的目标节点，从而将该数据获取请求发送给目标节点。

进一步地，数据获取请求中还可以包含协议标识信息。

协议标识信息为当前发送同步消息所用的协议，可以为预先定义的一种协议。

进一步地，数据获取请求中还可以包括客户端的标识信息。

客户端的标识信息可以为客户端的命名标识的信息，即在共识系统中，每个节点对应一个标识，该标识信息可以为数字、字母或者字符串等形式。

例如，客户端的标识信息可以为客户端的用户标识信息（User Identification，简称UID）。区块链网络中的每个在线节点可以维护全局的在线节点状态信息表，在线节点状态信息表中包含在线节点的UID。

可选的，数据获取请求中还可以包括随机数。

由于数据获取请求在网络中转发时，某一个节点可能收到不同节点转发的相同的数据获取请求，因此，可以在数据获取请求中增加随机数字段，若接收的数据获取请求中随机数字段内的随机数相同，则可以认为是相同的数据获取请求，则后接收的数据获取请求可以不进行处理。

在一些实施例中，命名寻址的通信方式中，主要可以包括两种报文形式，分别是询问/通知包（ask）、回应数据包(answer)。节点路由根据名字（不是位置）构建转发逻辑，即命名寻址的含义，询问包用于基于名字请求数据，或者下发通知。回应数据包用于作为询问包的响应，即如果询问包需要请求数据，则回应数据包将该请求的数据按照与询问包发送来的路径返回，回应数据包将询问包作为自身的包头，在其后携带请求的数据。这样网络中即知道该回应数据包是询问包的响应，回应数据包沿着“相同名字”的询问包的来源路径“原路返回”。以上可知，询问包和回应数据包在每个路由节点中转发是“一问一答”工作模式，当前节点可以记录转发出去等待回复的回应数据包。在转发过程中，一个询问包可以产生多个副本，同时向多个邻居节点转发。

可选的，报文可以采用类型-长度-值（Type-Length-Value，简称TLV）格式。

可选的，包头采用类型（type）数值区分不同种类的包。

在一些实施例中，上述客户端广播的共识请求消息可以为一种基于命名寻址的询问包，从而共识副节点在接收到该询问包后，获取其中的待共识区块数据的名字，根据该名字组装成新的询问包，向系统中发送，从而异步下载待共识区块数据。

下面以具体的示例介绍本申请中的多种消息的一种报文格式：

“协议标识://可路由的标识前缀/客户端的UID/操作符/参数字段”。

比如，仲裁请求消息可以是：

“MyProtocol://viewStage/序列号/clientUID/datablockID”。

比如，共识请求消息可以是：

“MyProtocol://newProposal/clientUID/notify/datablockID”。

其语义为：客户端告知系统网络，一个新的提议开始，请接收待共识区块数据的名字。

比如，数据获取请求可以是：

“MyProtocol://PULL/ClientUID/datablockID”。

其语义为：共识副节点向网络中请求拉取客户端的UID的datablockID的数据。

相应的，目标节点接收到共识副节点发送的数据获取请求以后，如果本地有待共识区块数据，可以将该待共识区块数据以回应数据包的形式发送：

“协议标识://询问包的可路由标识前缀/参数字段/数据内容/签名等字段”。

可以看出回应数据包中，包头，即“协议标识://询问包的可路由标识前缀/参数字段”部分与询问包保持一致。

比如，回应数据包可以是：

“MyProtocol://PULL/ClientUID/datablockID/待共识区块数据/客户端的私钥签名”。

在一些实施例中，图1所示的实施例的共识过程可以通过两轮共识单元完成。

下面以图2所示的共识流程为例，说明本申请实施例提供的上述方法。

请参见图2，图2为本申请实施例提供的一种共识、数据分发双通道工作流程示意图，如图2所示，在共识过程中，通过数据通道获取待共识区块数据，通过共识交互通道完成共识过程，该共识交互通道用于完成共识指令的传输。

在一些场景中，共识副节点在共识过程中若待共识区块数据丢失，可以随时基于待共识区块数据的名字，通过命名寻址的方式获取到待共识区块数据。即在命名寻址网络中，节点中缺失的数据可以向上层可信节点快速恢复。

不稳定的网络环境可能使共识节点丢失共识数据，导致节点落后。因为有了基于命名的数据分离与信用等级高的节点数据存储机制，可以比较方便地采取并行向不同节点拉取区块的机制，整个过程可以以最快的速度拉取所有丢失的数据块，减少整个过程的等待时间。可以灵活配置并行度。并行拉取的区块先进行持久化排序组装，再有序执行。

另外，可以记录各个节点拉取效率的分数，可以补充相关节点的交互评分信任度。

根据共识节点落后的程度，可以将数据恢复方式分为两种模式：

模式1：大尺度恢复：节点数据账本落后较多，直接以命名寻址的方式向协调层节点（不选择陌生节点）拉取数据区块执行恢复到最新检查点。既能一定程度上保证可靠性，也降低共识主节点的负载；

模式2：小尺度恢复：检查点之后的共识进度落后，例如，错过了第一阶段共识单元向主控节点拉取当前阶段的共识单元的共识块与数据块，降低错误几率。

实施例二：

在一些场景中，BFT共识的每一轮共识单元都需要挑选（选取算法就有一定的复杂度）共识主节点。每次更换共识主节点的代价非常大，因此，挑选、甄别、管理信用度好的共识主节点，包括增加代理节点可以扩展系统性能。

本申请实施例中在区块链系统中，将区块链系统中的所有节点按照信用度值分为三个层级，共识过程中的进行共识的节点并非系统中的所有节点，而是信用度值较高的可信赖的节点。共识主节点也是从信用度值较高的可信赖的节点中挑选出来的。

本申请实施例提供的区块链的双通道共识方法，应用于区块链的双通道共识系统，区块链的双通道共识系统包括：多个节点；每个节点具有所属的节点类型，节点类型包括：主控类型、协调类型、边缘类型；主控类型的节点为区块链的双通道共识系统初始确定的；协调类型的节点和边缘类型的节点基于信用度值确定。下面介绍本实施例提供的系统。

请参见图3，图3为本申请实施例提供的一种节点信用度分层管理示意图，如图3所示，

构建三个层级的信用度高低的节点集合，三个层级分别为主控/可信层、协调/代理层和边缘/陌生层。其中，主控/可信层指定高信任值或有高稳定性的主动部署节点，是系统预设的。协调/代理层是指有一定信任值或良好历史行为的用户/节点/终端，边缘/陌生层可以是新加入、低信任或负信任/异常的用户/节点/终端。其中，主控/可信层和协调/代理层的节点是参与共识节点，边缘/陌生层不参与共识交互，只直接参与系统数据任务功能。

第一层：也就是主控层，是顶层，主要是由事先安排的可信的高性能计算节点组成。共识主节点可以从主控层中的节点选择。

在结合实施例一实现时，实施例一中将数据和共识交互处理分离，因此，共识主节点可以尽可能不优选主控层的节点进行消耗特别大的数据分发工作，在第二层代理节点不足等情况下，主控层的节点也可以承担数据分发的工作。

主控层节点同时也担任系统的起搏器，从全局时钟角度调控共识单元的花费时钟的进度，遇到“一直不响应”时可以进行强制的系统干预，避免无限等待，系统失去活性，其中，全局时钟只做宏观控制，并不能完全控制各个节点的状态，因为开放互联网中有各种不确定性；因为主控节点与大部分节点都保持状态交互，也可以启动对系统中节点进行信用度计算、选拔高信用度的“协调层节点”管理、节点信用等级水平管理、分组管理等功能。

第二层：是协调层，是通过计算信用度水平由主控层来选拔、标记形成的节点集合。从而实现负载卸载与均衡，扩大共识参与者，避免垄断、提高公信力，提高主节点处理当前出块的随机性，提高共识的健壮性，扩展性提高。

第三层，也就是边缘层，或者是外围层，不参与共识交互，即不参与仲裁投票。因为无法判断是好人还是坏人—当作“陌生”节点来看待。需要等运行一段时间以后，通过观察与评判，提升到一定的信用度以后，可以由主控层决定其“信用类型”的变化，可以晋级到参与共识，即加入“协调/代理”层节点集合。信用度的公式与第二层相同, 类似处理。

低信任节点不参与共识。但这些节点可以通过信誉的提升的方式入选到协调层，提升扩展性、降低攻击发生的可能性。这些低信任节点可以参与共识的存储、备份、数据转发等，保证网络的规模化。

基于上述图3介绍的节点分层机制，本申请实施例提供的选择共识主节点的共识工作模式可以包括：主控模式、双层协同模式和开放模式。

其中，主控模式是指共识主节点从主控层节点中选取，主控模式适合规模比较小的应用场景；

其中，双层协同模式是指共识主节点可以从主控层和一部分协调层节点混合选取；

其中，开放模式是指共识主节点可以从任意层节点中选取。

下面以具体的实施例进行详细说明本申请的技术方案。

请参见图4，图4为本申请实施例提供的一种区块链的双通道共识方法的交互示意图，本实施例的可以应用于区块链的双通道共识系统，该系统可以为上述区块链的双通道共识系统，本实施例的方法包括：

步骤401：客户端向主控类型的节点发送的共识请求消息。

其中，共识请求消息中包含待共识区块数据的名字。

本实施例中的主控类型的节点可以为一个或多个。

步骤401与步骤101类似，此处不再赘述。

步骤402：主控类型的节点基于可验证随机函数和多个节点分别对应的信用度值，确定共识节点。

其中，共识节点包括：共识主节点和共识副节点，共识节点所属的类型是协调类型或主控类型。

其中，可验证随机函数（Verifiable Random Function，简称VRF）可以使得各共识副节点在无现场见证的情况下，进行独立抽签，得到抽签结果，向网络公开抽签结果。即使其他节点无法见证，也可以很容易地验证这个结果确实是该共识副本节点生成的，从而验证抽签结果的有效性。

其中，节点的信用度值用于指示节点的受信任程度，即节点的信用度值越高，表明该节点越可靠。

步骤403：主控类型的节点向共识节点分别发送入选通知。

其中，入选通知用于指示已被选为共识节点。

步骤404：主控类型的节点向共识节点广播共识主节点。

主控类型的节点向所有的共识节点广播共识主节点，这样共识节点可以确定此次共识的共识主节点。

步骤405：共识副节点和共识主节点完成共识过程，得到共识结果。

共识过程可以为多种，例如，BFT共识过程、PBFT共识过程等，本实施例对共识过程不做限定。

可选的，步骤405可以通过上述步骤102-步骤105实现。

本实施例中，通过在共识过程中，节点在本地进行VRF抽签，将抽签结果上报主控类型的节点，主控类型的节点进行对比筛选，轮选出共识节点，从共识节点中选出共识主节点，并进行共识验证，验证通过后向共识节点发布。共识节点选取考虑了信用度值，可验证随机函数和信用度值高来选择主节点，并提高了主节点的隐蔽性、随机性、不可预测性，可以免受黑客的攻击，同时，也提高了防范DDoS等攻击的门槛。

下面简单介绍VRF函数。

将VRF算法应用于PBFT节点选取的过程中 有以下三个关键点： (1)VRF算法的输入为全网公认的种子数，在一次投票过程中不随时间的变化而变化； (2)VRF法中的加密过程采用RSA非对称加密算法实现，以节点的公钥对原数据进行加密，加密的结果是唯一的；(3)VRF算法算出的结果即随机数可以通过该节点的公钥进行验证，用以获知该随机数是否是通过全网公认的种子节点调用VRF算法产生的随机数。

VRF函数由(秘钥生成函数Key_Gen、VRF计算函数VRF_Hash、VRF证明函数VRF_Proof与VRF验证函数VRF_Verify等密码学函数组成)。VRF是公钥版本的密码学哈希函数。

VRF函数的设计难点：1、全网都公开知道、公认的一个种子/输入函数；2、该种子函数有随机性，也就是并不是一成不变的；3、争取能区分好坏节点被选举的概率大小不同，从而优先选取稳定性高、计算能力强、历史表现良好的节点。

本申请实施例中的种子函数选取与区块数据内容无关，从而避免算法由于区块数量多作为线索导致被容易操纵。

本申请实施例中，种子函数可以设计为：由主控节点在某一个周期的全网协调节点的平均信用值Creditproxy_avg+当前第几个共识单元的序号构成，从而保证不同的共识单元的种子不同。

在一些实施例中，共识副节点和共识主节点可以是在共识流程实现前确定的，也可以是先确定的，在共识流程实现前直接获取到的。下面以具体的实施例来说明确定共识副节点和共识主节点的一种具体方式。

在上述实施例的基础上，进一步地，步骤402可以通过如下步骤实现：

步骤4021：主控类型的节点向协调类型的节点发送遴选通知。

步骤4022：协调类型的节点向主控类型的节点发送遴选通知响应。

其中，遴选通知响应中包含协调类型的节点的私钥签名。

步骤4023：主控类型的节点基于可验证随机函数对各协调类型的节点的私钥签名进行验证，得到验证结果。

步骤4024：主控类型的节点在验证结果为验证通过的情况下，确定共识节点和候选共识主节点。

步骤4025：主控类型的节点通过共识过程完成对候选共识主节点的验证，在对候选共识主节点验证通过的情况下，确定候选共识主节点为共识主节点。

共识单元切换的时候，共识主节点的选取需要考虑增加判断是否是“拜占庭错误”节点。采用门限签名的简单共识方法。一轮连通性测试、一轮拜占庭信用度测试后再确定是否切合共识主节点，这种对大规模、高动态网络场景避免误杀“好的共识主节点”，从而减少共识的抖动性。

本实施例，使用参与者节点私钥作为输入，针对同一个输入而输出值是固定的，因此无法通过多次尝试来改变抽签结果。验证抽签结果时利用私钥对应的公钥来进行验证，因此这个抽签结果是无法被伪造的。提高选举共识节点的安全性。

进一步地，节点的信用度值是根据该节点的多方面指标数据得到的。指标数据可以包括但不限于如下指标中的至少一种：

指标一：计算能力；

其中，节点的计算能力可以通过节点测量一组哈希运算的耗时来计量。

指标二：内存能力；

其中，因为大部分协调层节点参与数据的加密、签名、打包和验证等工作，因此需要比较好的内存计算、存储数据块、高速读写的能力，因此，需要考虑节点的内存能力。

指标三：带宽水平；

其中，带宽水平主要包括有效带宽和延时。可以通过现有的多种方法测量得到。

指标四：在线稳定性；

其中，在线稳定性可以通过测量节点的在线率和连通成功率等来计量得到。比如，节点移动性高，且上下线频繁，该节点的稳定性数值偏低。

指标五：拜占庭信任度；

其中，拜占庭信任度需要通过预设时间周期内累计统计多个其他节点对该节点发起“验证性”的拜占庭测试后，完成的正确次数来定量给出数值，例如，主控类型的节点和预设比例（预设比例可以动态调整）的协调类型的节点。

指标六：交互评分信任度：

其中，节点之间在相互成功完成转发、通信的时候记录相关的一个单调递增的交互评分信任度值，从而边缘类型的节点可以从非主控类型的节点来民主评价一个节点的额外信用表现。

信用度值的计算可以是对上述多个指标加权求和得到的综合数值。其中，前四个指标指示该节点的客观处理能力，也可能因为节点的整体繁忙程度发生高低动态变化。指标五和指标六主要由一定的共识出错的统计相关，这2项权重比较高，因为不慎选入一个经常出错的节点，会干扰整体共识的计算流程，甚至重启，包括被攻击等“灾难性”、“破坏性”事件导致性能大幅抖动、下降的问题。

在一些场景中，信用度值可以通过节点信用度值获取方法来确定，下面以具体的实施例进行详细说明。

请参见图5，图5为本申请实施例提供的一种区块链的节点信用度值的确定方法的交互示意图，本实施例的方法包括：

步骤501：主控类型的节点向其他节点发送上报数值通知。

其中，其他节点包括：协调类型的节点和边缘类型的节点。

步骤502：多个节点中每个节点分别向主控类型的节点发送节点的自身信用度评估值和对节点的相邻节点的信用度评估值。

步骤503：对于每个节点，主控类型的节点根据节点的自身信用度评估值和节点的相邻节点对节点的信用度评估值，确定节点的信用度值。

步骤504：主控类型的节点根据各节点的信用度值，确定各节点所属的类型。

步骤505：主控类型的节点向多个节点发送数值报文。

其中，数值报文中携带个节点的信用度值和各节点所属的类型。

本实施例提供的方法步骤可以单独执行，也可以与图4所示的方法步骤结合执行。本实施例提供的方法步骤在与图4所示的方法步骤结合执行时，可以与图4所示的方法步骤并行执行，即其执行没有先后顺序，也可以在步骤402之前执行本实施例的方法步骤。

实施例三：

在一些场景中，在HotStuff论文或者大多数BFT共识过程中，活性机制使用了一个全局一致的超时时间确定了共识单元超时（随着时间变化， 网络中也有动态变化，每个共识单元的任务环境情况不一样，也需要相应的动态适应机制）。

本申请实施例中提供的区块链的双通道共识方法，在IENBFT数据块中，每个节点进入新的共识单元后，根据配置等待超时时间，如果视图未超时，则定时器时长不变。若某个节点本地共识单元超时仍未完成，但是这种判断如果仅仅是节点本地的判断，并不能判断共识主节点为拜占庭错误节点，也可能是中间网络故障或者共识主节点在收集投票过程中（局部延时比较长，属于正常情况），就可能会造成一部分节点判断共识主节点出错而另一部分节点判断共识主节点没有出错。因此需要一定轻量级的探测机制，在不给系统带来较大负担的同时判断是否需要替换共识主节点，即重启这个共识单元。下面以具体的实施例进行详细说明。

本实施例的方法可以在任一种共识过程中执行，也可以在上述实施例介绍的共识过程中执行。本实施例的方法包括以下步骤：

步骤601：共识副节点检测到共识单元超时，判断共识主节点是否连通。

其中，共识单元超时可以指共识单元所用时间大于超时时长。

若是，继续执行步骤602；若否，继续执行步骤610。

步骤602：共识副节点调整超时时长。

步骤603：共识副节点判断是否得到共识结果。

若否，则继续执行步骤604；若是，则继续执行步骤605。

步骤604：共识副节点确定当前调整超时时长的次数是否等于预设次数。

若是，则继续执行步骤606；若否，则返回执行步骤602。

步骤606：共识副节点测试共识主节点的信任度，判断信任度值是否大于信任度阈值。

若是，则继续执行步骤607；若否，则继续执行步骤608。

步骤607：共识副节点向主控类型的节点发送拜占庭信任度探测申请。

其中，拜占庭信任度探测申请用于指示启动测试共识主节点的信任度值。其中，拜占庭信任度值即为上述实施例二中的信任度值。

步骤608：共识副节点向主控类型的节点发送切换共识主节点申请消息。

步骤609：共识副节点更新对共识主节点的信用度评分。

步骤610：共识副节点向主控类型的节点申请多节点连通测试。

步骤611：主控类型的节点对共识主节点进行测试，判断是否通过测试。

若是，继续执行步骤602；若否，继续执行步骤608。

本实施例中，共识副节点在本地检测到共识单元超时以后，发起向另外一个在线的主控类型的节点请求对该共识主节点做一轮网络连通性、拜占庭信任度探测，另外，投共识副节点本身的一票（门限投票）。发起的每一轮上述探测可以多次来回, 例如间隔一个比较短的时间，发动3次来回。

在步骤611中的连通性探测中，可能出现多种情况，如下：

情况1：大于2f+1的连通性探测结果为失败，说明共识主节点反应迟缓严重，即此时存在CFT错误，需要立即启动更换共识主节点。

情况2：负责探测的主控类型的节点收到的有效门限签名少于2f+1，则拜占庭信任度测试不通过，需要立即启动更换共识主节点。

情况3：共识主节点连通性测试、拜占庭信任度测试都通过了，但不返回共识进展，修改本地定时器置，延长若干轮周期，其中，具体延长多少轮，可以根据任务规模大小、经验值确定，系统有最大轮次的上限设定。为原始配置时间递增2的幂次倍，连续超时3次则置超时器为8倍。以此类推，这样避免在网络不稳定时、大规模任务由于收敛慢而导致频繁切换视图。

实施例四：

本实施例提供一种区块链的双通道共识系统，该系统包括：多个节点；每个节点属于一种节点类型，节点类型包括：主控类型、协调类型、边缘类型；主控类型的节点为区块链的双通道共识系统初始确定的；协调类型的节点和边缘类型的节点基于信用度值确定；

主控类型的节点接收客户端广播的共识请求消息，共识请求消息携带待共识区块数据的名字；

主控类型的节点向协调类型的节点发送遴选通知；

主控类型的节点接收协调类型的节点发送的遴选通知响应，遴选通知响应中包含协调类型的节点的私钥签名；

主控类型的节点基于可验证随机函数对各协调类型的节点的私钥签名进行验证，得到验证结果；

主控类型的节点在验证结果为验证通过的情况下，基于各协调类型的节点的信用度值，确定共识节点和候选共识主节点；

主控类型的节点向共识节点分别发送入选通知，入选通知用于指示已被选为共识节点；

主控类型的节点通过共识过程完成对候选共识主节点的验证，在对候选共识主节点验证通过的情况下，确定候选共识主节点为共识主节点；

主控类型的节点向共识节点广播共识主节点；

共识主节点向共识副节点发送仲裁请求消息，仲裁请求消息携带待共识区块数据的名字；

共识副节点根据待共识区块数据的名字，通过命名寻址的通信方式，获取待共识区块数据；

共识副节点进行签名验证和仲裁投票，并进行门限签名，得到投票结果；

共识副节点向共识主节点发送投票结果；

共识主节点根据接收到的各投票结果，得到共识结果，共识结果包括：达成共识或者未达成共识。

本实施例提供的系统的实现原理与有益效果与上述实施例一和实施例二类似，此处不再赘述。

实施例四：

本申请实施例提供一种计算机可读存储介质，介质上存储有程序，程序能够被处理器执行以实现如上述实施例一或实施例二的方法。

本领域技术人员可以理解，上述实施方式中各种方法的全部或部分功能可以通过硬件的方式实现，也可以通过计算机程序的方式实现。当上述实施方式中全部或部分功能通过计算机程序的方式实现时，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器、随机存储器、磁盘、光盘、硬盘等，通过计算机执行该程序以实现上述功能。例如，将程序存储在设备的存储器中，当通过处理器执行存储器中程序，即可实现上述全部或部分功能。另外，当上述实施方式中全部或部分功能通过计算机程序的方式实现时，该程序也可以存储在服务器、另一计算机、磁盘、光盘、闪存盘或移动硬盘等存储介质中，通过下载或复制保存到本地设备的存储器中，或对本地设备的系统进行版本更新，当通过处理器执行存储器中的程序时，即可实现上述实施方式中全部或部分功能。

以上应用了具体个例对本申请进行阐述，只是用于帮助理解本申请，并不用以限制本申请。对于本申请所属技术领域的技术人员，依据本申请的思想，还可以做出若干简单推演、变形或替换。

Claims (10)

1.一种区块链的双通道共识系统，其特征在于，包括：多个节点；每个节点属于一种节点类型，所述节点类型包括：主控类型、协调类型、边缘类型；所述主控类型的节点为所述区块链的双通道共识系统初始确定的；所述协调类型的节点和所述边缘类型的节点基于信用度值确定；

所述主控类型的节点接收客户端广播的共识请求消息，所述共识请求消息携带待共识区块数据的名字；

所述主控类型的节点向协调类型的节点发送遴选通知；

所述主控类型的节点接收所述协调类型的节点发送的遴选通知响应，所述遴选通知响应中包含所述协调类型的节点的私钥签名；

所述主控类型的节点基于可验证随机函数对各协调类型的节点的私钥签名进行验证，得到验证结果；

所述主控类型的节点在验证结果为验证通过的情况下，基于各协调类型的节点的信用度值，确定共识节点和候选共识主节点；

所述主控类型的节点向所述共识节点分别发送入选通知，所述入选通知用于指示已被选为共识节点；

所述主控类型的节点通过共识过程完成对候选共识主节点的验证，在对所述候选共识主节点验证通过的情况下，确定候选共识主节点为共识主节点；

所述主控类型的节点向所述共识节点广播所述共识主节点；

所述共识主节点向共识副节点发送仲裁请求消息，所述仲裁请求消息携带待共识区块数据的名字；

所述共识副节点根据所述待共识区块数据的名字，通过命名寻址的通信方式，获取所述待共识区块数据；

所述共识副节点进行签名验证和仲裁投票，并进行门限签名，得到投票结果；

所述共识副节点向所述共识主节点发送所述投票结果；

所述共识主节点根据接收到的各投票结果，得到共识结果，所述共识结果包括：达成共识或者未达成共识。

2.一种区块链的双通道共识方法，其特征在于，应用于区块链的双通道共识系统，所述区块链的双通道共识系统包括：共识主节点和共识副节点；所述方法包括：

所述共识副节点接收所述共识主节点发送的仲裁请求消息，所述仲裁请求消息携带待共识区块数据的名字；

所述共识副节点根据所述待共识区块数据的名字，通过命名寻址的通信方式，获取所述待共识区块数据；

所述共识副节点进行签名验证和仲裁投票，并进行门限签名，得到投票结果；

所述共识副节点向所述共识主节点发送所述投票结果，以使所述共识主节点根据接收到的各投票结果，得到共识结果，所述共识结果包括：达成共识或者未达成共识。

3.如权利要求2所述的方法，其特征在于，所述共识副节点根据所述待共识区块数据的名字，通过命名寻址的通信方式，获取所述待共识区块数据，包括：

所述共识副节点在确定未存储所述待共识区块数据的情况下，通过命名寻址的通信方式，向其他共识节点发送数据获取请求，所述其他共识节点包括所述共识主节点和除所述共识副节点以外的共识副节点；

所述共识副节点接收所述其他共识节点中的目标节点发送的所述待共识区块数据。

4.如权利要求3所述的方法，其特征在于，所述待共识区块数据的名字包括：客户端的标识信息和待共识区块数据的标识，所述待共识区块数据的标识包括：区块高度和区块头的哈希值；

所述数据获取请求中包含：协议标识信息、可路由的标识前缀信息、客户端的标识信息和待共识区块数据的名字。

5.如权利要求2-4任一项所述的方法，其特征在于，所述区块链的双通道共识系统中的包含多个节点，所述共识主节点和所述共识副节点是从所述多个节点中选择的，每个节点具有所属的节点类型，所述节点类型包括：主控类型、协调类型、边缘类型；所述主控类型的节点为所述区块链的双通道共识系统初始确定的；所述协调类型的节点和所述边缘类型的节点基于信用度值确定；所述共识主节点和所述共识副节点为所述主控类型的节点基于可验证随机函数和所述多个节点分别对应的信用度值确定的，所述共识副节点所属的类型是协调类型或主控类型，所述共识主节点所属的类型是协调类型或主控类型。

6.一种区块链的双通道共识方法，其特征在于，应用于区块链的双通道共识系统，所述区块链的双通道共识系统包括：共识主节点和共识副节点；所述方法包括：

所述共识主节点接收客户端发送的共识请求消息，所述共识请求消息中包含待共识区块数据的名字；

所述共识主节点向所述共识副节点分别发送仲裁请求消息，所述仲裁请求消息携带待共识区块数据的名字，以使所述共识副节点根据所述待共识区块数据的名字，通过命名寻址的通信方式，获取所述待共识区块数据，并进行签名验证、仲裁投票和进行门限签名，得到投票结果；

所述共识主节点接收各共识副节点发送的所述投票结果；

所述共识主节点根据接收到的各投票结果，得到共识结果，所述共识结果包括：达成共识或者未达成共识。

7.一种区块链的双通道共识方法，其特征在于，应用于区块链的双通道共识系统，所述区块链的双通道共识系统包括：多个节点；每个节点具有所属的节点类型，所述节点类型包括：主控类型、协调类型、边缘类型；所述主控类型的节点为所述区块链的双通道共识系统初始确定的；所述协调类型的节点和所述边缘类型的节点基于信用度值确定；所述方法包括：

所述主控类型的节点接收客户端发送的共识请求消息，所述共识请求消息中包含待共识区块数据的名字；

所述主控类型的节点基于可验证随机函数和所述多个节点分别对应的信用度值，确定共识节点，所述共识节点包括：共识主节点和共识副节点，所述共识节点所属的类型是协调类型或主控类型；其中，节点对应的信用度值根据以下至少一种所述节点的指标确定：计算能力、内存能力、带宽水平、在线稳定性、拜占庭信任度和交互评分信任度；

所述主控类型的节点向所述共识节点分别发送入选通知，所述入选通知用于指示已被选为共识节点；

所述主控类型的节点向所述共识节点广播所述共识主节点，以使所述共识副节点接收所述共识主节点发送的仲裁请求消息，并根据所述待共识区块数据的名字，通过命名寻址的通信方式，获取所述待共识区块数据，进行签名验证和仲裁投票，并进行门限签名，得到共识结果，所述共识结果包括：达成共识或者未达成共识。

8.如权利要求7所述的方法，其特征在于，所述主控类型的节点基于可验证随机函数和所述多个节点分别对应的信用度值，确定共识节点，包括：

所述主控类型的节点向协调类型的节点发送遴选通知；

所述主控类型的节点接收所述协调类型的节点发送的遴选通知响应，所述遴选通知响应中包含所述协调类型的节点的私钥签名；

所述主控类型的节点基于可验证随机函数对各协调类型的节点的私钥签名进行验证，得到验证结果；

所述主控类型的节点在验证结果为验证通过的情况下，确定共识节点和候选共识主节点；

所述主控类型的节点通过共识过程完成对候选共识主节点的验证，在对所述候选共识主节点验证通过的情况下，确定候选共识主节点为共识主节点。

9.如权利要求7所述的方法，其特征在于，所述方法还包括：

所述主控类型的节点向其他节点发送上报数值通知，其中，所述其他节点包括：所述协调类型的节点和所述边缘类型的节点；

所述主控类型的节点接收所述多个节点中每个节点发送的所述节点的自身信用度评估值和对所述节点的相邻节点的信用度评估值；

对于每个节点，所述主控类型的节点根据所述节点的自身信用度评估值和所述节点的相邻节点对所述节点的信用度评估值，确定所述节点的信用度值；

所述主控类型的节点根据各节点的信用度值，确定各节点所属的类型；

所述主控类型的节点向所述多个节点发送数值报文，所述数值报文中携带个节点的信用度值和各节点所属的类型。

10.一种计算机可读存储介质，其特征在于，所述介质上存储有程序，所述程序能够被处理器执行以实现如权利要求2-9中任一项所述的方法。

Images