基于區塊鏈的水產品交易溯源系統研究與實現

馮國富,胡俊輝,陳 明

(1上海海洋大學信息學院，上海 201306;2 農業農村部漁業信息重點實驗室，上海 201306)

水產養殖業在農業經濟發展中占有重要地位，據統計，2020年中國水產品總產量為6 549萬t，其中養殖產品占比達到了79.8%[1]。近年來，水產品質量安全事件頻發，不僅危及人們的身體健康，對水產養殖業發展也有不利影響[2-3]。在水產品交易環節中，交易數據的安全至關重要，這些數據不只是消費者進行水產品質量追溯的依據，還能讓養殖企業帶來更高經濟收益。在傳統水產品交易模式下，數據多采用中心化的存儲方式，數據的安全可靠性得不到保證[4-5]。當存儲數據的中心服務器出現故障時，數據就會存在丟失的風險，并且中心化存儲的數據有可能會被篡改，數據可靠性存疑。除此之外，數據不能共享且溯源困難，水產品的養殖廠家、經銷商以及消費者之間的數據是不互通的，因此導致交易鏈的上下游不能有效協同，數據溯源的透明性較低，出現問題無法第一時間定位。

區塊鏈具有去中心化、可追溯和不可篡改的特點[6-9]，區塊鏈的出現為解決水產品交易中存在的數據安全問題提供了新的解決思路。首先，區塊鏈是由多方參與共同維護的分布式數據庫，不存在中心化的管理機構，解決了中心化存儲數據不可靠的問題[10]。其次，區塊鏈運用密碼學技術，每個區塊包含前一個區塊鏈的哈希(Hash)值，形成有序的鏈式結構，確保數據不易被篡改[11]。最后，區塊鏈具有可追溯性，共識機制保證節點間的數據共享和監督，存儲于區塊鏈之上的每一條記錄、每一筆交易都可以進行可信溯源[12]。但是將區塊鏈技術直接應用于水產品交易數據存儲會存在問題，一是水產品交易環節中節點眾多，產生的數據量較大，如果這些數據直接存儲到區塊鏈網絡上，會給區塊鏈存儲容量造成壓力。二是要保證交易的隔離性，即當前交易參與主體間的操作對其他主體是不可見的，數據加密之后再進行傳輸。

本研究以Fabric區塊鏈平臺為基礎，通過對水產品交易流程分析，梳理并提煉出交易環節中關鍵主體和數據，提出基于區塊鏈的水產品交易數據溯源系統模型。在該模型中，數據不直接存儲在區塊鏈網絡中，而是結合星際文件系統(IPFS)存儲原始數據，區塊鏈網絡中只需要存儲IPFS的文件Hash地址降低鏈上存儲壓力。在此基礎上，提出了系統訪問權限控制方案，不同主體間進行數據交易時運行在獨立的通道內，每個通道有獨立的賬本和智能合約，不同通道間數據隔離，保證數據的隱私性和安全性。

1 相關背景

1.1 區塊鏈

區塊鏈是一種分布式去中心化賬本[13-14]，隨著區塊鏈在不同領域研究的深入，區塊鏈的應用也越來越多樣化，學者們提出了許多數據存儲和溯源方案[15-17]。Xie等[18]基于區塊鏈提出了一種雙鏈存儲結構進行農產品數據的存儲，利用鏈式數據結構存儲交易的哈希值，然后將其與區塊鏈鏈接在一起形成鏈式結構，保證數據不會被篡改。Hao等[19]提出了一種基于IPFS和區塊鏈的農產品數據存儲模型，將傳感器數據存入IPFS文件系統，然后利用區塊鏈存儲分布式文件系統IPFS的哈希值，確保數據安全。葛艷等[20]將區塊鏈技術與危害分析及關鍵控制點(HACCP)結合，提出了生食牡蠣的質量溯源模型，通過設計智能合約，對鏈上和鏈下數據進行監控并進行質量判斷。李夢琪等[21]通過分析水產品供應鏈的關鍵信息，提出了一種主從多鏈存儲模型對供應鏈溯源信息進行管理，保證了溯源數據的真實性和追溯過程的透明化。趙磊等[22]從信息生態視角分析用戶需求，提出追溯參與主體的風險補償方案，并進行信息鏈流程再造，給出了一種基于區塊鏈的生鮮食品追溯模型。以上基于區塊鏈的數據溯源模型都有各自的優點，但是水產品交易數據溯源場景下數據量較大，直接存儲在區塊鏈之上會給鏈上造成很大壓力，并且交易數據的隱私性應該進行控制。因此，本研究結合區塊鏈技術的優勢以及現有溯源系統的不足，提出區塊鏈在水產品交易數據上的溯源模型。

1.2 星際文件系統

