CN114338673A - 一种交易数据处理方法、装置、设备、系统及存储介质 - Google Patents

Abstract

本申请公开了一种交易数据处理方法、装置、设备、系统及存储介质，涉及区块链技术领域，以提高交易数据处理速度。该方法包括：获取目标交易数据组；将所述目标交易数据组打包成区块；所述区块的父哈希为当前区块高度中至少两个区块的哈希；对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。本申请实施例可以提高交易数据处理速度。

Description

一种交易数据处理方法、装置、设备、系统及存储介质

技术领域

本申请涉及区块链技术领域，尤其涉及一种交易数据处理方法、装置、设备、系统及存储介质。

背景技术

区块链技术在各个领域得到了广泛的应用。现有技术中，无论是联盟链还是公链，由于共识速度的限制影响了交易的处理速度。

发明内容

本申请实施例提供一种交易数据处理方法、装置、设备、系统及存储介质，以提高交易数据处理速度。

第一方面，本申请实施例提供了一种交易数据处理方法，应用于区块链的出块节点；包括：

获取目标交易数据组；

将所述目标交易数据组打包成区块；所述区块的父哈希为当前区块高度中至少两个区块的哈希；

对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

第二方面，本申请实施例还提供一种交易数据处理方法，应用于区块链；包括：

获取待交易数据；

将所述待交易数据分配到交易数据组；

多个出块节点将所述交易数据组打包成区块；所述区块的父哈希为当前区块高度中至少两个区块的哈希；

对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

第三方面，本申请实施例还提供一种交易数据处理装置，应用于区块链的出块节点；包括：

第一获取模块，用于获取目标交易数据组；

第一打包模块，用于将所述目标交易数据组打包成区块；所述区块的父哈希为当前区块高度中至少两个区块的哈希；

第一存储模块，用于对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

第四方面，本申请实施例还提供一种交易数据处理装置，应用于区块链，其中，所述区块链的至少一个视图下包括多个出块节点；包括：

第一获取模块，用于获取待交易数据；

第一分配模块，用于将所述待交易数据分配到交易数据组；

第一打包模块，用于通过多个出块节点将所述交易数据组打包成区块；所述区块的父哈希为当前区块高度中至少两个区块的哈希；

第一存储模块，用于当对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

第五方面，本申请实施例还提供一种电子设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的程序，所述处理器执行所述程序时实现如上所述的交易数据处理方法中的步骤。

第六方面，本申请实施例还提供一种可读存储介质，所述可读存储介质上存储程序，所述程序被处理器执行时实现如上所述的交易数据处理方法中的步骤。

第七方面，本申请实施例还提供一种存证系统，包括：第一存证系统，区块链，以及第二存证系统；所述区块链包括多个节点；

其中，所述第一存证系统，用于对待存证数据进行安全处理，并将安全处理后的待存证数据发送到所述区块链上；

所述区块链，用于将所述安全处理后的待存证数据进行分组，得到多个数据组，并将形成的数据组打包成区块，所述区块的父哈希为当前区块高度中至少两个区块的哈希；对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块；

所述第二存证系统，用于对所述区块链中的数据进行安全处理，并将安全处理后的数据发送到所述区块链上。

在本申请实施例中，由于至少一个视图下包括多个出块节点，因此，多个出块节点可基于获得的目标交易数据组进行打包区块处理，并在当前视图的共识节点间执行共识流程，并在达成共识时，存储区块。由于所述区块的父哈希为当前区块高度中至少两个区块的哈希，多个出块节点可分别处理目标交易数据组并打包区块和进行共识，因此，相较于现有技术中只有一个出块节点进行共识的方式，利用本申请实施例的方案，可提高共识速度，从而也提高了交易数据处理速度。

附图说明

图1是本申请实施例提供的交易数据处理方法的流程图之一；

图2是本申请实施例中的共识流程的示意图；

图3是本申请实施例的树形存储结构的示意图；

图4是本申请实施例的存证系统的应用架构图；

图5是本申请实施例提供的交易数据处理方法的流程图之二；

