CN115081022A - 一种面向大宗商品交易场景的区块链性能优化方法及系统 - Google Patents

Abstract

本发明提供了一种面向大宗商品交易场景的区块链性能优化方法及系统，其中，面向大宗商品交易场景的区块链性能优化方法，该方法应用在大宗商品交易场景，包括：利用外部链码技术为每一背书节点构建多个链码容器；在背书节点接收到交易提案的情况下，将交易提案中的多笔交易分别分发至多个链码容器，以使得多个链码容器并行执行多笔交易，其中，所述交易提案为大宗商品交易环节中生成。本发明能够提升背书阶段性能、吞吐量和灵活性，从而解决在大宗商品交易场景下，使用区块链进行交易存证时，因区块链技术原理导致的性能低下的问题。

Description

一种面向大宗商品交易场景的区块链性能优化方法及系统

技术领域

本发明属于区块链技术领域，具体涉及一种面向大宗商品交易场景的区块链性能优化方法及系统。

背景技术

过去十几年，为满足国内建设热潮，中国对大宗商品和原材料的进口增长了数倍，中国也早已成为全球第一大大宗商品的进口国和消费国。除了原油之外，其他类大宗商品的消费量，中国几乎均位居全球第一的位置。仓单是大宗商品流通的重要工具。我国商品现货长期以来资产缺乏真实性、安全性和流动性保障，仓单多以场外非标形式存在，在交易、仓储、交收等流转环节中无法达到金融机构的风控要求。市场主体准入资格难以把控、交易过程信息不完全可信、传统监管手段难以监控市场交易风险等是制约当前大宗商品交易市场发展的根本原因。

构建基于区块链的大宗商品数字化生态能推动我国大宗商品市场更好发展。利用区块链技术，可以解决大宗商品交易环节不透明、仓储物流环节信息不准确等问题。区块链与交易平台深度融合已是行业当下重点研究课题，区块链技术的成熟应用必将为行业发展带来新动能，实现平台全产业链服务的提质增效，创新产品与服务新模式。引入防篡改、可追溯、抗抵赖的区块链系统来对交易平台进行交易凭据存证。利用区块链系统，可以使得入链后的交易证据不可抵赖，不可篡改，能够追踪溯源之外，还能通过一定的机制确保入链前的数据的真实有效性，从而形成一个公正、可信、具有权威性的第三方存证体系，为未来可能发生的交易争端提供可靠的取证渠道。

现有的区块链技术中，Hyperledger Fabric是开源的，企业级的，带权限的联盟链。它的设计初衷就是针对企业级应用的，针对市面上流行的其他分布式账本系统或者区块链平台，Hyperledger Fabric拥有很多不同的特点和应用领域。Hyperledger Fabric很适用于大宗商品交易的场景，然而即使Fabric是开源区块链系统中吞吐量最高的系统之一，其性能距工业级应用场景需求仍有差距，Fabric系统性能优化研究有极强的应用价值和现实意义。

具体地，Fabric完成一笔交易时包括如下流程：客户端构造交易提案，发送给一个或多个Peer节点，交易提案中包含本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等。Peer节点收到交易提案后，会模拟执行交易，然后将原始交易提案和执行结果打包到一起，进行签名并发回给客户端，其中在模拟执行交易期间产生的数据修改不会写到账本和世界状态数据库中。客户端收到各个Peer的应答后，将一批应答打包到一起组成一个交易并签名，发送给Orderer节点。Orderer节点对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，发送给负责验证的Peer节点。验证节点会对收到的交易进行读写集验证，交易验证通过后会被更新到区块账本和世界状态数据库中，验证节点返回成功的状态给客户端。在Fabric的检查、验证提案、模拟交易执行、签名提案等背书阶段的各个环节中，模拟交易执行环节耗时最长，该环节的核心是容器执行链码。然而，现有技术因考虑了读写冲突问题，限制每个节点只启动一个背书服务和一个执行模拟交易的链码容器，导致该环节执行效率低下。对Fabric单笔交易耗时分析的过程中发现，背书过程中链码执行耗时占比达到92％。如何提高交易执行环节的效率是亟待解决的问题。

