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

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 供需匹配算法

蟻群算法(Ant colony optimization, ACO)，又稱螞蟻算法，是一種模擬螞蟻覓食行為的啟發(fā)式算法，用來(lái)在圖中尋找優(yōu)化路徑，在旅行商問(wèn)題、復(fù)雜網(wǎng)絡(luò)、深度學(xué)習(xí)、數(shù)據(jù)處理等問(wèn)題應(yīng)用普遍[36-38]，可作為處理雙邊匹配問(wèn)題的有效途徑。本文采用基于歷史狀態(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)方個(gè)體，k∈[1,n]。

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

function Match(){

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

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

while(nc<=NC){ ∥每次實(shí)驗(yàn)迭代NC次

randomly choose an initial target ∥隨機(jī)選擇一個(gè)螞蟻?zhàn)鳛槌跏挤?/p>

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

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

calculate the evaluation value for each matching result of this iteration ∥計(jì)算評(píng)價(jià)值

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

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

print result}

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

表1 匹配屬性Tab.1 Matching attributes

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

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

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

2.2 智能合約設(shè)計(jì)

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

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

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

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

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

function CompanyRegister(args []string){

KeyAsBytes := stub.GetState

if KeyAsBytes != nil{

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

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

CompanyJsonAsBytes := json.Marshal(Company)

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

stub.PutState(Key, CompanyJsonAsBytes)

∥將注冊(cè)信息上鏈

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

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

輸入：需求方企業(yè)編號(hào) CreateCompanyKey、數(shù)量Amount、期望最低價(jià)格PriceLow、期望最高價(jià)格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)建需求單對(duì)象

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

stub.PutState(Key, DemandListJsonAsBytes)

∥將需求單信息上鏈

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

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

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

輸入：需求方企業(yè)編號(hào) FirstCompanyKey、供應(yīng)方企業(yè)編號(hào)SecondCompanyKey、品種Breed、數(shù)量Amount、價(jià)格TotalPrice、鮮活度Fresh、尺寸Size、收貨地址FirstAddress、出貨地址SecondAddress、運(yùn)輸距離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)建交易合同對(duì)象

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)建者查詢和合同查詢。鍵查詢指的是通過(guò)Key查詢鏈上數(shù)據(jù)，可用于商品信息查詢、企業(yè)信息查詢、交易合同查詢、供應(yīng)單查詢和需求單查詢；創(chuàng)建者查詢指的是通過(guò)上傳數(shù)據(jù)的企業(yè)主鍵查詢鏈上數(shù)據(jù)，可用于需求單查詢、供應(yīng)單查詢；合同查詢指的是通過(guò)上傳數(shù)據(jù)的企業(yè)主鍵以及買(mǎi)賣(mài)方標(biāo)記字段(0代表買(mǎi)方，1代表賣(mài)方)查詢鏈上的合同信息，可用于交易合同查詢。以通過(guò)Key查詢需求單信息為例，其代碼邏輯如下：

輸入：需求單編號(hào)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è)計(jì)與實(shí)現(xiàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文中水產(chǎn)品“鮮活度”參考的標(biāo)準(zhǔn)為SC/T 3048—2014(魚(yú)類鮮度指標(biāo)K值的測(cè)定：高效液相色譜法)[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è)為鮮活度等級(jí)3(非常新鮮)，將K值位于10%～20%(不含20%)的水產(chǎn)品新鮮度設(shè)為等級(jí)2(比較新鮮)，將K值位于20%～50%(含50%)的水產(chǎn)品新鮮度設(shè)為等級(jí)1(適度新鮮)，將K值高于50%的水產(chǎn)品新鮮度設(shè)為等級(jí)0(不新鮮)。原則上K值高于50%的水產(chǎn)品不被認(rèn)為可以進(jìn)行交易，因此本系統(tǒng)中的水產(chǎn)品鮮活度從低到高分為等級(jí)1、2、3。

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

圖4 用戶注冊(cè)界面Fig.4 User registration interface

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)束語(yǔ)

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