图6是本申请实施例提供的交易数据处理方法的流程图之三；

图7是本申请实施例提供的交易数据处理装置的结构图之一；

图8是本申请实施例提供的交易数据处理装置的结构图之二。

具体实施方式

本申请实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

本申请实施例中术语“多个”是指两个或两个以上，其它量词与之类似。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，并不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

现有技术中，由于在当前视图下只有一个出块节点进行区块打包和共识流程，因此，其共识速度较慢，从而也影响了对交易的处理速度。基于此，本申请提出了一种交易数据处理方法。在本申请实施例的方法中，在当前视图下，可由多个出块节点共同进行区块打包和共识处理，因而，提高了共识速度，也提高了交易数据处理速度。其中，所述交易可以理解为包括数据。

首先，先对区块链的相关信息做一简单介绍。

区块链上的节点类型包括：

Leader/Primary:出块节点，负责将交易打包成区块和区块共识；

Replica:副本节点，负责区块共识，每轮共识过程中有多个Replica节点；

Observer:观察者节点，负责从共识节点或副本节点获取最新区块，执行并验证区块执行结果后，将产生的区块上链。

其中，Leader和Replica统称为共识节点，Leader可称为出块节点。

PBFT(Practical Byzantine Fault Tolerance，实用拜占庭容错算法)采用签名、签名验证、哈希等密码学算法确保消息传递过程中的防篡改性、防伪造性、不可抵赖性，将拜占庭容错算法复杂度从指数级降低到多项式级别。在给算法中，在一个由(3*f+1)个节点构成的系统中，只要有不少于(2*f+1)个非恶意节点正常工作，该系统就能达成一致性，如：7个节点的系统中允许2个节点出现拜占庭错误。其中，f表示允许出错的节点的个数。

PBFT共识算法使用视图(view)记录每个节点的共识状态，相同视图维护相同的Leader和Replicas节点列表。当Leader出现故障，会发生视图切换，若视图切换成功(至少2*f+1个节点达到相同视图)，则根据新的视图选出新的Leader，新Leader开始出块；否则继续进行视图切换，直至全网大部分节点(大于等于2*f+1)达到一致视图。

为了防止节点作恶，PBFT共识过程中，每个共识节点均对其发送的消息进行签名，对收到的消息包进行验签名，因此每个节点均维护一份公私钥对，私钥用于对发送的消息进行签名，公钥作为节点ID，用于标识和验签。考虑到节点ID很长，引入了节点索引，每个共识节点维护一份公共的共识节点列表，其中，节点索引记录了每个共识节点ID在这个列表中的位置。在共识节点发送网络消息包时，只需要带上节点索引，其他节点即可以从公共的共识节点列表中索引出节点的ID，进而对消息进行验签。

参见图1，图1是本申请实施例提供的交易数据处理方法的流程图，应用于区块链的出块节点；其中，至少一个视图下包括多个出块节点。需要说明的是，在此，仅以某个出块节点的角度描述本申请实施例的实现过程，对于其他出块节点，其处理方式相同。在同一视图下，可能存在多个出块节点同时进行以下处理。如图1所示，包括以下步骤：

步骤101、获取目标交易数据组。

在本申请实施例中，将待处理交易数据划分到不同的交易数据组，从而便于不同的出块节点获取不同的交易数据组，以进行后续处理，从而提高打包区块和共识速度。其中，所述目标交易数据组指的是的当前出块节点处理的交易数据组。

在本申请实施例中，可按照如下方式将待交易数据分配到对应的交易数据组中：

首先，确定交易数据的分组数，其中，所述分组数根据下一区块高度对应的树宽确定。然后，将待交易数据分配到对应的交易数据组中，其中，所述交易数据组的编号根据所述待交易数据的ID和所述下一区块高度对应的树宽确定。

具体的，区块是按时间次序构建的数据结构，区块链的第一个区块称为“创世块”，后续生成的区块用“高度”标识，每个区块高度逐一递增，新区块都会引入前一高度区块的hash(哈希)信息，再用hash算法和本区块的数据生成唯一的数据指纹，从而形成环环相扣的块链状结构，称为“Blockchain”也即区块链。

