CN109697217B - 一种区块链事务处理方法 - Google Patents

Abstract

本发明提供一种区块链事务处理方法，能够解决非确定性代码的问题，提升效率，优化全网共识问题，还能够提高系统的整体灵活性，其处理方法大体步骤如下：客户端首先将事务进行打包和封装，发送至网络中的执行节点，由执行节点执行事务，并得到相应的结果返回给客户端。在收到足够的结果后，足够的结果判定取决于客户端提交的执行策略，客户端会将结果重新封装成待排序的数据结构，发送给网络中的排序节点进行排序。最后，经过排序的结果集将分发至网络中的各个其他节点进行确认，确认后的事务将会最终更新账本。

Description

一种区块链事务处理方法

技术领域

本发明涉及区块链事务处理领域，具体而言，涉及一种利用“执行-排序-验证”步骤的区块链事务处理方法。

背景技术

在目前的大部分区块链平台中，对于事务的执行往往都是利用共识协议先对其进行排序，然后在区块链网络中的其他节点按照相同的顺序进行执行。例如，在以太坊中，其目前使用的是基于PoW的共识协议。节点首先会组装一个包含有合法事务的块，接着节点会试图计算一个PoW难题，当某个节点P1成功计算出结果后，它就会将这个块广播至全网。所有接收到该块的节点都会去验证这个结果和重复执行一次块中的所有事务。

“排序-执行”从架构上来看非常简单，因此也被广泛应用于各大区块链平台中。但是，在某些场景中，例如带权限认证的区块链网络中，“排序-执行”的方式还是存在一些缺点。

首先，在所有节点上顺序执行事务会降低区块链整体的TPS(每秒传输的事物处理个数)。因为TPS与系统延迟成反比，这将会成为整个区块链网络的性能瓶颈。另一方面，DoS攻击也会严重降低这种区块链的性能，当有恶意的“智能合约”被部署时，由于无法停止，也可能会带来很严重的后果。为了解决无限循环的“智能合约”问题，以太坊才引入了“gas”的概念，但同时也增加了额外的费用开销。

其次，所有在共识后的操作执行必须是确定性的，否则就会导致账本的“分叉”。这通常通过面向特定领域的编程语言来解决，例如以太坊的Solidity。但这样的语言在设计上往往都是非常复杂的。

发明内容

本发明的目的在于提供一种区块链事务处理方法，其能够解决非确定性代码的问题，提升效率，优化全网共识问题，并且还能够提高系统的整体灵活性。

本发明的实施例是这样实现的：

一种区块链事务处理方法，该区块链事务处理方法包括如下步骤：

S1：客户端向执行节点提交事务，事务经过打包和封装后发送至网络中的执行节点，客户端在所述事务打包时产生一个执行策略；

S2：执行节点执行智能合约并反馈结果至客户端；

S3：使用排序节点为事务进行排序并将事务分发网络，客户端在收到一定量的结果时，客户端将结果重新封装成待排序的数据结构，并将数据结构发送至网络中的排序节点进行排序；排序节点为一组节点共同组成的集群，排序节点之间具有同步共识机制；

S4：将区块分发至各个Peer节点，排序节点将经过排序的结果分发至网络中的各个Peer节点进行确认，确认后的事务形成最终更新账本。

在本发明的较佳实施例中，上述S1的操作方法如下：

S11：客户端对事务进行标记，用于在事务执行过程中验证来源的准确性；

S12:形成执行策略，客户端在事务打包时产生一个执行策略，执行策略中预设有结果有效值区间，返回结果值符合结果有效值区间时，则事务提交有效；返回结果值不符合结果有效值区间，则事务提交无效；

在本发明的较佳实施例中，上述S11的具体操作如下：客户端对事务进行标记，标记内容包括对事务的签名和事务对应执行策略的权限证明；若智能合约的操作仅为账本查询，则在打包过程中剔除智能合约。

