基于区块链的水产品撮合交易模型与系统实现

王文娟 张 旭 陈 明 邹一波 葛 艳

(1.上海海洋大学信息学院， 上海 201306; 2.农业农村部渔业信息重点实验室， 上海 201306)

0 引言

近年来，以水产品为主打品牌的生鲜电商已经在生鲜市场中占据着不可或缺的位置。将水产品交易由传统线下为主的贸易方式转移到线上平台为水产品的流通带来了极大的便利。然而，当前的水产品电商平台以提供信息共享功能为主，不论是传统贸易方式还是现存的生鲜电商平台，买卖双方仍然存在着信息不对等的情况。水产品作为一种易腐商品，对交易的时效性有着极高的要求，若不能在较短的时间内完成交易匹配会大大提高水产品的损耗率[1]。此外，现存的水产品电商交易平台还存在着用户信息泄露和商品信息造假等安全漏洞[2]。针对以上问题，亟需一种新的解决方案，提高交易匹配效率，增强平台监管力度并降低监管成本，同时保障买卖双方的隐私和信息安全。

区块链是在对等网络环境下，通过透明可信的规则，按照时间戳序列，不可伪造、篡改和可追踪的数据结构，可以实现和管理交易处理过程，保障交易数据的安全性[3]。每个区块由区块头和区块体构成。区块头里存有上一个区块的哈希值。前一个区块中的数据如果发生改变则连同后面所有区块的哈希值都需要改变，以达到数据防篡改的目的。区块链集成了共识机制、分布式数据存储、点对点传输、密码学等技术，受到国内外学者的广泛关注[4]。将区块链引入水产品领域是解决水产品交易平台监管难度大、提高数据安全性和交易匹配效率的有效途径。

目前，国内外学者主要将区块链技术引入到食品质量安全溯源体系(含水产品质量溯源)，结合物联网技术提出了一些特定应用场景下食品供应链或全产业链的区块链安全架构[5-11]。其他学者则从微观视角侧重于农产品或水产品质量溯源过程中数据存储结构和效率[12-19]、身份认证机制[20-22]、共识算法优化[23-25]等研究内容。然而，目前质量安全追溯体系相关研究大部分未涵盖线上交易环节。该环节作为水产品流通的最后阶段，对于构建完整的水产品供应链具有重要作用。冯国富等[26]提出基于区块链的水产品撮合交易溯源系统模型，将交易记录加密后对数据地址进行上链，但是仍然没有将交易过程上链。此外，现有少数的基于区块链的撮合交易机制研究主要集中在电能源领域[27-34]，且目标函数始终围绕价格单因素展开，与水产品撮合交易场景不完全相符。水产品撮合交易过程中，不仅关注价格，对商品的配送距离、鲜活度、购买品种、数量、尺寸等属性也有约束。周超等[35]首次尝试构建水产品线上交易匹配模型，并使用鸟群觅食算法对模型进行求解,证明了算法的可行性,但该研究并未涉及线上交易平台的安全与隐私保障等问题。考虑到水产品撮合交易多属性匹配的特点，并融入区块链技术保障其交易安全性的研究鲜见报道。

本文首先对水产品撮合交易业务流程进行梳理和分析，构建基于区块链的水产品撮合交易模型；然后，阐述本模型中的供需匹配算法和智能合约设计方案；最后，以Hyperledger Fabric为底层架构，构建基于该模型的原型系统，并结合案例对所设计的原型系统进行验证和分析。

1 基于区块链的水产品撮合交易机制模型

为了解决水产品线上交易平台监管难度大、安全漏洞多的问题，缓解水产品易腐性与当前交易匹配效率低的矛盾，本文提出基于区块链的水产品撮合交易机制模型。该模型设计智能合约实现交易数据上链及交易匹配等功能，并以联盟链平台Hyperledger Fabric为底层架构实现水产品自动撮合交易过程。

1.1 水产品撮合交易业务流程

水产品撮合交易中包括3类参与对象,即买方企业、卖方企业以及平台企业自身。其中,买卖双方在向平台递交商品的交易信息后,平台将依据交易信息的约束条件(如价格、鲜活度、配送距离、品种、数量、尺寸等),完成双方交易自动优化匹配任务。

