CN113973064A - 一种基于区块链的稳定性测试方法及系统 - Google Patents

Abstract

本申请提供一种基于区块链的稳定性测试方法及系统，方法包括：构造每一笔交易参数及原始交易体，并将交易参数和原始交易体发送至代理节点；对接收到的交易参数及原始交易体重新计算哈希值并签名得到签名交易体；按照交易顺序将多个签名交易体依次转发到区块链系统各个节点上；接收交易请求和数据查询请求，按照预设的区块链共识程序执行交易请求和数据查询请求，将执行结果返回给代理节点；在稳定性测试结束后将执行结果反馈给客户端；控制对应的非代理节点程序的启停，模拟拜占庭节点的产生以达到覆盖区块链系统共识拜占庭容错的测试场景的目的。本申请既能满足覆盖多个复杂测试场景需求，又便于测试人员直观地判断区块链系统稳定性的测试结果。

Description

一种基于区块链的稳定性测试方法及系统

技术领域

本申请涉及区块链技术领域，尤其涉及一种基于区块链的稳定性测试方法及系统。

背景技术

现有的区块链稳定性测试只是性能测试的一种，即在较低的负载下（TPS设定为峰值性能的10% - 80%），持续往区块链系统中发送恒定的交易数，并运行一段比较长的时间（通常是24小时），通过收集并分析区块链各节点的日志和服务器资源占用情况，人工衡量区块链系统的稳定性。目前国内权威的区块链测评机构中国信通院发布的区块链测试标准涵盖了功能、性能、安全、密码、存证应用、政务应用等多个类型，但是在区块链的稳定性方面缺少系统的测试规范和标准。

由于区块链交易的特性，每一笔交易需要经过交易hash和数字签名的双重认证通过后才能被视作有效交易，而每一笔交易hash本来是在客户端每次调用服务时根据区块链系统特定的hash算法生成，这使得目前区块链稳定性的测试过程中需要将所有待执行的交易hash提前算出来并存储在服务器的内存中，这种方法一是比较耗费时间，二是当服务器重启或者交易参数发生变化之后需要重新计算一遍交易hash，并再次更新到服务器内存中。

而且，目前区块链的稳定性测试场景比较单一，仅仅是测试区块链系统在持续交易情况下的稳定性，对于区块链系统的其他应用场景没有完整覆盖，例如共识的拜占庭容错、链上数据（包括账本数据、区块数据）查询等常见场景，这与实际的区块系统应用场景存在较大偏差，使得区块链稳定性测试缺乏普遍适应性。

发明内容

本申请提供一种基于区块链的稳定性测试方法及系统，以解决目前区块链稳定性测试缺乏普遍适应性的问题。

第一方面，本申请提供了一种基于区块链的稳定性测试系统，一种基于区块链的稳定性测试系统，包括客户端、代理节点、非代理节点以及非代理控制节点，其中：

客户端被配置为执行下述步骤：

构造每一笔交易参数及原始交易体，并将交易参数和原始交易体发送至代理节点；

代理节点被配置为执行下述步骤：

对接收到的交易参数及原始交易体重新计算哈希值并签名，得到签名交易体；

按照交易顺序将多个签名交易体依次转发到区块链系统的各个节点上；签名交易体包括交易请求和数据查询请求；

非代理节点被配置为执行下述步骤：

接收交易请求和数据查询请求，并按照预设的区块链共识程序执行交易请求和数据查询请求，以及，将执行结果返回给代理节点；

代理节点进一步被配置为执行下述步骤：

在稳定性测试结束后将执行结果反馈给客户端；

每个非代理节点对应一个非代理控制节点，非代理控制节点被配置为执行下述步骤：

控制对应的非代理节点程序的启停，模拟拜占庭节点的产生，以达到覆盖区块链系统共识拜占庭容错的测试场景的目的。

进一步地，客户端进一步被配置为执行下述步骤：

将交易参数以参数化的变量文件形成存储，使用测试脚本逐个读取变量文件中预设好的参数值，并将交易参数拼装成JSON格式的原始交易体发送至代理节点，以减少交易参数构造的难度。