在本发明的较佳实施例中，上述S12的具体操作如下：客户端在打包事务时即生成一个执行策略，执行策略用于指定网络中的特定节点执行对应的事务，并且收集结果；当执行策略收集的结果值时，其中一部分节点都返回结果并且一部分结果相同时，此次事务提交判定为有效；否则，此次事务提交判定为无效，并将此次无效事务抛弃，或者将无效事务标记为“非确定结果”等待后续处理。

在本发明的较佳实施例中，上述S2的操作方法如下：

S21：执行节点验证有效提交的事务，确认有效后执行节点执行事务；

S22：执行节点封装执行后的结果形成结果集并响应：在结果集上签名后，执行节点将结果集反馈至客户端；

S23：客户端验证结果集的有效性并执行有效结果集。

在本发明的较佳实施例中，上述S23的具体操作步骤如下：客户端接收到结果集响应后对结果集进行验证，证明结果集来自正确的执行节点，并开始检查执行策略和收到的各个执行节点反馈的结果集，当结果集满足执行策略时，表示客户端认可执行结果；否则客户端将剔除该次交易并在稍后再次尝试验证。

在本发明的较佳实施例中，上述S3的操作方法如下：

S31：客户端收集到一定量的结果集后，将事务重新打包，并将打包的事务发送至排序节点；

S32：排序节点将交易打包至区块；区块在交付时采用gossip协议作为底层协议。

在本发明的较佳实施例中，上述S31中的发送内容包括事务数据和执行数据。

在本发明的较佳实施例中，上述S4的操作方法如下：

S41：排序节点将区块交付给各个Peer节点，Peer节点在接收到区块后对区块中智能合约的执行策略进行验证和评估，若事务不符合执行策略，则事务标记为无效，结果忽略；

S42：Peer节点判断每个事务的版本号信息，若事务的版本号和Peer中的预置版本号不匹配时，事务被标记为无效，结果忽略；

S43：经过版本号核实后，Peer节点更新本地账本。

在本发明的较佳实施例中，上述S41中的排序节点将区块交付给各个Peer节点，交付包括如下交付方式：直接交付或者gossip交付。

本发明实施例的有益效果是：1.提升效率：基于“执行-排序-验证”的架构可以提高区块链网络的整体TPS，且“执行”和“排序”并不需要全网的所有节点都参与执行，而只需要一部分“代表”来做这些事情，这在很大程度上也优化了全网共识问题；2.解决了“非确定性代码”问题：在本发明中使用“执行策略”来对执行结果进行筛选，并在排序阶段仅需要对排序节点之间达成共识即可。且“智能合约”只会在“执行”阶段执行一次，在“验证”阶段通过后将结果直接更新至账本中，这也提升了整体的执行效率；3.应用与协议的信任分离：本发明通过“执行策略”将应用间信任与协议间信任分离开来，这很大程度的提高了系统的整体灵活性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明实施例的“执行-排序-验证”方法的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

第一实施例

本实施例提供一种区块链事务处理方法，其大体操作如下：客户端首先将事务进行打包和封装，发送至网络中的执行节点，由执行节点执行事务，并得到相应的结果返回给客户端。在收到足够的结果后，足够结果的判断取决于客户端提交的执行策略，客户端会将结果重新封装成待排序的数据结构，发送给网络中的排序节点进行排序。最后，经过排序的结果集将分发至网络中的各个其他节点进行确认，确认后的事务将会最终更新账本。

本专利主要分为4个阶段来实现，整体结构示意图如图1所示：

S1：客户端向执行节点提交事务：

S12：客户端在将事务打包时会生产一个“执行策略”，该执行策略主要指定了网络中哪些节点需要执行这些事务，以及对结果的收集策略。比如策略指定了至少要等到一部分节点都返回结果，并且至少有多少结果相同时，这次事务提交才会被确认为有效。否则，本次事务提交会被抛弃，作为一种优化，这里也可以将无效的事务标记成“非确定性结果”以待后续处理。

S12：在提交事务和“执行策略”前，客户端会将该信息进行签名，并附上自己的权限证明，以便在后续执行过程中验证来源正确性。通常情况下，如果“智能合约”中的操作仅仅是对账本的查询，那么这次事务将不会被重新打包提交到“排序”节点中。

