基于區(qū)塊鏈的水產(chǎn)品撮合交易模型與系統(tǒng)實現(xiàn)

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

(1.上海海洋大學(xué)信息學(xué)院， 上海 201306; 2.農(nóng)業(yè)農(nóng)村部漁業(yè)信息重點實驗室， 上海 201306)

0 引言

近年來，以水產(chǎn)品為主打品牌的生鮮電商已經(jīng)在生鮮市場中占據(jù)著不可或缺的位置。將水產(chǎn)品交易由傳統(tǒng)線下為主的貿(mào)易方式轉(zhuǎn)移到線上平臺為水產(chǎn)品的流通帶來了極大的便利。然而，當(dāng)前的水產(chǎn)品電商平臺以提供信息共享功能為主，不論是傳統(tǒng)貿(mào)易方式還是現(xiàn)存的生鮮電商平臺，買賣雙方仍然存在著信息不對等的情況。水產(chǎn)品作為一種易腐商品，對交易的時效性有著極高的要求，若不能在較短的時間內(nèi)完成交易匹配會大大提高水產(chǎn)品的損耗率[1]。此外，現(xiàn)存的水產(chǎn)品電商交易平臺還存在著用戶信息泄露和商品信息造假等安全漏洞[2]。針對以上問題，亟需一種新的解決方案，提高交易匹配效率，增強平臺監(jiān)管力度并降低監(jiān)管成本，同時保障買賣雙方的隱私和信息安全。

區(qū)塊鏈?zhǔn)窃趯Φ染W(wǎng)絡(luò)環(huán)境下，通過透明可信的規(guī)則，按照時間戳序列，不可偽造、篡改和可追蹤的數(shù)據(jù)結(jié)構(gòu)，可以實現(xiàn)和管理交易處理過程，保障交易數(shù)據(jù)的安全性[3]。每個區(qū)塊由區(qū)塊頭和區(qū)塊體構(gòu)成。區(qū)塊頭里存有上一個區(qū)塊的哈希值。前一個區(qū)塊中的數(shù)據(jù)如果發(fā)生改變則連同后面所有區(qū)塊的哈希值都需要改變，以達(dá)到數(shù)據(jù)防篡改的目的。區(qū)塊鏈集成了共識機制、分布式數(shù)據(jù)存儲、點對點傳輸、密碼學(xué)等技術(shù)，受到國內(nèi)外學(xué)者的廣泛關(guān)注[4]。將區(qū)塊鏈引入水產(chǎn)品領(lǐng)域是解決水產(chǎn)品交易平臺監(jiān)管難度大、提高數(shù)據(jù)安全性和交易匹配效率的有效途徑。

目前，國內(nèi)外學(xué)者主要將區(qū)塊鏈技術(shù)引入到食品質(zhì)量安全溯源體系(含水產(chǎn)品質(zhì)量溯源)，結(jié)合物聯(lián)網(wǎng)技術(shù)提出了一些特定應(yīng)用場景下食品供應(yīng)鏈或全產(chǎn)業(yè)鏈的區(qū)塊鏈安全架構(gòu)[5-11]。其他學(xué)者則從微觀視角側(cè)重于農(nóng)產(chǎn)品或水產(chǎn)品質(zhì)量溯源過程中數(shù)據(jù)存儲結(jié)構(gòu)和效率[12-19]、身份認(rèn)證機制[20-22]、共識算法優(yōu)化[23-25]等研究內(nèi)容。然而，目前質(zhì)量安全追溯體系相關(guān)研究大部分未涵蓋線上交易環(huán)節(jié)。該環(huán)節(jié)作為水產(chǎn)品流通的最后階段，對于構(gòu)建完整的水產(chǎn)品供應(yīng)鏈具有重要作用。馮國富等[26]提出基于區(qū)塊鏈的水產(chǎn)品撮合交易溯源系統(tǒng)模型，將交易記錄加密后對數(shù)據(jù)地址進(jìn)行上鏈，但是仍然沒有將交易過程上鏈。此外，現(xiàn)有少數(shù)的基于區(qū)塊鏈的撮合交易機制研究主要集中在電能源領(lǐng)域[27-34]，且目標(biāo)函數(shù)始終圍繞價格單因素展開，與水產(chǎn)品撮合交易場景不完全相符。水產(chǎn)品撮合交易過程中，不僅關(guān)注價格，對商品的配送距離、鮮活度、購買品種、數(shù)量、尺寸等屬性也有約束。周超等[35]首次嘗試構(gòu)建水產(chǎn)品線上交易匹配模型，并使用鳥群覓食算法對模型進(jìn)行求解,證明了算法的可行性,但該研究并未涉及線上交易平臺的安全與隱私保障等問題。考慮到水產(chǎn)品撮合交易多屬性匹配的特點，并融入?yún)^(qū)塊鏈技術(shù)保障其交易安全性的研究鮮見報道。

本文首先對水產(chǎn)品撮合交易業(yè)務(wù)流程進(jìn)行梳理和分析，構(gòu)建基于區(qū)塊鏈的水產(chǎn)品撮合交易模型；然后，闡述本模型中的供需匹配算法和智能合約設(shè)計方案；最后，以Hyperledger Fabric為底層架構(gòu)，構(gòu)建基于該模型的原型系統(tǒng)，并結(jié)合案例對所設(shè)計的原型系統(tǒng)進(jìn)行驗證和分析。