进一步地，交易请求是通过拼凑得到的，数据查询请求是在区块链上预先设置的。

进一步地，代理节点进一步被配置为执行下述步骤：将一个链上的交易请求和数据查询请求一起转发到区块链的其他节点上，以达到覆盖链上数据查询测试场景的目的。

进一步地，代理节点进一步被配置为执行下述步骤：收集交易请求和数据查询请求的执行结果，以及，在稳定性测试结束后，汇总所有执行结果并反馈给客户端。

进一步地，根据拜占庭共识机制理论，当满足预设条件时，区块链系统中的节点执行共识机制及执行签名交易体，预设条件根据区块链系统中的节点总数和拜占庭节点数预先设定。

进一步地，执行结果包括交易请求成功率和数据查询请求成功率。

进一步地，交易请求成功率是通过如下方式计算出来的：交易请求成功率=交易执行成功数量/交易请求总数量*100%；

数据查询请求成功率是通过如下方式计算出来的：数据查询请求成功率=查询请求成功数量/查询请求总数量*100%。

进一步地，非代理控制节点进一步被配置为执行下述步骤：

在稳定性测试过程中，自动采集区块链节点日志和节点服务器的资源占用情况，当节点日志中抛出异常或者节点服务器资源占用超过预设的阈值时，自动告警。

第二方面，本申请提供了一种基于区块链的稳定性测试方法，一种基于区块链的稳定性测试方法，包括：

构造每一笔交易参数及原始交易体，并将交易参数和原始交易体发送至代理节点；

对接收到的交易参数及原始交易体重新计算哈希值并签名，得到签名交易体；按照交易顺序将多个签名交易体依次转发到区块链系统的各个节点上；签名交易体包括交易请求和数据查询请求；

接收交易请求和数据查询请求，并按照预设的区块链共识程序执行交易请求和数据查询请求，以及，将执行结果返回给代理节点；

在稳定性测试结束后将执行结果反馈给客户端；

控制对应的非代理节点程序的启停，模拟拜占庭节点的产生，以达到覆盖区块链系统共识拜占庭容错的测试场景的目的。

由以上技术方案可知，本申请提供一种基于区块链的稳定性测试方法及系统，方法包括：构造每一笔交易参数及原始交易体，并将交易参数和原始交易体发送至代理节点；对接收到的交易参数及原始交易体重新计算哈希值并签名，得到签名交易体；按照交易顺序将多个签名交易体依次转发到区块链系统的各个节点上；签名交易体包括交易请求和数据查询请求；接收交易请求和数据查询请求，并按照预设的区块链共识程序执行交易请求和数据查询请求，以及，将执行结果返回给代理节点；在稳定性测试结束后将执行结果反馈给客户端；控制对应的非代理节点程序的启停，模拟拜占庭节点的产生，以达到覆盖区块链系统共识拜占庭容错的测试场景的目的。本申请实施例的稳定性测试方法既能满足覆盖多个复杂测试场景的要求，又便于测试人员直观地判断区块链系统稳定性的测试结果。

附图说明

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

图1为本申请实施例提供的一种基于区块链的稳定性测试方法流程示意图；

图2为本申请实施例提供的一种基于区块链的稳定性测试系统结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。以下结合附图，详细说明本申请各实施例提供的技术方案。

目前区块链的稳定性测试场景比较单一，仅仅是测试区块链系统在持续交易情况下的稳定性，对于区块链系统的其他应用场景没有完整覆盖，例如共识的拜占庭容错、链上数据（包括账本数据、区块数据）查询等常见场景，这与实际的区块系统应用场景存在较大偏差，使得区块链稳定性测试缺乏普遍适应性。

基于上述问题，本申请提供一种基于区块链的稳定性测试方法及系统，包括持续交易、链上数据查询、共识容错等多种混合应用场景的稳定性测试，更贴合区块链的实际业务应用场景，使得区块链稳定性测试更具普遍适用性。

图1为本申请实施例提供的一种基于区块链的稳定性测试方法流程示意图，如图1所示，一种基于区块链的稳定性测试方法，包括以下步骤S1- S5：

S1:构造每一笔交易参数及原始交易体，并将交易参数和原始交易体发送至代理节点；