IPFS是一個由所有參與的節點共同構成的分布式文件系統[23-24]。IPFS在進行數據存儲時不會受到文件大小的限制，因為它會將文件分為大小相等的數據塊，每一塊數據都有一個對應的Hash值，根據這些Hash值可以構建出一張文件檢索表，從而可以實現將這些數據塊分散存放在不同的服務器上[25]。

在進行數據查詢時，只需要輸入要查詢的文件Hash值，IPFS就會根據文件檢索表去對應的文件服務器上查詢數據并返回。IPFS分布式的特點使其可以天然地與區塊鏈結合，區塊鏈網絡中不再存放完整的數據，只需要存放對應數據文件的IPFS散列地址，從而節省區塊鏈的網絡帶寬，降低鏈上存儲壓力。

2 系統模型

2.1 水產交易流程分析

在整個水產品交易流程中，首先要保證源頭數據的真實可靠，即保證消費者購買到的水產品的養殖信息是真實可追溯的。水產品交易溯源流程如圖1所示。

圖1 系統流程圖

整個流程主要包括3個主體，分別為養殖廠、消費者和監管部門。在水產品流入市場進行交易前，養殖廠首先要將水產品的養殖信息，如池塘編號、水產品種類、入塘時間和捕撈時間等信息通過智能合約協調IPFS和區塊鏈的工作，將原始數據存入IPFS中，再將返回的IPFS地址Hash值上傳至區塊鏈網絡。消費者和養殖廠進行交易時，也需要將這些水產品的訂單交易記錄，包括買賣雙方姓名、水產品名稱、重量、單價和訂單金額等信息結合IPFS進行存儲。在交易完成之后，如果消費者發現購買的水產品出現食品質量安全問題，也可以將投訴信息上傳至IPFS中進行存儲。監管部門根據投訴信息在IPFS中找到對應交易訂單信息和問題水產品的養殖信息，若該批次水產品存在質量問題，可以及時進行處理。

2.2 系統結構

聯盟鏈Hyperledger Fabric平臺具有去中心化、部署成本低、可擴展性高和數據安全可追溯等特點[26]。因此，通過對水產品交易流程分析，結合Hyperledger Fabric平臺提出了系統整體架構。系統整體架構設計如圖2所示，自上而下可分為應用層、數據庫層、網絡層和數據層。其中區塊鏈技術主要用于數據庫層和網絡層。

圖2 系統整體架構

應用層是在區塊鏈網絡的基礎上，通過在區塊鏈中編寫智能合約對外提供API接口，設計一個水產品交易溯源平臺，利用可視化的界面提供信息交互服務，面向的對象為水產品養殖廠、消費者和監管部門。

數據庫層包括區塊鏈網絡中的分布式賬本和IPFS文件系統。系統中所有的原始數據在IPFS中進行存儲，數據存儲完成后IPFS會返回對應文件的地址Hash值。區塊鏈網絡中的分布式賬本存儲的不再是原始數據，而是地址Hash值。為了實現數據隱私保護，文件地址Hash值在提交上鏈之前先通過對稱加密的方式進行加密，然后再做上鏈處理。通過這種方式可以實現上傳地址Hash值不會被通道內的其他用戶看到，并且只有獲得訪問權限的用戶才可以查看區塊鏈網絡中的地址Hash值，最終實現根據地址Hash值從IPFS文件系統中獲取原始數據。

網絡層采用共識算法解決用戶之間的信任問題，通過共識機制選取背書節點進行數據驗證。基于工作量證明的PoW共識算法會消耗很大的算力資源，不適合在商業領域應用[27]。因此，本研究使用了更加高效的Kafka共識算法，采用一組排序節點對消息進行處理，根據排序之后的結果進行上鏈處理[28]。網絡層還要進行節點的訪問權限控制，通過多通道機制實現通道間的數據隔離，通過證書頒發機構(Certification Authority，CA)簽發證書控制節點對數據的訪問，實現數據的隱私保護。

數據層作為最底層主要進行3部分數據信息的收集。一是水產品養殖過程中的數據，如池塘編號、水產品種類、入塘時間和捕撈時間等。二是交易過程中的訂單數據，如買賣雙方姓名、水產品名稱、重量、單價和訂單金額等。三是交易完成之后消費者給出的反饋數據，如質量問題的類型和描述、水產品名稱和對應訂單號等。

3 系統實現

3.1 Fabric網絡環境模塊