发明内容

为解决在大宗商品交易场景下，使用区块链为交易存证时，因区块链技术原理导致的性能低下的问题，本发明通过改造Fabric的源码实现多链码容器并行化，配合交易的分发与容器资源的负载均衡，打造高吞吐量的存证平台，从而提出了一种面向大宗商品交易场景的区块链性能优化方法及系统，本发明采用了如下技术方案：

本发明提供了一种面向大宗商品交易场景的区块链性能优化方法，应用在大宗商品交易区块链平台，包括：利用外部链码技术为每一背书节点构建多个链码容器；其中，多个链码容器之间共享命名空间；在背书节点接收到交易提案的情况下，将交易提案中的多笔交易分别分发至多个链码容器，以使得多个链码容器并行执行多笔交易；其中，所述交易提案为大宗商品交易环节中生成。

在本发明提供的一种面向大宗商品交易场景的区块链性能优化方法中，还可以具有这样的特征，其中，将交易提案中的多笔交易分发至多个链码容器，包括：基于一致性哈希算法以及Fabric SDK技术，将交易提案中的多笔交易分发至多个链码容器。

在本发明提供的一种面向大宗商品交易场景的区块链性能优化方法中，还可以具有这样的特征，其中，基于一致性哈希算法以及Fabric SDK技术，将交易提案中的多笔交易分发至多个链码容器，包括：根据链码容器名称的Hash值将各个链码容器放置在预先构建的Hash环上；根据待分发交易的交易数据对应的Key值计算得到Key值对应的Hash值；从Hash环上查询到距离Key值对应的Hash值距离最小的链码容器，作为待分发容器；将待分发交易分发至待分发容器。

在本发明提供的一种面向大宗商品交易场景的区块链性能优化方法中，还可以具有这样的特征，在利用外部链码技术为每一背书节点构建多个链码容器之后，方法还包括：根据网络的负载情况控制多个链码容器的开启或关闭，并在链码容器中的智能合约需求更新的情况下，对多个链码容器中的智能合约更新。

在本发明提供的一种面向大宗商品交易场景的区块链性能优化方法中，还可以具有这样的特征，在将交易提案中的多笔交易分别分发至多个链码容器之前，方法还包括：对交易提案进行合法性验证；在验证通过的情况下，将交易提案中的多笔交易分别分发至多个链码容器。

本发明还提供一种面向大宗商品交易场景的区块链性能优化系统，应用在大宗商品交易场景，包括：外部链码构建模块，用于利用外部链码技术为每一背书节点构建多个链码容器；其中，多个链码容器之间共享命名空间；链码并行模块，用于在背书节点接收到交易提案的情况下，将交易提案中的多笔交易分别分发至多个链码容器，以使得多个链码容器并行执行多笔交易；其中，所述交易提案为大宗商品交易环节中生成。

发明作用与效果

根据本发明的一种面向大宗商品交易场景的区块链性能优化方法及系统，由于利用外部链码技术为每一背书节点构建多个链码容器；并在背书节点接收到交易提案的情况下，将交易提案中的多笔交易分别分发至多个链码容器，以使得多个链码容器并行执行多笔交易。因此，能够通过链码容器并行化实现背书阶段性能提升，并通过外部链码技术实现容器的管理，通过一致性哈希算法实现交易的分发和负载均衡，最终达成整个区块链系统拥有动态并行化模拟背书的功能，提高系统的吞吐量和灵活性，从而解决在大宗商品交易场景下，使用区块链进行交易存证时，因区块链技术原理导致的性能低下的问题。

附图说明

图1为现有技术中Fabric世界状态命名空间划分示意图；

图2为现有技术中Fabric背书流程示意图；

图3为本发明实施例的本发明实施例的面向大宗商品交易场景的区块链性能优化方法的流程图；