基于以上描述，当前区块高度指的是当前视图对应的区块高度，下一区块高度指的是当前区块高度之后生成的下一区块的高度。其中，不同区块高度对应的树宽可根据需要设置。树宽可以理解为，下一区块高度中包括的区块的个数。在本申请实施例中，可将下一区块高度对应的树宽的取值作为交易数据的分组数(也即分组数等于树宽)，从而可保证不同的交易数据组都能打包形成区块。

在将待交易数据分配到对应的交易数据组中时，按照如下方式确定交易数据组的编号，也即需要将待交易数据分配到哪个交易数据组中：

txidseq＝txid％treewidthsize+1

其中，txidseq表示交易数据组的编号，txid表示所述待交易数据的ID，treewidthsize表示下一区块高度对应的树宽。

在将待交易数据分配到不同的交易数据组之后，各个节点即可获得相应的目标交易数据组。在本申请实施例中，根据预设规则，确定当前出块节点的目标交易数组。例如，任意选择交易数据作为目标交易数组，按照索引依次选择目标交易数组等。无论采用哪种方式，只要保证不同的交易数据组有出块节点进行处理即可。

对于区块链中的多个节点，需确定出共识节点和出块节点。其中，确定共识节点的方式和现有技术的相同。当前视图中的每个节点根据如下方式计算出索引，如果索引和自身的索引相同，那么即可确定自身为出块节点。其中，当前视图中的每个出块节点的索引按照如下方式确定：

获取索引计算参数，所述索引计算参数包括下一区块高度对应的树宽、当前视图的编号、当前区块高度以及当前视图中的共识节点的个数，之后，根据所述索引计算参数，确定当前视图中的每个出块节点的索引。

具体的，可利用以下公式，根据所述索引计算参数，确定当前视图中的每个出块节点的索引：

leader_idxs＝(view+block_number+i)％node_num

其中，leader_idxs表示出块节点的索引，view表示当前视图的编号，block_number表示当前区块高度，treewidthsize表示下一区块高度对应的树宽，node_num表示当前视图中的共识节点的个数，i为参数，1≤i≤treewidthsize，且i为整数。以下一区块高度对应的树宽为3为例，i的取值分别为1，2，3。

在具体应用中，首先生成交易。将交易池待上链交易(即待处理交易数据)根据树宽进行分组，得到交易数据组。每个交易数据组的编号按照前述描述的方式确定。接着，找到区块链的所有叶子节点，获取当前叶子节点(当前视图下当前区块高度的区块)的下一个区块高度的树宽度treewidthsize，并确定当前视图中具有树宽度个出块节点。

假设，有4个共识节点，view＝1(view从1开始，每次视图切换+1，每次共识节点变更，发生视图切换)，当前区块高度block_number＝99，树宽度为3，下一区块高度为100(block_number)时：

出块节点的索引分别为：(1+100+1)％4＝2，(1+100+2)％4＝3，(1+100+3)％4＝4。

基于此，可得到如表1所示的对应关系：

表1

基于以上表格，节点索引分别为2，3，4的出块节点处理txidseq分别为1，2，3的交易数据组。

步骤102、将所述目标交易数据组打包成区块。

在此步骤中，首先生成空区块。然后，将所述目标交易数据组插入到所述空区块中，之后，根据插入有目标交易数据组的空区块形成准备Prepare包，并向所述当前视图中的共识节点广播所述Prepare包。

其中，所述区块的父哈希为当前区块高度中至少两个区块的哈希。可选的，所述区块的父哈希为当前区块高度中全部区块的哈希。例如，当前区块高度中有3个区块，那么，新生成的空区块的父哈希为该3个区块的哈希。通过这种方式，由于新区块的父哈希为当前区块高度中每个区块的哈希，因此，在后续进行共识流程时，一个共识节点可同时对多个共识节点提供的信息进行验证，从而提高了共识的速度。