S2：:执行节点执行智能合约，并反馈结果：

S21：:执行节点(Execute Peer，以下简称EP)在收到客户端提交的事务和策略后，首先对其签名和权限进行验证，以确定这是一个合法的提交。随后EP开始对这些智能合约进行预执行。注意，这里所有的EP之前并没有进行同步，且EP的结果不会在这里更新本地账本。

S22：执行完成后EP将结果封装成结果集响应，并对该结果集进行签名。随后将结果集反馈给客户端。

S23：客户端接收到结果响应后对结果集进行验证，证明其来自正确的EP。并开始检查“执行策略”和收集到的各个EP反馈的结果集，当这些结果集满足“执行策略”时，则表示客户端认可该执行结果。否则客户端将会抛弃这个交易并在稍后再次尝试。这个过程需要客户端和EP之间的频繁交互。

S3：使用“排序节点”为事务进行排序并分发：

S31：当客户端收集到足够多的结果集后，会将事务重新打包，发送至排序节点(Ordering Peer，以下简称OP)，发送内容会包含事务数据和执行数据等信息。OP通常是由一组节点共同组成的集群，且他们之间需要有同步共识机制。

S32：OP会将交易打包至区块中。OP会保证即将交付的区块都是被排过序的，考虑到区块链网络中可能包含有大量的普通节点和少部分的OP，本发明使用gossip协议来作为区块交付时的底层依赖。

S4：将区块分发到各个Peer：

S41：OP将区块直接交付给Peer，或者通过gossip的方式交付。Peer在接收到区块后首先会对区块中智能合约的执行策略进行验证和评估。如果不满足执行策略，则事务被标记为无效，其结果也将被忽略。

S42：随后Peer将会对每个事务的版本号信息进行判断，如果事务的版本号与Peer中存储的当前版本号不匹配，则该事务会被标记为无效，其结果将被忽略。

S43：上述步骤通过后，Peer即开始更新本地账本。一般来讲，当将区块添加到账本中时，前两个步骤中有效性检查的结果也会被持久化。这样做对以后的重建和追溯是有好处的。

综上所述，本发明与现有技术和模式相比，最主要有如下优点：

1.提升效率：基于“执行-排序-验证”的架构可以提高区块链网络的整体TPS，且“执行”和“排序”并不需要全网的所有节点都参与执行，而只需要一部分“代表”来做这些事情，这在很大程度上也优化了全网共识问题。

2.“非确定性代码”问题：在传统的区块链平台例如以太坊中，为了消除非确定性带来的共识影响，采取了一些诸如消费gas、设计确定性语言Solidity等手段来规避。在本发明中使用“执行策略”来对执行结果进行筛选，并在排序阶段仅需要对排序节点之间达成共识即可。且“智能合约”只会在“执行”阶段执行一次，在“验证”阶段通过后将结果直接更新至账本中，这也提升了整体的执行效率。

3.应用与协议的信任分离：大多数被许可的区块链依赖于异步BFT复制协议来建立共识。相同的对等节点也经常执行应用程序，尽管实际上可以将BFT的执行限制在更少的对等点上。然而，这种信任假设，无论节点在系统中的角色如何，都可能与“智能合约”执行所需的信任不匹配。本发明通过“执行策略”将应用间信任与协议间信任分离开来，这很大程度的提高了系统的整体灵活性。

本说明书描述了本发明的实施例的示例，并不意味着这些实施例说明并描述了本发明的所有可能形式。应理解，说明书中的实施例可以多种替代形式实施。附图无需按比例绘制；可放大或缩小一些特征以显示特定部件的细节。公开的具体结构和功能细节不应当作限定解释，仅仅是教导本领域技术人员以多种形式实施本发明的代表性基础。本领域内的技术人员应理解，参考任一附图说明和描述的多个特征可以与一个或多个其它附图中说明的特征组合以形成未明确说明或描述的实施例。说明的组合特征提供用于典型应用的代表实施例。然而，与本发明的教导一致的特征的多种组合和变型可以根据需要用于特定应用或实施。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种区块链事务处理方法，其特征在于，所述区块链事务处理方法包括如下步骤：