1 基于區(qū)塊鏈的水產(chǎn)品撮合交易機制模型

為了解決水產(chǎn)品線上交易平臺監(jiān)管難度大、安全漏洞多的問題，緩解水產(chǎn)品易腐性與當(dāng)前交易匹配效率低的矛盾，本文提出基于區(qū)塊鏈的水產(chǎn)品撮合交易機制模型。該模型設(shè)計智能合約實現(xiàn)交易數(shù)據(jù)上鏈及交易匹配等功能，并以聯(lián)盟鏈平臺Hyperledger Fabric為底層架構(gòu)實現(xiàn)水產(chǎn)品自動撮合交易過程。

1.1 水產(chǎn)品撮合交易業(yè)務(wù)流程

水產(chǎn)品撮合交易中包括3類參與對象,即買方企業(yè)、賣方企業(yè)以及平臺企業(yè)自身。其中,買賣雙方在向平臺遞交商品的交易信息后,平臺將依據(jù)交易信息的約束條件(如價格、鮮活度、配送距離、品種、數(shù)量、尺寸等),完成雙方交易自動優(yōu)化匹配任務(wù)。

水產(chǎn)品交撮合交易流程主要包括企業(yè)注冊、商品供應(yīng)單信息上傳、商品需求單信息上傳、交易撮合、交易狀態(tài)確認(rèn)等5個過程,如圖1所示。

圖1 水產(chǎn)品撮合交易業(yè)務(wù)流程Fig.1 Trading matching business process of aquatic products

(1)企業(yè)注冊。企業(yè)申請加入?yún)^(qū)塊鏈，并自行決定是否作為全節(jié)點參與分布式賬本的維護(hù)或作為輕節(jié)點使用系統(tǒng)功能，僅同步與自己相關(guān)的數(shù)據(jù)。區(qū)塊鏈?zhǔn)盏焦?jié)點的申請后，監(jiān)管中心會對其進(jìn)行驗證。聯(lián)盟鏈的準(zhǔn)入機制通過認(rèn)證中心(Certification authority，CA)來實現(xiàn)。首先，企業(yè)節(jié)點向CA機構(gòu)申請證書，節(jié)點獲得證書后攜帶證書申請入鏈；之后，區(qū)塊鏈網(wǎng)絡(luò)會向CA機構(gòu)驗證證書的真?zhèn)尾Q定是否同意節(jié)點加入?yún)^(qū)塊鏈。驗證通過之后，水產(chǎn)品銷售企業(yè)與水產(chǎn)品消費企業(yè)通過提交公司名稱、法定代表人和社會信用代碼等企業(yè)信息注冊成為交易平臺用戶。平臺會根據(jù)注冊信息對該企業(yè)的合法性進(jìn)行核實，保證唯一社會信用代碼沒有重復(fù)，完成企業(yè)交易資質(zhì)認(rèn)證。

(2)供應(yīng)單信息上傳。賣方企業(yè)發(fā)布相應(yīng)的供應(yīng)單信息，系統(tǒng)判斷供應(yīng)單中商品數(shù)量是否大于0，并通過核查其他商品屬性字段是否合法對供應(yīng)單信息進(jìn)行校驗，校驗通過的供應(yīng)單由區(qū)塊鏈分布式網(wǎng)絡(luò)共識上鏈。

(3)需求單信息上鏈。買方企業(yè)發(fā)布相應(yīng)的需求單信息，系統(tǒng)判斷需求單中商品數(shù)量是否大于0，并通過核查其他商品屬性字段是否合法對需求單信息進(jìn)行校驗，校驗通過的需求單由區(qū)塊鏈分布式網(wǎng)絡(luò)共識上鏈。

(4)交易撮合。系統(tǒng)收集某一時段內(nèi)用戶上傳的供應(yīng)單和需求單，調(diào)用供需匹配算法進(jìn)行撮合匹配，并將匹配結(jié)果反饋給用戶。

(5)交易狀態(tài)確認(rèn)。用戶可根據(jù)系統(tǒng)自動匹配結(jié)果決定是否與匹配方進(jìn)行交易，通過上傳電子簽名選擇同意或拒絕交易。若匹配雙方都同意該匹配結(jié)果，則交易合同成立，用戶需要按照交易合同的成交量和成交價格進(jìn)行交易；若匹配雙方至少有一方拒絕該匹配結(jié)果，則交易合同失效，用戶可自行決定繼續(xù)下一輪匹配或撤銷供需單。系統(tǒng)將調(diào)用智能合約對雙方確認(rèn)匹配的交易合同進(jìn)行上鏈。之后，買賣雙方完成交易物流配送過程并在平臺上對交易的完成狀態(tài)進(jìn)行確認(rèn)。交易完成后，買賣雙方可以隨時查詢已上鏈的歷史交易合同，防止雙方的不誠信行為，同時可以在出現(xiàn)水產(chǎn)品質(zhì)量等問題時作為交易信用憑證。

1.2 水產(chǎn)品撮合交易機制模型

在圖1的業(yè)務(wù)流程基礎(chǔ)上構(gòu)建了如圖2所示的水產(chǎn)品撮合交易機制模型。該模型基于區(qū)塊鏈技術(shù)通過撰寫智能合約實現(xiàn)了企業(yè)注冊信息、商品供應(yīng)信息、商品需求信息、交易合同信息的上鏈存儲、查詢以及交易的撮合匹配。

