基于区块链跨链技术的水产品交易模型研究

2022-02-08姚海东邹一波孙侦龙

农业机械学报 2022年12期

葛艳姚海东邹一波陈明孙侦龙

(1.上海海洋大学信息学院，上海 201306; 2.农业农村部渔业信息重点实验室，上海 201306;3.中洋渔业(江门)有限公司，江门 226600)

0 引言

水产品供应链各环节通过信息共享以及水产品和资金流通，将企业以物资流向连载整合，从而提升整个水产品供应链的运作效率[1]。但是传统水产品供应链存在信息化程度较低、结构松散且相对独立以及各环节之间协调不足、效率低等问题[2]，同时在水产品供应链的应用中同样存在着安全性差、信息不对称、质量安全缺乏监管等问题[3-5]。

区块链具有去中心化、可追溯和不可篡改的特点[6-7]，为解决上述问题提供了新的思路[8]。国外学者利用区块链的特性，从交易管理方面对供应链上的应用展开研究[9-12]。随着各种区块链项目之间融合交互需求日益增长，传统的单链业务结构逐步发展为多链业务结构，而区块链的信息孤岛是企业之间区块链无法实现链上数据互通的关键[13]，区块链的跨链技术也应运而生。

跨链是一种价值在不同区块链之间流动的过程，这里的价值不仅指链上的资产，也是一种信息[14]，价值交换要在价值守恒的前提下，保证精确性和可靠性[15]。目前，已有公证人机制[16]、侧链/中继[17]、哈希锁定[18]和分布式私钥控制[19]这4种主流的跨链技术，在不同程度上解决了跨链互操作问题，为实现跨链提供了技术方案[20]。国内外学者采用上述跨链机制从共识机制[21-22]、密码学技术[23]、多链架构[24-26]等角度对区块链的效率、安全性以及扩展性等展开研究。此外在能源[27]、电信[28]、电力[29]等领域，也使用跨链技术为其交易与认证设计出安全可靠的模型。

图1 水产品供应链的业务分析Fig.1 Business analysis of aquatic products supply chain

同样，国内外学者也分别从技术角度和业务逻辑角度对现有水产品供应链的效率、安全性以及扩展性等做出了改进。文献[30]构建多链结构将不同类型的数据信息分开存储，实现不同数据的隔离保存，提高数据的安全性；文献[31-33]构建出基于双区块链架构的产品防伪溯源系统，扩展溯源数据的存储容量，同时提高了溯源的效率与可信度。将现有供应链结构与多链架构相结合，使供应链的扩展性有了较大的提升，同时水产品供应链的应用也更加灵活。

跨链技术在水产品供应链领域更加偏向溯源的应用，而利用跨链技术对供应链中水产品交易改进方面的研究却很少。本文将跨链技术应用在水产品交易领域，改进交易流程，实现水产品在链间交易。

1 水产品供应链的业务逻辑分析

水产品供应链的特点是环节众多，根据水产品供应链中业务功能的特点，将水产品供应链按照业务逻辑分为养殖、加工、仓储、销售、运输5个环节，如图1所示。各个环节分属的企业之间相互独立，水产品在供应链中按照交易流向，从养殖企业开始交易至销售企业，最终到达消费者手中。

各个环节不同的业务功能需求，导致环节之间业务信息的数据结构不同，水产品供应链中的业务信息是水产品供应链上交易的基础，针对上述供应链中水产品交易的业务信息特点，将水产品供应链各环节的业务信息分为产品信息和交易信息：①产品信息是指在当前环节中记录的产品情况信息，各个环节的水产品信息根据业务需求有所不同。②交易信息中不仅包含交易双方信息和包含水产品数量、单价、保质期等水产品的交易产品信息，还包含交易双方是否对交易达成一致的交易确认信息以及交易在后续执行情况的交易执行信息。