图4为本发明实施例的修改后的Fabric命名空间示意图；

图5为本发明实施例的外部链码和节点的关系示意图；

图6为本发明实施例的Fabric实现交易的示意图；以及

图7为本发明实施例的性能效果对比。

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，以下结合实施例及附图对本发明的一种面向大宗商品交易场景的区块链性能优化方法及系统作具体阐述。

在具体介绍本发明提供的一种面向大宗商品交易场景的区块链性能优化方法及系统之前，先介绍一下本发明的研发背景，本发明基于Hyperledger Fabric进行。

其中，Hyperledger Fabric中的账本由世界状态和区块链两部分组成，它们彼此不同但却相互关联。二者都代表了与业务对象有关的一些事实。世界状态是一个数据库，它存储了一组账本状态的当前值。通过世界状态，程序可以直接访问一个账本状态的当前值，不需要遍历整个交易日志来计算当前值。默认情况下，账本状态是以键值对的方式来表示的，Hyperledger Fabric提供这一方面的灵活性。因为可以创建、更新和删除状态，世界状态能够频繁更改。

其次，区块链是交易日志，它记录了促成当前世界状态的所有改变。交易被收集在附加到区块链的区块中，能帮助理解所有促成当前世界状态的改变的历史。区块链数据结构与世界状态相差甚远，因为一旦把数据写入区块链，就无法修改，它是不可篡改的。世界状态数据库根据不同的的链码被分成不同的命名空间。

如图1所示，对于一个通道，调用同一个智能合约完成的交易之间共享相同的世界状态，不同的智能合约无法直接访问对方的世界状态。同样的道理，一个区块链账本中可以包含多个不同链码世界状态相关的交易。总的来说，每个智能合约都包含一个方法。若多个方法、结构体之间关系紧密，Hyperledger Fabric提倡将它们部署在同一智能合约中，这些方法、变量共享相同的世界状态。链码命名空间将不同的世界状态分隔开来，可以将彼此不相关的数据区分开。每个智能合约的命名空间由Hyperledger Fabric分配并直接映射到链码名字上，用户无法自主定义。不同的智能合约之间可以使用invokeChaincode()API来进行链码间交互，前提是这两个智能合约安装在相同节点上。在通道方面，如果仅需要查询被调用链码的世界状态，调用可以发生在与调用发起者链码不同的通道上；如果需要更新被调用链码世界状态，调用必须发生在与调用发起者链码相同的通道上。由于需要跨智能合约调用，因此使用这个API也会带来一些性能上的延缓。

Fabric中一笔交易的原背书流程如图2所示，客户端通过gRPC将交易提案发送到Peer节点，Peer节点中启动了一个背书服务endorserServ和一个链码容器CC Container，背书服务和链码容器也通过gRPC进行通信。当Peer节点接收到交易提案后，会先进行合法性验证，验证之后就会交给背书服务执行响应的链码，链码容器是一个无状态的服务，容器中只运行链码逻辑，链码执行中所需要的所有状态数据均需要和背书服务通信，由背书服务获取并发送到链码容器中。链码执行完成后，背书服务会获得该交易执行结果的读写集，将读写集背书签名后Peer会将结果返回给ok客户端，至此，一次背书过程结束。

本发明中考虑上述技术因读写冲突问题，限制每个节点只启动一个背书服务和一个执行模拟交易的链码容器，导致该环节执行效率低下，故提出一种面向大宗商品交易场景的区块链性能优化方法及系统，以下结合附图具体介绍本发明的一种面向大宗商品交易场景的区块链性能优化方法及系统。

<实施例>

图3为本发明实施例的面向大宗商品交易场景的区块链性能优化方法的流程图。

如图3所示，一种面向大宗商品交易场景的区块链性能优化方法，该方法应用在大宗商品交易场景，包括如下步骤：

步骤S1，利用外部链码技术为每一背书节点构建多个链码容器。其中，多个链码容器之间共享命名空间。

