一种区块链系统中的共识方法、区块链系统和共识节点

技术领域

本说明书实施例属于区块链技术领域，尤其涉及一种区块链系统中的共识方法、区块链系统和共识节点。

背景技术

区块链是一个去中心化的、无需信任第三方的分布式账本。区块链技术具有多方写入、公开透明、不可篡改等特点。区块链按照准入机制的不同，可以分为公链、联盟链以及私有链。联盟链具备访问控制功能，只有被授权的节点才可以加入联盟链网络，因此往往比公链网络更安全和高效，主要用于企业或机构间的相互合作。

基于区块链技术创建的由权威节点组成的联盟链，有利于打破数据孤岛，在各联盟成员之间形成可信记录存证，保障上链数据的不可篡改性，实现跨区域、跨部门的合作。

衡量区块链性能的一个指标是TPS(Transactions Per Second，每秒交易量)。TPS越高，交易在区块链上执行、验证和确认的速度就越快。早期公链的TPS普遍较低，远远不能满足需要。而联盟链的TPS，普遍比公链有很大提高，但是仍然显著低于中心化交易系统，尤其是去中心化程度比较高的联盟链。可见，区块链的性能是阻碍区块链技术大规模推广的瓶颈。

TPS是由两方面因素决定的：每个区块所包含的交易数目和整个系统发布区块的速度。每个区块包含的交易数目越多，出块速度越快，TPS就越高。但是，这两个参数不能随意增大。区块变大之后，传播到全网的时间也会增大。如果出块间隔过短，不足以让系统中的绝大多数节点收到新发布的区块，那么区块链的安全就会受到影响。对于以PoW共识协议为代表的公链来说，这种情况下会产生分叉，导致某些交易可能被回滚。联盟链，由于可以控制参与共识的节点的身份和数量，因此可以采用传统的分布式共识协议产生区块。通常情况下，联盟链的共识节点数量相对于公链来说要少很多，并且节点带宽条件较好，所以TPS也会比公链高很多。但是，联盟链中区块增大后传输延迟也会增大，对于拥有大规模节点(比如数百乃至上千个节点)的联盟链网络来说，区块增大会导致更长的交易执行时间，共识协议中验证签名的时间也会增加，同时节点间发送的消息的剧烈增长，也会引起网络的拥塞，进一步增大区块传输时间，降低达成共识的效率，也影响到下一区块的出块时间。

可见，无论是公链还是联盟链，对区块达成共识的效率，对区块链系统的TPS有很大影响。因此，如何提升对区块达成共识的效率，对于提升区块链系统的性能，具有非常重要的意义。

发明内容

本说明书提出一种区块链系统中的共识方法，所述方法应用于从所述区块链系统中参与共识的多个共识节点中选举出的主节点；其中，所述多个共识节点中的各个共识节点的本地交易池中，分别维护了本地子链；所述本地子链包括所述各个共识节点基于本地交易池中存储的交易创建的若干个子区块；包括：

将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；

从本地交易池中维护的各个本地子链中，获取子区块集合，并基于获取到的子区块集合创建提议区块；其中，所述提议区块包含与所述子区块集合中的各个子区块对应的子区块标识；

将所述提议区块分别分发至其它的各个共识节点，以由各个共识节点分别从其本地交易池中维护的各个本地子链中，获取与所述子区块标识对应的各个子区块所包含的交易列表，并对获取到的交易列表进行共识处理。

本说明书还提出一种区块链系统中的共识方法，所述区块链系统中参与共识的多个共识节点中包括选举出的主节点；所述方法应用于所述多个共识节点中除了所述主节点以外的任一共识节点；其中，所述多个共识节点中的各个共识节点的本地交易池中，分别维护了本地子链；所述本地子链包括所述各个共识节点基于本地交易池中存储的交易创建的若干个子区块；包括：

将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；

获取所述主节点传输的提议区块；其中，所述提议区块为所述主节点基于从其本地交易池中维护的各个子链中获取到的子区块集合创建的提议区块；所述提议区块包含与所述子区块集合中的各个子区块对应的子区块标识；

从本地交易池中维护的各个本地子链中，获取与所述子区块标识对应的各个子区块所包含的交易列表，并对获取到的交易列表进行共识处理。

本说明书还提出一种区块链系统，包括多个共识节点；所述多个共识节点包括选举出的主节点；所述多个共识节点中的各个共识节点的本地交易池中，分别维护了本地子链；所述本地子链包括所述各个共识节点基于本地交易池中存储的交易创建的若干个子区块；其中：

主节点，将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；从本地交易池中维护的各个本地子链中，获取子区块集合，并基于获取到的子区块集合创建提议区块；其中，所述提议区块包含与所述子区块集合中的各个子区块对应的子区块标识；将所述提议区块分别分发至其它的各个共识节点；

除了所述主节点以外的其它共识节点，将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；获取所述主节点传输的提议区块，从本地交易池中维护的各个本地子链中，获取与所述子区块标识对应的各个子区块所包含的交易列表，并对获取到的交易列表进行共识处理。

本说明书还提出一种区块链系统中的共识节点，所述区块链系统包括多个共识节点；所述多个共识节点包括选举出的主节点；所述多个共识节点中的各个共识节点的本地交易池中，分别维护了本地子链；所述本地子链包括所述各个共识节点基于本地交易池中存储的交易创建的若干个子区块；包括：

第一发送模块，将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；

创建模块，从本地交易池中维护的各个本地子链中，获取子区块集合，并基于获取到的子区块集合创建提议区块；其中，所述提议区块包含与所述子区块集合中的各个子区块对应的子区块标识；

传输模块，将所述提议区块分别分发至其它的各个共识节点，以由各个共识节点分别从其本地交易池中维护的各个本地子链中，获取与所述子区块标识对应的各个子区块所包含的交易列表，并对获取到的交易列表进行共识处理。

本说明书还提出一种区块链系统中的共识节点，所述区块链系统包括多个共识节点；所述多个共识节点包括选举出的主节点；所述多个共识节点中的各个共识节点的本地交易池中，分别维护了本地子链；所述本地子链包括所述各个共识节点基于本地交易池中存储的交易创建的若干个子区块；包括：

第二发送模块，将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；

获取模块，获取所述主节点传输的提议区块；其中，所述提议区块为所述主节点基于从其本地交易池中维护的各个子链中获取到的子区块集合创建的提议区块；所述提议区块包含与所述子区块集合中的各个子区块对应的子区块标识；

共识模块，从本地交易池中维护的各个本地子链中，获取与所述子区块标识对应的各个子区块所包含的交易列表，并对获取到的交易列表进行共识处理。

上述实施例中，一方面，由于区块链系统中的各个共识节点可以将本地交易池中存储的交易，创建成由若干子区块构成的本地子链的形式在本地交易池进行维护，并在主节点创建提议区块之前，提前将该提议区块包含的交易列表分发到各个共识节点：因此，通过这种方式，可以在区块链系统中引入预传输机制，将提议区块的分发过程和针对该提议区块的共识过程进行解耦，使得在主节点创建提议区块之前，可以充分利用除了主节点以外的其它的各个共识节点的闲置带宽，提前将该提议区块包含的交易列表分发到各个共识节点，让每个共识节点可以都参与到共识数据的分发过程中，大幅提升了共识协议的吞吐量。

另一方面，由于主节点在创建提议区块时，该提议区块中可以不再包含交易列表，而只包含该交易列表所在的子区块的子区块标识；因此，该提议区块的数据容量将不再与该提议区块中包含的交易量相关，使得传输该提议区块的带宽耗费，将与区块中交易的量无关，从而可以显著降低主节点在向其它的各个共识节点分发提议区块时的数据容量和带宽负载，提升对该提议区块进行共识时的共识效率。