以养殖企业与加工企业之间的交易为例，养殖企业可为加工企业提供一批水产品养殖的详细信息，然后双方会对数量、规格、单价等交易的产品信息进行协商，最终对交易达成一致并在后续完成对交易的执行。交易过程中交易双方对交易的协商、确认和执行分别作为交易产品信息、交易确认信息和交易执行信息进行保存。

2 水产品跨链交易模型架构

2.1 水产品跨链交易模型架构设计

基于水产品供应链交易的业务分析，本文设计了水产品跨链交易模型的架构，如图2所示。模型架构共分为5层，根据实现功能自下而上分别是网络层、智能合约层、数据层、交互层和业务层。

图2 水产品跨链交易模型架构Fig.2 Aquatic products cross-chain trading model architecture

(1)网络层包括区块链结构和跨链结构。区块链结构是指水产品供应链中各个企业的区块链，而跨链结构是实现跨链交易的核心。区块链结构负责跨链交易的发起与确认，以及对跨链交易中跨链资源的发送与接收。而跨链结构负责接收由区块链发送的跨链资源然后进行转发，其中跨链资源包括跨链交易信息、验证信息以及智能合约等。

(2)智能合约层对交易流程在链上实现的功能设计了相应的智能合约，包括用于发起跨链交易并完成交易流程的跨链合约、实现跨链功能的系统合约以及能够对交易信息进行访问的查询合约。智能合约布署在区块链上，企业用户在链上直接调用智能合约就可以完成跨链交易的流程。

(3)数据层根据水产品供应链业务分析中的信息字段内容以及跨链传输的功能需求，在模型中设计了跨链交易信息与跨链传输信息。跨链交易信息包括产品信息、交易产品信息、交易双方信息、交易确认信息和交易执行信息，用于跨链交易过程中区块链结构和跨链结构之间的信息传输。而跨链传输信息在跨链结构中流转，包括跨链交易信息和含时间戳、哈希、背书信息等的区块信息。

(4)交互层操作包括跨链交易传输、跨链交易确认和跨链交易验证。发起链通过系统合约以及跨链结构，将交易信息发送至目的链；目的链接收到交易信息后，对交易进行判断，选择是否确认当前交易：若确认交易，则表示接收交易；若回滚交易，则表示拒绝交易；最后将确认或回滚的结果返回至发起链，完成交易。同时，在跨链交易信息的传输过程中，还需要对跨链交易进行验证，验证通过则进行下一步，若验证失败，则返回错误信息并取消当前跨链交易。

(5)业务层可实现跨链交易发起、交易信息上传和交易信息查询功能。企业将区块链接入模型后就可以作为发起链发起跨链交易，也可以作为目的链接受或拒绝一笔跨链交易。若选择接受交易，则在交互层完成对交易的确认，并在线下完成后续交易执行的环节，并上传交易执行的信息；若选择拒绝交易，则在交互层完成对交易的回滚，取消交易。交易的企业双方可以通过交易编号对当前交易进行查询，获取交易信息。

2.2 跨链路由功能模块设计

图3 跨链路由的模块设计Fig.3 Modular design of cross-chain routing

在水产品跨链交易模型中，将负责接收和转发跨链资源的跨链结构与交互层的功能实现整合，设计了跨链路由。

跨链路由中使用中继的跨链方式，将跨链路由作为实现跨链功能的中介，一方面结合业务需求，融合水产品在链上交易的流程业务，跨链路由采用模块化的设计，降低耦合性；另一方面结合跨链需求，设计了区块链链入接口、权限、交易队列、验证和通信模块，如图3(图中CCIF表示跨链信息格式)所示，实现跨链功能，减少维护成本。跨链路由之间以P2P自组网的方式相互连接，共同组成跨链网络，实现跨链资源在跨链路由之间、跨链网络之中传输同步。

2.2.1区块链链入接口

每个区块链平台都有独立的框架结构和运行逻辑，不同区块链之间无法直接交互，这也是跨链技术难点之一。因此区块链链入接口的意义便是适配对应的区块链，通过区块链链入接口实现跨链交互功能。