水产品交撮合交易流程主要包括企业注册、商品供应单信息上传、商品需求单信息上传、交易撮合、交易状态确认等5个过程,如图1所示。

图1 水产品撮合交易业务流程Fig.1 Trading matching business process of aquatic products

(1)企业注册。企业申请加入区块链，并自行决定是否作为全节点参与分布式账本的维护或作为轻节点使用系统功能，仅同步与自己相关的数据。区块链收到节点的申请后，监管中心会对其进行验证。联盟链的准入机制通过认证中心(Certification authority，CA)来实现。首先，企业节点向CA机构申请证书，节点获得证书后携带证书申请入链；之后，区块链网络会向CA机构验证证书的真伪并决定是否同意节点加入区块链。验证通过之后，水产品销售企业与水产品消费企业通过提交公司名称、法定代表人和社会信用代码等企业信息注册成为交易平台用户。平台会根据注册信息对该企业的合法性进行核实，保证唯一社会信用代码没有重复，完成企业交易资质认证。

(2)供应单信息上传。卖方企业发布相应的供应单信息，系统判断供应单中商品数量是否大于0，并通过核查其他商品属性字段是否合法对供应单信息进行校验，校验通过的供应单由区块链分布式网络共识上链。

(3)需求单信息上链。买方企业发布相应的需求单信息，系统判断需求单中商品数量是否大于0，并通过核查其他商品属性字段是否合法对需求单信息进行校验，校验通过的需求单由区块链分布式网络共识上链。

(4)交易撮合。系统收集某一时段内用户上传的供应单和需求单，调用供需匹配算法进行撮合匹配，并将匹配结果反馈给用户。

(5)交易状态确认。用户可根据系统自动匹配结果决定是否与匹配方进行交易，通过上传电子签名选择同意或拒绝交易。若匹配双方都同意该匹配结果，则交易合同成立，用户需要按照交易合同的成交量和成交价格进行交易；若匹配双方至少有一方拒绝该匹配结果，则交易合同失效，用户可自行决定继续下一轮匹配或撤销供需单。系统将调用智能合约对双方确认匹配的交易合同进行上链。之后，买卖双方完成交易物流配送过程并在平台上对交易的完成状态进行确认。交易完成后，买卖双方可以随时查询已上链的历史交易合同，防止双方的不诚信行为，同时可以在出现水产品质量等问题时作为交易信用凭证。

1.2 水产品撮合交易机制模型

在图1的业务流程基础上构建了如图2所示的水产品撮合交易机制模型。该模型基于区块链技术通过撰写智能合约实现了企业注册信息、商品供应信息、商品需求信息、交易合同信息的上链存储、查询以及交易的撮合匹配。

图2描述了水产品撮合交易模型中数据共识上链逻辑。共识采用实用拜占庭容错共识算法(Practical byzantine fault tolerance, PBFT)，在对等(Peer-to-peer networking，P2P)网络上进行，采用非对称加密技术，用户将数据及请求通过客户端(即水产品撮合交易系统平台)经由服务器完成与区块链的数据交互。图2中以供应单信息上链为例，描述了数据在区块中的存储结构。区块之间按照时间戳的顺序依次连接，上传到链上的供应单信息通过计算得到哈希值，再与其相邻的供应单信息计算得到的哈希值，两两向上取哈希值，不断获得新哈希值，构成Merkel树，并将Merkel树的树根存储在当前区块的块头中。系统的企业信息、供需单信息由用户上传，并由系统调用相应的智能合约共识上链。某个时段内的供需单信息通过撮合匹配算法得到交易匹配结果，暂存在中心化数据库中交由用户确认。用户在客户端完成交易匹配结果的确认，若双方均同意则生成订单记录并通过智能合约将交易合同信息上链。交易完成后，用户在客户端对订单是否完成进行确认，并将订单完成结果保存在中心化数据库。

