一种区块链一致性处理方法、区块链节点和区块链系统与流程

1.本说明书涉及区块链技术领域，特别涉及一种区块链一致性处理方法、区块链节点和区块链系统。


背景技术：

2.区块链是一种以密码学方式保证的不可伪造、不可篡改的分布式账本。区块链系统属于分布式系统，通常对一致性有着严格的要求。一致性是保证区块链系统可靠性的关键。


技术实现要素：

3.本说明书实施例之一提供一种区块链一致性处理方法,包括：区块链节点在生成当前区块的过程中，并行的执行待确认区块的确认过程。其中，所述待确认区块包括所述当前区块之前连续的n个已生成但未确认的区块；所述n个已生成但未确认的区块为预定数量的已生成但未确认的区块，或预定时长内累积的已生成但未确认的区块。
4.本说明书实施例之一提供一种区块链节点，包括：区块生成单元，用于生成当前区块；区块确认单元，用于执行待确认区块的确认。所述区块生成单元生成当前区块的过程中，所述区块确认单元并行的执行待确认区块的确认过程。其中，所述待确认区块包括所述当前区块之前连续的n个已生成但未确认的区块。所述n个已生成但未确认的区块为预定数量的已生成但未确认的区块，或预定时长内累积的已生成但未确认的区块。
5.一种区块链节点，包括：处理器；存储器，存储有计算机指令，其中，在所述处理器执行所述计算机指令时，执行上述方法。
6.本说明书实施例之一提供一种区块链系统，包括若干各区块链节点，其中：各区块链节点在本地独立生成当前区块，并在生成当前区块的过程中，并行的执行待确认区块的确认过程。所述确认过程包括，对于至少quorum个区块链节点来说，其中每一个都依本地区块编号顺序确认本节点与其它节点中共有至少quorum个一致的针对同一编号的已生成但未确认的区块的区块hash，且与本节点中同一编号的已生成但未确认的区块的区块hash一致。
附图说明
7.本说明书将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：
8.图1是根据本说明书一些实施例所示的区块链系统的应用场景示意图；
9.图2是根据本说明书一些实施例所示的区块链示意图；
10.图3是根据本说明书另一些实施例所示的区块链示意图；
11.图4是根据本说明书一些实施例所示的区块链一致性处理方法的示例性流程图；
12.图5是根据本说明书一些实施例所示的区块链一致性处理系统的示例性模块图。
具体实施方式
13.为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本说明书应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。
14.应当理解，本文使用的“系统”、“装置”、“单元”和/或“模组”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。
15.如本说明书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。
16.本说明书中使用了流程图用来说明根据本说明书的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。
17.图1是根据本说明书一些实施例所示的区块链系统的应用场景示意图。
18.如图1所示，区块链系统100可以包括区块链用户端(简称用户端)110和区块链网络120。其中，区块链网络120可以包括多个区块链节点，例如，图1中的节点120
‑
1、节点120
‑
2、节点120
‑
3、...、节点120
‑
n。
19.在一些实施例中，用户端120/区块链网络110中的节点可以包括各类计算设备，如智能电话、膝上型计算机、台式计算机、服务器等等。
20.在一些实施例中，服务器可以是独立的服务器或者服务器组，该服务器组可以是集中式的或者分布式的。在一些实施例中，服务器可以是区域的或者远程的。在一些实施例中，服务器可在云平台上执行。例如，该云平台可包括私有云、公共云、混合云、社区云、分散式云、内部云等中的一种或其任意组合。
21.用户端110是使用区块链服务的终端，其可以链接至区块链网络120中的某一节点以获取区块链服务。用户端110可以发起交易，即生成交易并将生成的交易发送至区块链网络120，以使交易在区块链网络120被广播。
22.区块链交易(简称交易)可以用于记录各类事件和/或数据。在一些实施例中，交易记录的事件可以包括表征新节点的加入、节点的退出、转账等中的一种或多种。在一些实施例中，交易记录的数据可以包括医疗信息、电子合同、电子凭据、电子订单、数字指纹等中的一种或多种。
23.期望的代码可以通过交易触发执行，也可称作交易的执行，区块链节点可以是交易的执行者。仅作为示例，用于记录转账行为的交易可以触发对转账双方账户余额的更新，用于存证数据的交易可以触发将数据写入区块链数据，用于查询数据的交易可以触发对区
块链数据的查询，等等。
24.在一些实施例中，交易的执行可包括智能合约的部署和调用。智能合约是一套以数字形式定义的承诺，包括合约参与方可以在上面执行这些承诺的协议。智能合约本质是一段运行在区块链网络中的代码，用于完成用户所赋予的业务逻辑。
25.区块链可由多个区块按时间顺序链接而成，这里的时间可指区块的产生时间。交易是区块的基本组成单位，节点可基于一段时间内接收到的一个或多个交易生成区块。
26.区块链系统中，不同参与方通过部署的节点(node)可以建立一个分布式的区块链网络。利用链式区块结构构造的去中心化(或称为多中心化)的分布式账本，保存于分布式的区块链网络中的每个节点(或大多节点上，如共识节点)上。这样的区块链系统需要解决去中心化(或多中心化)的多个节点上各自的账本数据的一致性和正确性的问题。每个节点上都运行着区块链程序，在一定容错需求的设计下，通过共识(consensus)机制保证所有忠诚节点具有相同的交易，从而保证所有忠诚节点对相同交易的执行结果一致，并将交易及执行结果打包生成区块。
27.区块链分布式一致性的特性，对交易执行结果的一致性提出了较为严格的要求。整个交易的执行可能涉及签名验证、交易调度、合约执行、存储、解密等中任意多个环节，只要其中任一环节中某一节点与其它节点出现不一致的行为，该节点上生成的区块可能就会与其它节点上生成的相同位置(如同为编号是n的区块)的区块不一致，就没法满足一致性的要求，这时不同节点上产生的相同编号的区块就会不同，也称作产生分叉。尤其是面对区块链版本/智能合约版本的不断迭代，新的版本不断推出，可能出现不同区块链节点运行不同版本的区块链程序/智能合约的复杂场景，使得出现不一致性的可能越来越高。
28.在一些实施例中，区块的生成和区块的确认可以按照串行逻辑进行。其中，区块的生成过程一般可以包括交易的打包和传播、交易的执行和区块的生成；区块的确认是指本节点验证保存的某一区块与其他节点保存的位于区块链中同一位置的区块是否一致(可视为对生成区块的共识)。如图2所示，此时区块链包括已生成的n+4个已确认区块(创世区块)、区块1、区块2、
……
、区块n+3，共n+4个区块)。已确认区块是指各节点通过共识确定至少quorum(法定数量，指共识机制中满足容错需求前提下保持一致的最少节点数量)个节点上保持一致的区块。
29.按照串行逻辑，节点的处理顺序可以是：生成创世区块，确认创世区块，生成区块1，确认区块1，生成区块2，确认区块2，...，生成区块n，确认区块n+1，生成区块n+2，确认区块n+2，生成区块n+3，确认区块n+3，生成区块n+4(即当前区块)。串行逻辑下，总是要等确认完上一区块，才能生成下一区块，区块产生效率和交易吞吐量有待提高。其中，交易吞吐量是指单位时间内区块链系统处理的交易数量。特别的，在一些联盟链中，如果经确认某一节点的第m号区块与其它节点的第m号区块不同，则该节点可能需要停止运行而由人工介入，这样会严重的影响区块链的效率。
30.在另一些实施例中，区块的生成和区块的确认可以按照并行逻辑进行。如图3所示，此时区块链包括已生成的n+1个已确认区块(创世区块至区块n)和3个已生成并待确认的区块(区块n+1至区块n+3)。可以理解，待确认区块是指未经(有待)各节点确认的区块，区块生成完毕后或生成完毕一段时间后可以被确定为待确认区块。相同或类似的概念已在图2的相关描述中介绍，这里不再赘述。
31.按照并行逻辑，节点在生成区块n+4的同时，可以并行的验证一个或多个待确认区块(如区块0、1、2，区块n+1、n+2)与其他节点保存的相同编号的区块是否一致。通过并行逻辑，可以解耦区块生成和区块确认过程，当前区块的生成不受限于上一区块的确认完毕，从而可以提高区块产生效率和交易吞吐量。
32.关于并行逻辑下区块生成和区块确认的更多细节，可以参考图4及其相关描述。
33.图4是根据本说明书一些实施例所示的区块链一致性处理方法的示例性流程图。如图4所示，该流程包括并行的区块生成过程和区块确认过程。图4中将区块信息做了简化，标识为其编号。
34.以一种采用pbft(practical byzantine fault tolerance，实用拜占庭容错算法)共识机制的联盟链为例，典型的，主节点可以分别进行交易打包、交易共识、交易执行和生成区块四个步骤，备份节点可以分别执行交易共识、交易执行和生成区块三个步骤。其中，主节点可以打包对应第m号区块的交易集合(其中包含了确定顺序的交易)。进而主节点可以发起交易共识，将该交易集合传播至备份节点。备份节点可以参与主节点发起的交易共识。经过共识后，主节点和备份节点中至少quorum数量的共识节点都可以确认待执行的交易集合，其中包含了确定的交易内容及顺序。接着，至少quorum数量的共识节点各自在本地分别按照顺序执行这个交易集合中包含的交易，并产生交易结果。最后，至少quorum数量的共识节点各自在本地分别根据交易结果产生并存储第m号区块，并将第m号区块顺序添加至区块链末尾(即置于第m
‑
1号区块之后)。生成的第m号区块可以包括区块头和区块体。其中，区块体可以包括交易集合、世界状态。区块头中可以包括区块号(这里例如为编号m)、时间戳、父hash、交易根、状态根等内容。交易根可以是区块体中的交易集合按照某一确定性规则组织成merkle树或mpt树之后的树根的hash值。状态根可以是节点执行区块体中的交易集合所产生的世界状态按照某一确定性规则组织成merkle树或mpt树之后的树根的hash值。在类似以太坊的联盟链中，世界状态一般可以包括外部账户的状态和合约账户的状态，其中包括交易执行后带来的状态的变化，例如balance、nonce的变化。合约账户的状态中，还可以包括状态根字段，用于存储该合约涉及的状态按照某一确定性规则组织成merkle树或mpt树之后的树根的hash值。此外，区块体还可以包括收据集合，相应地，区块头中可以包括收据根。所述收据根可以是区块体中的收据集合按照某一确定性规则组织成merkle树或mpt树之后的树根的hash值。
35.这样，各个节点可以在本地生成新的区块，沿用上一段中的例子，例如生成编号为m的最新区块。结合图3中所示，如前所述，此时的待确认区块包括n+1号区块、n+2号区块和n+3号区块，当前生成的区块为n+4号区块(也称为当前区块)。相应地，节点可生成当前区块并在该区块生成完毕后将该区块确定为待确认区块。
36.之所以限定为本节点与其它节点中共有至少quorum个一致的针对同一编号的已生成但未确认的区块的区块hash，且与本节点中同一编号的已生成但未确认的区块的区块hash一致，是因为可能这quorum数量以外的节点只是响应比较慢，因此所述quorum个节点可以继续后续区块的生成和确认过程。一旦某个节点确认本地生成的第m号区块与其它节点上生成的第m号区块不一致，则该节点可以执行回退操作。
37.在区块确认过程中，响应于设定条件达成，节点可确认一个或多个待确认区块。
38.在一些实施例中，所述预设条件可以包括待确认区块数量达到或超过预设数量，
相应地，节点可以确认所述预设数量的待确认区块。例如，如图4所示，所述预设数量可以是3，当待确认区块的数量达到3时，节点可以对这些待确认区块进行确认，直至确定问题区块或这3个待确认区块都通过确认。例如，如图4所示，节点依次确认区块0、1、2，且区块0、1、2均被确定为已确认区块。又如，如图4所示，节点依次确认区块n和区块n+1，其中区块n被确定为已确认区块，而区块n+1被确定为问题区块，故节点不再对区块n+2进行确认(虚线示意)。此外，也可以停止对n+3号区块的生成过程。显然的，及时停止对后续区块的生成过程，可以降低对系统资源的无谓消耗。
39.在一些实施例中，所述预设条件可以包括经过预设时间间隔，节点可以周期性地确认一个或多个待确认区块，直至确定问题区块或累积的待确认区块都通过确认。
40.参考前述内容，区块的确认是指本节点验证保存的某一区块与其他节点保存的位于区块链中同一位置的区块是否一致。若一致，则通过确认，否则未通过确认。
41.具体的，可以类似pbft中prepare(准备，简称为p消息)和commit(提交，简称为c消息)的过程，由各共识节点发送本地生成的第m号区块的区块hash。在一个至少包括3f+1个节点的区块链系统中(f为拜占庭容错数量，则需要满足至少2f+1个结果一致)，某一节点如果在有限时长内收集到至少2f+1个一致的关于第m号区块的区块hash时(包括该节点自己发出的关于区块m的区块hash和接收到的其它不同节点发出的针对区块m的区块hash)，可以确认该区块链系统中至少quorum个节点对第m号区块的区块hash达成了共识，因此可以完成对第m号区块的确认。反之，如果某一节点在有限时长内无法收集到至少2f+1个一致的关于第m号区块的区块hash时，可以确认该区块链系统中无法满足至少quorum个节点对第m号区块的区块hash达成共识，因此可以确认第m号区块为问题区块。
42.在另一个采用pbft共识算法的例子中，也可以是主节点在发起针对第m+3号区块对应交易集合的共识提议(pre
‑
prepare消息，预准备消息，也简称为pp消息)中携带生成的第m号区块的区块hash。这样，经过pbft的共识，至少quorum个节点对第m号区块的区块hash可以达成共识，因此可以完成对第m号区块的确认。类似的，如果某一节点在有限时长内无法收集到至少2f+1个一致的关于第m号区块的区块hash时，可以确认该区块链系统中无法满足至少quorum个节点对第m号区块的区块hash达成共识，因此可以确认第m号区块为问题区块。其中，主节点发起的pp消息中，可以是直接在pp消息中附加生成的第m号区块的区块hash，也可以是将第m号区块的hash与第m+3号区块对应交易集合的hash再次组合后计算得到hash值。通过上述各种方式，均可以最终确认该区块链系统中是否满足至少quorum个节点对第m号区块的区块hash达成共识，即是否为已确认区块或问题区块。
43.上述的quorum，意为法定大多数，其取值在不同共识算法中可以不相同。例如在pbft、hbbft(honeybadgerbft，蜜獾拜占庭容错算法)类共识算法中可以是2f+1(节点总数不少于3f+1)，在raft类共识算法中可以是f+1(节点总数不少于2f+1)，其中f为容错节点数量，等等。
44.需要注意的是，当要确认多个连续的区块时，节点可按顺序依次确认这些区块，这里的顺序可指区块的生成时间(如区块头中的时间戳)或区块编号。例如，如图4所示，节点可依次确认区块0、区块1和区块2，以及依次确认区块n、区块n+1和区块n+2。
45.如前所述，如果区块链网络中quorum个节点已确认第m号区块，而quorum数量以外的节点只是响应比较慢，因此所述quorum个节点可以继续后续区块的生成和确认过程。一
旦所述quorum个节点之外的某个节点后续跟上对第m号区块的确认过程，但确认结果是本地生成的第m号区块与其它节点上生成的第m号区块不一致，则该第m号区块即为问题区块，该节点可以执行回退操作。
46.前述的问题区块，可以是由于交易执行过程中由于虚拟机带来的执行结果的偶然性，合约版本差异带来的执行结果的偶然性，区块链平台代码带来的执行结果的偶然性，以及存储过程带来的偶然性等等导致的某一节点中生成的某一区块与其它节点中生成的相同位置的区块存在差异。这个差异可能包括交易集合的差异，世界状态的差异，收据集合的差异，区块头的差异等。这些差异都可能导致某一节点的区块头中的某一字段与其它节点的相同位置的区块的区块头对应字段的不一致，从而导致该节点的区块hash与其它节点的相同位置的区块的区块hash不一致(区块hash例如是按照确定性的hash算法对区块头中包含的各个字段的值顺序拼接后计算得到)。
47.按照待确认区块的顺序执行确认的过程中，当发现存在问题区块，例如对于任一区块确认为不一致，则可以终止对后续待确认区块的确认过程。类似的，及时终止对后续区块的确认过程，可以降低对系统资源的无谓消耗。如图4中所示，生成当前区块n+3的过程中，并行执行待确认区块n、n+1和n+2这3个区块的确认过程。例如节点确认本地生成的待确认区块n+1与其它节点的不一致，则可以终止对n+2号待确认区块的确认。这是因为，经确认节点本地生成的n+1号待确认区块与其它节点生成的n+1号区块不一致，而n+2号区块会链接到n+1号区块，即将n+1号区块的区块hash作为n+2号区块的区块头中父hash字段，则本地生成的n+2号区块的区块hash必然不会与其它节点生成的n+2号的区块hash相同，也就没有必要继续确认本地生成的n+2号区块的区块hash是否与其它节点一致。
48.此外，顺序确认当前区块之前连续的若干个已生成但未确认的区块的过程中，如果对于任一区块确认不一致，可以终止当前区块的生成。类似的，因为经确认节点本地生成的n+1号待确认区块与其它节点生成的n+1号区块不一致，而n+3号区块会通过n+2号区块链接到n+1号区块，即将n+1号区块的区块hash作为n+2号区块的区块头中父hash字段，n+2号区块的区块hash作为n+3号区块的区块头中父hash字段，则本地生成的n+3号区块的区块hash必然不会与其它节点生成的n+3号的区块hash相同，也就没有必要继续生成本地的n+3号区块，因此可以终止当前区块的生成。如前所述，及时终止对后续区块的生成过程，尤其是尽早终止对后续区块的生成过程，可以降低对系统资源的无谓消耗。
49.针对问题区块，可以执行回退操作，以保证节点本地的区块链与其它节点的一致。针对任一问题区块的回退操作完成后，可以从(首个)问题区块开始，重新顺序生成后续的区块。具体的，可以从当前区块开始回退，直至回退到(首个)问题区块之前的第一个区块的区块数据和状态数据(或还包括收据数据)，进而重新顺序生成后续的区块。对于按照区块号保存区块数据和状态数据(或还包括收据数据)的存储模式，也可以是丢弃(首个)问题区块及后续的所有区块，并从(首个)问题区块开始，重新顺序生成后续的区块。
50.在一些实施例中，可认为问题区块的产生(例如各节点获得不一致的交易执行结果)具备偶然性。换言之，通过重新执行问题区块中的所有交易，有较大可能避免问题区块的再次产生，因此基于(首个)问题区块中打包的交易可以生成第一区块中可保留该问题区块中的所有交易(即将问题区块恢复至执行前的状态)。
51.假设经前述描述的确认操作，区块链网络中的节点a确认本地生成的区块m与其它
节点生成的区块m不一致，而其它节点上生成的区块m是一致的。这样，节点a可以执行回退操作。所述回退操作完成之后，节点a可以从最后一个已确认区块开始重新生成区块，并在生成后续区块的过程中并行的确认已生成但未确认的区块。
52.如前所述，对于偶然性出现的区块不一致情况，通过重新执行生成区块的操作，一般可以克服，即一般重新生成的区块有较大概率会与其它节点生成的相同位置的区块一致。仍以上一段中的节点a为例，对于区块m，经过确认操作后，与其它区块链节点生成的区块m
′
并不一致。节点a可以重新执行区块m中的交易，生成区块m
″
。节点a之前就m区块与其它节点确认的过程中，可以获得其它节点生成的相同位置的区块m
′
的hash值。节点a重新生成的区块m
″
后，可以根据本次区块m
″
的hash值判断本次区块m
″
是否与其它节点生成的相同位置的区块m
′
是相同的区块。如果相同，即m
′
＝m
″
,则完成对重新生成的区块m
′
(即m
″
)的确认。
53.应当注意的是，上述有关流程的描述仅仅是为了示例和说明，而不限定本说明书的适用范围。对于本领域技术人员来说，在本说明书的指导下可以对流程进行各种修正和改变。然而，这些修正和改变仍在本说明书的范围之内。
54.图5是根据本说明书一些实施例所示的区块链节点的示例性模块(或称作单元)图。
55.如图5所示，区块链节点500可以包括区块生成单元510和区块确认单元520。其中：
56.区块生成单元510可以用于生成当前区块。
57.区块确认单元520可以用于执行待确认区块的确认。
58.区块生成单元510生成当前区块的过程中，区块确认单元520可以并行的执行待确认区块的确认过程。
59.其中，所述待确认区块可以包括所述当前区块之前连续的n个已生成但未确认的区块。所述n个已生成但未确认的区块为预定数量的已生成但未确认的区块，或预定时长内累积的已生成但未确认的区块。
60.所述执行待确认区块的确认过程可以包括：响应于设定条件的达成，依区块编号顺序确认本节点与其它节点中共有至少quorum个一致的针对同一编号的已生成但未确认的区块的区块hash，且与本节点中同一编号的已生成但未确认的区块的区块hash一致。
61.所述设定条件可以包括待确认区块的数量达到或超过预设数量，或待确认区块的生成时间达到预设时间长度。
62.所述执行待确认区块的确认过程可以包括：确认至少quorum个节点对待确认区块的区块hash达成一致；或，顺序确认当前区块之前连续的n个已生成但未确认的区块。
63.其中，顺序确认当前区块之前连续的n个已生成但未确认的区块的过程中，如果对于任一区块确认不一致，则终止确认过程和/或终止当前区块的生成。
64.其中，顺序确认当前区块之前连续的n个已生成但未确认的区块的过程中，如果对于任一区块确认不一致，执行回退操作。
65.其中，所述回退操作完成后，从首个确认不一致的区块开始重新顺序生成后续区块。
66.其中，所述回退操作可以包括：从当前区块开始回退，直至回退到问题区块之前的第一个区块的区块数据和状态数据；或，丢弃首个问题区块/问题区块及后续的所有区块。
67.其中，所述回退操作完成之后，从最后一个已确认区块开始重新生成区块，并在生成后续区块的过程中并行的确认已生成但未确认的区块。
68.关于区块链节点500及其模块的更多细节，可以参考图3和4及其相关描述。
69.应当理解，图5所示的系统及其模块可以利用各种方式来实现。例如，在一些实施例中，系统及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、cd或dvd
‑
rom的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本说明书的系统及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。
70.需要注意的是，以上对于系统及其模块的描述，仅为描述方便，并不能把本说明书限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。例如，在一些实施例中，区块生成单元510和/或区块确认单元520可以进一步划分为多个子模块。诸如此类的变形，均在本说明书的保护范围之内。
71.本技术还提供一种区块链节点实施例，其中，区块链节点可以包括处理器和存储有计算机指令的处理器，其中，在所述处理器执行所述计算机指令时，执行上述图4中的方法。
72.本技术还提供一种区块链系统实施例，该区块链系统包括若干各区块链节点。其中，各区块链节点在本地独立生成当前区块，并在生成当前区块的过程中，并行的执行待确认区块的确认过程。
73.所述确认过程可以包括：对于至少quorum个区块链节点来说，其中每一个都依本地区块编号顺序确认本节点与其它节点中共有至少quorum个一致的针对同一编号的已生成但未确认的区块的区块hash，且与本节点中同一编号的已生成但未确认的区块的区块hash一致。
74.本说明书实施例可能带来的有益效果包括但不限于：(1)提出了将区块分类为已确认区块和待确认区块以及将区块执行和区块确认并行化的区块链一致性处理方案，解耦区块执行和区块确认，有助于提高区块产生效率和交易吞吐量；(2)在确保区块链系统可靠性的前提下，降低对一致性的要求，对整个区块链系统的发展具有重大意义；(3)在区块回退的基础上，有利于各节点控制各自的区块执行节奏。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。
75.上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书实施例的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书实施例进行各种修改、改进和修正。该类修改、改进和修正在本说明书实施例中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。
76.同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。
77.此外，本领域技术人员可以理解，本说明书实施例的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本说明书实施例的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本说明书实施例的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。
78.计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、rf、或类似介质，或任何上述介质的组合。
79.本说明书实施例各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如java、scala、smalltalk、eiffel、jade、emerald、c++、c#、vb.net、python等，常规程序化编程语言如c语言、visualbasic、fortran2003、perl、cobol2002、php、abap，动态编程语言如python、ruby和groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或处理设备上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(lan)或广域网(wan)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(saas)。
80.此外，除非权利要求中明确说明，本说明书实施例所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书实施例流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的处理设备或移动设备上安装所描述的系统。
81.同理，应当注意的是，为了简化本说明书实施例披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书实施例对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。
82.针对本说明书引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本说明书作为参考。与本说明书内容不一致或产生冲突的申请历史文件除外，对本说明书权利要求最广范围有限制的文件(当前或之后附加于本说明书中的)也除外。需要说明的是，如果本说明书附属材料中的描述、定义、和/或术语的使用与本说明书所述内容有不一致或冲突的地方，以本说明书的描述、定义和/或术语的使用为准。
83.最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书实施例的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。