区块链链入接口在跨链路由中发挥两种作用：区块链与跨链路由的连接以及跨链资源在区块链与跨链路由之间的传输。区块链链入接口中的跨链接口分为跨链信息接口、跨链交易接口和调用接口。在企业区块链上布署的系统合约中包含与区块链链入接口相连接的接口。系统合约中的接口分为两部分：跨链调用接口和交易接口。通过系统合约与区块链链入接口，完成区块链与跨链路由的连接，实现跨链资源的传输。

2.2.2权限模块

区块链使用本链的公钥、私钥、证书等文件与跨链路由一对一进行绑定。绑定后，会生成该链在水产品跨链交易模型中的唯一身份标识即区块链编号，同时区块链也赋予跨链路由一定的权限。

区块链编号用来标识区块链，进而可以标识链上的智能合约。区块链编号会在跨链路由之间同步，从而区块链的身份能够在整个跨链网络中得到认证，使跨链资源能够在跨链路由间正确传输，实现跨链资源在不同链间的可信流转。

跨链路由在接入区块链后，不仅要能够监听交易，而且要保证跨链交易的可验证性。区块链会赋予跨链路由一定的权限，使跨链路由能够获取跨链交易的背书信息等验证信息。跨链路由会根据区块存储结构获取该跨链交易的合法性证明。

2.2.3交易队列模块

交易队列模块会将区块链发送的跨链交易信息形成跨链交易信息列表，暂时存储等待执行。当企业用户发起跨链交易，跨链路由接收跨链交易信息后，会收集当前跨链交易的验证信息，以便后续验证。而未执行的跨链交易信息按照顺序暂时存储在交易队列模块中，等待获取相应的验证信息。

2.2.4验证模块

在跨链场景中，由于双方并没有参与对方区块链的共识流程，因此本文引入跨链验证协议，实现数据信息在链间的安全传输。验证模块收集跨链交易的验证信息，并根据跨链验证协议对这些验证信息进行验证。在跨链验证协议中，使用Merkle验证[34]对跨链交易实施验证，保证跨链交易的正确性，也保障了整个水产品跨链交易模型处于正确的状态。

图4是某一区块内的Merkle树，若要验证交易TX1的存在性，只需要提供路径哈希即Hash2、Hash34、RootHash。具体的Merkle验证过程如下：根据交易TX1计算得到，Hash等于Hash(TX1)；根据Hash1和提供的Hash2计算得到，Hash12等于Hash(Hash1 + Hash2)；根据Hash12和提供的Hash34计算得到Hash1234等于Hash(Hash12 + Hash34)；最后比较Hash1234和提供的根哈希RootHash，若Hash1234等于RootHash，则证明当前区块中存在TX1，反之则不存在。

图4 Merkle验证Fig.4 Merkle verification

而一次跨链交易，不仅需要验证发起跨链交易时在发起链上的存在性，还需要验证跨链交易是否在目的链上成功执行。即目的链是否成功对跨链交易进行执行并上链。因此当跨链交易返回至发起链的跨链路由后，还需验证跨链交易在目的链上的存在性，即验证跨链交易的执行性。验证跨链交易执行性的步骤与验证存在性是相同的。若验证执行性失败，则将错误信息按原路径返回至发起链，然后取消当前跨链交易，并根据状态Merkle树回滚至跨链交易前的状态。只有当跨链交易的存在性与执行性全部验证通过，跨链交易才认为成功。

2.2.5通信模块

跨链路由接收来自企业区块链的跨链交易信息，然后在链上获取跨链交易的背书信息和Merkle证明信息，一同由通信模块按照跨链信息格式打包生成CCIF信息，并由通信模块对CCIF信息进行发送、接收和解析[25]。表1为跨链路由传输的CCIF信息的详细内容。

表1 跨链信息格式Tab.1 Cross-chain information format