在本申请实施例中，主要涉及到4个执行主体，分别为客户端、代理节点、非代理节点以及非代理控制节点。步骤S1由客户端来执行，客户端负责构造每一笔交易参数及原始交易体，并将交易参数和原始交易体发送至代理节点。

在一些实施例中，原始交易体可以是客户端最初构建的原始交易本身，客户端负责构造每一笔交易的参数和原始交易体，为了减少交易参数构造的难度，客户端还被配置为执行下述步骤：将交易参数以参数化的变量文件形成存储，使用测试脚本逐个读取变量文件中预设好的参数值，并将交易参数拼装成JSON格式的原始交易体发送至代理节点，以减少交易参数构造的难度。

具体地，客户端可以将需要构造的交易参数（例如转账交易中的转账发起账户、转账接收账户、转账金额）以参数化的变量文件形式存储，然后使用测试脚本逐个读取变量文件中预设好的参数值，将交易参数拼装成JSON格式的交易体，然后发送至代理节点。

客户端将交易参数和原始交易体发送至代理节点之后，可以继续执行如下步骤：

S2:对接收到的交易参数及原始交易体重新计算哈希值并签名，得到签名交易体；按照交易顺序将多个签名交易体依次转发到区块链系统的各个节点上；签名交易体包括交易请求和数据查询请求；

代理节点对接收到的交易参数及原始交易体重新计算哈希值并签名，得到签名交易体后，按照交易顺序将多个签名交易体依次转发到区块链系统的各个节点上。由于代理节点的本质上就是区块链系统众多节点中的一个，那么其计算的交易哈希值和签名自然会被其他节点认可。

在一些实施例中，签名交易体包括交易请求和数据查询请求，其中，交易请求可以是通过拼凑得到的，数据查询请求可以是在区块链上预先设置的。代理节点按照交易顺序将多个签名交易体依次转发到区块链系统的各个节点上，在这个过程中，代理节点也会将预置好的链上数据查询请求同交易请求一并转发到这些节点上，或者说，代理节点将拼凑好的交易请求和链上数据查询请求一并转发到非代理节点上。这样，代理节点转发的交易请求必然会因被其他节点视为合法的交易请求而顺利执行。同时，代理节点还会将一个链上的交易请求和数据查询请求一起转发到区块链的其他节点上，以达到覆盖链上数据查询测试场景的目的。

在稳定性测试期间，代理节点进一步被配置为执行下述步骤：收集交易请求和数据查询请求的执行结果，以及，在稳定性测试结束后，汇总所有执行结果并反馈给客户端。

具体地，在稳定性测试期间，代理节点还会收集交易请求和数据查询请求的执行结果并在测试结束后汇总所有执行结果发回给客户端。汇总后的执行结果包括交易请求成功率和数据查询请求成功率。即，代理节点还可以收集这些请求的结果并统计区块链系统交易执行的成功率和链上数据查询的成功率，在测试结束后发回给客户端。

其中，交易请求成功率是通过如下方式计算出来的：交易请求成功率=交易执行成功数量/交易请求总数量*100%；数据查询请求成功率是通过如下方式计算出来的：数据查询请求成功率=查询请求成功数量/查询请求总数量*100%。

在步骤S2中，代理节点按照交易顺序将多个签名交易体依次转发到区块链系统的各个节点上后，可以继续执行如下步骤：

S3:接收交易请求和数据查询请求，并按照预设的区块链共识程序执行交易请求和数据查询请求，以及，将执行结果返回给代理节点；

非代理节点负责接收由代理节点转发过来的交易请求和数据查询请求，并按照原有区块链的共识程序执行这两个请求，并将执行结果返回给代理节点。本申请实施例中，非代理节点是指区块链系统中除代理节点外的其他节点。在稳定性测试过程中，非代理节点可以实时或者阶段性将交易请求和数据查询请求的执行结果返回给代理节点，也可以是根据需要选择异步地将经过各节点共识后的执行结果返回给代理节点，具体申请不做限定。优选地，本申请选择异步反馈的方式，这样，代理节点即收到了反馈结果，同时又不影响链上的交易及处理效率。这里的执行结果可以是阶段性执行结果，也可以是最终的执行结果。