以步骤101中的例子为例，在进行出块时，判断三个交易数据组中是否至少有一条以上的交易。若满足该条件，则节点索引分别为2、3、4的节点从交易缓存池中获取分组后的交易(编号2的leader获取编号为1的交易数据分组，编号3的leader获取编号为2的交易数据分组，编号4的节点获取编号为3的交易数据分组)进行出块。否则，节点可暂停、等待，直到三个交易数据组中至少有一条以上的交易。其中，出块的每个区块中的父哈希包括当前区块高度block_number＝99的每个区块的哈希。例如，假设当前区块高度block_number＝99有三个区块，那么，出块的每个区块中的父哈希包括该三个区块的每个区块的哈希。

在本申请实施例中，父哈希采用string数组的形式，以存储多个哈希。

步骤103、对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

在此步骤中，各共识节点基于各出块节点形成的区块在当前视图中的共识节点间执行共识流程，对每个区块进行共识的原理相同。

PBFT的共识流程主要包括三个阶段：pre-prepare(预准备)阶段、Prepare(准备)阶段和Commit(承诺)阶段。在此步骤中，基于形成的区块在所述共识节点间依次执行上述三个阶段。

其中，Pre-prepare阶段：负责执行区块，产生签名包，并将签名包广播给所有共识节点；Prepare阶段：负责收集签名包，某共识节点收集满2*f+1个签名包后，表明自身达到可以提交区块的状态，开始广播Commit包；Commit阶段：负责收集Commit包，某共识节点收集满2*f+1个Commit包后，直接将本地缓存的最新区块提交到数据库。

在本申请实施例中，对上述共识流程进行改进。图2所示为本申请实施例中的共识流程的示意图。结合图2，详细描述一下共识的具体流程。为每个出块节点定义编号leaderseq，例如，从1开始，最大的编号等于树宽treewidthsize。共识流程由共识节点执行，出块节点是共识节点中的一部分，所以，以下共识流程也适用于出块节点。图2中以node0、node1作为其中的一个出块节点为例。

(1)，所述pre-prepare阶段，包括：

接收其他共识节点发送的Prepare包。共识节点可向其他共识节点分别广播Prepare包。

对所述Prepare包进行验证，其中，所述验证包括对所述Prepare包中的父哈希的验证。由于Prepare包中的父哈希为当前区块高度中的多个区块的哈希，因此，在此步骤中需要对每个哈希进行校验。只有校验全部通过时，才确定对Prepare包的验证通过。

在所述Prepare包的通过验证的情况下，若所述Prepare包中的交易数据为0，则触发视图切换；若所述Prepare包中的交易数据不为0，则执行所述Prepare包中的交易数据，并根据执行结果产生签名包，向其他共识节点广播所述签名包，所述签名包的父哈希为当前区块高度中每个区块的哈希。

以上面的例子为例，各共识节点校验Prepare包中的交易是否正常，如果均正常，向其他所有节点发送自己的签名包。此过程中，共识节点不校验自己出块的Prepare包，即：索引为1的节点要校验3个Prepare包，其他只需要校验2个Prepare包。

(2)，所述Prepare阶段，包括：

接收其他共识节点发送的签名包。共识节点可向其他共识节点分别广播签名包。

对所述签名包进行验证，其中，所述验证包括对所述签名包中的父哈希的验证。由于签名包中的父哈希为当前区块高度中的多个区块的哈希，因此，在此步骤中需要对每个哈希进行校验。只有校验全部通过时，才确定对签名包的验证通过。

当通过验证的签名包的数量满足预设要求时，广播Commit包。

其中，所述预设要求是签名包的数量达到2*f+1。由于每个节点的签名包的数量满足2*f+1，因此，所有共识节点的签名包的数量满足(2*f+1)*n)，n表示共识节点的个数。联盟链中，如果一到多个节点对签名包的校验不通过，则不进行Commit包的广播，直至超时，当前共识节点不再作为共识节点，发生视图切换，启动新一轮共识机制。

(3)，所述Commit阶段，包括：

接收其他共识节点发送的Commit包。共识节点可向其他共识节点分别广播Commit包。