圖3所示為根據系統流程圖設計的Fabric網絡結構模型，Fabric網絡采用單機多節點的部署方式。在Fabric網絡中，每1個參與主體對應1個組織節點，使用配置文件的方式創建系統所需要的養殖廠、消費者和監管機構3個組織節點，并通過Fabric模塊生成對應的數字證書、數據文件和通道創始區塊。每個組織下面包含2個Peer節點，用于實現各組織的背書、記賬等功能。除此之外，需要配置CA證書節點和排序節點，CA證書節點用于給用戶分發并且驗證證書，排序節點用于對傳遞的消息進行排序以便后續生成相應的區塊。在Fabric網絡中，每一個組織都有相應的CA證書機構給用戶頒布證書進行身份驗證，采用支持富查詢的CouchDB數據庫作為Fabric的狀態數據庫，每個組織配有相應的數據庫進行數據存儲。共識模塊是由多個Order排序節點組成的Kafka集群來實現的，它具有高擴展性的特點，并且由于多個排序節點的存在，具有很高的容錯能力。

圖3 Fabric網絡結構模型

系統中存在養殖廠、消費者和監管機構3個組織，其中，組織標志符、組織ID和各個組織安裝的智能合約信息如表1所示。

表1 系統組織表

3.2 系統訪問權限控制模塊

在系統模型中，養殖廠、消費者和監管機構3個組織下存在不同的用戶，用戶之間應當是相互獨立的，當消費者A進行數據查詢時，對其他消費者來說應該是不可見的。因此，本研究在系統模型中配置了多條通道，每條通道擁有自己獨立的賬本和智能合約。從系統上看，通道仍然是由Order節點進行管理，劃分目的只是為了將不同的通道信息進行隔離，保證數據交易信息的安全性和隱私性。

如圖4所示為系統的通道設計模型，在該系統模型中，所有的節點會共同加入一個公共通道之中，他們共同維護一個賬本并將自己的數據寫入其中進行交易。channel1和channel2是按照業務需求劃分的私有通道，私有通道之間以及私有通道和主通道之間都是隔離的，可以保證數據的隱私性。在該模型中，養殖廠不希望養殖數據直接被其他養殖企業看到，消費者也不希望將自己的消費信息暴露出去。因此，養殖企業BP1和BP2分別訂閱channel1和channel2通道，購買了相應企業水產品的消費者C1和C2也會訂閱對應的通道，監管機構根據業務需求訂閱需要監管的通道。在圖4中，BP1和C1在channel1通道中進行交易，BP2和C2在channel2通道中進行交易，通道外組織節點無法查看交易數據。

圖4 多通道設計模型

除了對區塊鏈網絡進行多通道劃分，數據在網絡中應該以密文的方式進行傳輸，確保數據的隱私性。當用戶不希望IPFS文件數據的地址Hash值直接被通道內其他用戶看到時，可以對其加密后再進行上鏈操作。如當通道內用戶A上傳地址Hash值并且只希望同一通道內的用戶B查看時，可以采用對稱加密算法對地址Hash值進行加密，上鏈過程可以描述為：用戶A首先獲取用戶B通過AES(Advanced Encryption Standard)生成的密鑰K，對地址Hash值進行對稱加密。加密函數定義為encrypt(K,Hash)，加密后的地址Hash值為E_Hash，加密完成之后再將密文E_Hash上傳至區塊鏈網絡。當用戶B要查詢原始數據時，首先會從區塊鏈中獲取加密之后的地址Hash值E_Hash，然后使用密鑰K對E_Hash進行解密獲取地址Hash值，解密函數定義為decrypt(K,E_Hash)，最后再根據IPFS文件的地址Hash值執行查詢操作獲取原始數據。

3.3 智能合約模塊

在Fabric平臺中，智能合約又被稱為鏈碼，鏈碼是連接客戶端與Fabric網絡的橋梁[29]。鏈碼就是一段程序代碼，用來表示系統流程的業務邏輯，也需要通過編譯之后才能夠運行，鏈碼在經過編譯和部署之后，一般運行于Docker容器之中。在Docker容器中，客戶端可以通過調用鏈碼，完成數據的發布和查詢操作。鏈碼可以由多種語言進行實現，本研究選用Go語言編寫，系統編寫的部分智能合約接口如表2所示。

表2 智能合約接口說明

鏈碼的主要功能包括發布和查詢水產品養殖信息、水產品交易數據信息和問題投訴信息。根據組織的不同安裝對應的鏈碼，鏈碼部署成功后首先會調用Init方法進行系統的實例化，然后執行Invoke方法發起交易執行定義的業務功能。以水產品養殖信息發布為例，當用戶在客戶端執行養殖信息發布操作時，數據存儲的業務邏輯如圖5所示。

圖5 養殖信息上傳流程圖

用戶登錄成功后會發起數據發布請求，首先會進行權限認證驗證節點身份信息，然后執行文件上傳操作將數據提交到IPFS中并返回存儲該文件的地址Hash值，再將返回的地址Hash值進行加密，最終通過調用智能合約將加密后的地址Hash值通過底層共識機制完成上鏈。