圖2描述了水產(chǎn)品撮合交易模型中數(shù)據(jù)共識上鏈邏輯。共識采用實用拜占庭容錯共識算法(Practical byzantine fault tolerance, PBFT)，在對等(Peer-to-peer networking，P2P)網(wǎng)絡(luò)上進(jìn)行，采用非對稱加密技術(shù)，用戶將數(shù)據(jù)及請求通過客戶端(即水產(chǎn)品撮合交易系統(tǒng)平臺)經(jīng)由服務(wù)器完成與區(qū)塊鏈的數(shù)據(jù)交互。圖2中以供應(yīng)單信息上鏈為例，描述了數(shù)據(jù)在區(qū)塊中的存儲結(jié)構(gòu)。區(qū)塊之間按照時間戳的順序依次連接，上傳到鏈上的供應(yīng)單信息通過計算得到哈希值，再與其相鄰的供應(yīng)單信息計算得到的哈希值，兩兩向上取哈希值，不斷獲得新哈希值，構(gòu)成Merkel樹，并將Merkel樹的樹根存儲在當(dāng)前區(qū)塊的塊頭中。系統(tǒng)的企業(yè)信息、供需單信息由用戶上傳，并由系統(tǒng)調(diào)用相應(yīng)的智能合約共識上鏈。某個時段內(nèi)的供需單信息通過撮合匹配算法得到交易匹配結(jié)果，暫存在中心化數(shù)據(jù)庫中交由用戶確認(rèn)。用戶在客戶端完成交易匹配結(jié)果的確認(rèn)，若雙方均同意則生成訂單記錄并通過智能合約將交易合同信息上鏈。交易完成后，用戶在客戶端對訂單是否完成進(jìn)行確認(rèn)，并將訂單完成結(jié)果保存在中心化數(shù)據(jù)庫。

在水產(chǎn)品交易供需匹配環(huán)節(jié)，為最大化匹配精度和效率，本模型引入啟發(fā)式算法——蟻群算法來進(jìn)行尋優(yōu)求解。供需匹配模型采用間隔型，即需要統(tǒng)計某一時段內(nèi)提交的供需單總量來對該時段內(nèi)的供需單進(jìn)行匹配。本文將一天分為12個時段，記作12個匹配周期，每2 h整點進(jìn)行交易匹配，如圖2所示。買賣雙方企業(yè)可以在一天中的任意時刻上傳各自的供應(yīng)單和需求單。在每個交易周期內(nèi)系統(tǒng)會統(tǒng)計上一個周期內(nèi)上傳的供應(yīng)單和需求單進(jìn)行撮合匹配。假設(shè)匹配周期數(shù)為T，那么周期T內(nèi)匹配的為周期T-1內(nèi)上傳的供應(yīng)單和需求單，而周期T上傳的需求單和供應(yīng)單將在周期T+1進(jìn)行匹配。該模型可以確保該交易周期的匹配結(jié)果不會對下一交易周期的匹配產(chǎn)生影響，且任意時刻上傳的供需單都可以被系統(tǒng)收集并完成匹配。以圖2所標(biāo)記的時段為例，記10：00—12：00為交易周期T-1、12：00—14：00為交易周期T、14：00—16：00為交易周期T+1，水產(chǎn)品撮合匹配流程如下：

圖2 水產(chǎn)品撮合交易機制模型Fig.2 Trading matching mechanism model of aquatic products

水產(chǎn)品買賣雙方根據(jù)銷售和購買需求上傳各自的供應(yīng)單和需求單至聯(lián)盟鏈平臺Hyperledger Fabric。在周期T內(nèi)，系統(tǒng)在12：00—12：30時段內(nèi)(30 min內(nèi))收集周期T-1內(nèi)上傳的供需單，并調(diào)用含有蟻群匹配算法的智能合約完成交易的撮合匹配，將交易匹配結(jié)果反饋給買賣企業(yè)。水產(chǎn)品企業(yè)需要在12：30—13：30時段內(nèi)(60 min內(nèi))完成對交易結(jié)果的確認(rèn)，防止其影響下一交易周期的匹配。在13：30—14：00時段內(nèi)(30 min內(nèi))系統(tǒng)根據(jù)買賣雙方的確認(rèn)結(jié)果進(jìn)行水產(chǎn)品交易合同上鏈，同時標(biāo)記已完成匹配的供需單。

2 關(guān)鍵技術(shù)

2.1 供需匹配算法