对所述Commit包进行验证，其中，所述验证包括对所述Commit包中的父哈希的验证。由于Commit包中的父哈希为当前区块高度中的多个区块的哈希，因此，在此步骤中需要对每个哈希进行校验。只有校验全部通过时，才确定对Commit包的验证通过。

在通过验证的Commit包的数量满足预设要求的情况下，将所述区块落盘，也即，直接将本地缓存的区块提交到数据库。

其中，所述预设要求是Commit包的数量达到2*f+1。由于每个节点的Commit包的数量满足2*f+1，因此，所有共识节点的Commit包的数量满足(2*f+1)*n)，n表示共识节点的个数。

当PBFT三阶段共识超时或节点收到空块时，会试图切换到更高的视图，并触发视图切换(ViewChange)处理流程；节点收到视图切换(ViewChange)包时，也会触发ViewChange处理流程。

当共识流程的结果表明共识节点间达成共识时，存储形成的区块。

在本申请实施例中，形成的区块按照树形结构存储。如图3所示，不同的区块高度可包括一个或者多个区块，下一区块高度的每个区块的父哈希是前一区块高度的每个区块的哈希。

在本申请实施例中，由于至少一个视图下包括多个出块节点，因此，多个出块节点可基于获得的目标交易数据组进行打包区块处理，并在当前视图的共识节点间执行共识流程，并在达成共识时，存储区块。由于所述区块的父哈希为当前区块高度中至少两个区块的哈希，多个出块节点可分别处理目标交易数据组并打包区块和进行共识，因此，相较于现有技术中只有一个出块节点进行共识的方式，利用本申请实施例的方案，可提高共识速度，从而也提高了提高交易数据处理速度，同时也能降低打包延迟。

本申请实施例的方案可应用于区块链技术中，如数据库写数据操作等。

如图4所示，为本申请实施例所应用的架构图，包括：第一存证系统(App)401；第二存证系统(App’)402；区块链403，包括多个Baas(Blockchain as service，区块链即服务节点)节点(Node1、Node2、Node3、Node4……)。

其中，所述第一存证系统401，用于对待存证数据进行安全处理，并将安全处理后的待存证数据发送到所述区块链上；

所述区块链403，用于将所述安全处理后的待存证数据进行分组，得到多个数据组，并将形成的数据组打包成区块，所述区块的父哈希为当前区块高度中至少两个区块的哈希；对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块；

所述第二存证系统402，用于对所述区块链中的数据进行安全处理，并将安全处理后的数据发送到所述区块链上。

其中，所述区块链进行共识的过程可参照前述对共识过程的描述。在第一存证系统、第二存证系统中所进行的安全处理包括对数据进行签名、验证等。

在实际应用中，该存证系统还可包括多个第二存证系统。通过各个存证系统之间对区块链上的数据的安全处理，可保证区块链上存储的数据的安全性。

如图5所示，为在图4所示的架构中进行交易数据处理的流程图。如图5所示，包括：

步骤501，待存证的数据发送请求到第一存证系统(App)。

步骤502，第一存证系统(App)对待存证的数据进行安全处理。

例如，所述第一存证系统可使用消息摘要算法生产数据摘要，并使用自己的私钥进行签名。在安全处理完成之后，将摘要和签名的待存证数据发送到区块链上。

步骤503，区块链上的多个区块链节点组成联盟链，接收上链请求，全网广播交易。根据前述的共识流程进行打包上链，生成新的区块。

步骤504，第二存证系统(App’)监听区块生成事件，并订阅合约Event(事件)。当产生新存证Event时，第二存证系统发起请求，从区块链获取上链数据(如存证摘要信息)，进行签名后将签名数据发送到区块链上。

第二存证系统存储到区块链上的数据，可由区块链重复前述的共识流程，进而完成存证数据处理。

在上述过程中，由于共识流程中有多个出块节点进行出块，因此，可使得出块的速度加快，共识流程也相应的加快。相应的，也能够提高交易数据处理速度。

参见图6，图6是本申请实施例提供的交易数据处理方法的流程图，应用于区块链，其中，所述区块链的至少一个视图下包括多个出块节点。如图6所示，包括以下步骤：