在水产品交易供需匹配环节，为最大化匹配精度和效率，本模型引入启发式算法——蚁群算法来进行寻优求解。供需匹配模型采用间隔型，即需要统计某一时段内提交的供需单总量来对该时段内的供需单进行匹配。本文将一天分为12个时段，记作12个匹配周期，每2 h整点进行交易匹配，如图2所示。买卖双方企业可以在一天中的任意时刻上传各自的供应单和需求单。在每个交易周期内系统会统计上一个周期内上传的供应单和需求单进行撮合匹配。假设匹配周期数为T，那么周期T内匹配的为周期T-1内上传的供应单和需求单，而周期T上传的需求单和供应单将在周期T+1进行匹配。该模型可以确保该交易周期的匹配结果不会对下一交易周期的匹配产生影响，且任意时刻上传的供需单都可以被系统收集并完成匹配。以图2所标记的时段为例，记10：00—12：00为交易周期T-1、12：00—14：00为交易周期T、14：00—16：00为交易周期T+1，水产品撮合匹配流程如下：

图2 水产品撮合交易机制模型Fig.2 Trading matching mechanism model of aquatic products

水产品买卖双方根据销售和购买需求上传各自的供应单和需求单至联盟链平台Hyperledger Fabric。在周期T内，系统在12：00—12：30时段内(30 min内)收集周期T-1内上传的供需单，并调用含有蚁群匹配算法的智能合约完成交易的撮合匹配，将交易匹配结果反馈给买卖企业。水产品企业需要在12：30—13：30时段内(60 min内)完成对交易结果的确认，防止其影响下一交易周期的匹配。在13：30—14：00时段内(30 min内)系统根据买卖双方的确认结果进行水产品交易合同上链，同时标记已完成匹配的供需单。

2 关键技术

2.1 供需匹配算法