第三方面，由于主节点生成的提议区块中包含的各个子区块，是由除了主节点以外的其它的各个共识节点基于本地交易池中存储的交易自主生成，每个子区块中包含的交易的交易顺序，将可以由各个共识节点来自主决定；因此，通过这种方式，可以让每个共识节点都参与到交易排序中，可以削弱主节点对交易排序的垄断权，使得整个共识算法更加公平。

附图说明

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本说明书根据一示例性实施例示出的一种区块链系统中的共识方法的流程图；

图2是本说明书根据一示例性实施例示出的共识节点的链式交易池结构的示意图；

图3是本说明书根据一示例性实施例示出的一种子区块的数据格式的示意图；

图4是本说明书根据一示例性实施例示出的另一种子区块的数据格式的示意图；

图5是本说明书根据一示例性实施例示出的node1发起分叉攻击的示意图；

图6是本说明书根据一示例性实施例示出的一种提议区块对应的数据格式的示意图；

图7是本说明书根据一示例性实施例示出的另一种提议区块对应的数据格式的示意图；

图8是本说明书根据一示例性实施例示出的pbft算法的常规阶段的示意图；

图9是本说明书根据一示例性实施例示出的另一种pbft算法的常规阶段的示意图；

图10是本说明书根据一示例性实施例示出的另一种区块链系统中的共识方法的流程图；

图11是本说明书根据一示例性实施例示出的一种电子设备的示意结构图；

图12是本说明书根据一示例性实施例示出的一种区块链系统中的共识节点的框图；

图13是本说明书根据一示例性实施例示出的另一种区块链系统中的共识节点的框图。

具体实施方式

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

很多区块链，尤其是联盟链，普遍采用存在主节点的共识协议(leader-based)。例如，典型的leader-based共识协议有PBFT(Practical Byzantine Fault Tolerance，实用拜占庭容错算法)、PAXOS、RAFT(Replicated And Fault Tolerant，复制和容错)、HotStuff，等等。采用leader-based共识协议，可以从区块链系统中参与共识的共识节点中，选举出一主节点，由主节点来创建提议区块，然后共识协议可以协调各个共识节点，使得各个共识节点就主节点创建的提议区块达成一致。

其中，对于leader-based共识协议来说，主节点在一次共识过程中创建的提议区块的数据容量，决定了本次共识的吞吐量。当共识节点数量越多时，整个共识过程中共识节点为了达成共识而发送的消息的数量将与节点数量成正比。