當用戶需要查詢水產品養殖信息時，數據查詢的業務邏輯如圖6所示，用戶在前端界面發起查詢請求后，節點首先進行身份驗證獲取訪問權限，然后調用智能合約執行查詢操作，從區塊鏈上獲取IPFS地址Hash值密文，再將地址Hash值進行解密，最終根據地址Hash值從IPFS中獲取原始數據返回給前端用戶。

圖6 養殖信息查詢流程圖

4 系統測試與分析

4.1 功能測試

在虛擬機VMware中完成水產品交易溯源系統環境的搭建，操作系統為Ubuntu16.4。虛擬機的配置為內存2 GB，硬盤為40 GB，Hyperledger Fabric版本為1.2，采用JavaScript進行Web服務開發。

在Fabric網絡環境中，系統采用單機多節點部署的方式，通過在Cryptogen模塊中配置3個節點來模擬系統中的Org1、Org2和Org3共3個組織，每個組織下分別有peer0和peer1共2個節點。系統首先生成每個節點的證書文件并存放在本地，然后執行創建通道的命令，根據業務規則創建2個私有通道channel1和channel2，同時執行命令將對應節點加入通道內，最后在每一個組織節點中安裝鏈碼完成網絡啟動。用戶在登錄時會對節點身份證書進行認證，只有在證書認證通過以后才可以進行操作。

水產品交易溯源系統提供的功能包括水產品養殖數據、訂單數據和問題反饋信息的發布和查詢。當用戶登錄系統后，系統訪問權限控制模塊會根據當前用戶所在組織的權限，控制用戶可以執行哪些業務功能。如當登錄養殖廠用戶peer0org1，用戶所在組織為Org1MSP，節點發起交易訂單數據發布請求后，首先需要在前端用戶界面輸入訂單交易數據的相關信息，然后節點會調用安裝在Org1組織內的智能合約執行上鏈操作。操作是在一個單獨的通道內完成，對于未訂閱該通道的組織和用戶，所有的數據都是不可見的。訂單數據發布成功之后，擁有權限的組織內的節點可以根據訂單編號查詢該訂單的詳細信息進行驗證。如圖7和圖8分別為根據交易訂單編號查詢訂單詳細信息和根據水產品編號查詢水產品養殖信息，系統首先驗證當前peer節點的證書keyStore是否正確，驗證成功后調用智能合約執行相應的業務邏輯返回結果。

圖7 交易訂單數據查詢界面

圖8 水產品養殖信息查詢界面

4.2 性能測試

對于系統整體性能，主要關注系統的吞吐量(Transaction Per Second ，TPS)。采用HyperLeager項目中的Caliper性能測試框架，測試在系統交易量為100～700筆/s時，吞吐量的變化情況。如圖9所示，橫坐標表示交易的并發數，縱坐標表示系統吞吐量，當發送請求數量在0～200次/s之間時，系統吞吐量呈穩步上升趨勢。當發送請求數超過200次/s時，系統吞吐量在220筆/s左右波動，此時已經為系統最大吞吐量。

圖9 系統吞吐量測試結果

通過對系統的功能和性能進行測試和分析可知，系統功能的有效性得到了驗證，性能上220筆/s交易的吞吐量可以應用于生產實踐[30]，完成了預期的設計目標。將本研究提出的模型與其他幾篇文獻模型對比如表3所示。

表3 方案性能對比

可以發現，5篇文章的模型都是基于區塊鏈去中心化的特點實現了數據的發布和追溯功能。文獻[19]和文獻[21]均沒有訪問控制機制，本模型進行了完善的通道設計，并且通過智能合約來進行訪問控制，數據的隱私性較好。除此之外，文獻[20-22]均未將區塊鏈與分布式文件系統相結合，數據直接存儲在區塊鏈網絡上，本模型結合IPFS的存儲方案使得該模型在進行大文件存儲時有更好的適用性。但是，本研究模型未采用物聯網、傳感器設備實時采集數據，下一步可將區塊鏈技術與物聯網技術相結合，進一步提升數據的可信性。

5 結論

本研究從水產品交易流程出發，提出了一種基于區塊鏈的水產品交易溯源模型，基于Fabric技術框架和分布式數據存儲方案IPFS實現了該系統。通過區塊鏈去中心化的特點和共識機制解決了水產品交易數據在中心化存儲模式下面臨的安全問題，同時利用分布式文件系統IPFS降低了鏈上的數據存儲壓力。在此基礎上，進行了多通道設計和訪問權限控制，用戶只能訪問所在通道內的數據，提高了數據的隱私性。從性能上看吞吐量為220筆/s左右，方案的可行性和有效性得到了驗證。在水產品供應鏈交易中引入區塊鏈技術，保證供應鏈中數據的完整性和安全性，防止信息孤島和篡改。這些數據對于水產品的質量安全監控，以及提升養殖廠的經濟效益具有很大的作用，為整個水產品供應鏈良性運轉提供了保障。

□