S4:在稳定性测试结束后将执行结果反馈给客户端；

非代理节点根据共识逻辑执行签名交易体并将交易执行结果和数据查询结果返回给代理节点后，代理节点在稳定性测试结束后将结果汇总发回给客户端，以使客户端及时获取到执行结果。这里的执行结果可以为最终的执行结果。

S5:控制对应的非代理节点程序的启停，模拟拜占庭节点的产生，以达到覆盖区块链系统共识拜占庭容错的测试场景的目的。

每个非代理节点对应一个非代理控制节点，非代理控制节点的作用为，负责直接控制对应的非代理节点程序的启停，通过非代理控制节点控制非代理节点的节点程序启停的方式，模拟拜占庭节点的产生，达到覆盖区块链共识拜占庭容错的测试场景。

具体地，在稳定性测试期间，非代理控制节点还可以通过启停对应的非代理节点程序，以模拟故障节点，也称之为“拜占庭节点”的产生。根据拜占庭共识机制理论，当满足预设条件时，区块链系统中的节点执行共识机制及执行签名交易体，预设条件根据区块链系统中的节点总数和拜占庭节点数预先设定。例如，一种方式可以为，根据拜占庭共识机制理论，当满足n≥3f+1（n为区块链系统节点总数，f为拜占庭节点数）的条件时，区块链系统中的节点仍能正常达成共识并执行交易。

此外，非代理控制节点进一步被配置为执行下述步骤：在稳定性测试过程中，自动采集区块链节点日志和节点服务器的资源占用情况，当节点日志中抛出异常或者节点服务器资源占用超过预设的阈值时，自动告警。

在稳定性测试过程中，非代理控制节点还可以自动采集区块链节点日志和节点服务器的资源占用情况，一旦节点日志中抛出异常或者节点服务器资源占用超过预设的阈值，就会自动上报告警，测试人员只需依据稳定性测试期间产生的告警信息，就可以直接判断区块链系统的稳定性。

由以上技术方案可知，本申请提供一种基于区块链的稳定性测试方法，包括：构造每一笔交易参数及原始交易体，并将交易参数和原始交易体发送至代理节点；对接收到的交易参数及原始交易体重新计算哈希值并签名，得到签名交易体；按照交易顺序将多个签名交易体依次转发到区块链系统的各个节点上；签名交易体包括交易请求和数据查询请求；接收交易请求和数据查询请求，并按照预设的区块链共识程序执行交易请求和数据查询请求，以及，将执行结果返回给代理节点；在稳定性测试结束后将执行结果反馈给客户端；控制对应的非代理节点程序的启停，模拟拜占庭节点的产生，以达到覆盖区块链系统共识拜占庭容错的测试场景的目的。本申请实施例的稳定性测试方法既能满足覆盖多个复杂测试场景的要求，又便于测试人员直观地判断区块链系统稳定性的测试结果。

另外，基于上述区块链的稳定性测试方法，本申请还提供一种基于区块链的稳定性测试系统，图2为本申请实施例提供的一种基于区块链的稳定性测试系统结构示意图，如图2所示，一种基于区块链的稳定性测试系统包括客户端、代理节点、非代理节点以及非代理控制节点，其中：

客户端被配置为执行下述步骤：构造每一笔交易参数及原始交易体，并将交易参数和原始交易体发送至代理节点；

代理节点被配置为执行下述步骤：对接收到的交易参数及原始交易体重新计算哈希值并签名，得到签名交易体；按照交易顺序将多个签名交易体依次转发到区块链系统的各个节点上；签名交易体包括交易请求和数据查询请求；

非代理节点被配置为执行下述步骤：接收交易请求和数据查询请求，并按照预设的区块链共识程序执行交易请求和数据查询请求，以及，将执行结果返回给代理节点；

代理节点进一步被配置为执行下述步骤：在稳定性测试结束后将执行结果反馈给客户端；

每个非代理节点对应一个非代理控制节点，非代理控制节点被配置为执行下述步骤：控制对应的非代理节点程序的启停，模拟拜占庭节点的产生，以达到覆盖区块链系统共识拜占庭容错的测试场景的目的。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (10)