蟻群算法(Ant colony optimization, ACO)，又稱螞蟻算法，是一種模擬螞蟻覓食行為的啟發(fā)式算法，用來在圖中尋找優(yōu)化路徑，在旅行商問題、復(fù)雜網(wǎng)絡(luò)、深度學(xué)習(xí)、數(shù)據(jù)處理等問題應(yīng)用普遍[36-38]，可作為處理雙邊匹配問題的有效途徑。本文采用基于歷史狀態(tài)轉(zhuǎn)移的蟻群算法[39]。設(shè)需求和供應(yīng)雙方分別為D={di|1

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

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

其中，Sk為S中與Dm相匹配的供應(yīng)方個體，k∈[1,n]。

本系統(tǒng)使用的蟻群算法如下：

function Match(){

while(m<=M){ ∥進(jìn)行M次實驗

initial c0、α、β ∥初始化參數(shù)

while(nc<=NC){ ∥每次實驗迭代NC次

randomly choose an initial target ∥隨機選擇一個螞蟻作為初始方

for i = 1 to n { ∥每次迭代有n只螞蟻

choose next target with probability } ∥根據(jù)輪盤賭法確定下一只螞蟻

calculate the evaluation value for each matching result of this iteration ∥計算評價值

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

update new value c0、α、β} ∥更新參數(shù)

print result}

其中，按照屬性的不同類型將水產(chǎn)品交易匹配屬性分為硬約束型、收益型、成本型和區(qū)間型，如表1所示。成本型、收益型和區(qū)間型統(tǒng)稱為軟約束型。硬約束型是指該屬性必須滿足；成本型是指其值越小越好的屬性；收益型是指其值越大越好的屬性；區(qū)間型是指其必須在某個區(qū)間內(nèi)的屬性。

表1 匹配屬性Tab.1 Matching attributes

根據(jù)水產(chǎn)品的交易屬性定義的上鏈數(shù)據(jù)，即需求單和供應(yīng)單的字段表，供應(yīng)單包括Key、賣方企業(yè)Key、提交時間、數(shù)量、最低價格、最高價格、品種、鮮活度、尺寸和出貨地址10個字段；需求單包含Key、買方企業(yè)Key、提交時間、數(shù)量、期望最低價格、期望最高價格、品種、鮮活度、尺寸和收貨地址10個字段。其中Key是企業(yè)上傳供需單時由系統(tǒng)自動生成的，提交時間Time根據(jù)數(shù)據(jù)上傳時所在區(qū)塊的時間戳獲取，買賣方企業(yè)Key是系統(tǒng)識別登錄用戶的編號自動填補的；而收貨地址和出貨地址則對應(yīng)著配送距離，配送距離為收貨地址和出貨地址之間的直線距離，供應(yīng)單和需求單的字段見表2和表3。

表2 供應(yīng)單字段表Tab.2 Supply order fields

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

2.2 智能合約設(shè)計

智能合約最早由美國密碼學(xué)家尼克·薩博提出，是運用于區(qū)塊鏈上的一段代碼[40]。智能合約是以數(shù)字形式定義的承諾，控制著數(shù)字資產(chǎn)并包含了合約參與者約定的權(quán)利和義務(wù)，是一個用計算機編程語言取代傳統(tǒng)法律語言記錄條款內(nèi)容的協(xié)議[41]。

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

(1)企業(yè)注冊函數(shù)(CompanyRegister)。買賣雙方上傳本企業(yè)的名稱、法定代表人及社會信用代碼，系統(tǒng)審查企業(yè)注冊信息是否合法，即企業(yè)名稱是否注冊、法定代表人身份是否有效以及社會信用代碼是否唯一且可查證。若企業(yè)注冊信息合法則調(diào)用企業(yè)注冊函數(shù)，將企業(yè)信息進(jìn)行上鏈，保證水產(chǎn)品撮合交易平臺上參與交易的企業(yè)身份合法，以降低非法企業(yè)發(fā)生不誠信行為的概率。

輸入：企業(yè)名稱Name、社會信用代碼UnifiedSocialCreditId、LegalPerson。

企業(yè)注冊函數(shù)代碼邏輯如下：

function CompanyRegister(args []string){

KeyAsBytes := stub.GetState

if KeyAsBytes != nil{

return false} ∥檢查該企業(yè)是否已存在

Company := &Company{ObjectType, Key, Name, UnifiedSocialCreditId, LegalPerson} ∥創(chuàng)建企業(yè)對象

CompanyJsonAsBytes := json.Marshal(Company)

∥數(shù)據(jù)序列化

stub.PutState(Key, CompanyJsonAsBytes)

∥將注冊信息上鏈

return shim.Success(nil)} ∥返回注冊結(jié)果

(2)供需單提交函數(shù)(SubmitDemandList、SubmitSupplyList)。企業(yè)根據(jù)自身實際需要上傳供需單信息，系統(tǒng)響應(yīng)用戶的上傳需求，調(diào)用供需單提交函數(shù)，將企業(yè)的供應(yīng)單和需求單信息廣播到區(qū)塊鏈網(wǎng)絡(luò)的各節(jié)點，背書節(jié)點完成背書操作之后發(fā)給各節(jié)點，共識節(jié)點對所傳數(shù)據(jù)進(jìn)行共識。鑒于供需單提交函數(shù)代碼邏輯相似，此處以需求單提交函數(shù)為例，闡述其代碼邏輯。

輸入：需求方企業(yè)編號 CreateCompanyKey、數(shù)量Amount、期望最低價格PriceLow、期望最高價格PriceHigh、品種Breed、鮮活度Fresh、尺寸Size、收貨地址Address。

需求單提交函數(shù)代碼邏輯如下：

function SubmitDemandList(args []string){

KeyAsBytes := stub.GetState

if KeyAsBytes != nil{

return false} ∥檢查該需求單是否已存在

DemandList := &DemandList{ObjectType, Key, CreateCompanyKey, Amount, PriceLow,PriceHigh, Breed, Fresh, Size, Address} ∥創(chuàng)建需求單對象

DemandListJsonAsBytes:=json.Marshal(DemandList) ∥數(shù)據(jù)序列化

stub.PutState(Key, DemandListJsonAsBytes)

∥將需求單信息上鏈

return shim.Success(nil) } ∥返回上傳成功結(jié)果

(3)撮合匹配函數(shù)(Match)。系統(tǒng)從鏈上查詢一個周期內(nèi)(2h)買賣雙方上傳的所有供應(yīng)單和需求單，構(gòu)成供應(yīng)單集合和需求單集合，通過蟻群算法根據(jù)雙方的匹配屬性進(jìn)行匹配度計算，完成尋優(yōu)求解。其代碼邏輯見2.1節(jié)供需匹配算法部分。

(4)交易合同上傳函數(shù)(SubmitContract)。當(dāng)買賣雙方均同意系統(tǒng)的匹配結(jié)果時，系統(tǒng)調(diào)用交易合同上鏈函數(shù)，保留匹配雙方的交易憑證。交易合同上傳代碼邏輯如下：

輸入：需求方企業(yè)編號 FirstCompanyKey、供應(yīng)方企業(yè)編號SecondCompanyKey、品種Breed、數(shù)量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}

∥創(chuàng)建交易合同對象

ContractJsonAsBytes,err:=json.Marshal(Contract)

∥數(shù)據(jù)序列化

stub.PutState(Key, ContractJsonAsBytes) ∥將交易合同上鏈

return shim.Success(nil) } ∥返回上鏈結(jié)果