在本实施例中，对上述Fabric背书流程进行修改，使得修改后的Fabric背书流程和修改前类似，但用于并行背书的链码容之间将共享同一个命名空间，由于每个链码容器通过ccid标识，因此在存入命名空间之前，容器之间是并行背书的，存入世界状态数据库后由于共享一个命名空间，因此可以无差别地使用任何一个容器查询、存储数据，如图4所示。具体的修改包括：使得用于并行处理背书流程的容器之间共享命名空间，以及使得Peer节点中每次调用多个链码容器以便并行执行交易提案中的多笔交易。

其中，实现多链码容器并行的具体实现如下：

i、实验环境与日志配置

源码修改基于Fabric最新的2.3版本，使用logger.Infof()指令进行修改日志记录，引入var logger＝flogging.MustGetLogger()，以及新的包"github.com/hyperledger/fabric/common/flogging"。

ii、增加检查修改链码命名空间的方法

统一需要拥有相同命名空间的链码名称格式为：

XXX_x_shard

其中，XXX为所有并行链码统一的命名空间，x为该链码的编号，shard为附加后缀用于区分需要统一命名空间的并行化链码和其他非并行化链码。在fabric/core/chaincode/handler.go中添加函数check_namespace用于检查是否需要改命名空间。

iii、将修改命名空间的方法加入到源码中

将检查方法加入到core/endorser/endorser.go中，用于检查并修改链码容器打包回来的背书结果中的命名空间；将检查方法加入到core/committer/txvalidator/v14/vscc_validator.go中，该方法用于检查部署规范过程中的链码容器名称是否一致，此处修改可以防止检查时出现命名空间不一致报错的问题。

通过上述方法实现多个链码容器之间共享命名空间，然后部署外部链码容器。

具体地，Fabric v2.0支持链码在Fabric环境外部署和执行。允许用户管理与节点保持独立的链码运行。这种方案激励了Fabric中的链码云部署，例如Kubernetes。外部链码技术代替了在每一个节点上面构建与运行链码。链码可以作为一个服务运行，它的生命周期将可以在Fabric环境外进行管理。这种措施利用Fabirc v2.0的外部构建和运行功能。其功能具有允许操作者通过程序构建、运行、发现链码对节点进行扩展。外部链码与节点之间的关系如图5所示。

在外部链码中，链码包内容要求指定的编程语言的源代码进行构建并作为链码二进制文件运行。新的外部构建和运行功能允许用户有选择地定制构建过程。将链码作为外部服务运行。构建过程允许指定链码运行服务的端点信息。因此包内容可以简单地由外部链码运行服务端点信息和用于安全通信的TLS归档组成。

在编写的智能合约里，CCID是启动外部链码时写的docker-compose文件中写入的CHAINCODE_ID和CHAINCODE_SERVER_ADDRESS，这是CCID在容器中最开始的传入点。而在链码容器这边，注册了server用于监听peer发出请求，其中包括了CCID参数(链码名称：链码ID)，因此peer端与docker容器进行通讯主要通过CCID标识链码容器。

部署外部链码的主要流程如下：

i、准备相关的配置文件

外部链码需要detect、build、release三个脚本，detect脚本用于确定是否应使用此buildpack来构建chaincode程序包并启动它；build脚本转换链码包为可执行的链码；release脚本为peer节点提供关于链码的元数据。

在搭建Fabric网络时还需要对启动网络的配置文件core.yaml进行修改，以便于Fabric能够知晓需要构建外部链码。对容器配置文件修改，即docker-compose-test-net.yaml，将core.yaml和脚本文件挂载进容器内。

链码打包需要用到metadata.json及connection.json两个文件。其中，connection.json文件定义了外部链码服务地址及连接参数；metadata.json是一个JSON格式的文档，包含三个键：链码的类型、到主链码包的相对路径、用于生成包ID的链码标签，在新的链码lifecycle过程中用于标识包的身份。

ii、部署外部链码