S1：客户端向执行节点提交事务，所述事务经过打包和封装后发送至网络中的执行节点，所述客户端在所述事务打包时产生一个执行策略；

S2：执行节点执行智能合约并反馈结果至所述客户端；

S3：使用排序节点为所述事务进行排序并将所述事务分发网络，所述客户端在收到一定量的所述结果时，所述客户端将所述结果重新封装成待排序的数据结构，并将所述数据结构发送至所述网络中的所述排序节点进行排序；所述排序节点为一组节点共同组成的集群，所述排序节点之间具有同步共识机制；

S4：将区块分发至各个Peer节点，所述排序节点将经过排序的结果分发至所述网络中的各个Peer节点进行确认，确认后的所述事务形成最终更新账本；

所述S1的操作方法如下：

S11：所述客户端对事务进行标记，用于在事务执行过程中验证来源的准确性；

S12:形成执行策略，所述执行策略中预设有结果有效值区间，返回结果值符合所述结果有效值区间时，则所述事务提交有效；返回结果值不符合所述结果有效值区间，则所述事务提交无效。

2.根据权利要求1所述区块链事务处理方法，其特征在于，所述S11的具体操作如下：所述客户端对事务进行标记，所述标记内容包括对所述事务的签名和所述事务对应执行策略的权限证明；若所述智能合约的操作仅为账本查询，则在打包过程中剔除所述智能合约。

3.根据权利要求2所述区块链事务处理方法，其特征在于，所述S12的具体操作如下：客户端在打包事务时即生成一个执行策略，所述执行策略用于指定网络中的特定节点执行对应的事务，并且收集结果；当执行策略收集的结果值时，其中一部分节点都返回结果并且一部分结果相同时，此次事务提交判定为有效；否则，此次事务提交判定为无效，并将此次无效事务抛弃，或者将所述无效事务标记为“非确定结果”等待后续处理。

4.根据权利要求1所述区块链事务处理方法，其特征在于，所述S2的操作方法如下：

S21：执行节点验证有效提交的事务，确认有效后所述执行节点执行所述事务；

S22：执行节点封装执行后的结果形成结果集并响应：在所述结果集上签名后，所述执行节点将所述结果集反馈至客户端；

S23：客户端验证结果集的有效性并执行有效结果集。

5.根据权利要求4所述区块链事务处理方法，其特征在于，所述S23的具体操作步骤如下：客户端接收到结果集响应后对所述结果集进行验证，证明所述结果集来自正确的执行节点，并开始检查执行策略和收到的各个执行节点反馈的结果集，当结果集满足所述执行策略时，表示客户端认可执行结果；否则客户端将剔除此次交易并在稍后再次尝试验证。

6.根据权利要求1所述区块链事务处理方法，其特征在于，所述S3的操作方法如下：

S31：客户端收集到一定量的结果集后，将所述事务重新打包，并将打包的事务发送至排序节点；

S32：所述排序节点将交易打包至区块；所述区块在交付时采用gossip协议作为底层协议。

7.根据权利要求6所述区块链事务处理方法，其特征在于，所述S31中的发送内容包括事务数据和执行数据。

8.根据权利要求1所述区块链事务处理方法，其特征在于，所述S4的操作方法如下：

S41：排序节点将区块交付给各个Peer节点，Peer节点在接收到区块后对区块中智能合约的执行策略进行验证和评估，若事务不符合执行策略，则所述事务标记为无效，所述结果忽略；

S42：Peer节点判断每个事务的版本号信息，若事务的版本号和Peer中的预置版本号不匹配时，所述事务被标记为无效，所述结果忽略；

S43：经过所述版本号核实后，Peer节点更新本地账本。

9.根据权利要求8所述区块链事务处理方法，其特征在于，所述S41中的排序节点将区块交付给各个Peer节点，所述交付包括如下交付方式：直接交付或者gossip交付。

Images