在Proof中还分为4个字段：Hash、Path、MerkleRoot、Signature。其中Hash是跨链交易内容的哈希，Path是Merkle验证的路径哈希，MerkleRoot是根哈希，Signature是对于根哈希的签名。其中Signature字段在Fabric链中则是背书节点的背书信息，也是由跨链路由从区块链中获得。

2.3 模型拓扑结构

水产品跨链交易模型的拓扑结构如图5所示。模型整体的拓扑结构是由多条交易链和多个跨链路由组成，每一个跨链路由与一条交易链连接。跨链路由之间通过P2P网络进行连接，共同构成跨链网络。跨链信息通过跨链网络实现多方参与、信息相互隔离的模式。企业用户可通过链上的节点在链上发起跨链交易，并经由跨链网络将跨链信息进行转发。

图5 模型拓扑结构Fig.5 Model topology structure

3 水产品跨链交易流程

为了保护企业在链上交易时企业内部的数据安全，在各个企业现有的区块链网络的基础上增加一条交易链，将此链作为每个企业的交易链加入到水产品跨链交易模型中，实现链与链之间的数据互通并进行跨链交易。

3.1 水产品跨链交易模型中的模块交互

如图6所示，水产品跨链交易模型可分为两个部分：区块链网络以及跨链网络。区块链网络由各个企业的交易链组成，企业用户可在链内发起跨链请求，调用跨链合约生成跨链交易信息，并且在交易链上记录跨链交易的详细信息。跨链网络则由各条企业交易链的跨链路由组成。跨链交易信息的存储、验证、打包、传输都由跨链路由完成，实现了数据信息在不同区块链之间的传输，完成跨链交易，即交易合同在链上的拟定和确认。

图6 水产品跨链交易模型中模块交互Fig.6 Module interaction in the model of cross-chain aquatic product trading

图6是交易在水产品跨链交易模型中模块间交互。跨链交易由发起链发起，通过跨链合约和系统合约与区块链链入接口的连接，将生成的跨链交易信息发送至跨链路由；验证模块收集跨链交易的背书信息和Merkle证明信息，并连同跨链交易信息一同发送至通信模块；通信模块按照跨链信息格式打包成CCIF信息，发送至目的链的跨链路由；目的链跨链路由中的通信模块接收后，验证模块先对CCIF信息进行验证；验证通过后，再经通信模块解析重新获取跨链交易信息后，由区块链链入接口发送至目的链，目的链通过系统合约来接收跨链交易信息。之后，目的链完成跨链交易的后续执行操作。

3.2 水产品跨链交易流程设计

由于跨链交易信息不仅包含交易产品信息，同时还要将交易执行信息保存。考虑到交易过程的原子性与交易信息的可溯性，简单地将跨链转账流程引入并不适用。因此本文引入两阶段提交协议，加入跨链事件，将跨链交易分为两个步骤：发起跨链事件，并根据跨链交易信息发起存证交易，保存存证信息；根据跨链交易信息，对跨链事件执行确认或回滚操作，保存执行结果信息。图7为水产品跨链交易流程的示意图，并以养殖企业与加工企业为例说明跨链交易的具体流程。

图7 水产品跨链交易流程示意图Fig.7 Schematic diagram of the cross-chain trading process of aquatic products

(1)发起跨链交易，生成跨链交易信息。养殖企业用户发起跨链请求，与加工企业对某水产品进行交易。此时养殖交易链作为发起链，而加工交易链就作为目的链。通过调用链中的跨链合约发起一笔跨链交易，然后生成跨链交易信息，此时链中的背书节点对当前交易进行模拟计算并按照共识机制完成背书，验证通过后，当前交易便打包至区块中。

(2)发起跨链事件，发起链生成存证交易。在生成跨链交易信息后，跨链合约会在当前跨链交易中开启一次跨链事件，跨链事件中包含两笔存证交易，分别由发起链与目的链生成。其中在生成跨链事件后，养殖交易链根据跨链交易信息内容发起存证交易，并将存证信息保存至链上。