启动Fabric网络后，在cli中进行后续的操作，使用docker exec-it cli bash进入cli容器，按照chaincode lifecycle，完成install和commit操作。具体而言，需要在每个peer节点上完成install操作，通过在cli中修改环境变量以完成在不同peer节点上的操作，进入存放外部链码配置压缩文件的位置，安装完成后，可以通过命令查询获得链码的package id，在每个org中选择一个节点完成approveformyorg操作，注意参数中的name和package-id需要使用对应的链码名和id。完成上述操作后，即可在cli中检查，提交合约，只要提交成功即链码安装成功，此处需要将前面所有进行过approveformyorg的peer节点地址以--peerAddresses填入。

iii、启动外部链码容器

在peer节点上安装好链码后还需要在cli容器外，手动启动容器，运行链码服务，供peer节点调用。首先构建链码容器镜像，使用Dockerfile构建，链码文件和链码的相关依赖例如vendor文件夹都要和Dockerfile文件在一个目录下，否则构建镜像失败，然后运行指令dockerbuild-t构建镜像，如果链码的编写有误，也会在这个环节报错，需要根据报错内容改正链码，构建镜像后，使用docker-compose启动容器，environment参数中挂载的链码id和地址需要根据实际情况修改，链码id的参数名称要与编写的链码内容中定义一致。

步骤S2，在背书节点接收到交易提案的情况下，将交易提案中的多笔交易分别分发至多个链码容器，以使得多个链码容器并行执行多笔交易。

其中，所述交易提案为大宗商品交易环节中生成。

在本实施例中，大宗商品交易过程中生成的交易提案会包含多笔交易，在此条件下，对区块链的交易执行模拟的效率要求比较高，本发明通过多个链码容器并行执行多笔交易，从而提升大宗商品交易的存证效率。

另外，将交易提案中的多笔交易分发至多个链码容器，包括：

基于一致性哈希算法以及Fabric SDK技术，将交易提案中的多笔交易分发至多个链码容器。

具体地，根据链码容器名称的Hash值将各个链码容器放置在预先构建的Hash环上。

根据待分发交易的交易数据对应的Key值计算得到Key值对应的Hash值。

从Hash环上查询到距离Key值对应的Hash值距离最小的链码容器，作为待分发容器。

将待分发交易分发至待分发容器。

在本实施例中，由于传统的交易分布中对象与节点是映射关系，使用对象的哈希值，对节点个数取模，再映射到相应编号的节点，这种方案在节点个数变动时，绝大多数对象的映射关系会失效而需要迁移。而改造后的Fabric中实现了多容器并行化，每个容器的地位是对等的，对于一笔交易分发给哪个容器进行模拟交易，需要进行分发的工作，但由于引入外部链码对容器进行管理，单个容器可能在某个时刻关闭或改动，因此需要选择适合动态分发场景的算法，而一致性哈希算法中，当节点个数变动时，映射关系失效的对象非常少，迁移成本也非常小。

其中，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，假设某哈希函数H的值空间为0到232-1，即哈希值是一个32位无符号整形，整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、5、6……直到232-1，即0点左侧的第一个点代表232-1，0和232-1在零点中方向重合，这个由232个点组成的圆环称为Hash环。

将各个背书节点使用Hash算法进行一个哈希，这样每台节点就能确定其在哈希环上的位置，接下来使用如下算法定位数据访问到相应节点：将数据key使用相同的函数Hash算法计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针查找，第一个遇到的节点就是其应该定位到的节点。在一致性Hash算法中，如果增加一个节点，则受影响的数据仅仅是新节点到其环空间中前一节点，即沿着逆时针方向行走遇到的第一个节点之间数据，其它数据也不会受到影响。一致性Hash算法对于节点的增减都只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性。

但一致性Hash算法在节点太少时，容易因为节点分部不均匀而造成数据倾斜，被缓存的对象大部分集中缓存在某一台服务器上的问题，因此引入了虚拟节点机制，即对每一个节点计算多个哈希，每个计算结果位置都放置一个此节点，称为虚拟节点。这样就解决了节点少时数据倾斜的问题。