步骤601、获取待交易数据。

用户的请求发送到客户端后，客户端会构建出有效的待交易数据。之后，客户端对其进行处理后发送至区块链。相应的，区块链获取该待交易数据。

步骤602、将所述待交易数据分配到交易数据组。

在此步骤中，确定交易数据的分组数，其中，所述分组数根据下一区块高度对应的树宽确定，并将待交易数据分配到对应的交易数据组中，其中，所述交易数据组的编号根据所述待交易数据的ID和所述下一区块高度对应的树宽确定。

步骤603、多个出块节点将所述交易数据组打包成区块。

生成空区块，其中，所述空区块的父哈希为当前区块高度中每个区块的哈希，然后将所述交易数据组插入到所述空区块中。根据插入有交易数据组的空区块形成准备Prepare包，并向所述当前视图中的共识节点广播所述Prepare包。其中，所述区块的父哈希为当前区块高度中至少两个区块的哈希。

步骤604、对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

其中，上述过程中的共识流程以及存储区块的过程可参照前述实施例的描述。

在本申请实施例中，由于至少一个视图下包括多个出块节点，因此，多个出块节点可基于获得的目标交易数据组进行打包区块处理，并在当前视图的共识节点间执行共识流程，并在达成共识时，存储区块。由于所述区块的父哈希为当前区块高度中至少两个区块的哈希，多个出块节点可分别处理目标交易数据组并打包区块和进行共识，因此，相较于现有技术中只有一个出块节点进行共识的方式，利用本申请实施例的方案，可提高共识速度，从而也提高了提高交易数据处理速度，同时也能降低打包延迟。

本申请实施例还提供了一种交易数据处理装置，应用于区块链的出块节点；其中，至少一个视图下包括多个出块节点。如图7所示，交易数据处理装置700包括：

第一获取模块701，用于获取目标交易数据组；第一打包模块702，用于将所述目标交易数据组打包成区块；所述区块的父哈希为当前区块高度中至少两个区块的哈希；第一存储模块703，用于对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

可选的，当前视图中的每个出块节点的索引按照如下方式确定：

获取索引计算参数，所述索引计算参数包括下一区块高度对应的树宽、当前视图的编号、当前区块高度以及当前视图中的共识节点的个数；

根据所述索引计算参数，确定当前视图中的每个出块节点的索引。

可选的，利用以下公式，根据所述索引计算参数，确定当前视图中的每个出块节点的索引：

leader_idxs＝(view+block_number+i)％node_num

其中，leader_idxs表示出块节点的索引，view表示当前视图的编号，block_number表示当前区块高度，treewidthsize表示下一区块高度对应的树宽，node_num表示当前视图中的共识节点的个数，i为参数，1≤i≤treewidthsize，且i为整数。

可选的，所述装置还可包括：

确定模块，用于确定交易数据的分组数，其中，所述分组数根据下一区块高度对应的树宽确定；

分配模块，用于将待交易数据分配到对应的交易数据组中，其中，所述交易数据组的编号根据所述待交易数据的ID和所述下一区块高度对应的树宽确定；

所述第一获取模块601，用于根据预设规则，从所述交易数据组中选择所述目标交易数据组。

可选的，所述第一打包模块602包括：

生成子模块，用于生成空区块，其中，所述空区块的父哈希为当前区块高度中每个区块的哈希；

数据处理子模块，用于将所述目标交易数据组插入到所述空区块中；

广播子模块，用于根据插入有目标交易数据组的空区块形成准备Prepare包，并向所述当前视图中的共识节点广播所述Prepare包。

可选的，所述共识流程包括：pre-prepare阶段、Prepare阶段和承诺Commit阶段。

可选的，所述pre-prepare阶段，包括：

接收其他共识节点发送的Prepare包；

对所述Prepare包进行验证，其中，所述验证包括对所述Prepare包中的父哈希的验证；

在所述Prepare包的通过验证的情况下，若所述Prepare包中的交易数据为0，则触发视图切换；若所述Prepare包中的交易数据不为0，则执行所述Prepare包中的交易数据，并根据执行结果产生签名包，向其他共识节点广播所述签名包，所述签名包的父哈希为当前区块高度中每个区块的哈希。