(3)跨链交易信息发送至跨链路由。系统合约首先调用跨链调用接口与区块链链入接口中的调用接口相连，然后系统合约通过交易接口将跨链交易信息发送至养殖跨链路由。养殖跨链路由通过区块链链入接口中的跨链交易接口接收跨链交易信息。

(4)生成CCIF信息。接收到的跨链交易信息都会被暂时存储在交易列表模块中等待顺序执行。对于要执行的跨链交易，跨链路由首先从交易链中获取当前跨链交易的Merkle证明信息以及背书信息，然后通信模块将这些信息统一打包成CCIF信息。

(5)发送CCIF信息。养殖跨链路由根据CCIF信息中的To字段，将CCIF信息发送至加工跨链路由。

(6)验证跨链交易存在性。加工跨链路由接收后，通信模块将CCIF信息发送至验证模块。验证模块根据CCIF信息中的Proof字段对当前跨链交易进行验证。验证通过，进行下一步；验证不通过，跨链交易结束。

(7)解析CCIF信息并发送至目的链。验证模块将验证通过的CCIF信息再发给通信模块进行解析，重新得到跨链交易信息，然后将跨链交易信息发送至加工交易链。

(8)目的链生成存证交易。加工交易链接收到跨链交易信息后，同样根据跨链交易信息发起存证交易。至此跨链事件中的两笔存证交易都已生成。

(9)执行跨链交易。目的链对跨链交易的执行，就是目的链对跨链事件执行确认或回滚操作。在加工交易链对两笔存证交易都确认后，当前跨链事件会结束，同时在链上保存确认后的存证信息以及确认后跨链交易信息；若加工交易链对跨链交易信息有疑问，可以选择回滚当前跨链事件，存证交易中的存证信息会回滚至跨链事件前，则此时存证交易中没有任何信息，然后结束跨链事件，而执行跨链交易的失败结果与回滚后的存证交易也都会记录在链上。然后将包含跨链交易执行结果的跨链交易信息返回。

(10)跨链交易信息返回至跨链路由，返回CCIF信息。加工跨链路由接收到跨链交易信息后，从交易链中获取相应的验证信息，再由通信模块重新打包成CCIF信息发送至养殖跨链路由。

(11)验证跨链交易执行性，并返回至发起链。养殖跨链路由接收返回的CCIF信息后，执行步骤(6)、(7)，将解析后的跨链交易信息发送至养殖交易链。

(12)获取回调结果。养殖交易链获得返回的执行结果，即加工交易链是否同意当前跨链交易，交易完成。之后双方都可以在各自链上查看存证交易和跨链交易获取交易详情。

4 智能合约设计

4.1 系统合约

系统合约(System smart contract)用于交易链与跨链路由的连接以及信息在交易链与跨链路由之间的传输。通过系统合约中的InterchainInvoke接口，完成交易链与跨链路由的连接，实现跨链资源的传输。系统合约被调用后，将传入的参数做json格式数据转换，便于信息的传输，并对每一笔接收到的跨链交易信息进行编号排序，然后将信息上链，返回跨链调用成功与否的结果，最后等待跨链交易的有序执行。具体算法如下：

输入：目的链编号ToID，目的链调用合约Contract，调用合约地址Addr，调用合约方法Method，参数args

输出：跨链调用响应结果

function InterchainInvoke (stub, args[])

if len(args) != 5

return传入的参数数量有误

Cert = Stub.GetCreator()

∥获取发起跨链调用请求用户的信息

if Exit = Stub.GetState(ToID)

∥查询目的链编号是否存在

if Exit = Stub.GetState(Addr)

∥查询目的链上合约地址是否存在

SeqNum ++ ∥对跨链交易依次排序

Message = json.Marshal (SeqNum+args[]+Cert)

∥将跨链信息做json格式数据转换