大宗商品交易区块链存证平台下并行的链码容器即服务节点，容器数量有限，且外部链码技术的使用伴随着容器的开启和关闭，服务节点的数量将会动态变化，容器之间的配置没有差异，场景期望尽可能在不受容器开关的影响下均匀地将交易分发给各个容器，因此适合采用带有虚拟节点的一致性Hash算法进行交易的分发。

需要说明的是，在利用外部链码技术为每一背书节点构建多个链码容器之后，方法还包括：

根据网络的负载情况控制多个链码容器的开启或关闭，并在链码容器中的智能合约需求更新的情况下，对多个链码容器中的智能合约更新。

本实施例中除了使用外部链码技术创建并行化的容器之外，还能结合当前网络的负载情况对容器进行部署或关闭，需要更新容器中的智能合约时，可以在不影响Fabric网络的情况下对容器内的智能合约进行更新，达到在容器数量、内容的动态管理。

另外，如图6所示，在将交易提案中的多笔交易分别分发至多个链码容器之前，方法还包括：

对交易提案进行合法性验证。

在验证通过的情况下，将交易提案中的多笔交易分别分发至多个链码容器。

在本实施例中，背书节点在收到客户端发起的交易提案后，会通过并行链码容器并行模拟执行交易，然后将原始交易提案和执行结果打包到一起，进行签名并发回给客户端。其中，在模拟执行交易期间产生的数据修改不会写到账本和世界状态数据库中。客户端收到各个Peer的应答后，将一批应答打包到一起组成一个交易并签名，发送给Orderer节点。Orderer节点对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，发送给负责验证的Peer节点。验证节点会对收到的交易进行读写集验证，交易验证通过后会被更新到区块账本和世界状态数据库中，验证节点返回成功的状态给客户端。

为了验证本发明提出的面向大宗商品交易场景的区块链性能优化方法，本实施例在如下实验环境下进行实验。

具体地，本次实验在一台物理机上进行，具体的配置如下表1所示：

表1实验配置

对源码进行修改后解除了命名空间。使用marble链码存入01交易，使用marble_1_shard和marble_2_shard都可以查到01交易，在日志中也能看到命名空间被正确的修改。除此以外，使用marble存0，使用marble_1_shard存1，使用marble_2_shard存2，均存储成功，使用marble、marble_1_shard、marble_2_shard分别查0、1、2，均查询成功，可以得知符合命名规则的链码解除了命名空间，而其他链码则不受影响。

对实现背书容器并行化后的Fabric进行性能测试，采用性能测试工具tape发送大量的交易请求给peer节点，结合Fabric浏览器explorer监控出块情况，交易数量设定为50000笔交易，区块大小设定为500，增加并行容器的数量比较Fabric性能优化程度。

表2测试结果对比表

由表2以及图7可知，修改后的Fabric出块速度大概提升了两倍，tape性能测试工具直接返回的tps结果提高了接近三倍。

安装外部链码成功后，可以看到在容器列表中有自主命名的容器，通过docker-compose文件可以关闭或启动容器，当容器启动后，能够成功调用链码。

对一致性哈希算法的分发情况进行测试，虚拟节点的数量越多，分发越均匀，当虚拟数量接近上万时，分发基本均匀，测试中设置虚拟节点数量从10开始以十倍增长，真实节点数量为5的情况下，每个节点基本上分发到20％左右的交易，实验记录见下表3所示。

表3一致性哈希算法的分发情况测试结果对比表

	10	100	1000	10000	50000
						abstore_1_shard	10％	24％	21％	19％	20％
abstore_2_shard	38％	16％	20％	20％	20％
						abstore_3_shard	3％	28％	18％	20％	19％
abstore_4_shard	16％	18％	19％	20％	20％
						abstore_5_shard	30％	11％	19％	19％	19％

本实施例中，上述面向大宗商品交易场景的区块链性能优化方法也可以被配置成对应的计算机模块，即外部链码构建模块以及链码并行模块，上述模块形成一种面向大宗商品交易场景的区块链性能优化装置。