(5)信息查詢函數(shù)(GetDataByKey、GetDataByCreateCompany、ContractQuery)。信息查詢函數(shù)包含3種，分別是鍵查詢、創(chuàng)建者查詢和合同查詢。鍵查詢指的是通過Key查詢鏈上數(shù)據(jù)，可用于商品信息查詢、企業(yè)信息查詢、交易合同查詢、供應(yīng)單查詢和需求單查詢；創(chuàng)建者查詢指的是通過上傳數(shù)據(jù)的企業(yè)主鍵查詢鏈上數(shù)據(jù)，可用于需求單查詢、供應(yīng)單查詢；合同查詢指的是通過上傳數(shù)據(jù)的企業(yè)主鍵以及買賣方標(biāo)記字段(0代表買方，1代表賣方)查詢鏈上的合同信息，可用于交易合同查詢。以通過Key查詢需求單信息為例，其代碼邏輯如下：

輸入：需求單編號Key

輸出：需求單信息

function Query(args []string){

Key := args[0]

KeyAsBytes, err := stub.GetState(Key) ∥獲取數(shù)據(jù)

if KeyAsBytes == nil {

return shim.Error("該條數(shù)據(jù)不存在！")}

∥判斷數(shù)據(jù)是否在鏈上

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

3 系統(tǒng)設(shè)計與實現(xiàn)

3.1 系統(tǒng)架構(gòu)設(shè)計

如圖3所示，本文設(shè)計的水產(chǎn)品撮合交易原型系統(tǒng)的區(qū)塊鏈架構(gòu)主要分為6層：應(yīng)用層、接口層、智能合約層、存儲層、網(wǎng)絡(luò)層和業(yè)務(wù)層。

圖3 水產(chǎn)品撮合交易系統(tǒng)分層架構(gòu)Fig.3 Hierarchical structure of aquatic products trading matching system

應(yīng)用層是整個系統(tǒng)的最頂層，是提供用戶操作的可視化界面。系統(tǒng)通過網(wǎng)頁前端和APP等途徑采集來自企業(yè)上傳的各種請求信息，包括注冊請求、供應(yīng)單上傳請求、需求單上傳請求、交易狀態(tài)確認(rèn)和交易合同查詢請求等。系統(tǒng)收到來自用戶的請求后，調(diào)用相應(yīng)的智能合約完成相應(yīng)的功能。

接口層是連接應(yīng)用層與智能合約層之間的橋梁和紐帶，是智能合約代碼的一個支撐，主要是為智能合約的編寫提供了一個封裝性的語言環(huán)境。本系統(tǒng)接口層實現(xiàn)采用的是面向?qū)ο驡o語言開發(fā)環(huán)境。

智能合約層由存儲在區(qū)塊鏈內(nèi)的功能代碼構(gòu)成，主要分為以下幾類函數(shù)：企業(yè)注冊函數(shù)(CompanyRegister)、供需單提交函數(shù)(Submit-DemandList、SubmitSupplyList)、撮合匹配函數(shù)(Match)、交易合同上傳函數(shù)(SubmitContract)和信息查詢函數(shù)(GetDataByKey、GetDataByCreate-Company、ContractQuery)。當(dāng)用戶產(chǎn)生信息上鏈、查詢等請求時，系統(tǒng)通過智能合約接口調(diào)用相應(yīng)的智能合約以實現(xiàn)所對應(yīng)的功能。