可选的，所述Prepare阶段，包括：

接收其他共识节点发送的签名包；

对所述签名包进行验证，其中，所述验证包括对所述签名包中的父哈希的验证；

在通过验证的签名包的数量满足预设要求的情况下，广播Commit包。

可选的，所述Commit阶段，包括：

接收其他共识节点发送的Commit包；

对所述Commit包进行验证，其中，所述验证包括对所述Commit包中的父哈希的验证；

在通过验证的Commit包的数量满足预设要求的情况下，将所述区块落盘。

本申请实施例提供的装置，可以执行上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

本申请实施例还提供了一种交易数据处理装置，应用于区块链，其中，所述区块链的至少一个视图下包括多个出块节点。如图8所示，交易数据处理装置800包括：

第一获取模块801，用于获取待交易数据；第一分配模块802，用于将所述待交易数据分配到交易数据组；第一打包模块803，用于通过多个出块节点将所述交易数据组打包成区块；所述区块的父哈希为当前区块高度中至少两个区块的哈希；第一存储模块804，用于对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

可选的，所述第一分配模块包括：

确定子模块，用于确定交易数据的分组数，其中，所述分组数根据下一区块高度对应的树宽确定；

分配子模块，用于将待交易数据分配到对应的交易数据组中，其中，所述交易数据组的编号根据所述待交易数据的ID和所述下一区块高度对应的树宽确定。

可选的，所述第一打包模块包括：

生成子模块，用于生成空区块，其中，所述空区块的父哈希为当前区块高度中每个区块的哈希；

数据处理子模块，用于将所述目标交易数据组插入到所述空区块中；

广播子模块，用于根据插入有目标交易数据组的空区块形成准备Prepare包，并向所述当前视图中的共识节点广播所述Prepare包。

本申请实施例提供的装置，可以执行上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例提供了一种电子设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的程序；所述处理器，用于读取存储器中的程序实现如前所述的交易数据处理方法中的步骤。

本申请实施例还提供一种可读存储介质，可读存储介质上存储有程序，该程序被处理器执行时实现上述交易数据处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的可读存储介质，可以是处理器能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。根据这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁盘、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (17)

1.一种交易数据处理方法，应用于区块链的出块节点，其特征在于，包括：

获取目标交易数据组；

将所述目标交易数据组打包成区块，所述区块的父哈希为当前区块高度中至少两个区块的哈希；

对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

2.根据权利要求1所述的方法，其特征在于，当前视图中的每个出块节点的索引按照如下方式确定：

获取索引计算参数，所述索引计算参数包括下一区块高度对应的树宽、当前视图的编号、当前区块高度以及当前视图中的共识节点的个数；

根据所述索引计算参数，确定当前视图中的每个出块节点的索引。

3.根据权利要求2所述的方法，其特征在于，利用以下公式，根据所述索引计算参数，确定当前视图中的每个出块节点的索引：

leader_idxs＝(view+block_number+i)％node_num

其中，leader_idxs表示出块节点的索引，view表示当前视图的编号，block_number表示当前区块高度，treewidthsize表示下一区块高度对应的树宽，node_num表示当前视图中的共识节点的个数，i为参数，1≤i≤treewidthsize，且i为整数。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

确定交易数据的分组数，其中，所述分组数根据下一区块高度对应的树宽确定；

将待交易数据分配到对应的交易数据组中，其中，所述交易数据组的编号根据所述待交易数据的ID和所述下一区块高度对应的树宽确定；

所述获取目标交易数据组，包括：

根据预设规则，从所述交易数据组中选择所述目标交易数据组。

5.根据权利要求1所述的方法，其特征在于，所述将所述目标交易数据组打包成区块，包括：

生成空区块，其中，所述空区块的父哈希为当前区块高度中每个区块的哈希；

将所述目标交易数据组插入到所述空区块中；

根据插入有目标交易数据组的空区块形成准备Prepare包，并向所述当前视图中的共识节点广播所述Prepare包。