具体地，外部链码构建模块用于利用外部链码技术为每一背书节点构建多个链码容器。其中，多个链码容器之间共享命名空间。

链码并行模块用于在背书节点接收到交易提案的情况下，将交易提案中的多笔交易分别分发至多个链码容器，以使得多个链码容器并行执行多笔交易；其中，所述交易提案为大宗商品交易环节中生成。

实施例作用与效果

根据本实施例提供的一种面向大宗商品交易场景的区块链性能优化方法及系统，由于利用外部链码技术为每一背书节点构建多个链码容器；并在背书节点接收到交易提案的情况下，将交易提案中的多笔交易分别分发至多个链码容器，以使得多个链码容器并行执行多笔交易。因此，能够通过链码容器并行化实现背书阶段性能提升，并通过外部链码技术实现容器的管理，通过一致性哈希算法实现交易的分发和负载均衡，最终达成整个区块链系统拥有动态并行化模拟背书的功能，提高系统的吞吐量和灵活性，从而解决在大宗商品交易场景下，使用区块链进行交易存证时，因区块链技术原理导致的性能低下的问题。

上述实施例仅用于举例说明本发明的具体实施方式，而本发明不限于上述实施例的描述范围。

Claims (6)

1.一种面向大宗商品交易场景的区块链性能优化方法，应用在大宗商品交易区块链平台，其特征在于，包括：

利用外部链码技术为每一背书节点构建多个链码容器；其中，所述多个链码容器之间共享命名空间；

在所述背书节点接收到交易提案的情况下，将所述交易提案中的多笔交易分别分发至所述多个链码容器，以使得所述多个链码容器并行执行所述多笔交易；其中，所述交易提案为大宗商品交易环节中生成。

2.根据权利要求1所述的面向大宗商品交易场景的区块链性能优化方法，其特征在于：

其中，所述将所述交易提案中的多笔交易分发至所述多个链码容器，包括：

基于一致性哈希算法以及Fabric SDK技术，将所述交易提案中的多笔交易分发至所述多个链码容器。

3.根据权利要求2所述的面向大宗商品交易场景的区块链性能优化方法，其特征在于：

其中，所述基于一致性哈希算法以及Fabric SDK技术，将所述交易提案中的多笔交易分发至所述多个链码容器，包括：

根据链码容器名称的Hash值将各个链码容器放置在预先构建的Hash环上；

根据待分发交易的交易数据对应的Key值计算得到Key值对应的Hash值；

从所述Hash环上查询到距离所述Key值对应的Hash值距离最小的链码容器，作为待分发容器；

将所述待分发交易分发至所述待分发容器。

4.根据权利要求1所述的面向大宗商品交易场景的区块链性能优化方法，其特征在于，在所述利用外部链码技术为每一背书节点构建多个链码容器之后，方法还包括：

根据网络的负载情况控制所述多个链码容器的开启或关闭，并在链码容器中的智能合约需求更新的情况下，对所述多个链码容器中的智能合约更新。

5.根据权利要求1-4任一所述的面向大宗商品交易场景的区块链性能优化方法，其特征在于，在将所述交易提案中的多笔交易分别分发至所述多个链码容器之前，方法还包括：

对所述交易提案进行合法性验证；

在验证通过的情况下，将所述交易提案中的多笔交易分别分发至所述多个链码容器。

6.一种面向大宗商品交易场景的区块链性能优化系统，应用在大宗商品交易场景，其特征在于，包括：

外部链码构建模块，用于利用外部链码技术为每一背书节点构建多个链码容器；其中，所述多个链码容器之间共享命名空间；

链码并行模块，用于在所述背书节点接收到交易提案的情况下，将所述交易提案中的多笔交易分别分发至所述多个链码容器，以使得所述多个链码容器并行执行所述多笔交易；其中，所述交易提案为大宗商品交易环节中生成。

Images