存儲層接收來自網(wǎng)絡(luò)層聚合轉(zhuǎn)發(fā)之后的數(shù)據(jù)，將驗證后的數(shù)據(jù)上鏈。存儲層主要由3個部分構(gòu)成，分別為區(qū)塊鏈、中心化數(shù)據(jù)庫以及CouchDB。系統(tǒng)選用CouchDB數(shù)據(jù)庫作為狀態(tài)數(shù)據(jù)庫。建立狀態(tài)數(shù)據(jù)庫便于方便快捷地查詢鏈上數(shù)據(jù)，同時相較于LevelDB，CouchDB支持富查詢的功能。CouchDB數(shù)據(jù)庫中數(shù)據(jù)存儲的是JSON (JavaScript Object Notation)格式，可以使用JSON工具包中的json.Marshal()方法將數(shù)據(jù)序列化為JSON字符串，使用json.Unmarshal()進(jìn)行反序列化，實現(xiàn)智能合約中的數(shù)據(jù)與狀態(tài)數(shù)據(jù)庫中數(shù)據(jù)的轉(zhuǎn)化。鏈上的數(shù)據(jù)以Merkle樹的形式存儲在塊體中，區(qū)塊內(nèi)的數(shù)據(jù)不可篡改、不可刪除。部分非敏感數(shù)據(jù)存儲在平臺中心化數(shù)據(jù)庫中，以維護(hù)系統(tǒng)數(shù)據(jù)流的完整。

網(wǎng)絡(luò)層包括共識算法和節(jié)點身份認(rèn)證。共識算法是一種可以在互不信任的節(jié)點之間建立信任、獲取權(quán)益的數(shù)學(xué)算法。代表性的共識算法有比特幣系統(tǒng)采用的工作量證明機制(Proof of work, POW)、以太坊采用的權(quán)益證明算法(Proof of stake, POS)、委權(quán)權(quán)益證明算法(Delegated proof of stake, DPOS)等，本文采用聯(lián)盟鏈中常用的實用拜占庭容錯算法PBFT。PBFT算法有著很強的適應(yīng)性，可以容忍經(jīng)典拜占庭故障模型，能夠更大程度地保證系統(tǒng)的安全性。即使出現(xiàn)節(jié)點故障或不誠信節(jié)點惡意攻擊等情況，區(qū)塊鏈系統(tǒng)上已經(jīng)發(fā)生的交易也能夠按照預(yù)期方式執(zhí)行。用戶在前端上傳的注冊信息、供需單信息、狀態(tài)確認(rèn)信息等在網(wǎng)絡(luò)層通過共識算法進(jìn)行聚合轉(zhuǎn)發(fā)，完成對數(shù)據(jù)的共識上鏈。節(jié)點身份認(rèn)證模塊主要負(fù)責(zé)企業(yè)節(jié)點的身份認(rèn)證。Fabric是一個許可網(wǎng)絡(luò)，水產(chǎn)品企業(yè)想要加入?yún)^(qū)塊鏈參與維護(hù)分布式賬本需要向Fabric中的其他節(jié)點證明自己的身份。在Fabric中，CA機構(gòu)生成的公鑰和私鑰可以形成一對公私密鑰來證明身份，使用其私鑰對用戶的公鑰進(jìn)行加密可以形成數(shù)字簽名。公鑰、私鑰和數(shù)字簽名最后將返回給用戶，并由用戶提交給監(jiān)管中心進(jìn)行驗證。監(jiān)管中心審核登記后，企業(yè)即可成為法定節(jié)點。

業(yè)務(wù)層是系統(tǒng)可以實現(xiàn)的功能。本系統(tǒng)主要包括身份認(rèn)證和交易匹配兩大核心功能。身份認(rèn)證功能主要指系統(tǒng)通過企業(yè)注冊信息完成對水產(chǎn)品企業(yè)的資質(zhì)審查，保證所有注冊后參與水產(chǎn)品交易的企業(yè)都是合法企業(yè)。交易匹配是指用戶可以根據(jù)供需實際要求，通過系統(tǒng)自動化實現(xiàn)交易的撮合過程，獲得匹配結(jié)果，并按照上鏈的交易合同完成線下交易和結(jié)算，必要時可以向系統(tǒng)查詢交易記錄來維護(hù)自己的合法權(quán)益等。

3.2 系統(tǒng)實現(xiàn)

本系統(tǒng)采用聯(lián)盟鏈平臺 Hyperledger Fabric為底層架構(gòu)，配置支持富查詢的CouchDB作為Fabric中的狀態(tài)數(shù)據(jù)庫，中心化數(shù)據(jù)庫采用SQL Server，借助面向?qū)ο笳Z言Go完成智能合約的開發(fā)，使用基于C#的Windows窗體應(yīng)用完成前端界面的設(shè)計。

實驗環(huán)境采用64位Ubuntu搭建，版本為Ubuntu 16.04，為其分配8 GB內(nèi)存，100 GB磁盤空間，再通過應(yīng)用容器引擎技術(shù)Docker下載架構(gòu)中每個模塊的圖像，版本為Docker 20.10.7，Hyperledger Fabric版本為1.4.4，實現(xiàn)通過智能合約連接數(shù)據(jù)的區(qū)塊鏈系統(tǒng)。布署4臺主機作為服務(wù)器，測試系統(tǒng)的功能和性能，確保安全的分布式信息共享，提高系統(tǒng)的穩(wěn)定性。

