基于區塊鏈的水產品撮合交易模型與系統實現

王文娟 張 旭 陳 明 鄒一波 葛 艷

(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平臺實際水產品交易的需求。基于區塊鏈的水產品撮合交易模型和系統保障了交易企業信息、產品信息、合同信息的安全性，極大地提高了水產品線上撮合交易的效率，降低了水產品交易平臺的監督成本和難度，為水產品中介和買賣雙方提供了一個公開、透明、可信的自動化交易方案。