6.根据权利要求5所述的方法，其特征在于，所述共识流程，包括：

预准备pre-prepare阶段、准备Prepare阶段和承诺Commit阶段。

7.根据权利要求6所述的方法，其特征在于，所述pre-prepare阶段，包括：

接收其他共识节点发送的Prepare包；

对所述Prepare包进行验证，其中，所述验证包括对所述Prepare包中的父哈希的验证；

在所述Prepare包的通过验证的情况下，若所述Prepare包中的交易数据为0，则触发视图切换；若所述Prepare包中的交易数据不为0，则执行所述Prepare包中的交易数据，并根据执行结果产生签名包，向其他共识节点广播所述签名包，所述签名包的父哈希为当前区块高度中每个区块的哈希。

8.根据权利要求6所述的方法，其特征在于，所述Prepare阶段，包括：

接收其他共识节点发送的签名包；

对所述签名包进行验证，其中，所述验证包括对所述签名包中的父哈希的验证；

在通过验证的签名包的数量满足预设要求的情况下，广播Commit包。

9.根据权利要求6所述的方法，其特征在于，所述Commit阶段，包括：

接收其他共识节点发送的Commit包；

对所述Commit包进行验证，其中，所述验证包括对所述Commit包中的父哈希的验证；

在通过验证的Commit包的数量满足预设要求的情况下，将所述区块落盘。

10.一种交易数据处理方法，应用于区块链，其特征在于，包括：

获取待交易数据；

将所述待交易数据分配到交易数据组；

多个出块节点将所述交易数据组打包成区块，所述区块的父哈希为当前区块高度中至少两个区块的哈希；

对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

11.根据权利要求10所述的方法，其特征在于，所述将所述待交易数据分配到交易数据组，包括：

确定交易数据的分组数，其中，所述分组数根据下一区块高度对应的树宽确定；

将待交易数据分配到对应的交易数据组中，其中，所述交易数据组的编号根据所述待交易数据的ID和所述下一区块高度对应的树宽确定。

12.根据权利要求10所述的方法，其特征在于，所述将所述交易数据组打包成区块，包括：

生成空区块，其中，所述空区块的父哈希为当前区块高度中每个区块的哈希；

将所述交易数据组插入到所述空区块中；

根据插入有交易数据组的空区块形成准备Prepare包，并向所述当前视图中的共识节点广播所述Prepare包。

13.一种交易数据处理装置，应用于区块链的出块节点；其特征在于，包括：

第一获取模块，用于获取目标交易数据组；

第一打包模块，用于将所述目标交易数据组打包成区块，所述区块的父哈希为当前区块高度中至少两个区块的哈希；

第一存储模块，用于对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

14.一种交易数据处理装置，应用于区块链；其特征在于，包括：

第一获取模块，用于获取待交易数据；

第一分配模块，用于将所述待交易数据分配到交易数据组；

第一打包模块，用于通过多个出块节点将所述交易数据组打包成区块，所述区块的父哈希为当前区块高度中至少两个区块的哈希；

第一存储模块，用于对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块。

15.一种电子设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的程序；其特征在于，所述处理器，用于读取存储器中的程序实现如权利要求1至12中任一项所述的交易数据处理方法中的步骤。

16.一种可读存储介质，用于存储程序，其特征在于，所述程序被处理器执行时实现如权利要求1至12中任一项所述的交易数据处理方法中的步骤。

17.一种存证系统，其特征在于，包括：第一存证系统，区块链，以及第二存证系统，所述区块链包括多个节点；

所述第一存证系统，用于对待存证数据进行安全处理，并将安全处理后的待存证数据发送到所述区块链上；

所述区块链，用于将所述安全处理后的待存证数据进行分组，得到多个数据组，并将形成的数据组打包成区块，所述区块的父哈希为当前区块高度中至少两个区块的哈希；对于当前视图，若所述当前视图中的共识节点通过共识流程对所述区块达成共识，则存储所述区块；

所述第二存证系统，用于对所述区块链中的数据进行安全处理，并将安全处理后的数据发送到所述区块链上。

Images