本文整理了各大生鮮電商平臺上的水產(chǎn)品交易信息，通過訪談和問卷調(diào)研了水產(chǎn)品買賣雙方企業(yè)的需求偏好，并據(jù)此來設(shè)計仿真實驗。以某天中的10:00—14:00為例，設(shè)10：00—12：00為時段T、12：00—14：00為時段T+1，實驗假設(shè)在時段T內(nèi)系統(tǒng)收集到來自賣方和買方提交的供應(yīng)單和需求單各10條數(shù)據(jù)，如表4、5所示。

表4 供應(yīng)單信息Tab.4 Supply orders

本文中水產(chǎn)品“鮮活度”參考的標(biāo)準(zhǔn)為SC/T 3048—2014(魚類鮮度指標(biāo)K值的測定：高效液相色譜法)[42]。K值是腺苷三磷酸降解產(chǎn)物次黃嘌呤核苷、次黃嘌呤量之和與腺苷三磷酸關(guān)聯(lián)化合物總量的百分比。根據(jù)文獻(xiàn)[43-44]中關(guān)于水產(chǎn)品K值與新鮮度關(guān)聯(lián)的描述，本文中將K值低于10%(不含10%)的新鮮度設(shè)為鮮活度等級3(非常新鮮)，將K值位于10%～20%(不含20%)的水產(chǎn)品新鮮度設(shè)為等級2(比較新鮮)，將K值位于20%～50%(含50%)的水產(chǎn)品新鮮度設(shè)為等級1(適度新鮮)，將K值高于50%的水產(chǎn)品新鮮度設(shè)為等級0(不新鮮)。原則上K值高于50%的水產(chǎn)品不被認(rèn)為可以進(jìn)行交易，因此本系統(tǒng)中的水產(chǎn)品鮮活度從低到高分為等級1、2、3。

為完成撮合交易，參與仿真實驗的20家企業(yè)首先需要向聯(lián)盟鏈平臺 Hyperledger Fabric提交節(jié)點準(zhǔn)入申請。通過之后，通過圖4所示的系統(tǒng)前端界面，輸入合法的公司名稱、法定代表人、社會信用代碼、密碼等信息注冊，完成資質(zhì)審核，成為系統(tǒng)用戶，其注冊信息通過智能合約上鏈。

圖4 用戶注冊界面Fig.4 User registration interface

買賣雙方登錄系統(tǒng)后，可以通過前端界面上傳各自的供應(yīng)單和需求單，如圖5、6所示。收到用戶的供需單上傳請求后，系統(tǒng)調(diào)用智能合約接口對供需單數(shù)據(jù)進(jìn)行檢驗并上鏈。

圖5 供應(yīng)單上傳Fig.5 Submitting of supply order

圖6 需求單上傳Fig.6 Submitting of demand order

系統(tǒng)在時段T+1(12：00—14：00)收集時段T內(nèi)(10：00—12：00)用戶上傳的供應(yīng)單(表4)和需求單(表5)，并調(diào)用智能合約Match函數(shù)進(jìn)行交易匹配，匹配結(jié)果如圖7所示，本次匹配耗時2.3 s，全局最優(yōu)求解形成了10個交易匹配對，最終偏好序和為122。

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

圖7 時段T的匹配結(jié)果Fig.7 Matching results for period T

偏好序和表示買方對賣方偏好的排序與賣方對買方偏好的排序之和，偏好序和越小表示所有(全局)買賣雙方對對方的偏好度排序越靠前，即雙方的全局滿意度越高。假設(shè)用1～10的數(shù)值代表對對方的偏好排序，1代表最喜歡，10代表最不喜歡。根據(jù)偏好序和的計算公式，當(dāng)匹配對的個數(shù)為n時，偏好序和的取值范圍一般為[2n,20n]。本實施例的匹配對為10，偏好序和的取值合理范圍為20～200，蟻群算法計算的匹配結(jié)果中偏好序和為122，在可以接受的范圍內(nèi)。

匹配完成后，系統(tǒng)會將匹配結(jié)果存儲在中心數(shù)據(jù)庫中，用戶可在前端看到自己所上傳的供需單的匹配結(jié)果。以編號為54000的企業(yè)為例，該用戶看到的時段T企業(yè)上傳的需求單(編號84006)的匹配的供應(yīng)單編號為72010，如圖8所示。用戶可在此界面選擇是否同意該匹配結(jié)果，以便系統(tǒng)對此匹配結(jié)果形成交易合同并上鏈。此外，用戶還可在此界面查看上鏈的歷史交易合同記錄，根據(jù)線下交易完成情況對交易的完成狀態(tài)進(jìn)行確認(rèn)。若超過線下交易規(guī)定的時間上限(本系統(tǒng)設(shè)置為10 d)，系統(tǒng)將根據(jù)上鏈的交易合同自動確認(rèn)線下交易完成狀態(tài)。

圖8 匹配結(jié)果用戶可視化界面Fig.8 User matching result interface

3.3 系統(tǒng)性能測試

3.3.1系統(tǒng)測試結(jié)果

在Hyperledger Fabric實驗環(huán)境下安裝測試軟件Caliper對系統(tǒng)模型進(jìn)行測試。測試當(dāng)交易數(shù)據(jù)量分別為50、100、200、1 000、1 626(此時對應(yīng) 0.5 h)、2 000條時，交易的匹配時間。系統(tǒng)需要在0.5 h(即1 800 s)內(nèi)完成供需雙方的交易信息匹配。測試結(jié)果顯示：0.5 h內(nèi)，系統(tǒng)最多能匹配的數(shù)據(jù)量為1 626條，測試結(jié)果如圖9所示。