1.一种基于区块链的稳定性测试方法，其特征在于，包括：

构造每一笔交易参数及原始交易体，并将所述交易参数和所述原始交易体发送至代理节点；

对接收到的所述交易参数及所述原始交易体重新计算哈希值并签名，得到签名交易体；按照交易顺序将多个所述签名交易体依次转发到区块链系统的各个节点上；所述签名交易体包括交易请求和数据查询请求；

接收所述交易请求和所述数据查询请求，并按照预设的区块链共识程序执行所述交易请求和所述数据查询请求，以及，将执行结果返回给所述代理节点；

在稳定性测试结束后将所述执行结果反馈给所述客户端；

控制对应的所述非代理节点程序的启停，模拟拜占庭节点的产生，以达到覆盖区块链系统共识拜占庭容错的测试场景的目的。

2.根据权利要求1所述的基于区块链的稳定性测试方法，其特征在于，还包括：

将所述交易参数以参数化的变量文件形成存储，使用测试脚本逐个读取所述变量文件中预设好的参数值，并将所述交易参数拼装成JSON格式的原始交易体发送至所述代理节点，以减少所述交易参数构造的难度。

3.根据权利要求1所述的基于区块链的稳定性测试方法，其特征在于，所述交易请求是通过拼凑得到的，所述数据查询请求是在区块链上预先设置的。

4.根据权利要求1所述的基于区块链的稳定性测试方法，其特征在于，还包括：将一个链上的所述交易请求和所述数据查询请求一起转发到区块链的其他节点上，以达到覆盖链上数据查询测试场景的目的。

5.根据权利要求1所述的基于区块链的稳定性测试方法，其特征在于，还包括：收集所述交易请求和所述数据查询请求的执行结果，以及，在稳定性测试结束后，汇总所有所述执行结果并反馈给所述客户端。

6.根据权利要求1所述的基于区块链的稳定性测试方法，其特征在于，根据拜占庭共识机制理论，当满足预设条件时，区块链系统中的节点执行共识机制及执行所述签名交易体，所述预设条件根据区块链系统中的节点总数和拜占庭节点数预先设定。

7.根据权利要求1所述的基于区块链的稳定性测试方法，其特征在于，所述执行结果包括交易请求成功率和数据查询请求成功率。

8.根据权利要求7所述的基于区块链的稳定性测试方法，其特征在于，

所述交易请求成功率是通过如下方式计算出来的：交易请求成功率=交易执行成功数量/交易请求总数量*100%；

所述数据查询请求成功率是通过如下方式计算出来的：数据查询请求成功率=查询请求成功数量/查询请求总数量*100%。

9.根据权利要求1所述的基于区块链的稳定性测试方法，其特征在于，还包括：

在稳定性测试过程中，自动采集区块链节点日志和节点服务器的资源占用情况，当节点日志中抛出异常或者节点服务器资源占用超过预设的阈值时，自动告警。

10.一种基于区块链的稳定性测试系统，其特征在于，包括客户端、代理节点、非代理节点以及非代理控制节点，其中：

客户端被配置为执行下述步骤：

构造每一笔交易参数及原始交易体，并将所述交易参数和所述原始交易体发送至代理节点；

所述代理节点被配置为执行下述步骤：

对接收到的所述交易参数及所述原始交易体重新计算哈希值并签名，得到签名交易体；

按照交易顺序将多个所述签名交易体依次转发到区块链系统的各个节点上；所述签名交易体包括交易请求和数据查询请求；

非代理节点被配置为执行下述步骤：

接收所述交易请求和所述数据查询请求，并按照预设的区块链共识程序执行所述交易请求和所述数据查询请求，以及，将执行结果返回给所述代理节点；

所述代理节点进一步被配置为执行下述步骤：

在稳定性测试结束后将所述执行结果反馈给所述客户端；

每个所述非代理节点对应一个非代理控制节点，所述非代理控制节点被配置为执行下述步骤：

控制对应的所述非代理节点程序的启停，模拟拜占庭节点的产生，以达到覆盖区块链系统共识拜占庭容错的测试场景的目的。

Images