stub.PutState(Message)

return shim.Success

∥返回跨链调用的响应结果

4.2 跨链合约

跨链合约(Interchain smart contract)发起链调用后，发起跨链交易，经过目的链对跨链交易进行确认或拒绝，并将结果返回至发起链。跨链合约的算法为：发起链发起跨链交易，生成跨链交易信息，并以json文件格式将跨链交易信息保存至链上，然后返回当前跨链交易的编号。具体算法如下：

输入：发起链编号FromID，目的链编号ToID，跨链交易信息TxInfo

输出：跨链交易编号TxID

function CrossChainTx (stub, args[])

if len(args) !=3

return传入的参数数量有误

return TxID

存证交易包含在跨链事件中，一次跨链事件中会包含两笔分别由发起链和目的链发起的存证交易。跨链事件只有在两笔存证交易都确认或是回滚后，才会结束。而在交易确认或回滚前，正处于跨链事件中时，是无法发起新的交易对当前交易进行修改。跨链事件生成的具体算法如下：

输入：发起链编号FromID，目的链编号ToID，跨链交易编号TxID，跨链交易信息TxInfo

输出：跨链事件编号EventID

function Event (stub, args[])

if len(args) != 4

return传入的参数数量有误

if Exit = Stub.GetState(TXID)

∥查询链上是否已经存在交易记录

IsEventExec = false

∥锁定跨链事件，双方链无法再次生成跨链事件

Stub.PutState (args[] + IsEventExec)

∥发起链根据信息生成存证交易上链

return EventID

跨链事件执行的具体算法如下：

输入：发起链编号FromID，目的链编号ToID，跨链事件编号EventID

输出：跨链事件执行结果

EventCommit/ EventRollback

function EventExec (stub, args[])

if len(args) != 3

return传入的参数数量有误

if Exit = Stub.GetState(EventID)

∥查询链上是否已经存在交易记录

if IsEventExec

∥查询跨链事件是否已经执行

return跨链事件执行结果

if commitEvent ( EventID ){

∥目的链确认跨链事件，接受交易

return EventCommit = true,

IsEventExec = true

∥返回“接受”执行结果

} else if rollbackEvent ( EventID ){

∥目的链回滚跨链事件，拒绝交易

return EventRollback = true,

IsEventExec = true

∥返回“拒绝”执行结果

}

一笔跨链交易从发起到执行最后返回结果后完成交易的过程：首先交易链上发起跨链请求，生成跨链交易；之后发起跨链事件，并根据跨链交易信息生成存证交易；然后调用系统合约中的InterchainInvoke接口，将跨链交易信息进行传输；经由跨链路由的转发，目的链对跨链事件执行确认或回滚操作，执行结果返回至发起链，完成跨链交易。具体算法如下：

输入：跨链交易编号TxID

输出：跨链交易执行结果TxExec

function InterChain (stub, args[])

CrossChainTx() ∥发起链发起跨链交易

if Exit = Stub.GetState( TXID )

∥查询链上是否已经存在交易记录

Event() ∥发起链开启跨链事件

Stub.InvokeChaincode(“System”)

∥调用系统合约中的跨链调用接口

EventExec() ∥目的链执行跨链事件

If EventCommit {

return TxExec = true

∥返回“成功”的跨链交易结果

}If EventRollback {

return TxExec = false

∥返回“失败”的跨链交易结果

}

4.3 查询合约

查询合约(Query smart contract)在水产品跨链交易模型中，一笔跨链交易结束后，企业用户可在交易链上调用查询合约，通过输入交易编号或是跨链事件编号，获取对应跨链交易或存证交易的详细信息。查询合约的具体算法如下：

输入:交易编号TxID，跨链事件编号EventID

输出:交易信息Info

function Query (stub, args[] )

if Exit = Stub.GetState( TxID/EventID )

∥查询企业链上是否存在当前交易记录

return Info ∥返回交易详细信息