为了提高共识的效率，在相关技术中，通过更加倾向于降低共识过程中的消息复杂度；例如，以Hotstuff共识协议为例，Hotstuff共识协议就是在Pbft协议的基础上，把共识协议的复杂度从O(n

然而，在实际应用中，影响共识性能的不仅有共识中的消息复杂度，还有主节点将创建的提议区块分发给其它的各个共识节点时的带宽负载。

具体而言，在联盟链中，一次共识需要对大量的交易达成共识，典型的一笔交易大小为250B，一个区块中包括400笔交易时，一个区块大小为100KB。

基于leader-based共识协议通用的共识过程，主节点在将创建的提议区块分发给其它的所有共识节点之后，在后续的针对该提议区块的共识阶段，其它的各个共识节点通常只需要发送针对该提议区块的签名数据即可。而一个签名数据通常不超过100B，由此可见，主节点将提议区块分发给其它的所有的共识节点的数据带宽耗费，是后续共识阶段的几百倍。

可见，主节点在分发提议区块的阶段，对整个共识的性能影响更大。若主节点分发的提议区块包含的交易数量较多，那么一次共识中的吞吐量就越大。然而，在实际应用中，一个主节点的带宽是有限的，一次共识中需要分发的提议区块包含的数据量越大，主节点将该提议区块给其他节点的时间也越久，这就会导致后续共识的时间也越久。

根据上述分析可以看出，对于leader-based共识协议，一次共识过程中的吞吐量，通常是由主节点的带宽决定的。或者可以理解为，在一次共识过程中，所有共识节点，只有主节点在分发提议区块时自身的带宽被使用，而其他时间其它的各个共识节点的带宽，通常处于闲置状态，未能充分利用。

基于此，本申请针对现有的leader-based共识协议未能充分发挥共识节点带宽的问题，在区块链系统中引入预传输机制，并设计了基于并行链的数据分发策略，可以在分发提议区块时，充分利用除了主节点以外的各个共识节点在共识过程中的闲置带宽，将分发提议区块时的带宽消耗，由线性级别降低到常量级别，从而可以大幅提升整个共识算法的吞吐量，降低区块传输时延，提高对提议区块进行共识时的共识效率。在实现时，一方面，可以在区块链系统现有的区块链的基础上，设计出一条分别维护在各个共识节点的本地交易池中的本地子链，由区块链系统中参与共识的各个共识节点，将其本地交易池中存储的交易，创建成由若干子区块构成的本地子链，然后将该本地子链分别在各自的本地交易池进行维护。

另一方面，还可以在区块链系统中引入预传输机制，让各个共识节点在主节点创建提议区块之前，利用自身的闲置带宽，提前将本地交易池中维护的本地子链，广播发送至其它的各个共识节点，并接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链也在本地交易池中进行维护。

而主节点在创建提议区块时，此时该主节点的本地交易池中已经维护了各个共识节点的本地交易池中维护的本地子链，此时主节点可以从本地交易池中维护的各个本地子链中，获取子区块集合，并基于获取到的子区块集合创建提议区块。其中，该提议区块可以不再包含该待共识的交易列表，而只包含与该子区块集合中的各个子区块对应的子区块标识。

主节点在创建了提议区块之后，可以将该提议区块分别分发至其它的各个共识节点，而其它的各个共识节点在接收到主节点分发的提议区块之后，可以分别从其本地交易池中维护的各个本地子链中，获取与该子区块标识对应的各个子区块所包含的交易列表，然后对获取到的交易列表进行共识处理。

在以上技术方案中，一方面，通过在区块链系统中引入上述预传输机制，可以将提议区块的分发过程和针对该提议区块的共识过程进行解耦，使得在主节点创建提议区块之前，可以充分利用除了主节点以外的其它的各个共识节点的闲置带宽，提前将该提议区块包含的交易列表分发到各个共识节点，让每个共识节点可以都参与到共识数据的分发过程中，大幅提升了共识协议的吞吐量。

另一方面，由于主节点在创建提议区块时，该提议区块中可以不再包含交易列表，而只包含该交易列表所在的子区块的子区块标识；因此，该提议区块的数据容量将不再与该提议区块中包含的交易量相关，使得传输该提议区块的带宽耗费，将与区块中交易的量无关，从而可以显著降低主节点在向其它的各个共识节点分发提议区块时的数据容量和带宽负载，提升对该提议区块进行共识时的共识效率。

第三方面，由于主节点生成的提议区块中包含的各个子区块，是由除了主节点以外的其它的各个共识节点，基于本地交易池中存储的交易自主生成，每个子区块中包含的交易的交易顺序，将可以由各个共识节点来自主决定；因此，通过这种方式，可以让每个共识节点都参与到交易排序中，可以削弱主节点对交易排序的垄断权，使得整个共识算法更加公平。

请参见图1，图1是本说明书根据一示例性实施例示出的区块链系统中的共识方法的流程图，所述区块链系统包括多个共识节点；所述多个共识节点包括基于所述区块链系统采用的leader-based共识算法选举出的主节点，所该方法可以应用于所述主节点；所述方法包括：

步骤102，将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；

上述区块链系统采用的leader-based共识算法，具体可以包括leader-based的拜占庭共识算法，也可以包括leader-based的非拜占庭共识算法。

例如，典型的leader-based的拜占庭共识算法，可以包括诸如PBFT共识算法和HotStuff共识算法，等等。而典型的leader-based的非拜占庭共识算法，可以包括诸如当PAXOS共识算法和RAFT共识算法，等等。

在本说明书中，可以在区块链系统现有的区块链的基础上，设计出一条分别维护在各个共识节点的本地交易池中的本地子链。

其中，该本地子链，具体可以包括区块链系统中参与共识的各个共识节点，基于其本地交易池中存储的交易创建的若干个batch(以下称之为子区块链)。通过这种设计，可以让各个共识节点的本地交易池中存储的交易，有序的打包到子区块中。

需要说明的是，本说明书中描述的本地子链，是指各个共识节点基于本地交易池中存储的交易自主创建的一个子链结构，该子链结构由各个共识节点在其本地交易池中独立的进行维护。不同的共识节点之间，并不需要对其它的共识节点其本地交易池中维护的本地子链进行交叉验证和确认。

在示出的一种实施方式中，各个共识节点在基于本地交易池中存储的交易创建子区块时，具体可以基于该子区块的成块周期，周期性的从本地交易池中获取交易列表，并基于获取到的交易列表创建子区块。

例如，在一个例子中，该成块周期可以是1毫秒，各个共识节点可以每隔1毫秒定时从本地交易池中捞取一批交易，打包成一个子区块，从而可以将本地交易池中存储的交易有序的打包到子区块中。

其中，需要说明的是，上述子区块的成块周期，在实际应用中，可以基于实际的需求进行灵活的设定；例如，在一个例子中，由于子区块中包含的交易列表，最终会被打包进行提议区块，并且提议区块所能容纳的交易量，通常是子区块所能容纳的交易量的整数倍；比如，一个提议区块可能是主节点基于N个子区块打包而成。在这种情况下，上述提议区块的成块周期对应的周期时长，具体可以是上述子区块的成块周期对应周期时长的整数倍。

进一步的，当各个共识节点基于获取到的交易列表创建了子区块之后，可以将该子区块与本地交易池中维护的本地子链上的最新的子区块进行链接。

例如，可以在创建的该子区块的数据格式中，填充本地交易池中维护的本地子链上的最新的子区块的hash值，将创建的该子区块与上述最新的子区块进行链接，当完成链接之后，此时创建的该子区块将变为该本地子链上的最新的子区块。

在本说明书中，还可以在区块链系统中引入预传输机制，让各个共识节点在主节点创建提议区块之前，利用自身的闲置带宽，提前将本地交易池中维护的本地子链，广播发送至其它的各个共识节点。

对于各个共识节点来说，一方面，可以将本地交易池中维护的本地子链，广播发送至其它的各个共识节点；另一方面，还可以接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护。

通过采用这种预传输机制，使得每个共识节点，都会接收到所有的共识节点的本地交易池中维护的本地子链，最终每个共识节点收到的所有的本地子链，将形成由多条子链构成的结构化的链式交易池结构。

例如，请参见图2，以上述区块链系统包含4个参与共识(图2示出的node1-node4)的共识节点为例，每个共识节点的本地交易池，将形成一个如图2所示的由4条子链构成的结构化的链式交易池结构。其中，图2上的Bth_i_j表示第i个共识节点生成的第j个Batch。

在示出的一种实施方式中，各个共识节点在将本地交易池中维护的本地子链，广播发送至其它的各个共识节点时，可以采用增量同步的方式，周期性的将本地子链中新增的子区块，广播发送至其它的各个共识节点。也即，当本地子链在一个新的成块周期中新增了一个子区块，则可以及时的将该新增的子区块广播发送至其它的各个共识节点。相应的，各个共识节点也可以接收其它的各个共识节点，周期性的广播发送的其本地子链上新增的子区块。

通过这种方式，使得各个共识节点可以按照本地子链上的子区块对应的成块周期，来周期性的将新增的子区块广播发送至其它的各个共识节点，从而可以避免将本地子链整体的同步到其它的各个共识节点，所造成的带宽消耗过多的问题。

当然，需要强调的是，在实际应用中，在区块链系统不关注带宽消耗的情况下，也可以采用将本地子链整体的广播发送至其它的各个共识节点的方式。

在示出的一种实施方式中，请参见图3，图3为本说明书示出的一种子区块对应的数据格式的示意图。

如图3所示，上述子区块的数据格式中，具体可以包括Batch header(即子区块头)，和TX List(交易列表)字段。Batch header可以进一步包括Previous Batch Hash字段，Batch Height字段(即高度字段)，Merkle Root字段，Batch Tip List字段(即指示列表字段)。

其中，Previous Hash字段，用于填充该子区块在其所属的本地子链中链接的上一子区块的hash值；

Batch Height字段，用于填充表示该子区块在其所属的本地子链中的区块高度的子区块标识；其中，该子区块标识具体可以是区块链系统中的一个全局的标识。例如，如前所述，该子区块标识可以是诸如Bth_i_j的形式，表示第i个共识节点生成的第j个Batch。j的取值表示该Batch在其所属的本地子链上的区块高度。

Merkle Root字段，用于填充基于该子区块包含的交易列表创建的Merkle树的根节点的hash值；

Batch Tip List字段：用于填充在创建当前子区块的时刻，本地交易池中存储的与其它的各个共识节点对应的本地子链上的最新子区块的区块高度构成的高度列表。

其中，需要说明的是，Batch Tip List字段中填充的高度列表，通常可以表示在创建该子区块的时刻，当前的共识节点本地存储的与其它的各个共识节点对应的本地子链的接收进度。

例如，请继续参见图2，假设图2所示的node1在创建Bth_1_5这个子区块的时刻，此时本地交易池中维护的与node2对应的本地子链上的最新子区块为Bth_2_5，对应的区块高度为5；与node3对应的本地子链上的最新子区块为Bth_3_5，对应的区块高度也为5；与node4对应的本地子链上的最新子区块为Bth_4_5，对应的区块高度也为5；在这种情况下，该Bth_1_5的子区块的数据结构中包含的Batch Tip List字段中填充的高度列表，可以表示成[1:5,2:5,3:5,4:5]。此时该高度列表表示的含义是，node1在创建Bth_1_5的时刻，node1的本地交易池中维护的与node1与对应的本地子链的最新子区块更新到Bth_1_5，node1的本地交易池中维护的与node2与对应的本地子链的最新子区块更新到Bth_2_5，node1的本地交易池中维护的与node3与对应的本地子链的最新子区块更新到Bth_3_5，node1的本地交易池中维护的与node4与对应的本地子链的最新子区块更新到Bth_4_5。不难理解，上述Batch Tip List字段中填充的高度列表，实际上表示的是node1本地交易池中维护的各个子链中的接收进度。需要说明的是，如果上述区块链系统采用leader-based的非拜占庭共识算法(比如RAFT或者PAXOS)时，上述子区块的数据格式，可以采用如图2所示的数据格式。

由于拜占庭共识算法通常要考虑共识节点中存在拜占庭节点(即恶意节点)的情况，因此在采用拜占庭共识算法的区块链系统中，通常需要对传输的数据进行签名，并基于签名验证机制来验证数据是否被拜占庭节点篡改。

在这种情况下，如果上述区块链系统采用的共识协议，为leader-based的拜占庭共识算法；比如，pbft或者HotStuff；在设计上述子区块的数据格式时，通常还需要在该子区块的数据格式中引入签名字段。

请参见图4，图4为本说明书示出的另一种子区块对应的数据格式的示意图。

如果上述区块链系统采用的共识协议，为leader-based的拜占庭共识算法，此时为上述子区块设计的数据格式，可以如图4所示。在图4示出的上述子区块的数据格式中，除了可以包含图3中示出的各个字段以外，还可以包含一个Signature字段。

其中，该Signature字段，具体可以用于填充子区块的创建者对该子区块的签名。需要说明的是，该子区块的签名，具体可以是针对该子区块整体提交的签名，也可以只是针对该子区块的子区块头提交的签名，在本说明书中不进行特别限定。

在示出的一种实施方式中，各个共识节点在接收到的其它的共识节点，通过以上描述的预传输机制，广播发送的其本地交易池中维护的本地子链之后，还可以对接收到的本地子链上包含的子区块进行合法性验证，并在合法性验证通过之后，再将接收到的本地子链在本地交易池中进行维护。

当然，对于准入门槛比较高，授信程度比较高的区块链系统，各个共识节点在接收到的其它的共识节点广播发送的其本地交易池中维护的本地子链之后，也可以不对接收到的本地子链上包含的子区块进行合法性验证，而直接将接收到的本地子链在本地交易池中进行维护。

其中，需要说明的是，各个共识节点在对接收到的本地子链上包含的子区块进行合法性验证时需要执行的验证项，通常与上述子区块的数据结构中包含的字段相对应。

在示出的一种实施方式中，各个共识节点在针对子区块进行合法性验证时，需要执行的验证项通常包括以下示出的验证项中的至少一项或者多个的组合：

验证项1：

针对该子区块的签名字段中填充的签名进行验证；如果针对该签名的验证通过，进一步执行下一步的验证；反之，确定针对该子区块的合法性验证未通过。

验证项2：

验证本地交易池中是否存储了该子区块的Previous Hash字段中填充的hash值所指示的该子区块链接的上一子区块；如果是，进一步执行下一步的验证；反之，进一步向创建所述上一子区块的共识节点获取该上一子区块。

通过执行验证项2，可以确保本地交易池中已经存储了该子区块链接的上一区块。

验证项3：

验证本地交易池中是否存储了与该子区块链接了相同的上一子区块的其它子区块；如果是，确定针对该子区块的合法性验证未通过；反之，进一步执行下一步的验证；

通过执行验证项3，可以避免本地交易池中同时存储了链接了同一区块的两个冲突的子区块的情形。这种情形下，通常都是由于恶意节点(即拜占庭节点)在本地子链上恶意的生成分叉的情形。例如，请参见图5，假设图2示出的node1发起了分叉攻击，则可能会分别创建两个同时链接子区块Bth_1_2的子区块Bth_1_3和Bth_1_3′。

验证项4：

验证该子区块的指示列表字段中填充的高度列表中包含的与其它的各个共识节点对应的区块高度，相较于该子区块链接的上一子区块的指示列表字段中填充的高度列表中包含的与其它的各个共识节点对应的区块高度是否递增；如果是，进一步执行下一步的验证；反之，确定针对所述子区块的合法性验证未通过；

由于在实际应用中，本地交易池中维护的与其它的各个共识节点对应的本地子链的区块高度，会由于不断接收到新的子区块而不断的递增，而一旦出现了接收到的某一子区块的指示列表字段中填充的高度列表中包含的与其它的各个共识节点对应的区块高度，相较于该子区块链接的上一子区块的指示列表字段中填充的高度列表中包含的与其它的各个共识节点对应的区块高度并没有递增，则该子区块在创建时，可能并没有正确的在该子区块的指示列表字段中填充其它的各个共识节点对应的本地子链上的最新的子区块(具体原因可能是恶意节点故意为止)，此时该子区块为创建出的错误子区块。基于此，通过执行验证项4，可以及时发现以上提到的错误子区块。

验证项5：

对该子区块包含的交易列表中的每笔交易的签名进行验证；如果针对所述每笔交易的签名的验证均通过，进一步执行下一步的验证；反之，确定针对所述子区块的合法性验证未通过；

通过执行验证项5，可以避免恶意节点恶意篡改交易列表中的交易的交易内容。

验证项6：

验证基于该子区块包含的交易列表创建的Merkle树的根节点的hash值，与该子区块的Merkle Root字段中填充的hash值是否相同；如果是，确定针对所述子区块的合法性验证通过；反之，确定针对所述子区块的合法性验证未通过。

通过执行验证项6，可以确保该子区块中包含了正确的交易列表。

其中，需要说明的是，以上示出的各个验证项的执行顺序，在本说明书中不进行特别限定，在实际应用中，可以基于实际的需求，来灵活的制定相应的顺序。当上述区块链系统采用的共识算法分别为leader-based的拜占庭共识算法以及leader-based的非拜占庭共识算法的两种情形下，各个共识节点在针对子区块进行合法性验证时，需要执行的验证项，通常也可以存在一定的差异。

在示出的一种实施方式中，如果上述区块链系统采用的共识算法分别为leader-based的拜占庭共识算法，此时上述子区块的数据格式可以如图3所示。由于拜占庭共识算法通常要考虑共识节点中存在拜占庭节点(即恶意节点)的情况，并且在采用拜占庭共识算法的区块链系统中，通常需要对传输的数据进行签名，并基于签名验证机制来验证数据是否被拜占庭节点篡改，因此在这种情形下，各个共识节点在针对子区块进行合法性验证时，需要执行的验证项可以包括以上提到的验证项1-验证项6。

其中，在示出的一种实现方式中，各个共识节点还可以在本地维护一个黑名单，该黑名单具体用于维护在针对子区块或者提议区块进行合法性验证的过程中发现的恶意节点。而在执行验证项3的过程中，如果本地交易池中存储了与该子区块，链接了相同的上一子区块的其它子区块，则可以进一步确定该子区块和该其它子区块的创建者，并将该创建者作为恶意节点添加至本地的黑名单。

除此之外，在一种实现方式中，还可以将该子区块和该其它子区块，广播发送至其它的各个共识节点，以使其它的各个共识节点来验证该该子区块和该其它子区块是否链接了相同的上一子区块，并在验证出该子区块和该其它子区块确实链接了相同的上一子区块时，可以进一步来确定该子区块和该其它子区块的创建者，并将该创建者作为恶意节点添加至黑名单；比如，在实现时，可以仅将该子区块和该其它子区块的子区块头，广播发送至其它的各个共识节点，以使其它的各个共识节点，可以基于上述子区块头中记录的信息，来进行上述验证，并基于上述子区块头中记录的信息，来确定该子区块和该其它子区块的创建者。

或者，在另一种实现方式中，也可以将已经确定出的创建者的信息，直接广播发送至其它的各个共识节点，以使其它的各个共识节点将该创建者作为恶意节点添加至黑名单。

其中，需要说明的是，由黑名单中维护的恶意节点创建的子区块，将不会被添加到主节点后续创建的提议区块中。例如，在一个例子中，主节点在创建提议区块的阶段，可以基于该黑名单，将由该黑名单中维护的恶意节点创建的子区块排除在提议区块之外。

在示出的一种实施方式中，如果上述区块链系统采用的共识算法分别为leader-based的非拜占庭共识算法，此时上述子区块的数据格式可以如图2所示。由于非拜占庭共识算法通常并不需要考虑共识节点中存在拜占庭节点的情况，因此在这种情形下，各个共识节点在针对子区块进行合法性验证时，需要执行的验证项可以包括以上提到的验证项2、验证项4和验证项6。也即，不需要执行以上提到的验证项1、验证项3和验证项5。步骤104，从本地交易池中维护的各个本地子链中，获取子区块集合，并基于获取到的子区块集合创建提议区块；其中，所述提议区块包含与所述子区块集合中的各个子区块对应的子区块标识；

如前所述，通过采用以上描述的这种预传输机制，使得每个共识节点，都会接收到所有的共识节点的本地交易池中维护的本地子链，最终每个共识节点收到的所有的本地子链，将形成由多条子链构成的结构化的链式交易池结构。

主节点可以从本地交易池中维护的链式交易池结构中的各个本地子链中，获取待共识的子区块集合，然后基于获取到的子区块集合创建提议区块。例如，在实现时，主节点可以按照提议区块的成块周期，周期性的从本地交易池中维护的各个本地子链中，来获取待共识的子区块集合。

其中，需要说明的是，主节点从本地交易池中维护的各个本地子链中，获取子区块集合的具体方式，在本说明书中不进行特别限定。

在本说明书中，主节点在从本地交易池中维护的各个本地子链中，获取子区块集合时，具体可以参考各个本地子链中的最新子区块中填充的高度列表，按照该高度列表所表示的各个共识节点对应的本地子链的接收进度，对从本地交易池中维护的各个本地子链进行切分，来确定需要添加到提议区块中的子区块集合。

其中，按照该高度列表所表示的各个共识节点对应的本地子链的接收进度，对从本地交易池中维护的各个本地子链进行切分的具体方式，在本说明书中也不进行特别限定，在实际应用中，可以基于具体的场景来灵活的确定。

在示出的一种实施方式中，主节点可以将本地交易池中维护的与各个共识节点对应的本地子链中，接收进度最慢的本地子链作为基准，通过确定出这些本地子链中的最新子区块的公共高度，来对各个本地子链进行切分。

在这种情况下，主节点首先可以分别确定本地交易池中维护的各个本地子链中的最新子区块，并进一步获取各个本地子链中的最新子区块的子区块头中的Batch Tip List字段中填充的高度列表。

在获取到各个本地子链中的最新子区块的子区块头中的Batch Tip List字段中填充的高度列表之后，可以基于获取到的高度列表，将各个共识节点中接收进度最慢的共识节点作为基准，进一步确定主节点的本地交易池中维护的各个子链中上的最新子区块的区块高度，和其它的各个共识节点的本地交易池中维护的各个子链上的最新子区块的区块高度之间的公共高度。

在确定出公共高度以后，主节点可以将该公共高度作为切分点，从主节点的本地交易池中维护的各个本地子链中，分别获取区块高度不大于该公共高度的子区块构成的子区块集合，再基于获取到的该子区块集合，来创建提议区块。

例如，在一个例子中，请继续参见图2，假如图2中的node1是主节点，该主节点本地交易池中维护的node1-node4对应的本地子链上的最新子区块(即区块高度最大的子区块)的Batch Tip List字段中填充的高度列表，如表1所示：

表1

其中，需要解释的是，在上表中，[1:5,2:5,3:5,4:5]表示Node1的本地交易池中维护的，与Node1对应的本地子链上的最新子区块的Batch Tip List字段中填充的高度列表，在该高度列表中，“1:5”表示的是Node1的本地交易池中维护的与node1对应的本地子链上的子区块的最高高度为5；“2:5”表示的是Node1的本地交易池中维护的与node2对应的本地子链上的子区块的最高高度为5(即Node1的本地交易池中维护的与node2对应的本地子链接收到第5个子区块)；“3:5”表示的是Node1的本地交易池中维护的与node3对应的本地子链上的子区块的最高高度为5(即Node1的本地交易池中维护的与node3对应的本地子链接收到第5个子区块)；“4:5”表示的是Node1的本地交易池中维护的与node4对应的本地子链上的子区块的最高高度为5(即Node1的本地交易池中维护的与node4对应的本地子链接收到第5个子区块)。

[1:5,2:5,3:4,4:3]表示node1的本地交易池中维护的，与node2对应的本地子链上的最新子区块的Batch Tip List字段中填充的高度列表；[1:3,2:4,3:5,4:5]表示node1的本地交易池中维护的，与node3对应的本地子链上的最新子区块的Batch Tip List字段中填充的高度列表；[1:3,2:3,3:4,4:6]表示node1的本地交易池中维护的，与node4对应的本地子链上的最新子区块的Batch Tip List字段中填充的高度列表；这些高度列表的含义与以上介绍的与node1的本地交易池中维护的，与node1对应的本地子链上的最新子区块的Batch Tip List字段中填充的高度列表的含义类似，不再赘述。

基于上表，主节点在通过本地交易池中维护的，与各个共识节点对应的本地子链中的最新子区块的公共高度，来对这些本地子链进行切分时，具体可以将各个共识节点中对于这些本地子链接收进度最慢的共识节点作为基准，来确定各个共识节点对应的本地子链中的最新子区块的公共高度。

通过上表可知，node1-node4对于与node1对应的本地子链的接收进度最慢的共识节点为node3和node4，均为接收到第3个子区块，此时node1-node4在其本地交易池中维护的与node1对应的本地子链的公共高度为3。

此时主节点可以从本地交易池中维护的与node1对应的本地子链上，选取Bth_1_1到Bth_1_3作为需要添加到提议区块中的子区块集合。

通过上表可知，node1-node4对于与node2对应的本地子链的接收进度最慢的共识节点为node4，为接收到第3个子区块，此时node1-node4在其本地交易池中维护的与node2对应的本地子链的公共高度为3。

此时主节点可以从本地交易池中维护的与node2对应的本地子链上，选取Bth_2_1到Bth_2_3作为需要添加到提议区块中的子区块集合。

通过上表可知，node1-node4对于与node3对应的本地子链的接收进度最慢的共识节点为node2和node4，均为接收到第4个子区块，此时node1-node4在其本地交易池中维护的与node3对应的本地子链的公共高度为4。

此时主节点可以从本地交易池中维护的与node3对应的本地子链上，选取Bth_3_1到Bth_3_4作为需要添加到提议区块中的子区块集合。

继续参见上表，node1-node4对于与node4对应的本地子链的接收进度最慢的共识节点为node2，为接收到第3个子区块，此时node1-node4在其本地交易池中维护的与node4对应的本地子链的公共高度为3。

此时主节点可以从本地交易池中维护的与node4对应的本地子链上，选取Bth_4_1到Bth_4_3作为需要添加到提议区块中的子区块集合。

基于上表，主节点从本地交易池中维护的与node1-node4对应的4条本地子链中选取出的子区块集合可以记录为[Bth_1_3,Bth_2_3,Bth_3_4,Bth_4_3]；

其中，在该记录中，Bth_1_3代表的是与node1对应的本地子链上的Bth_1_1到Bth_1_3；Bth_2_3代表的是与node2对应的本地子链上的Bth_2_1到Bth_2_3；Bth_3_4代表的是与node3对应的本地子链上的Bth_3_1到Bth_3_4；Bth_4_3代表的是与node4对应的本地子链上的Bth_4_1到Bth_4_3。

在示出的另一种实施方式中，主节点也可以将本地交易池中维护的与各个共识节点对应的本地子链中，接收进度最快的N个本地子链作为基准，通过确定出这些本地子链中的最新子区块的公共高度，来对各个本地子链进行切分。

在这种情况下，主节点在获取到各个本地子链中的最新子区块的子区块头中的Batch Tip List字段中填充的高度列表之后，可以基于获取到的高度列表，进一步确定主节点的本地交易池和其它的各个共识节点的本地交易池中，维护的各个本地子链中的最新子区块的区块高度最大的N个共识节点(也即对各个本地子链的接收进度最快的N个共识节点)；

然后可以将这N个共识节点的接收进度作为基准，进一步确定这N个共识节点的本地交易池中维护的各个本地子链上的最新子区块的区块高度之间的公共高度；

在确定出公共高度以后，主节点可以将该公共高度作为切分点，从主节点的本地交易池中维护的各个本地子链中，分别获取区块高度不大于该公共高度的子区块构成的子区块集合，再基于获取到的该子区块集合，来创建提议区块。

其中，上述N的取值，可以是区块链系统所采用的共识算法针对参与共识的共识节点的最大容错节点数。该N的取值可以是一个小于区块链系统中的共识节点的总数的取值。

例如，如果所述区块链系统所采用的共识算法为leader-based的拜占庭共识算法，所述区块链系统参与共识的共识节点的总数为3f+1，所述N的取值为2f+1。如果所述区块链系统所采用的共识算法为leader-based的非拜占庭共识算法，所述区块链系统参与共识的共识节点的总数为f，所述N的取值为f/2+1。

例如，在另一个例子中，仍然以图2中的node1是主节点，该主节点本地交易池中维护的node1-node4对应的本地子链上的最新子区块(即区块高度最大的子区块)的BatchTip List字段中填充的高度列表，仍如表1所示为例。假设区块链系统采用的共识算法为拜占庭共识算法，区块链系统的共识节点的数量为4，则f的取值为1，此时上述N的取值为2f+1＝3。

通过类比表1中node1-node4对于各个本地子链的接收进度可知，node4对于与node1-node3对应的本地子链的接收进度都是最慢的，因此除去接收进度最慢的node4，主节点可以将node1-node3等3个共识节点，确定为维护的各个本地子链中的最新子区块的区块高度最大的3个共识节点(也即对各个本地子链的接收进度最快的N个共识节点)。

进一步的，主节点可以进一步确定node1-node3的本地交易池中维护的与node1-node4对应的本地子链上的最新子区块的区块高度之间的公共高度。其中，求公共高度的具体方式，请参见之前的描述不再赘述。

基于表1可知，node1-node3的本地交易池中维护的与node1对应的本地子链上的最新子区块的区块高度之间的公共高度为3；node1-node3的本地交易池中维护的与node2对应的本地子链上的最新子区块的区块高度之间的公共高度为4；node1-node3的本地交易池中维护的与node3对应的本地子链上的最新子区块的区块高度之间的公共高度为4；node1-node3的本地交易池中维护的与node4对应的本地子链上的最新子区块的区块高度之间的公共高度为3。

此时主节点可以从本地交易池中维护的与node1对应的本地子链上，选取Bth_1_1到Bth_1_3作为需要添加到提议区块中的子区块集合，从本地交易池中维护的与node2对应的本地子链上，选取Bth_2_1到Bth_2_4作为需要添加到提议区块中的子区块集合，从本地交易池中维护的与node3对应的本地子链上，选取Bth_3_1到Bth_3_4作为需要添加到提议区块中的子区块集合，从本地交易池中维护的与node4对应的本地子链上，选取Bth_4_1到Bth_4_3作为需要添加到提议区块中的子区块集合。

基于表1，主节点从本地交易池中维护的与node1-node4对应的4条本地子链中选取出的子区块集合可以记录为[Bth_1_3,Bth_2_4,Bth_3_4,Bth_4_3]。而对于接收进度最慢的node4，需要从其他共识节点处接收到node2对应的本地子链上的第4个子区块(即Bth_2_4)，才能与其它几个共识节点完成最终的共识。

在本说明书中，当主节点采用以上实施例描述的切分方式，从本地交易池中维护的各个本地子链中，获取到需要添加至提议区块中的子区块集合之后，可以基于该子区块集合来创建提议区块。

其中，需要说明的是，由于本说明书中采用了以上描述的预传输机制，主节点从本地交易池中维护的各个本地子链中，获取到的需要添加至提议区块中的子区块集合，已经预先同步并存储在各个共识节点的本地交易池中；因此，在本说明书中，由主节点基于上述子区块集合创建的提议求区块中，可以包含上述子区块集合中的各个子区块对应的子区块标识，而不再包含上述子区块集合中的各个子区块对应的数据结构。通过这种方式，使得该提议区块中，将不再包含待共识的交易列表。

在示出的一种实施方式中，请参见图6，图6为本说明书示出的一种提议区块对应的数据格式的示意图。

如图6所示，在上述提议区块对应的数据格式中，具体可以包括Batch List字段(即子区块集合字段)和Merkle Root字段。

其中，Batch List字段，用于填充该提议区块包含的子区块集合中的各个子区块对应的子区块标识；

Merkle Root字段，用于填充基于子区块集合中的各个子区块包含的交易列表创建的Merkle树的根节点的hash值。

其中，需要说明的是，如果上述区块链系统采用leader-based的非拜占庭共识算法(比如RAFT或者PAXOS)时，上述提议区块的数据格式，可以采用如图6所示的数据格式。如果上述区块链系统采用的共识协议，为leader-based的拜占庭共识算法；比如，pbft或者HotStuff；在设计上述提议区块的数据格式时，通常还需要在该提议区块的数据格式中引入签名字段。

请参见图7，图7为本说明书示出的另一种提议区块对应的数据格式的示意图。

如果上述区块链系统采用的共识协议，为leader-based的拜占庭共识算法，此时为上述提议设计的数据格式，可以如图7所示。在图7示出的上述提议区块的数据格式中，除了可以包含图6中示出的各个字段以外，还可以包含一个Signature字段。

其中，该Signature字段，具体可以用于填充主节点对该提议区块的签名。

步骤106，将所述提议区块分别分发至其它的各个共识节点，以由各个共识节点分别从其本地交易池中维护的各个本地子链中，获取与所述子区块标识对应的各个子区块所包含的交易列表，并对获取到的交易列表进行共识处理。

在本说明书中，主节点在按照上述图6或者图7的数据格式，创建了提议区块之后，可以进一步将该提议区块，分别分发至其它的各个共识节点。

在实际应用中，区块链系统所采用的共识协议，无论是leader-based的拜占庭共识算法还是leader-based的非拜占庭共识算法，在其对应的算法流程中，通常均包含主节点对创建的提议区块进行分发的提议区块分发机制。

基于此，在示出的一种实施方式中，主节点在向其它的各个共识节点分发提议区块时，具体可以基于区块链系统采用的共识协议所支持的提议区块分发机制，将该提议区块广播发送至其它的各个共识节点。

在一个例子中，以pbft为例，作为一个经典的leader-based的拜占庭共识算法，pbft的算法流程通常包括Normal Case Phase和View Change Phase两个过程。其中，Normal Case Phase称之为pbft的算法流程中的常规阶段，图8为Normal Case Phase过程的流程图。如图8所示，Normal Case Phase中主要包括PRE-PREPARE(预准备)、PREPARE(准备)和COMMIT(提交)三个阶段，其中图8中示出的3号节点可以表示宕机的节点(图8中以×表示)。

基于图8中的算法流程，主节点通常会在PRE-PREPARE阶段，将基于收集到的由客户端发送的交易创建的提议区块附带在一个PRE-PREPARE消息中，然后将该PRE-PREPARE消息广播发送给其它的各个区块链节点，以将该提议区块的分别分发到其它的各个共识节点。

在这种场景下，如果上述区块链系统采用的共识算法为pbft，主节点在向其它的各个共识节点分发提议区块时，具体可以利用pbft支持的PRE-PREPARE阶段的提议区块分发机制，在PRE-PREPARE阶段将提议区块附带PRE-PREPARE消息中，广播发送至其它的各个共识节点。

在另一个例子中，再以HotStuff为例，HotStuff也是一种leader-based的拜占庭共识算法，与pbft不同的是，HotStuff的算法流程的常规阶段，包括PREPARE，PRE-COMMIT(预提交)，COMMIT和DECIDE等四个阶段。基于HotStuff的算法流程，主节点通常会在PREPARE阶段，将基于收集到的由客户端发送的交易创建的提议区块附带在一个PREPARE消息中，然后将该PREPARE消息广播发送给其它的各个区块链节点，以将该提议区块的分别分发到其它的各个共识节点。

在这种场景下，如果上述区块链系统采用的共识算法为HotStuff，主节点在向其它的各个共识节点分发提议区块时，具体可以利用HotStuff支持的PREPARE阶段的提议区块分发机制，在PREPARE阶段将提议区块附带PREPARE消息中，广播发送至其它的各个共识节点。

在第三个例子中，以raft为例，作为一个经典的leader-based的非拜占庭共识算法，raft的算法流程，通常包括leader election(主节点选举)、log replicate(日志同步)等两个阶段。基于raft的算法流程，主节点通常会在log replicate阶段，将基于收集到的由客户端发送的交易创建的提议区块封装到一个个log entry中，然后将这些log entries复制(replicate)到其它的各个共识节点，以将该提议区块的分别分发到其它的各个共识节点。

在这种场景下，如果上述区块链系统采用的共识算法为raft，主节点在向其它的各个共识节点分发提议区块时，具体可以利用raft支持的log replicate阶段的提议区块分发机制，在log replicate阶段将提议区块封装到一个个log entry中，然后将这些logentries复制(replicate)到其它的各个共识节点，以将该提议区块的分别分发到其它的各个共识节点。

在第四个例子中，以PAXOS为例，PAXOS也是一种leader-based的非拜占庭共识算法，PAXOS的算法流程，通常包括PREPARE、Accept等两个阶段。基于PAXOS的算法流程，主节点通常会在Accept阶段，将提议区块附带在一个Accept消息中，广播发送至其它的各个共识节点，以将该提议区块的分别分发到其它的各个共识节点。

在这种场景下，如果上述区块链系统采用的共识算法为PAXOS，主节点在向其它的各个共识节点分发提议区块时，具体可以利用PAXOS支持的Accept阶段的提议区块分发机制，将提议区块附带在一个Accept消息中，广播发送至其它的各个共识节点，以将该提议区块的分别分发到其它的各个共识节点。

在以上的实施例中，通过利用区块链系统采用的共识协议所支持的提议区块分发机制，将提议区块分发给其它的各个共识节点，可以将以上描述的预传输机制，与区块链系统采用的共识算法支持的提议区块分发机制进行有机结合。

由于采用上述预传输机制，使得主节点创建的提议区块中可以不再包含待共识的交易列表；因此，将以上描述的预传输机制，与区块链系统采用的共识算法支持的提议区块分发机制进行有机结合，可以降低在利用共识算法支持的提议区块分发机制分发提议区块时，所发出的消息的数据容量和带宽消耗。不难理解，将以上描述的预传输机制，与区块链系统采用的共识算法支持的提议区块分发机制进行有机结合，实际上可以起到对共识算法支持的提议区块分发机制进行优化的效果。

例如，请参见图9，仍以上述区块链系统采用的共识算法为pbft为例，在将以上描述的预传输机制，与pbft支持的提议区块分发机制进行有机结合之后，以上描述的预传输机制，可以作为pbft的PRE-PREPARE阶段之前的一个预传输阶段。

由于采用上述预传输机制，主节点创建的提议区块中可以不再包含交易列表；因此，主节点在PRE-PREPARE阶段，将生成的提议区块将附带在PRE-PREPARE消息中，广播发送给其它的各个区块链节点时，该PRE-PREPARE消息的数据容量也会显著降低。比如，一般情况下PRE-PREPARE消息中会附带交易列表和基于交易列表生成的Merkle Root，而将上述预传输机制与pbft支持的PRE-PREPARE阶段进行结合后，该PRE-PREPARE消息中可以只携带上文提到的Batch List字段和Merkle Root字段，而Batch List字段中填充的内容的大小相对于交易列表而言，显然是由线性级别降低到常量级别。

而PRE-PREPARE消息的数据容量的显著降低，势必会降低在交互PRE-PREPARE消息时的带宽消耗，这显然是有助于提升pbft协议本身的共识效率的。

需要说明的是，以上仅以上述区块链系统采用的共识算法为pbft为例进行了说明，在实际应用中，当区块链系统采用的共识算法为其它类型的共识算法时，上述预传输机制仍然可以与这些共识算法支持的区块分发机制进行有机结合，作为共识算法的第一阶段之前的一个预传输阶段，在本说明书中不再进行一一举例。

在本说明书中，当除了主节点以外的任一共识节点，接收到主节点分发的提议区块之后，可以对获取到的提议区块进行合法性验证。

当然，对于准入门槛比较高，授信程度比较高的区块链系统，各个共识节点在接收到主节点分发的提议区块之后，也可以不对该提议区块进行合法性验证。

其中，需要说明的是，各个共识节点在对接收到的提议区块进行合法性验证时需要执行的验证项，通常也与上述提议区块的数据结构中包含的字段相对应。

在示出的一种实施方式中，各个共识节点在针对子区块进行合法性验证时，需要执行的验证项通常包括以下示出的验证项中的至少一项或者多个的组合：

验证项7：

针对提议区块的签名字段中填充的签名进行验证；如果针对该签名的验证通过，进一步执行下一步的验证；反之，确定针对该提议区块的合法性验证未通过；

验证项8：

验证本地交易池中是否存储了与该提议区块的子区块集合字段中填充的子区块标识对应的各个子区块；如果本地交易池中存储了上述各个子区块，进一步执行下一步的验证；反之，进一步向主节点或者其它的共识获取本地交易池未存储的杉树各个子区块中的子区块；

通过执行验证项2，可以确保本地交易池中已经存储了提议区块包含的各个子区块。

验证项9：

验证基于获取到的所述各个子区块所包含的交易列表创建的Merkle树的根节点的hash值，与该提议区块的Merkle Root字段中填充的hash值是否相同；如果是，确定针对所述提议区块的合法性验证通过；反之，确定针对所述提议区块的合法性验证未通过。

通过执行验证项9，可以确保该子区块中包含了正确的交易列表。

其中，需要说明的是，以上示出的各个验证项的执行顺序，在本说明书中不进行特别限定，在实际应用中，可以基于实际的需求，来灵活的制定相应的顺序。当上述区块链系统采用的共识算法分别为leader-based的拜占庭共识算法以及leader-based的非拜占庭共识算法的两种情形下，各个共识节点在针对提议区块进行合法性验证时，需要执行的验证项，通常也可以存在一定的差异。

在示出的一种实施方式中，如果上述区块链系统采用的共识算法分别为leader-based的拜占庭共识算法，此时上述提议区块的数据格式可以如图7所示。由于拜占庭共识算法通常要考虑共识节点中存在拜占庭节点(即恶意节点)的情况，并且在采用拜占庭共识算法的区块链系统中，通常需要对传输的数据进行签名，并基于签名验证机制来验证数据是否被拜占庭节点篡改，因此在这种情形下，各个共识节点在针对子区块进行合法性验证时，需要执行的验证项可以包括以上提到的验证项7-验证项9。

其中，在示出的一种实施方式中，如果区块链系统所采用的共识算法为leader-based的拜占庭共识算法，此时图7示出的数据格式中的Batch List字段中，除了可以填充该提议区块包含的子区块集合中的各个子区块的子区块标识以外，还可以填充上述各个子区块的hash值。

在这种情况下，在执行上述验证项8的过程中，如果确定本地交易池中存储了该提议区块的Batch List字段中填充的子区块标识对应的各个子区块，还可以进一步计算本地交易池中存储的上述各个子区块的hash，并获取提议区块的Batch List字段中填充的与上述各个子区块对应的hash值，然后验证计算出的本地交易池中存储的上述各个子区块的hash，与获取到的该提议区块的Batch List字段中填充的与上述各个子区块对应的hash值是否均相同；如果是，再进一步执行下一步的验证。

其中，在示出的一种实现方式中，如果本地交易池中存储的上述各个子区块中的任一目标子区块的hash值，与获取到的该提议区块的Batch List字段中填充的该目标子区块的的hash值不相同，可以进一步确定该目标子区块的创建者，并将该创建者作为恶意节点添加至黑名单。

除此之外，在一种实现方式中，还可以将本地交易池中存储的该目标子区块和该提议区块的Batch List字段中填充的该目标子区块的hash值，一起广播发送至其它的各个共识节点，以使所述其它的各个共识节点来计算该目标子区块的hash值，并验证该目标子区块的hash值和提议区块的Batch List字段中填充的该目标子区块的hash值是否相同；如果经过验证，确认该目标子区块的hash值和提议区块的Batch List字段中填充的该目标子区块的hash值确实相同，可以进一步确定该目标子区块的创建者，并将该创建者作为恶意节点添加至黑名单。

或者，在另一种实现方式中，也可以将已经确定出的创建者的信息，直接广播发送至其它的各个共识节点，以使其它的各个共识节点将该创建者作为恶意节点添加至黑名单。

其中，需要强调的是，由黑名单中维护的恶意节点创建的子区块，将不会被添加到主节点后续创建的提议区块中。例如，在一个例子中，主节点在创建提议区块的阶段，可以基于该黑名单，将由该黑名单中维护的恶意节点创建的子区块排除在提议区块之外。

在示出的一种实施方式中，如果上述区块链系统采用的共识算法分别为leader-based的非拜占庭共识算法，此时上述提议区块的数据格式可以如图6所示。由于非拜占庭共识算法通常并不需要考虑共识节点中存在拜占庭节点的情况，因此在这种情形下，各个共识节点在针对子区块进行合法性验证时，需要执行的验证项可以包括以上提到的验证项8和验证9。也即，不需要执行以上提到的验证项7。

在本说明书当除了主节点以外的共识节点，对接收到的由主节点分发的提议区块进行合法性验证通过之后，可以分别从其本地交易池中维护的各个本地子链中，来获取与该提议区块中的Batch List字段中填充的各个子区块标识对应的各个子区块所包含的交易列表，然后进入到区块链系统采用的共识算法的共识投票阶段，对获取到的交易列表进行共识投票处理。

其中，需要强调的是，将以上描述的预传输机制，与区块链系统采用的共识算法支持的提议区块分发机制进行有机结合，不会对现有的共识算法的共识过程造成任何影响。后续对获取到的交易列表进行共识投票处理，仍然可以遵循区块链系统采用的共识算法现有的流程，在本说明书中不再进行详述。

请参见图10，图10是本说明书根据一示例性实施例示出的区块链系统中的共识方法的流程图，所述区块链系统包括多个共识节点；所述多个共识节点包括基于所述区块链系统采用的leader-based共识算法选举出的主节点，所该方法可以应用于所述除了所述主节点以外的任一共识节点；所述方法包括：

步骤1002，将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；

步骤1004，获取所述主节点传输的提议区块；其中，所述提议区块为所述主节点基于从其本地交易池中维护的各个子链中获取到的子区块集合创建的提议区块；所述提议区块包含与所述子区块集合中的各个子区块对应的子区块标识；

步骤1006，从本地交易池中维护的各个本地子链中，获取与所述子区块标识对应的各个子区块所包含的交易列表，并对获取到的交易列表进行共识处理。

在该实施例中，将以主节点以外的任一共识节点的角度来进行描述，以上各个步骤的具体实施细节，可以参考图1提供的实施例，在本说明书中不再进行详述。

与前述方法的实施例相对应，本说明书还提供了区块链系统、共识节点以及存储介质的实施例。

本说明书还提供一种区块链系统实施例，该区块链通可以包括多个共识节点；所述多个共识节点包括选举出的主节点；所述多个共识节点中的各个共识节点的本地交易池中，分别维护了本地子链；所述本地子链包括所述各个共识节点基于本地交易池中存储的交易创建的若干个子区块；其中：

主节点，将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；从本地交易池中维护的各个本地子链中，获取子区块集合，并基于获取到的子区块集合创建提议区块；其中，所述提议区块包含与所述子区块集合中的各个子区块对应的子区块标识；将所述提议区块分别分发至其它的各个共识节点；

除了所述主节点以外的其它共识节点，将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；获取所述主节点传输的提议区块，从本地交易池中维护的各个本地子链中，获取与所述子区块标识对应的各个子区块所包含的交易列表，并对获取到的交易列表进行共识处理。

图11是一示例性实施例提供的一种电子设备的示意结构图。请参考图1，在硬件层面，该设备包括处理器1102、内部总线1104、网络接口1106、内存1108以及非易失性存储器1110，当然还可能包括其他业务所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现，比如由处理器1102从非易失性存储器1110中读取对应的计算机程序到内存1108中然后运行。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑模块，也可以是硬件或逻辑器件。

如图12所示，图12是本说明书根据一示例性实施例示出的一种区块链系统中的共识节点的框图，该装置可以应用于如图11所示的电子设备中，以实现本说明书的技术方案。所述区块链系统包括多个共识节点；所述多个共识节点包括选举出的主节点；所述多个共识节点中的各个共识节点的本地交易池中，分别维护了本地子链；所述本地子链包括所述各个共识节点基于本地交易池中存储的交易创建的若干个子区块；所述共识节点120包括：

第一发送模块1201，将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；

创建模块1202，从本地交易池中维护的各个本地子链中，获取子区块集合，并基于获取到的子区块集合创建提议区块；其中，所述提议区块包含与所述子区块集合中的各个子区块对应的子区块标识；

传输模块1203，将所述提议区块分别分发至其它的各个共识节点，以由各个共识节点分别从其本地交易池中维护的各个本地子链中，获取与所述子区块标识对应的各个子区块所包含的交易列表，并对获取到的交易列表进行共识处理。

上述装置120的各个模块的具体细节已经在之前描述的方法流程中进行了详细的描述，因此此处不再赘述。

如图13所示，图13是本说明书根据另一示例性实施例示出的一种区块链系统中的共识节点的框图，该装置也可以应用于如图11所示的电子设备中，以实现本说明书的技术方案。所述区块链系统包括多个共识节点；所述多个共识节点包括选举出的主节点；所述多个共识节点中的各个共识节点的本地交易池中，分别维护了本地子链；所述本地子链包括所述各个共识节点基于本地交易池中存储的交易创建的若干个子区块；所述共识节点130包括：

第二发送模块1301，将本地交易池中维护的本地子链广播发送至其它的各个共识节点；以及，接收其它的各个共识节点广播发送的其本地交易池中维护的本地子链，并将接收到的本地子链在本地交易池中进行维护；

获取模块1302，获取所述主节点传输的提议区块；其中，所述提议区块为所述主节点基于从其本地交易池中维护的各个子链中获取到的子区块集合创建的提议区块；所述提议区块包含与所述子区块集合中的各个子区块对应的子区块标识；

共识模块1303，从本地交易池中维护的各个本地子链中，获取与所述子区块标识对应的各个子区块所包含的交易列表，并对获取到的交易列表进行共识处理。

上述装置130的各个模块的具体细节已经在之前描述的方法流程中进行了详细的描述，因此此处不再赘述。

相应的，本说明书还提供一种电子设备，所述电子设备包括有处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为实现之前描述的全部的方法流程中的步骤。

相应的，本说明书还提供一种计算机可读存储介质，其上存储有可执行的指令；其中，该指令被处理器执行时，实现之前描述的全部的方法流程中的步骤。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述实施例阐明的系统、装置、模块或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。