蚁群算法(Ant colony optimization, ACO)，又称蚂蚁算法，是一种模拟蚂蚁觅食行为的启发式算法，用来在图中寻找优化路径，在旅行商问题、复杂网络、深度学习、数据处理等问题应用普遍[36-38]，可作为处理双边匹配问题的有效途径。本文采用基于历史状态转移的蚁群算法[39]。设需求和供应双方分别为D={di|1

输入：D=(D1,D2,…,Dm)、S=(S1,S2,…,Sn)

输出：Result={(D1,S3),(D2,S1),…,(Dm,Sk)}

其中，Sk为S中与Dm相匹配的供应方个体，k∈[1,n]。

本系统使用的蚁群算法如下：

function Match(){

while(m<=M){ ∥进行M次实验

initial c0、α、β ∥初始化参数

while(nc<=NC){ ∥每次实验迭代NC次

randomly choose an initial target ∥随机选择一个蚂蚁作为初始方

for i = 1 to n { ∥每次迭代有n只蚂蚁

choose next target with probability } ∥根据轮盘赌法确定下一只蚂蚁

calculate the evaluation value for each matching result of this iteration ∥计算评价值

update the global pheromone } ∥更新全局信息素

update new value c0、α、β} ∥更新参数

print result}

其中，按照属性的不同类型将水产品交易匹配属性分为硬约束型、收益型、成本型和区间型，如表1所示。成本型、收益型和区间型统称为软约束型。硬约束型是指该属性必须满足；成本型是指其值越小越好的属性；收益型是指其值越大越好的属性；区间型是指其必须在某个区间内的属性。

表1 匹配属性Tab.1 Matching attributes

根据水产品的交易属性定义的上链数据，即需求单和供应单的字段表，供应单包括Key、卖方企业Key、提交时间、数量、最低价格、最高价格、品种、鲜活度、尺寸和出货地址10个字段；需求单包含Key、买方企业Key、提交时间、数量、期望最低价格、期望最高价格、品种、鲜活度、尺寸和收货地址10个字段。其中Key是企业上传供需单时由系统自动生成的，提交时间Time根据数据上传时所在区块的时间戳获取，买卖方企业Key是系统识别登录用户的编号自动填补的；而收货地址和出货地址则对应着配送距离，配送距离为收货地址和出货地址之间的直线距离，供应单和需求单的字段见表2和表3。

表2 供应单字段表Tab.2 Supply order fields

表3 需求单字段Tab.3 Demand order fields

2.2 智能合约设计

智能合约最早由美国密码学家尼克·萨博提出，是运用于区块链上的一段代码[40]。智能合约是以数字形式定义的承诺，控制着数字资产并包含了合约参与者约定的权利和义务，是一个用计算机编程语言取代传统法律语言记录条款内容的协议[41]。

本文涉及的智能合约如下：

(1)企业注册函数(CompanyRegister)。买卖双方上传本企业的名称、法定代表人及社会信用代码，系统审查企业注册信息是否合法，即企业名称是否注册、法定代表人身份是否有效以及社会信用代码是否唯一且可查证。若企业注册信息合法则调用企业注册函数，将企业信息进行上链，保证水产品撮合交易平台上参与交易的企业身份合法，以降低非法企业发生不诚信行为的概率。

输入：企业名称Name、社会信用代码UnifiedSocialCreditId、LegalPerson。

企业注册函数代码逻辑如下：

function CompanyRegister(args []string){

KeyAsBytes := stub.GetState

if KeyAsBytes != nil{

return false} ∥检查该企业是否已存在

Company := &Company{ObjectType, Key, Name, UnifiedSocialCreditId, LegalPerson} ∥创建企业对象

CompanyJsonAsBytes := json.Marshal(Company)

∥数据序列化

stub.PutState(Key, CompanyJsonAsBytes)

∥将注册信息上链

return shim.Success(nil)} ∥返回注册结果

(2)供需单提交函数(SubmitDemandList、SubmitSupplyList)。企业根据自身实际需要上传供需单信息，系统响应用户的上传需求，调用供需单提交函数，将企业的供应单和需求单信息广播到区块链网络的各节点，背书节点完成背书操作之后发给各节点，共识节点对所传数据进行共识。鉴于供需单提交函数代码逻辑相似，此处以需求单提交函数为例，阐述其代码逻辑。

输入：需求方企业编号 CreateCompanyKey、数量Amount、期望最低价格PriceLow、期望最高价格PriceHigh、品种Breed、鲜活度Fresh、尺寸Size、收货地址Address。

需求单提交函数代码逻辑如下：

function SubmitDemandList(args []string){

KeyAsBytes := stub.GetState

if KeyAsBytes != nil{

return false} ∥检查该需求单是否已存在

DemandList := &DemandList{ObjectType, Key, CreateCompanyKey, Amount, PriceLow,PriceHigh, Breed, Fresh, Size, Address} ∥创建需求单对象

DemandListJsonAsBytes:=json.Marshal(DemandList) ∥数据序列化

stub.PutState(Key, DemandListJsonAsBytes)

∥将需求单信息上链

return shim.Success(nil) } ∥返回上传成功结果

(3)撮合匹配函数(Match)。系统从链上查询一个周期内(2h)买卖双方上传的所有供应单和需求单，构成供应单集合和需求单集合，通过蚁群算法根据双方的匹配属性进行匹配度计算，完成寻优求解。其代码逻辑见2.1节供需匹配算法部分。

(4)交易合同上传函数(SubmitContract)。当买卖双方均同意系统的匹配结果时，系统调用交易合同上链函数，保留匹配双方的交易凭证。交易合同上传代码逻辑如下：

输入：需求方企业编号 FirstCompanyKey、供应方企业编号SecondCompanyKey、品种Breed、数量Amount、价格TotalPrice、鲜活度Fresh、尺寸Size、收货地址FirstAddress、出货地址SecondAddress、运输距离Distance。

function SubmitContract(args []string){

KeyAsBytes := stub.GetState(Key)

if KeyAsBytes != nil{

return false} ∥检查该交易合同是否已存在

Contract := &Contract{ObjectType, Key, FirstCompanyKey, SecondCompanyKey, Breed, Amount, TotalPrice, Fresh, Size, FirstAddress, SecondAddress, Distance}

∥创建交易合同对象

ContractJsonAsBytes,err:=json.Marshal(Contract)

∥数据序列化

stub.PutState(Key, ContractJsonAsBytes) ∥将交易合同上链

return shim.Success(nil) } ∥返回上链结果

(5)信息查询函数(GetDataByKey、GetDataByCreateCompany、ContractQuery)。信息查询函数包含3种，分别是键查询、创建者查询和合同查询。键查询指的是通过Key查询链上数据，可用于商品信息查询、企业信息查询、交易合同查询、供应单查询和需求单查询；创建者查询指的是通过上传数据的企业主键查询链上数据，可用于需求单查询、供应单查询；合同查询指的是通过上传数据的企业主键以及买卖方标记字段(0代表买方，1代表卖方)查询链上的合同信息，可用于交易合同查询。以通过Key查询需求单信息为例，其代码逻辑如下：

输入：需求单编号Key

输出：需求单信息

function Query(args []string){

Key := args[0]

KeyAsBytes, err := stub.GetState(Key) ∥获取数据

if KeyAsBytes == nil {

return shim.Error("该条数据不存在！")}

∥判断数据是否在链上

return shim.Success(KeyAsBytes)} ∥返回所查信息

3 系统设计与实现

3.1 系统架构设计

如图3所示，本文设计的水产品撮合交易原型系统的区块链架构主要分为6层：应用层、接口层、智能合约层、存储层、网络层和业务层。

图3 水产品撮合交易系统分层架构Fig.3 Hierarchical structure of aquatic products trading matching system

应用层是整个系统的最顶层，是提供用户操作的可视化界面。系统通过网页前端和APP等途径采集来自企业上传的各种请求信息，包括注册请求、供应单上传请求、需求单上传请求、交易状态确认和交易合同查询请求等。系统收到来自用户的请求后，调用相应的智能合约完成相应的功能。

接口层是连接应用层与智能合约层之间的桥梁和纽带，是智能合约代码的一个支撑，主要是为智能合约的编写提供了一个封装性的语言环境。本系统接口层实现采用的是面向对象Go语言开发环境。

智能合约层由存储在区块链内的功能代码构成，主要分为以下几类函数：企业注册函数(CompanyRegister)、供需单提交函数(Submit-DemandList、SubmitSupplyList)、撮合匹配函数(Match)、交易合同上传函数(SubmitContract)和信息查询函数(GetDataByKey、GetDataByCreate-Company、ContractQuery)。当用户产生信息上链、查询等请求时，系统通过智能合约接口调用相应的智能合约以实现所对应的功能。

存储层接收来自网络层聚合转发之后的数据，将验证后的数据上链。存储层主要由3个部分构成，分别为区块链、中心化数据库以及CouchDB。系统选用CouchDB数据库作为状态数据库。建立状态数据库便于方便快捷地查询链上数据，同时相较于LevelDB，CouchDB支持富查询的功能。CouchDB数据库中数据存储的是JSON (JavaScript Object Notation)格式，可以使用JSON工具包中的json.Marshal()方法将数据序列化为JSON字符串，使用json.Unmarshal()进行反序列化，实现智能合约中的数据与状态数据库中数据的转化。链上的数据以Merkle树的形式存储在块体中，区块内的数据不可篡改、不可删除。部分非敏感数据存储在平台中心化数据库中，以维护系统数据流的完整。

网络层包括共识算法和节点身份认证。共识算法是一种可以在互不信任的节点之间建立信任、获取权益的数学算法。代表性的共识算法有比特币系统采用的工作量证明机制(Proof of work, POW)、以太坊采用的权益证明算法(Proof of stake, POS)、委权权益证明算法(Delegated proof of stake, DPOS)等，本文采用联盟链中常用的实用拜占庭容错算法PBFT。PBFT算法有着很强的适应性，可以容忍经典拜占庭故障模型，能够更大程度地保证系统的安全性。即使出现节点故障或不诚信节点恶意攻击等情况，区块链系统上已经发生的交易也能够按照预期方式执行。用户在前端上传的注册信息、供需单信息、状态确认信息等在网络层通过共识算法进行聚合转发，完成对数据的共识上链。节点身份认证模块主要负责企业节点的身份认证。Fabric是一个许可网络，水产品企业想要加入区块链参与维护分布式账本需要向Fabric中的其他节点证明自己的身份。在Fabric中，CA机构生成的公钥和私钥可以形成一对公私密钥来证明身份，使用其私钥对用户的公钥进行加密可以形成数字签名。公钥、私钥和数字签名最后将返回给用户，并由用户提交给监管中心进行验证。监管中心审核登记后，企业即可成为法定节点。

业务层是系统可以实现的功能。本系统主要包括身份认证和交易匹配两大核心功能。身份认证功能主要指系统通过企业注册信息完成对水产品企业的资质审查，保证所有注册后参与水产品交易的企业都是合法企业。交易匹配是指用户可以根据供需实际要求，通过系统自动化实现交易的撮合过程，获得匹配结果，并按照上链的交易合同完成线下交易和结算，必要时可以向系统查询交易记录来维护自己的合法权益等。

3.2 系统实现

本系统采用联盟链平台 Hyperledger Fabric为底层架构，配置支持富查询的CouchDB作为Fabric中的状态数据库，中心化数据库采用SQL Server，借助面向对象语言Go完成智能合约的开发，使用基于C#的Windows窗体应用完成前端界面的设计。

实验环境采用64位Ubuntu搭建，版本为Ubuntu 16.04，为其分配8 GB内存，100 GB磁盘空间，再通过应用容器引擎技术Docker下载架构中每个模块的图像，版本为Docker 20.10.7，Hyperledger Fabric版本为1.4.4，实现通过智能合约连接数据的区块链系统。布署4台主机作为服务器，测试系统的功能和性能，确保安全的分布式信息共享，提高系统的稳定性。

本文整理了各大生鲜电商平台上的水产品交易信息，通过访谈和问卷调研了水产品买卖双方企业的需求偏好，并据此来设计仿真实验。以某天中的10:00—14:00为例，设10：00—12：00为时段T、12：00—14：00为时段T+1，实验假设在时段T内系统收集到来自卖方和买方提交的供应单和需求单各10条数据，如表4、5所示。

表4 供应单信息Tab.4 Supply orders

本文中水产品“鲜活度”参考的标准为SC/T 3048—2014(鱼类鲜度指标K值的测定：高效液相色谱法)[42]。K值是腺苷三磷酸降解产物次黄嘌呤核苷、次黄嘌呤量之和与腺苷三磷酸关联化合物总量的百分比。根据文献[43-44]中关于水产品K值与新鲜度关联的描述，本文中将K值低于10%(不含10%)的新鲜度设为鲜活度等级3(非常新鲜)，将K值位于10%～20%(不含20%)的水产品新鲜度设为等级2(比较新鲜)，将K值位于20%～50%(含50%)的水产品新鲜度设为等级1(适度新鲜)，将K值高于50%的水产品新鲜度设为等级0(不新鲜)。原则上K值高于50%的水产品不被认为可以进行交易，因此本系统中的水产品鲜活度从低到高分为等级1、2、3。

为完成撮合交易，参与仿真实验的20家企业首先需要向联盟链平台 Hyperledger Fabric提交节点准入申请。通过之后，通过图4所示的系统前端界面，输入合法的公司名称、法定代表人、社会信用代码、密码等信息注册，完成资质审核，成为系统用户，其注册信息通过智能合约上链。

图4 用户注册界面Fig.4 User registration interface

买卖双方登录系统后，可以通过前端界面上传各自的供应单和需求单，如图5、6所示。收到用户的供需单上传请求后，系统调用智能合约接口对供需单数据进行检验并上链。

图5 供应单上传Fig.5 Submitting of supply order

图6 需求单上传Fig.6 Submitting of demand order

系统在时段T+1(12：00—14：00)收集时段T内(10：00—12：00)用户上传的供应单(表4)和需求单(表5)，并调用智能合约Match函数进行交易匹配，匹配结果如图7所示，本次匹配耗时2.3 s，全局最优求解形成了10个交易匹配对，最终偏好序和为122。

表5 需求单信息Tab.5 Demand orders

图7 时段T的匹配结果Fig.7 Matching results for period T

偏好序和表示买方对卖方偏好的排序与卖方对买方偏好的排序之和，偏好序和越小表示所有(全局)买卖双方对对方的偏好度排序越靠前，即双方的全局满意度越高。假设用1～10的数值代表对对方的偏好排序，1代表最喜欢，10代表最不喜欢。根据偏好序和的计算公式，当匹配对的个数为n时，偏好序和的取值范围一般为[2n,20n]。本实施例的匹配对为10，偏好序和的取值合理范围为20～200，蚁群算法计算的匹配结果中偏好序和为122，在可以接受的范围内。

匹配完成后，系统会将匹配结果存储在中心数据库中，用户可在前端看到自己所上传的供需单的匹配结果。以编号为54000的企业为例，该用户看到的时段T企业上传的需求单(编号84006)的匹配的供应单编号为72010，如图8所示。用户可在此界面选择是否同意该匹配结果，以便系统对此匹配结果形成交易合同并上链。此外，用户还可在此界面查看上链的历史交易合同记录，根据线下交易完成情况对交易的完成状态进行确认。若超过线下交易规定的时间上限(本系统设置为10 d)，系统将根据上链的交易合同自动确认线下交易完成状态。

图8 匹配结果用户可视化界面Fig.8 User matching result interface

3.3 系统性能测试

3.3.1系统测试结果

在Hyperledger Fabric实验环境下安装测试软件Caliper对系统模型进行测试。测试当交易数据量分别为50、100、200、1 000、1 626(此时对应 0.5 h)、2 000条时，交易的匹配时间。系统需要在0.5 h(即1 800 s)内完成供需双方的交易信息匹配。测试结果显示：0.5 h内，系统最多能匹配的数据量为1 626条，测试结果如图9所示。

图9 水产品交易匹配时间变化曲线Fig.9 Matching time curve of aquatic products trading

设计的撮合交易系统模型要求在时段T+1的前0.5 h进行交易匹配，即交易撮合匹配时间不能超过1 800 s。如图9所示，当交易匹配时间为 1 800 s 时，交易数据量为1 626条，即当时段T内交易数据量不超过1 626条时，系统能够较好地完成买卖双方的自动化交易匹配。水产品撮合交易模型适用于B2B电子商务平台，B2B平台2 h内收集到的交易数据量一般不会超过1 626条，因此，本文设计的水产品自动化撮合交易系统模型可以满足日常实际交易的需求。

3.3.2与传统水产品交易系统对比

传统水产品交易系统主要有以下3个缺陷：①采用中心化数据库，数据易受攻击，信息安全难以保证。②达成交易匹配耗时长。传统水产品交易系统通常是靠消费者自己完成信息搜集、对比和筛选匹配，交易双方企业均需要花费大量的时间和精力进行交易对象的筛选。③监管力度不足，水产品质量难以保证，无法避免虚假商品和交易信息的产生，不利于买卖双方建立友好互信合作关系。相对应地，本文所提出的水产品撮合交易模型和系统的优势在于：采用区块链架构，数据去中心化共识上链，使用PBFT共识机制，能够包容一定比例的非法节点，提高了信息和系统的安全性；使用蚁群算法完成供需单匹配，缩短了匹配时间并提高了匹配准确性，大大提升了交易双方的匹配效率；区块链的每个区块块头都有时间戳，同时后一个区块需要存储前一个区块的哈希值，因此企业注册信息、供应单信息、需求单信息、交易合同等数据上链后无法篡改且可追溯，保证了交易记录的有效和不可篡改。同时，企业信息上链前，系统会对企业唯一的社会信用代码进行核验，确保参与交易的企业都是合法企业，保障了交易对象的安全可靠。

4 结束语

将区块链技术引入水产品流通的交易环节中，弥补了现有研究的不足。首先，在分析了传统水产品线上交易平台的缺陷后，梳理了基于区块链架构的水产品线上撮合交易业务流程，构建了水产品撮合交易区块链模型。针对传统水产品撮合匹配效率低的问题，构建基于价格、配送距离、新鲜度等多属性的水产品撮合供需匹配模型，并采用启发式蚁群算法对模型进行寻优求解。然后，进一步提出了基于区块链的水产品撮合交易系统的体系架构和设计方案，并基于联盟链平台Hyperledger Fabric给出了该系统的实现过程。最后，结合具体仿真案例，验证了该交易模型和系统的可行性和有效性。结果表明：基于区块链的水产品撮合交易模型通过智能合约可以实现企业注册信息上链、供应单信息上链、需求单信息上链、撮合匹配、交易合同上链和相关链上数据高效查询的功能，在每一个匹配周期(2 h)设定的0.5 h匹配时间内，支持的最高交易数据量达到1 626条，设计的水产品自动化撮合交易系统可以满足日常B2B平台实际水产品交易的需求。基于区块链的水产品撮合交易模型和系统保障了交易企业信息、产品信息、合同信息的安全性，极大地提高了水产品线上撮合交易的效率，降低了水产品交易平台的监督成本和难度，为水产品中介和买卖双方提供了一个公开、透明、可信的自动化交易方案。