5 系统功能测试

5.1 系统实现

基于水产品跨链交易模型，实现了水产品跨链交易的应用，应用架构层与模型架构层相对应，同样分为网络层、智能合约层、数据层、交互层和业务层5层。实验环境采用Ubuntu 16.04，Docker 20.10.7，Go 1.13，区块链架构使用Hyperledger Fabric 1.4.4。跨链路由依据Fabric平台的SDK和JAVA语言进行设计，智能合约层借助GO语言进行链码开发，并对业务层开发了前端界面。

图8 Fabric区块链结构Fig.8 Fabric blockchain structure

图9 跨链配置信息Fig.9 Cross-chain configuration information

图10 水产品跨链交易后台实现Fig.10 Aquatic products cross-chain trading back-end implementation

在实验中，对每条链做多通道处理后再接入模型中，实现跨链交易信息分离的同时，也避免了重新搭建新链作为交易链接入模型的成本。这样既可以确保链上原有数据和交易信息的安全性，又可以提高查询跨链交易的效率。如图8所示，水产品供应链中的养殖、加工和销售企业分别置于一条Fabric区块链。在每条链中设置org1、org2和org3共3个组织以及跨链通道channel12和原数据通道channelall两个通道，将跨链交易的链码以及交易流程中产生的信息保存至channel12中。将org1和org2接入channel12，org3接入channelall。之后在跨链通道上布署跨链合约、系统合约和查询合约，再将跨链通道接入跨链路由，如图9所示，模型中接入的部分区块链信息包括名称、类型、跨链账户、区块高度和公钥信息以及对应跨链路由的IP和端口信息。

用户可以通过org1上的节点向目的链发起跨链交易。如图10a所示，养殖企业A1在channel12中调用合约interchain_marine向加工企业B1发起交易，并传入交易产品信息。交易发起后，在channel12中再次调用合约query_marine，输入交易编号即可查询当前交易信息，如图10b所示。

图11是水产品跨链交易前端实现。如图11a所示，加工企业B1可以查询与自己企业相关的交易信息，并且对于作为目的方的交易，可以根据交易产品信息选择接受或是拒绝这笔交易，以修改交易状态；同样可以根据交易编号查询到当前交易的区块信息，如图11b所示。

5.2 性能测试

本文从发起跨链交易与交易查询两方面进行测试，采用Caliper性能测试工具，并从3个指标——每秒交易吞吐量、平均交易成功率和平均交易延迟对系统进行测试。每次实验的数据采用测试10次的平均值。本文中将系统设置每10笔交易生成一个区块，区块生成间隔为2 s，同时采用CouchDB数据库以提升数据查询效率。

图11 水产品跨链交易前端实现Fig.11 Front-end realization of cross-chain trading of aquatic products

图12 跨链交易性能测试结果Fig.12 Cross-chain transaction performance test results

图12为在交易总量分别为1 000、2 000、5 000笔的情况下，每秒向系统并发的交易量不同，记录每轮测试的平均交易成功率和平均交易延迟，10轮过后可求得系统的平均交易成功率和平均交易延迟。如图12所示，跨链交易的平均成功率都在99%左右，而交易的平均延迟在0.2 s左右。交易总量的增加会正向影响平均交易成功率，而增加交易的成功率，同时也增加了平均交易延迟；每秒交易并发量则是反向影响着平均交易成功率和平均交易延迟，二者都随着每秒交易并发量的增加而减小。

图13 交易查询性能测试结果Fig.13 Transaction query performance test results

在交易查询的测试中，随着查询交易数量的增长，查询的平均交易延迟整体呈现下降趋势，每秒交易吞吐量则是不断增长(图13)；同时数据总量的增加也使平均交易延迟增加；数据总量会反向影响每秒交易吞吐量，数据总量10 000条的每秒交易吞吐量会低于数据总量5 000条的每秒交易吞吐量；最后交易查询的平均成功率是非常稳定的100%。