一种共识方法、区块链系统与流程

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


背景技术：

2.区块链（blockchain）是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性，区块链也有着越来越多的应用。


技术实现要素：

3.本发明的目的在于提供一种共识方法、区块链系统，包括：一种区块链系统中的共识方法实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
4.一种区块链系统中的共识方法实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；任一共识节点在收集到至少quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
5.通过上述实施例，可以较快的完成共识。
6.一种区块链系统中的共识方法，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第
一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；共识节点收集到至少quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；至少f 1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f 1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f 1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
7.通过上述实施例，有利于保证整个系统是可用的，具有活性。
8.一种区块链系统中的共识方法实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；共识节点收集到至少quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；共识节点根据历史的共识结果情况在所述合作模式和竞争模式之间切换，其中：合作模式：接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；竞争模式：至少f 1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f 1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f 1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述
关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
9.一种区块链系统中的共识方法实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；共识节点根据历史的共识结果情况在所述合作模式和竞争模式之间切换，其中：合作模式：任一共识节点在收集到至少quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；竞争模式：至少f 1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f 1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f 1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
附图说明
10.为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
11.图1是一实施例中实用拜占庭容错算法常规阶段的示意图；图2是一实施例中实用拜占庭容错算法视图切换阶段的示意图；图3是一实施例中蜜獾拜占庭容错算法的示意图；图4是本说明书一实施例中共识算法的流程图；图5是本说明书一实施例中共识算法的示意图；图6是本说明书一实施例中共识算法的示意图；图7是本说明书一实施例中共识算法的示意图；图8是本说明书一实施例中共识算法的示意图；
图9是本说明书一实施例中共识算法的示意图；图10是本说明书一实施例中共识算法的示意图；图11是本说明书一实施例中共识节点分布图；图12是本说明书一实施例中共识方法的流程图；图13是本说明书一实施例中共识方法的示意图；图14是本说明书一实施例中共识方法的示意图。
具体实施方式
12.为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
13.区块链系统中，不同参与方通过部署的节点（node）可以建立一个分布式的区块链网络。利用链式区块结构构造的去中心化（或称为多中心化）的分布式账本，保存于分布式的区块链网络中的每个节点（或大多节点上，如共识节点）上。这样的区块链系统需要解决去中心化（或多中心化）的多个节点上各自的账本数据的一致性和正确性的问题。每个节点上都运行着区块链程序，在一定容错需求的设计下，通过共识（consensus）机制保证所有忠诚节点具有相同的交易，从而保证所有忠诚节点对相同交易的执行结果一致，并将交易及执行结果打包生成区块。当前主流的共识机制包括：工作量证明（proof of work，pow）、股权证明（proof of stake，pos）、委任权益证明（delegated proof of stake，dpos）、实用拜占庭容错（practical byzantine fault tolerance，pbft）算法，蜜獾拜占庭容错（honeybadgerbft）算法等。
14.以pbft为例，该算法是miguel castro (卡斯特罗)和barbara liskov（利斯科夫）在1999年提出来的，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。该论文发表在1999年的操作系统设计与实现国际会议上（osdi99）。pbft算法中，所有的副本（replica）在一个被称为视图（view）的轮换过程（succession of configuration）中运行。在某个视图中，一个副本作为主节点（primary），其他的副本作为备份节点（backups）。视图是连续编号的整数。主节点由公式p = v mod |r|计算得到，这里v是视图编号，p是副本编号，|r|是副本集合的个数。该算法中假设，当最多存在f个副本（即节点）失效时，如果存在总数为至少3f 1个副本，就能保证在异步系统中提供安全性和活性。为了能够确保所有副本的数据一致性要求和容错要求，需要的一定数量副本的集合，一般是分布式系统中的大多数节点构成的集合，构成大多数（quorum）。例如在总节点数n为3f 1（n=3f 2或n=3f的情况一般不会对容错效果带来提升）的情况下，quorum为2f 1。这样，对于包含四个节点的分布式系统，任意三个节点可以构成一个quorum。
15.pbft包括normal case phase和view change phase两个过程，图1为normal case phase（常规阶段）过程的流程图。normal case phase中主要包括pre
‑
prepare（预准备）、prepare（准备）和commit（提交）三个阶段，其中3号节点例如可以表示宕机的节点（图1中以
×
表示）。当主节点失效的时候（图2中以
×
表示，如更换视图前主节点primary也就是replica 0（副本0）失效）就需要启动视图更换（view change）过程，从而在系统存在故障时进行状态调整，更换新的主节点（如更换视图后replica 1为主节点primary）。图2为view change phase（视图切换）的示意图。如果主节点掉线或者作恶而不广播客户端的请求等，客户端可以设置超时机制。如果超时的话，客户端可以向所有副本节点广播请求消息。副本节点检测出主节点作恶或者下线后，也可以发起view change协议阶段，以更换主节点（经常简称为“换主”）。此外，也可能由于主节点发起错误的提议导致pre
‑
prepare、prepare和commit三阶段共识过程失败，或者，prepare、commit阶段可能达不成 quorum 数量（如3f 1个节点中的2f 1个，也称为法定数量）的一致，也都无法完成共识。这些情况下也可能发起view change协议阶段，以更换主节点。
16.pbft协议属于半同步（partial synchronous）协议，其特点是假设网络一开始是异步的，但是能够从某一时刻开始同步。要在网络中让不同节点对同一提议达成共识，最简便的方式是设置主节点，由主节点来统一各个节点的意见。通过设置定时器，可以防止主节点出错。pbft中，如果在有限时间内没有完成 normal case phase，会触发 backups 发起 view change phase，以更换主节点。pbft将主节点固定在一个位置，所有请求都可以先发送到主节点，再由主节点广播到其他共识节点。除了引入额外的、将请求发送到主节点的延迟之外，主节点的出入口带宽也可能成为性能瓶颈。
17.pbft这类单主节点类型的协议，在同一次共识中只有主节点能够发起共识提议，其它节点没有能力发起共识提议。或者，如果其它节点也有提议，就需要将提议转发至主节点，由主节点代为发起提议。前者对于共识节点构造区块的权力是不公平的，后者虽然备份节点也可以提议，但是会增加主节点出口带宽的压力。对于大多共识节点都需要发起共识提议的情况，两者都不是特别适合。
18.与此相对的，honeybadgerbft（也常简称为hbbft）算法属于一种异步（asynchronous）协议。异步协议适用于异步网络，也就是这个网络中节点间的消息可以被任意延迟，但最终会到达。honeybadgerbft中去掉了定时器，而是通过消息来驱动协议的执行。同时，honeybadgerbft算法中所有节点都是对等的，没有主节点和备份节点之分，也就没有换主的过程。hbbft等异步网络共识协议无主节点的概念，各节点都可提议请求，尝试构造区块，因此异步网络协议在一定程度上缓解了公平性和单节点瓶颈的问题。
19.图3为honeybadgerbft算法单节点角度的流程图。实际上，如前所述，honeybadgerbft算法中所有节点都是对等的，也就是说，所有节点都可以执行图3所示的流程。如图3所示，从单节点的视角来看，honeybadgerbft主要包括两个阶段，分别为可靠广播（reliable broadcast, rbc）和异步共识（asynchronous binary agreement, aba，异步二进制协议，也称为“01异步共识”）。此外，还有rbc和aba之上的异步公共子集（asynchronous common subset，acs）协议。rbc阶段至少包括rval、echo、ready三轮消息交互，aba阶段至少包括bval、aux和coin三轮消息交互。rbc使用三轮消息交互保证可靠的提议广播。aba首先进行两轮投票（bval和aux消息），然后借助抛硬币（coin）对各节点的提议统一认识，从而绕开半同步协议对网络同步的要求。一次honeybadgerbft共识，要经过rbc阶段和至少一次aba阶段。最好的情况下，存在1/2的概率可以结束本次honeybadgerbft共识过程，这样，需要经过6个轮次完成一次共识。此外，有1/4概率会进入再一次的aba过程，如图3中第二次
aba过程（7、8、9轮次表示的aba过程），有1/4概率会在第二轮结束，且存在至少1/4的概率可以结束本次honeybadgerbft共识过程，这样，需要经过9个轮次完成一次共识。在第二次aba过程后，整体上有1/8的概率会进入再一次的aba过程
……
以此类推。
20.综上所述，honeybadgerbft至少包括一次rbc（三轮）和一次aba（三轮），如果aba的投票结果与抛币结果不一致，协议进入新一轮的aba（至少额外三轮）。抛币给共识的轮次带来不确定性，可能增加延迟。
21.另外，对于一个最终生成的区块（对应一个epoch）来说，一个节点可以运行一个acs和n个rbc n个aba，n为共识节点个数，且其中1个rbc和aba对应自身发起的共识提议，其它(n
‑
1)个rbc和aba对应其它(n
‑
1)个节点发起的共识提议。也就是说，对于一个epoch来说，一个节点发起共识提议的同时，也会配合完成其它节点发起的共识提议。这样，对于一个节点来说，至少(n
‑
f)个rbc结束后会将这些rbc已经完成的情况（通过ready消息表示）发至acs，进而由acs为对应的aba赋初值，启动对应的aba过程。在至少(n
‑
f)个共识提议完成aba之后如果剩余的共识提议仍未完成rbc，则会被赋初值为0，进而执行该提议对应的aba过程。从全局的视角来看，至少(n
‑
f)个节点会执行相同的上述共识过程（至少(n
‑
f)个不同节点发起提议的过程），并最终由acs来收集各个提议的aba结果后按照某种规则对aba结果为1的提议排序后输出。
22.上述的过程中，与pbft相反的，对各个参与共识的节点提出了较强的提议要求，即参与共识的节点需要在每一个epoch中都发起提议，不论这个节点是否真的有提议。如果这个节点实际上没有提议，也需要发起一个内容为空的提议请求（rbc中可以对这个空的提议请求加密，这样其他节点并不能确定这个提议的内容，以避免恶意节点因能看到提议中的内容而有选择的在ba过程中赋值输入或输出）。即使这个节点是失效节点，无法发出提议，那么在其他节点的acs中仍然要给这个节点对应的提议留出位置。具体的，在其他节点中的每一个执行完至少quorum个aba且均共识为1后，如果还没有收到这个节点的提议对应rbc阶段的quorum个ready消息，acs需要给这个节点的提议对应的aba初值赋为0，进而进入aba过程。这样，其它节点还需要配合完成这个失效节点对应提议的aba过程。
23.本技术提供一种共识算法实施例，如图4所示，具体包括：s41：【第一轮】第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名。
24.本技术一种共识算法实施例中，可以包括3轮的交互。与hbbft类似的，图5所示实施例的共识算法，也属于一种异步协议，即假设网络中节点间的消息可以被任意延迟，但最终会到达。类似的，图5实施例中也去掉了定时器，通过消息来驱动协议的执行；同时，所有节点可以都是对等的，没有主节点和备份节点之分，任一共识节点都可以发起共识提议，每一个共识节点也都可以参与其他节点提起共识提议的共识过程。一次共识的结果，可以包括本次共识中所有节点提起且获得至少quorum数量投票一致的共识提议中的交易集合的总和。
25.以一个节点的视角来看，例如以发起共识提议的视角来看，交互过程如图5所示。在一次共识中， 可以发起共识提议，这个共识提议中可以包括打包的交易集合，例如标记为，中可以包括一系列的交易构成的集合{}。进而，
可以广播第一消息至其它共识节点，如图5中广播至、和。广播的第一消息中可以包括的共识提议的交易集合。这个消息可以称为val消息。
26.此外，这个消息还可以包括第一共识节点对的签名，例如记为。一般地，第一共识节点可以用自身的私钥对直接签名，得到，也可以是先对进行hash计算，得到hash值（即摘要值），进而再用自身的私钥对该hash值签名，从而得到，还可以是用自身的私钥对和在内的数据直接进行签名或对和在内的数据的hash值进行签名。
27.第一消息中还可以包括时间戳。这个时间戳可以是第一共识节点广播第一消息时或之前的物理时间，可以由本地时钟确定。如果区块链网络中的各个共识节点能够做到相对准确的时钟同步，第一消息中的时间戳也是接收到该第一消息的节点中相对准确的时间。
28.考虑到节点之间可能存在一定的物理距离，因此消息的传播存在不可忽略的延迟，因此，第一消息中包括的时间戳，可以基于第一共识节点广播第一消息时或之前的物理时间以及网络传输时延确定。例如在一个包括4个共识节点的区块链网络中，第一共识节点到其它三个共识节点的平均传输时延或最大传输时延为δ，则第一消息中的时间戳为 ，其中可以是第一共识节点广播第一消息的本地物理时间。这个δ可以由rtt(round
‑
trip time，往返时延)来确定，rtt一般可以表示网络中从一个发送端发送数据至接收端开始，到该发送端收到来自该接收端的确认总共经历的时间。一般的，δ可以是rtt的一半。对于第一共识节点与其它三个共识节点之间的rtt不同的情况，可以取三个δ的平均值，或者取三个δ的最大值，具体如δ=或者δ=。
29.val消息的格式可以如<, , >，其中可以表示发起共识提议的时间戳，可以表示共识提议中的交易集合。所述，可以是采用自身私钥对包括和在内的数据的签名，也可以是先对进行hash计算，得到hash值，进而再用自身的私钥对该hash值和在内的数据进行签名，从而得到，还可以是用自身的私钥对和在内的数据直接进行签名或对和在内的数据的hash值进行签名。
30.s43：【第二轮】接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值。
31.在第一轮的末尾，接收到第一消息的共识节点可以验证接收到的第一消息的正确性。例如，可以采用的公钥对第一消息中的的签名进行验证。如果通过验证，则进入s43。
32.s43，具体如图5中，接收到第一消息的共识节点可以广播第二消息。第二轮次的消息交互中，、、各自分别广播第二消息至其它共识节点。共识节点广播的第二消息中，可以包括对发起的共识提议的投票。
33.例如，、、可以通过广播第二消息来告诉其他共识节点自身对共识提议的投票，投票可以是对共识提议中的消息集合表示认可或者不认可。具体的，在第一轮的末尾，收到val消息的共识节点，可以计算val消息中共识提议的交易集合的hash值。进而，如果共识节点认可该次共识中提议的交易集合，可以在第2轮次的消息交互中广播该hash值。相反的，如果共识节点不认可该次共识中提议的交易集合，可以在第2轮次的消息交互中广播0。这个广播的第二消息可以记为bval。此外，也可以是在第2轮次的消息交互中广播该hash值的同时，用1来表示对该hash值代表的提议投票认可或通过，用0来表示对该hash值代表的提议投票不认可或不通过，这只是简单的变化。
34.本轮次中，可以不参与广播，这是因为在第一轮次中发起共识提议，本身即可以代表对共识提议中的消息集合是认可的，从而第二轮次中可以由、、分别广播第二消息至其它共识节点。
35.需要说明的是，共识节点可以更改自己的观点并再次投票，即发出多个不同的bval消息。例如，可以首次发出内容是所述交易集合的hash值的bval消息，以表示对所述共识提议中的交易集合的认可，而后续可以再次发送内容是0的bval消息，以表示对所述共识提议中的交易集合的不认可。再例如，可以首次发出内容是0的bval消息，以表示对所述共识提议中的交易集合的不认可，而后续可以再次发出内容是所述交易集合的hash值的bval消息，以表示对所述共识提议中的交易集合的认可。
36.此外，第二消息中还可以包括对所述交易集合的签名。前述提到，在第一轮的末尾接收到第一消息的共识节点可以验证接收到的第一消息的正确性，例如验证的签名是否正确。进而，接收到第一消息的共识节点，可以用自己的私钥对第一消息中的交易集合进行签名。例如对第一消息中的交易集合进行签名，得到；也可以是先对的hash值签名，从而得到。
37.类似的，bval消息的格式可以如<, hash, >，其中可以是收到的val消息中的，hash为的hash值，表示对的投票观点是认同。则所述，也可以是采用自身私钥对包括和在内的数据的签名。类似的，也可以是对的hash值和在内的数据进行签名，从而得到，还可以是用自身的私钥对和hash在内的数据的hash值进行签名。
38.收到发来的val消息后，类似的，也可以计算val消息中的的hash值，并采用自身私钥对该hash值签名得到，进而也可以广播bval消息。bval消息中可以包括计算得到的hash值以及签名，也可以是包括、hash值以及签名。
39.收到发来的val消息后，类似的，也可以计算val消息中的的hash值，并采用自身私钥对该hash值签名得到，进而也可以广播bval消息。bval消息中可以包括计算得到的hash值以及签名，也可以是包括、hash值以及签名。
40.s45：【第三轮】接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名。
41.第二轮中的共识节点广播第二消息，这样，在第二轮的末尾，接收到第二消息的共识节点可以收集第二消息中的投票，进而广播第三消息。
42.例如，在第二轮的末尾可以收集bval消息中的投票。假设收集到，、分别广播的bval消息中的投票都是所述交易集合的hash值，且在第一轮中广播的val消息中也是，其对应的hash显然也是的hash值，则在本轮次中收集到至少quorum个一致的摘要值（例如此时f=1，quorum=3，实际收集到4）。
43.例如，在第二轮的末尾可以收集bval消息中的投票，假设收集到、分别广播的第二消息中的投票都是所述交易集合的hash值，且在第二轮中广播的第二消息中的投票如果也是所述交易集合的hash值（也表示对所述交易集合的认可），且在第一轮中接收到的发出的val消息中的也是同样的hash值，则在本轮次中收集到至少quorum个一致的摘要值（例如此时f=1，quorum=3，实际收集到4）。需要说明的是，第一轮中，广播的val消息中可以包括，这样在第一轮的末尾可以计算val消息中包括的的hash值，从而可以统计与第二轮中广播的bval消息中的的hash值是否相同，以及是否与第二轮中接收到的和发来的的hash值是否相同，进而得出是否收集到至少quorum个来自于不同共识节点的一致的hash值。
44.和与类似，不再赘述。
45.此外，共识节点还可以在第二轮末尾收集到不同节点的签名，如前所述。通过签名可以统计第二轮中收集到的投票的数量。例如收集到分别有、、签名的同一hash值，则说明对该hash共有3个表示认可的投票。当然，也可以通过共识节点之间建立的安全传输通道来确定消息的唯一性，进而确定消息的数量。所述安全传输通道例如通过消息认证码（message authentication code，mac）、安全传输层协议（transport layer security，ttl）之类的技术创建。
46.对于，如果收集到至少quorum个来自于不同共识节点的一致的hash值，且自身针对该提议没有广播过0（即不同的投票），则广播第三消息。第三消息可以记为prom消息，意思是承诺不会对提议更改观点。如前所述，的hash值可以表示认可，0可以表示不认可。针对该提议没有广播过0，是指没有对提议持有过不认可的观点，当然也可以用0以外的其它形式表示这种不认可。和也是类似的。
47.广播的第三消息中，可以包括收集到的对的投票，例如上述第一轮和第二轮中
收集到的hash值和签名。
48.prom消息的格式可以如<, hash, <签名集合>>。
49.例如，假设在第二轮中收集到，、分别广播的bval消息中的投票都是所述交易集合的hash值，这样也就收集到、和各自分别对（或的hash值）的签名是、、的投票，且在第一轮中广播的val消息中也包括自身对（或的hash值）的签名为的hash值。这样，在本轮次中收集到至少quorum个一致的摘要值（例如此时quorum=3）。进而，在第三轮中广播的prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合表示认可的hash值及签名集合，签名集合例如为、、、。
50.例如，假设在第二轮中收集到、分别广播的bval消息中的投票都是所述交易集合的hash值，这样也就收集到和各自分别对（或的hash值）的签名是、的投票，且在第一轮中广播的val消息中也包括其对（或的hash值）的签名是的投票，且在第二轮中广播的bval消息中也包括其对（或的hash值）的签名是的投票。这样，在第一轮和第二轮中收集到至少quorum个一致的摘要值（例如此时quorum=3）和不同节点的签名。进而，在第三轮中广播的prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合表示认可的hash值及签名集合，签名集合例如包括、、、。
51.和也类似于。
52.需要说明的是，上述签名集合，也可以用聚合签名或门限签名替代。
53.s47：共识节点收集到至少quorum个来自于不同节点的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
54.第三轮执行后，接收到prom消息的共识节点可以统计收集的prom消息的数量。共识节点在第三轮中发出prom消息的条件是第二轮中收集到至少quorum个来自于不同共识节点的一致的投票，且自身针对该提议没有广播过不同的投票，即相当于第二轮末尾该共识节点确认总计至少quorum数量的共识节点（包括自身）对该提议的投票都是认同的。但是，第二轮结束之后还不能马上输出共识结果，而是还需要观察其他节点是否也是在第二轮末尾收集到至少quorum数量的对提议的表示认同的投票，因此需要通过第三轮的prom消息来确认，并且通过该prom消息承诺自身不会再针对同一提议的表示不同的观点。
55.例如在第一轮和第二轮中收集到至少quorum个一致的摘要值，进而，在第三轮中广播的prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合表示认可的hash值及签名集合，签名集合例如包括、、、。
56.例如在第一轮和第二轮中收集到至少quorum个一致的摘要值，进而，
在第三轮中广播的prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合表示认可的hash值及签名集合，签名集合例如包括、、、。
57.和也类似于。
58.这样，通过第三轮，例如可以收集到至少quorum个prom消息。通过至少quorum个prom消息，可以确认至少quorum个共识节点中的每一个都收集到了对该提议的交易集合表示认可的至少quorum数量的投票，且发出prom消息的每一个共识节点都承诺不再会更改投票的观点，这样，可以进一步完成本次共识。
59.上述实施例中，首先，可以在一定前提下缩短至3个轮次完成一次共识，相对于hbbft中的至少6轮，大大降低了共识过程带来的延迟。实际上，本技术实施例中，相当于采用前瞻投票和数字签名技术将hbbft中rbc过程的后两轮和aba过程的前两轮进行了合并，从而缩短了所需的轮次。所述前瞻投票，是指上述实施例中第二轮次的bval中进行投票，而hbbft在aba过程中需要在第四轮次的bval中才投票。所述数字签名，指上述实施例中第一轮次和第二轮次中采用的数字签名。
60.此外，上述的，如前所述，可以对应。实际上，可以并行或先后发起两个不同的第一消息。例如，在发起（对应）的上述三轮过程中，可以并行或在前/在后发起（对应）的上述三轮过程。假设对应，。则发起共识提议的节点和参与共识的节点、和在输出共识结果时，可以按照时间戳的先后顺序排序，这样，共识结果排在之前。相应的，最终生成的对应的区块，其区块高度小于对应的区块。
61.所述区块链系统中的至少quorum数量的共识节点中的每一个，都可以作为第一共识节点执行上述第一轮至第三轮的过程。例如，上述图5的实施例，可以扩展到由、、和均执行。、和各自分别作为第一共识节点执行，也可以如图6、7、8中所示。这样，从整体的视角来看可以是图5、6、7、8的叠加。其中，例如发起共识提议的交易集合为且时间戳为，发起共识提议的交易集合为且时间戳为、发起共识提议的交易集合为且时间戳为，发起共识提议的交易集合为且时间戳为，这样，可以对应，可以对应，可以对应，可以对应。假设，则、、和各自本地的共识结果均为、、、，即按照时间戳排序的结果。、、、可以分别对应一个最终的区块。上述排序，可以由共识节点的acs协议收集共识结果后进行。具体的，acs可以收集各个共识提议的结果后按照各个共识提议的时间戳来排序共识结果并输出。
62.按照考虑传输时延的时间戳排序，充分考虑了共识结束的时间，即尽可能的将生成区块的顺序与共识结果的完成顺序保持一致。
63.这样，通过上述方式，可以在共识提议被提出时即确定对应的区块在区块链上的相对位置。而且，对于一个最终生成的区块来说，其包含一个共识提议，即对应一个共识结果的产生过程，则该共识结果不需要等待其它共识提议的结果，能够快速输出共识结果。这也就省去了在一个共识结果的生成过程中需要等待、配合其它共识提议的共识完成。对于没有提议的共识节点，也不必提出内容实际为空的共识提议，降低了网络带宽的消耗。对于无法提出共识提议的失效节点，上述实施例中只要正常工作的节点达到quorum数量，则生成共识结果的过程并不需要hbbft中那样超时赋值为0后再进入aba过程，而是可以跳过该失效节点，从而可以大大降低共识的时延。
64.本技术实施例中，与pbft和hbbft类似，可以容忍一定数量的错误节点，例如是总数n为3f 1的共识节点中可以容错f个错误节点，quorum为2f 1。以下给出一个存在f（f=1）个失效节点的例子。
65.例如，如图9和图10叠加的情况，假设为失效节点。
66.如图9所示：第一轮中，广播val消息，val消息的格式可以如<, , >，其中可以表示发起共识提议的时间戳，可以表示共识提议中的交易集合。所述，可以是采用自身私钥对包括和在内的数据的签名，也可以是先对进行hash计算，得到hash值，进而再用自身的私钥对该hash值和在内的数据进行签名，从而得到，还可以是用自身的私钥对和在内的数据直接进行签名或对和在内的数据的hash值进行签名。
67.第一轮的末尾，接收到val消息的共识节点可以验证接收到的val消息的正确性。具体的，可以采用的公钥对第一消息中的的签名进行验证，如果通过验证，则进入第二轮。类似的，可以采用的公钥对第一消息中的的签名进行验证，如果通过验证，则进入第二轮。而为失效节点。
68.第二轮中，接收到所述val消息的共识节点广播bval消息，bval消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的hash值。由于是失效节点，因此不响应，即不会广播bval消息，而由、分别广播bval消息至其它共识节点。广播的bval消息例如包括的hash值和采用自身的私钥对的hash值的签名。此外，bval消息也可以是如<, hash, >，则其中的可以是用自身私钥对包括和的hash值在内的数据的签名。
69.收到发来的val消息后，类似的，也可以计算val消息中的的hash值，并采用自身私钥对该hash值和签名得到，进而也可以广播bval消息。
70.第二轮的末尾，接收到bval消息的共识节点可以收集bval中的投票。对于，在第二轮的末尾收集bval消息中的投票，收集到，分别广播的bval消息中的投
票都包括所述交易集合的hash值，且在第一轮中广播的val消息中也是，其对应的hash也是的hash值，且，分别广播的bval消息中包括各自的签名和，在第一轮中广播的val消息中也包括签名，则在第二轮末尾收集到总计3个一致的hash值（此时f=1，quorum=3）。对于，在第二轮的末尾收集广播的bval消息中的投票是的hash值和，且在第二轮中广播的bval消息中的投票也是hash值及，且在第一轮中接收到的发出的val消息中的也是同样的hash值以及，则在本轮次中收集到3个一致的hash值，满足quorum数量。对于，在第二轮的末尾收集广播的bval消息中的投票是的hash值和，且在第二轮中广播的bval消息中的投票也是hash值及，且在第一轮中接收到的发出的val消息中的也是同样的hash值以及，则在本轮次中收集到3个一致的hash值，满足quorum数量。
71.第三轮中，接收到bval消息的共识节点收集到至少quorum个来自于不同共识节点的一致的hash值后，如果自身针对该提议没有广播过0，则广播prom消息，prom消息包括所述hash值以及收集到的签名。
72.例如，在第三轮中广播的prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合表示认可的hash值及签名集合，签名集合为、、。在第三轮中广播的prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合表示认可的hash值及签名集合，签名集合也是、、。在第三轮中广播的prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合表示认可的hash值及签名集合，签名集合也是、、。
73.第三轮执行后，接收到prom消息的共识节点统计收集的prom消息的数量，如果收集到至少quorum个来自于不同节点的prom消息后，将所述hash值对应的交易集合作为共识结果输出。
74.对于，在第三轮结束后收集到和广播的prom消息，且自身也广播过prom消息，因此总计收集到3个prom消息。
75.类似的对于，在第三轮结束后收集到和广播的prom消息，且自身也广播过prom消息，因此总计收集到3个prom消息。
76.类似的对于，在第三轮结束后收集到和广播的prom消息，且自身也广播过prom消息，因此总计收集到3个prom消息。
77.通过第三轮，收集到3个prom，可以确认至少3个共识节点中的每一个（满足quorum）都收集到了对该提议的交易集合表示认可的至少3个投票（满足quorum），且发出prom消息的每一个共识节点都承诺不再会更改投票的观点，这样，可以进一步完成
本次共识，即将所述hash值对应的交易集合作为共识结果输出。、也类似，即、也将所述hash值对应的交易集合作为共识结果输出。
78.类似的，如图10所示过程，广播val消息，val消息的格式可以如<, , >，最终将交易集合作为共识结果输出。、也类似，即、也将交易集合作为共识结果输出。
79.假设的时间戳为，的时间戳为，且，则、和各自在本地都产生两个共识结果。每个共识节点都可以按照时间戳对这两个共识结果排序，则排序结果为、，对于最终生成的两个区块来说，对应的区块的区块高度较小，对应的区块的区块高度较大。
80.在上述实施例中，在共识提议被提出时即确定对应的区块在区块链上的相对位置。而且，对于一个最终生成的区块来说，其包含一个共识提议，即对应一个共识结果的产生过程，则该共识结果不需要等待其它共识提议的结果，能够快速输出共识结果。这也就省去了在一个共识结果的生成过程中需要等待、配合其它共识提议的共识完成。对于没有提议的共识节点，也不必提出内容实际为空的共识提议，降低了网络带宽的消耗。对于无法提出共识提议的失效节点，上述实施例中只要正常工作的节点达到quorum数量，则生成共识结果的过程并不需要hbbft中那样超时赋值为0后再进入aba过程，而是可以跳过该失效节点，从而可以大大降低共识的时延。
81.在实际的区块链应用中，上述实施例针对特定的情形有更为重要的意义。如图11所示，例如组成一个联盟链的4个节点分别部署于不同的国家，位于英国，位于德国，位于法国，位于中国。显然的，位于欧洲的，和三个节点之间的通信时延较小，而这三个节点与位于亚洲的通信时延较大。假设，和三个节点之间的通信时延均为10ms，这三个欧洲节点与的通信时延均为80ms。如果采用hbbft，这4个节点中位于欧洲的3个节点即可以构成quorum，且其在30ms多的时间内内均能完成rbc过程，在另外的30ms多的时间内均能完成aba过程，而发起的提议由于总是较慢的执行，这样，的提议的rbc过程有较大概率在其它三个节点的aba过程结束前仍然没有完成，因此的提议在aba赋初值中赋值为0，从而的提议经常无法被纳入生成的区块中（按照抛币结果有大于1/2的概率），相当于经常失去对区块的构造权。而且，即使拥有对区块的构造权，较大的延迟也会拖慢一次共识的过程。
82.而采用本技术上述实施例的共识方案，每个节点的提议可以单独成块（生成区块），且共识结果按照时间戳排序，这样可以保证在不失去区块构造权的情况下，在发起共识提议时即确定成块的相对位置。特别是对于失效节点，无须等待其发起共识提议，其它节点也就不需要配合其完成共识。换句话说，可以按照实际的提议需求，并按照时间戳的顺序对完成共识的结果排序。此外，没有提议的共识节点，也不需要发起实际内容为空的提议，
从而可以降低网络带宽的消耗。
83.如前所述，上述实施例按照考虑传输时延的时间戳排序，充分考虑了共识结束的时间，即尽可能的将生成区块的顺序与共识结果的完成顺序保持一致。假设，和均发起共识提议，发起共识提议的本地物理时间为60ms，则其第一消息的时间戳，发起共识提议的本地物理时间为70ms，则第一消息的其时间戳，发起共识提议的本地物理时间为10ms，则其第一消息的时间戳。如果按照本地物理时间排序，则顺序是
→→
，但这与共识结果的产生并不相符，因此并不合理，否则先完成的共识结果需要等待后完成的共识结果，区块的生成顺序会被拖长。考虑传输时延后，共识结果的完成顺序与时间戳大概率相同，因此区块的生成顺序不会被拖长。
84.特别的，针对同一提议，第二消息和第三消息中具有与第一消息中相同的时间戳，该时间戳可以用于标识相同提议的共识过程，而不需要引入其它的标识，从而可以节省协议过程的数据量。
85.在pbft中，每一次共识都有一个sequence number来标识本次共识的消息的序列。该sequence number可以是致密递增的，例如像1，2，3，4，...，n这样排列。具体的，例如在一次共识中，共识主节点发起的pre
‑
prepare消息中包含值为3的sequence number。在本次共识中后续的prepare消息和commit消息中，都包含该相同的值为3的sequence number。从而，本次共识结束后，各个共识节点可以确定本次共识的结果在前后的多个共识结果中的顺序。这个顺序一般可以用于确定共识节点执行共识结果和生成的区块的顺序。对于本次sequence number值为3的共识结果，共识节点可以安排其在sequence number值为2的共识结果之后执行或成块。后续，共识主节点可以对sequence number的值增1，即变更为4，从而在下一次共识中发起sequence number的值为4的pre
‑
prepare消息，相应地，在后续的prepare消息和commit消息中，sequence number的值为4。类似的，对于sequence number值为4的共识结果，共识节点可以安排其在sequence number值为3的共识结果之后执行或成块。后续，共识主节点可以对sequence number的值增1，即变更为5，......。这样，可以保证各共识节点按照相同的顺序执行相同的共识结果，从而保证各个共识节点上生成的区块的一致性。
86.hbbft中也是类似的，存在相同作用的sequence number。
87.而上述图4
‑
11实施例中的共识算法中，在共识提议被提出时即通过时间戳的方式确定对应的区块在区块链上的相对位置，一个最终生成的区块包含一个共识提议，这样，该共识结果不需要等待其它共识提议的结果，从而能够快速输出共识结果。而时间戳是比较松散的，并不具有sequence number的致密递增特性，也就无法严格保证区块的执行顺序。例如，对于一个共识节点来说，其可能已完成时间戳为80.5ms的共识结果，100.8ms的共识结果和135.2ms的共识结果，这三个共识结果可以通过时间戳来确定相对的执行顺序后成块顺序，但是，80.5ms的共识结果和100.8ms的共识结果之间是否还有其它共识结果，100.8ms的共识结果和135.2ms的共识结果之间是否还有其它共识结果，通过时间戳是无法确定的。如果另外的某个共识节点具有一个时间戳处于80.5ms和100.8ms之间的共识结果，
或者具有一个时间戳处于100.8ms和135.2ms之间的共识结果，则不同共识节点之间难以保证生成的区块的一致。为了保证各个共识节点上生成的区块的一致性，各共识节点需要按照相同的顺序执行相同的共识结果。因此，需要一种机制来保障各共识节点按照相同的顺序执行相同的共识结果。
88.本技术提供的一种实施例中，各共识节点通过fifo（first input first output，先入先出）方式处理消息。先入先出队列是一种传统的按序执行方法，先进入的指令先完成后，才执行第二条指令。为了保证正确共识节点之间的消息满足fifo，可以通过为每一个发送的消息编号，并要求接收者按编号顺序处理请求的方式实现。也可以通过tcp协议来保障消息的顺序化传输。tcp提供了可靠的数据传输，避免数据包的重传、顺序的颠倒甚至或者数据包的丢失。共识节点可以在每次发送消息时，将消息编号后压进网络传输层。网络传输层采用tcp协议，并将由上层协议转化的tcp数据包按照顺序发送至接收方，并在一个特定的时长内等待接收方对这个tcp数据包的确认。如果所述共识节点在一个特定时长内没有收到接收方的确认，则重新发送该tcp数据包。如果接收方在特定时长内对该tcp数据包返回了确认，共识节点发送下一tcp数据包。如此循环，直至完成上层协议数据的发送。接收方一旦收到一个上层协议消息的全部tcp数据包后，可以进行循环冗余校验（cyclic redundancy check，crc），如果正确则将这些数据包按正确的顺序重组成数据流并传递到高层协议进行处理，并发送下一序号的上层协议的tcp数据包。此外，也可以采用安全套接字层（secure sockets layer，ssl）/安全传输层协议（transport layer security，tls）通信来保证实现fifo。
89.本技术还提供一种实施例，可以如图12所示，包括：s121：【第一轮】第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；s123：【第二轮】接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；s125：【第三轮】接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；s127：共识节点收集到至少quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
90.例如，第一共识节点可以在本地维护一个关键时刻序列{, ,...... }，在上述s121
‑
s127的过程中，当经过某个关键时刻t时，可以广播一个第四消息，以表明自己经过了这一关键时刻，如图13所示。这样的第四消息例如为pass(t)消息，消息名pass表明该消息是表示经过某个关键时刻的消息，其中包括的参数t即为该关键时刻。这里例如广播的是pass()。
91.类似的，也可以在本地维护一个关键时刻序列{, , ...... }，在上述s121
‑
s127的过程中（从局部来看，也可以是在s121
‑
s125的过程中，以下不再重复），当经过某个关键时刻t时，可以广播一个第四消息，以表明自己经过了这一关键时刻，这
里例如广播的是pass()。也类似的，例如在本地维护一个关键时刻序列{, , ...... }，在上述s121
‑
s127的过程中，当经过某个关键时刻t时，可以广播一个第四消息，以表明自己经过了这一关键时刻，这里例如广播的是pass()。也类似的，在本地维护一个时刻序列{, , ...... }，在上述s121
‑
s127的过程中，当经过某个关键时刻t时，可以广播一个第四消息，以表明自己经过了这一关键时刻，这里例如广播的是pass()。上述内容一并如图14所示。图13、14中所示的关键时刻序列，可以更为稠密或稀疏，这里并不做限定。
92.参与共识的共识节点，可以是各自在本地维护关键时刻序列。参与共识的共识节点各自在本地维护的关键时刻序列，可以相同，也可以不完全相同，还可以是完全不相同。对于完全相同的情形，往往需要通过中心化的方式为每一参与共识的节点发送关键时刻序列，或者由参与共识的节点之间协商或同步。对于完全不相同的情形，则可以是由参与共识的各节点自身按照本地时钟来确定，从而不需要中心化的方式为每一参与共识的节点发送关键时刻序列，或者由参与共识的节点之间协商或同步。至于不完全相同的情形，可以是中心化的方式为每一参与共识的节点发送关键时刻序列，之后各共识节点在此基础上增加一定数量的其它关键时刻，或者由参与共识的节点之间协商或同步部分关键时刻序列，之后各共识节点在此基础上增加一定数量的其它关键时刻；当然，也可以是由参与共识的各节点自身按照本地时钟来确定关键时刻序列后发生部分重合的情况。
93.共识节点广播pass(t)消息，除了表明自身已经经过关键时刻t，还可以表示一种承诺，承诺之后对于时间戳小于关键时刻t的提议投票为0，或者是不再处理所述时间戳在所述关键时刻t之前的共识提议。这样，共识节点收集到至少quorum个pass(t)消息后（包括自身最新广播的pass(t)消息），可以得到这些消息中的关键时刻，该关键时刻例如是至少quorum个第四消息中的最小关键时刻。从而，该共识节点可以确认至少quorum个共识节点都经过了该关键时刻t，从而可以对“此后将时间戳小于t的共识提议投票为0”或“不再处理时间戳小于t的共识提议”达成一致。这样，通过广播pass消息和按照达成一致的承诺内容执行，也可以间接达到类似fifo的效果，不过该关键时刻t之前尚未投票的共识提议可能将无法通过共识，也可能即使通过投票也无法被处理；如果无法通过共识或不被处理，该共识提议对应的交易集合也就无法被收录进区块中。所述最新pass消息，是因为同一节点可能先后广播多个不同关键时刻的pass消息，这样，对于接收到同一节点发来的多个不同关键时刻的pass消息来说，可以取最新的那个关键时刻。
94.上述广播pass消息，可以至少由quorum个共识节点参与完成。这样，每一共识节点广播pass消息，则任一共识节点可以接收其它共识节点发来的至少(quorum
‑
1)数量的pass消息，加上自身广播的pass消息，可以收集齐至少quorum数量的pass消息。参与共识的共识节点各自在本地维护关键时刻序列，则各共识节点广播的最新的pass消息中的关键时刻可能相同，也可能不同。即使参与共识的共识节点各自在本地维护关键时刻序列相同或部分相同，各共识节点广播的最新的pass消息中的关键时刻可能相同，也可能不同。而参与共识的共识节点各自在本地维护关键时刻序列完全不同的情况，则各共识节点广播的最新的pass消息中的关键时刻一定不同。如果收集齐的至少quorum数量的最新pass消息中的关键
时刻相同，则可以对“此后将时间戳小于t的共识提议投票为0”或“不再处理时间戳小于t的共识提议”达成一致。如果收集齐的至少quorum数量的pass消息中的关键时刻不同，例如上述例子中的～收集的4个（此时quorum=3）最新的pass消息中的关键时刻分别是pass()、pass()、pass()和pass()，而其中最小的是，则可以对“此后将时间戳小于的共识提议投票为0”或“不再处理时间戳小于的共识提议”达成一致。
95.以下提供一种共识方法实施例，结合图4
‑
14实施例来说明发送pass消息的具体时机。
96.在图4
‑
14对应的实施例中，接收到所述val消息的共识节点广播bval消息，bval消息中包括对第一消息中共识提议的交易集合的投票和签名。
97.接收到bval消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，可以认为已经经过了关键时刻t，该关键时刻t即为本次共识中val消息中的时间戳，例如该时间戳为ts。进而，可以广播pass(ts)消息至其它共识节点。
98.进而，任一共识节点在收集到至少quorum数量的pass(ts)后，可以不再处理其它时间戳在所述关键时刻ts之前的共识提议或者对所述关键时刻ts之前的共识提议投票为不通过。例如，对于其它次共识中val消息的时间戳小于所述ts的，对其投票bval(0)，0在共识算法的投票中经常表示不通过。这样，对于任何新的时间戳落后的共识提议，都有至少quorum的共识节点认为其时间戳晚于所述关键时刻ts，从而对其在bval(0)中投票为0，该时间戳落后的共识提议将不会被包含新生成的区块上。这样，至少quorum的共识节点可以按照时间顺序执行已共识的所述
푡
s对应的区块。广播第四消息时如果存在共识中的更早时间戳的已完成投票的共识提议，即已完成bval轮次的共识提议，则完成该更早时间戳的共识提议的共识后，再将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。这样才能保证共识结果的完成顺序。
99.另一方面，接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；共识节点收集到至少quorum个来自于不同节点的第三消息后，可以将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
100.作为替换方案，将pass消息置入第三消息中广播，而不需要另外广播第四消息，这样可以节省协议需要传输的消息的数量。具体的，接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳。进而，任一共识节点在收集到至少quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。类似的，共识节点收集到至少quorum个来自于不同节点的第三消息后，还可以将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
101.上述方案可以称为“合作模式”，因为这样的方案可以较快的完成共识。而且，这种方式可以直接依赖发起共识提议的第一消息中的时间戳，而不需要共识节点在本地维护关
键时刻序列，降低了实现成本和复杂度。
102.上述关于合作模式的方案，虽然可以较快的完成共识，但存在一定的风险。例如，如果存在恶意节点，其在忠诚节点提出共识提议后立即提起一个更晚时间戳的共识提议，由于忠诚节点的共识提议还没有进入或尚未完成本技术前述共识方法实施例中的第二轮次，因此如果恶意节点提出的更晚时间戳的共识提议先完成第二轮次的话，则忠诚节点的共识提议最终将被共识为0，即投票不通过，或不被处理。这样，忠诚节点发起的共识提议将有可能由于恶意节点的攻击而被过滤掉。即使不存在恶意攻击，而是网络延迟或者时钟偏移突然增大的情况，也可以导致某些区块由于晚于预期时间到达其他节点，而被共识为0或不能被处理。
103.基于此，本技术给出一种“竞争模式”的共识方法实施例，仍然结合图4
‑
14实施例来说明发送pass消息的具体时机。
104.在图4
‑
14对应的一个实施例中，可以是至少f 1个不同共识节点分别作为第一共识节点发起共识提议，广播val消息。在至少f 1个不同共识节点中的每一个作为第一共识节点广播val消息的共识过程中，至少有其它2f个共识节点配合来完成本次共识。这样，参与共识的节点为2f 1个，达到quorum数量。
105.在这个过程中，当任一参与共识的节点确认有f 1个由不同共识节点提出的共识提议被共识为1（即通过共识，意味着将输出为共识结果），可以确认其中至少有1个忠诚节点的共识提议被共识为1，从而可以将这f 1个共识提议中最早的时间戳作为关键时刻。这是因为，按照拜占庭容错模型，总量为3f 1的共识节点中至多可以容错f个拜占庭节点（例如恶意节点，无响应的节点）。那么，有f 1个由不同共识节点提出的共识提议被共识为1，则其中至少有1个是忠诚节点提出的共识提议，说明忠诚节点的共识提议没有被完全过滤掉。这也说明整个系统是可用的，具有活性（分布式系统中liveness的概念）。进而，该共识节点可以不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
106.任一参与共识的节点确认有f 1个由不同共识节点提出的共识提议被共识为1，更强的条件可以是确认有f 1个连续的且由不同共识节点提出的共识提议被共识为1。上述被共识为1，更强的条件可以是输出为共识结果。
107.在图4
‑
14对应的另一个实施例中，可以是至少2f 1（quorum）个不同共识节点分别作为第一共识节点发起共识提议，广播val消息。在至少2f 1个不同共识节点中的每一个作为第一共识节点广播val消息的共识过程中，至少有其它2f个共识节点配合来完成本次共识。这样，参与共识的节点为2f 1个，也达到quorum数量。
108.在这个过程中，当任一参与共识的节点确认有2f 1（这里表示quorum数量，其它容错模型的共识算法中quorum可能不是2f 1）个由不同共识节点提出的共识提议被共识为1，可以确认其中至少有f 1个忠诚节点的共识提议被共识为1，从而可以将这2f 1个共识提议中最早的时间戳作为关键时刻。这是因为，按照拜占庭容错模型，总量为3f 1的共识节点中至多可以容错f个拜占庭节点（例如恶意节点，无响应的节点）。那么，有2f 1个由不同共识节点提出的共识提议被共识为1，则其中至少有f 1个是忠诚节点提出的共识提议，说明忠诚节点的共识提议没有被完全过滤掉，且忠诚节点必然是占上风的。这也说明整个系统是可用的，具有活性。进而，该共识节点可以不再处理其它时间戳在所述关键时刻之前的共识
提议或者对所述关键时刻之前的共识提议投票为不通过。
109.任一参与共识的节点确认有2f 1个由不同共识节点提出的共识提议被共识为1，更强的条件可以是确认有2f 1个连续的且由不同共识节点提出的共识提议被共识为1。上述被共识为1，更强的条件可以是输出为共识结果。
110.在一个实施例中，共识节点可以在合作模式和竞争模式之间切换。具体的，共识节点可以根据历史的共识结果情况在所述合作模式和竞争模式之间切换。
111.共识节点可以在确认有第一数量的来自于不同节点的共识提议被共识为不通过后，切换到竞争模式。例如，第一数量为f 1，这样，共识节点可以在确认有f 1数量的来自于不同节点的共识提议被共识为不通过后，切换到竞争模式。确认有f 1数量的来自于不同节点的共识提议被共识为不通过，说明至少有1个忠诚节点提出的共识提议被共识为不通过，说明之前的模式比较激进，或者存在拜占庭节点。因此，调整到竞争模式，将关键时刻设的离当前更远，从而允许更多的共识提议能够通过共识，但副作用是可能导致一些共识结果无法较快的确定顺序。更强的条件可以是确认有第一数量连续的来自于不同节点的共识提议被共识为不通过。
112.共识节点可以在确认有第二数量的来自于不同节点的共识提议通过共识/输出为共识结果后，切换到合作模式。例如，第二数量为2f 1或quorum，这样，共识节点可以在确认有2f 1或quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，切换到合作模式。确认有2f 1数量的来自于不同节点的共识提议通过共识/输出为共识结果，说明至少有f 1个忠诚节点提出的共识提议被共识为通过，说明之前的模式比较宽松，或者不存在拜占庭节点。因此，调整到合作模式，将关键时刻设的离当前更近，从而利于共识结果更快速的确定顺序，但副作用是可能导致一些由于网络延迟或时钟便宜较大确定情况下某些共识提议被过滤掉，或者相对来说更容易被恶意节点发起过滤攻击。更强的条件可以是确认有第二数量连续的来自于不同节点的共识提议通过共识/输出为共识结果。
113.本技术还提供一种区块链系统实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
114.本技术还提供一种区块链系统实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；任一共识节点在收集到至少quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
115.本技术还提供一种区块链系统实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；共识节点收集到至少quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；至少f 1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f 1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f 1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
116.本技术还提供一种区块链系统实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；共识节点收集到至少quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；共识节点根据历史的共识结果情况在所述合作模式和竞争模式之间切换，其中：合作模式：接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点
的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；竞争模式：至少f 1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f 1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f 1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
117.本技术还提供一种区块链系统实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；共识节点根据历史的共识结果情况在所述合作模式和竞争模式之间切换，其中：合作模式：任一共识节点在收集到至少quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；竞争模式：至少f 1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f 1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f 1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
118.在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进（例如，对二极管、晶体管、开关等电路结构的改进）还是软件上的改进（对于方法流程的改进）。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件（programmable logic device, pld）（例如现场可编程门阵列（field programmable gate array，fpga））就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员
自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器（logic compiler）”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言（hardware description language，hdl），而hdl也并非仅有一种，而是有许多种，如abel（advanced boolean expression language）、ahdl（altera hardware description language）、confluence、cupl（cornell university programming language）、hdcal、jhdl（java hardware description language）、lava、lola、myhdl、palasm、rhdl（ruby hardware description language）等，目前最普遍使用的是vhdl（very
‑
high
‑
speed integrated circuit hardware description language）与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
119.控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该（微）处理器执行的计算机可读程序代码（例如软件或固件）的计算机可读介质、逻辑门、开关、专用集成电路（application specific integrated circuit，asic）、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc 625d、atmel at91sam、microchip pic18f26k20 以及silicone labs c8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
120.上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然，本技术不排除随着未来计算机技术的发展，实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
121.虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行（例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境）。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
122.为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
123.本发明是参照根据本发明实施例的方法、装置（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。
124.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。
125.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。
126.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
127.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
128.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd
‑
rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
129.本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、
cd
‑
rom、光学存储器等）上实施的计算机程序产品的形式。
130.本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
131.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
132.以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。