圖9 水產(chǎn)品交易匹配時間變化曲線Fig.9 Matching time curve of aquatic products trading

設(shè)計的撮合交易系統(tǒng)模型要求在時段T+1的前0.5 h進(jìn)行交易匹配，即交易撮合匹配時間不能超過1 800 s。如圖9所示，當(dāng)交易匹配時間為 1 800 s 時，交易數(shù)據(jù)量為1 626條，即當(dāng)時段T內(nèi)交易數(shù)據(jù)量不超過1 626條時，系統(tǒng)能夠較好地完成買賣雙方的自動化交易匹配。水產(chǎn)品撮合交易模型適用于B2B電子商務(wù)平臺，B2B平臺2 h內(nèi)收集到的交易數(shù)據(jù)量一般不會超過1 626條，因此，本文設(shè)計的水產(chǎn)品自動化撮合交易系統(tǒng)模型可以滿足日常實際交易的需求。

3.3.2與傳統(tǒng)水產(chǎn)品交易系統(tǒng)對比

傳統(tǒng)水產(chǎn)品交易系統(tǒng)主要有以下3個缺陷：①采用中心化數(shù)據(jù)庫，數(shù)據(jù)易受攻擊，信息安全難以保證。②達(dá)成交易匹配耗時長。傳統(tǒng)水產(chǎn)品交易系統(tǒng)通常是靠消費者自己完成信息搜集、對比和篩選匹配，交易雙方企業(yè)均需要花費大量的時間和精力進(jìn)行交易對象的篩選。③監(jiān)管力度不足，水產(chǎn)品質(zhì)量難以保證，無法避免虛假商品和交易信息的產(chǎn)生，不利于買賣雙方建立友好互信合作關(guān)系。相對應(yīng)地，本文所提出的水產(chǎn)品撮合交易模型和系統(tǒng)的優(yōu)勢在于：采用區(qū)塊鏈架構(gòu)，數(shù)據(jù)去中心化共識上鏈，使用PBFT共識機制，能夠包容一定比例的非法節(jié)點，提高了信息和系統(tǒng)的安全性；使用蟻群算法完成供需單匹配，縮短了匹配時間并提高了匹配準(zhǔn)確性，大大提升了交易雙方的匹配效率；區(qū)塊鏈的每個區(qū)塊塊頭都有時間戳，同時后一個區(qū)塊需要存儲前一個區(qū)塊的哈希值，因此企業(yè)注冊信息、供應(yīng)單信息、需求單信息、交易合同等數(shù)據(jù)上鏈后無法篡改且可追溯，保證了交易記錄的有效和不可篡改。同時，企業(yè)信息上鏈前，系統(tǒng)會對企業(yè)唯一的社會信用代碼進(jìn)行核驗，確保參與交易的企業(yè)都是合法企業(yè)，保障了交易對象的安全可靠。

4 結(jié)束語

將區(qū)塊鏈技術(shù)引入水產(chǎn)品流通的交易環(huán)節(jié)中，彌補了現(xiàn)有研究的不足。首先，在分析了傳統(tǒng)水產(chǎn)品線上交易平臺的缺陷后，梳理了基于區(qū)塊鏈架構(gòu)的水產(chǎn)品線上撮合交易業(yè)務(wù)流程，構(gòu)建了水產(chǎn)品撮合交易區(qū)塊鏈模型。針對傳統(tǒng)水產(chǎn)品撮合匹配效率低的問題，構(gòu)建基于價格、配送距離、新鮮度等多屬性的水產(chǎn)品撮合供需匹配模型，并采用啟發(fā)式蟻群算法對模型進(jìn)行尋優(yōu)求解。然后，進(jìn)一步提出了基于區(qū)塊鏈的水產(chǎn)品撮合交易系統(tǒng)的體系架構(gòu)和設(shè)計方案，并基于聯(lián)盟鏈平臺Hyperledger Fabric給出了該系統(tǒng)的實現(xiàn)過程。最后，結(jié)合具體仿真案例，驗證了該交易模型和系統(tǒng)的可行性和有效性。結(jié)果表明：基于區(qū)塊鏈的水產(chǎn)品撮合交易模型通過智能合約可以實現(xiàn)企業(yè)注冊信息上鏈、供應(yīng)單信息上鏈、需求單信息上鏈、撮合匹配、交易合同上鏈和相關(guān)鏈上數(shù)據(jù)高效查詢的功能，在每一個匹配周期(2 h)設(shè)定的0.5 h匹配時間內(nèi)，支持的最高交易數(shù)據(jù)量達(dá)到1 626條，設(shè)計的水產(chǎn)品自動化撮合交易系統(tǒng)可以滿足日常B2B平臺實際水產(chǎn)品交易的需求?；趨^(qū)塊鏈的水產(chǎn)品撮合交易模型和系統(tǒng)保障了交易企業(yè)信息、產(chǎn)品信息、合同信息的安全性，極大地提高了水產(chǎn)品線上撮合交易的效率，降低了水產(chǎn)品交易平臺的監(jiān)督成本和難度，為水產(chǎn)品中介和買賣雙方提供了一個公開、透明、可信的自動化交易方案。