基于區塊鏈的河豚供應鏈可信溯源優化研究

陳 明 孫 浩 鄒一波 葛 艷 陳 希

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

0 引言

河豚是一種劇毒魚類, 特別是肝臟、性腺和血液中含有大量的河豚毒素[1]，不當處理或錯誤食用可能會導致中毒。然而由于它肉質美味細膩和營養豐富，自古以來深受食客喜愛[2]。國家相關部門嚴禁銷售野生河豚、養殖河豚活魚和未加工整魚[3]，但是近年來銷售和食用河豚中毒人死亡等事件[4-6]仍時有發生。河豚不同于其他水產品，根據國家相關規定，河豚產品需擁有明確可溯源標識才可以在市場上流通。傳統溯源模型通過數據庫存儲數據，數據庫在上傳或更新數據時存在信息篡改的風險。因為河豚溯源信息的分布式存儲特性，溯源時需要依次查詢供應鏈的數據庫，所以溯源效率較低。這些問題導致傳統溯源模型難以應用于河豚供應鏈，因此河豚行業急需建立一個可靠有效的溯源模型[7]。

農產品供應鏈溯源研究中，一些研究結合射頻識別設備(Radio frequency identification,RFID)、二維碼、同位素技術和移動無線監測等技術，提供了供應鏈全程溯源系統[8-11]，建立了供應鏈食品質量安全溯源體系[12-14]，實現了農產品可溯源性和食品質量安全性的需求。但傳統的溯源技術還存在以下問題：供應鏈中各個廠商不同的底層平臺導致的信息孤島效應；溯源系統的防篡改能力不足。區塊鏈技術由于其不可篡改和分布式的特點常應用于溯源系統中，其分布式特點可以打破部門壁壘，實現信息共享[15]。近些年來國內外學者將區塊鏈技術應用到農產品溯源過程中[16-18]，利用量子密鑰分發技術提高數據安全性[19],結合危害分析及關鍵控制點(Hazard analysis and critical control points，HACCP)保障產品安全[20-21]等。

但是區塊鏈技術犧牲了部分效率來保證數據安全性[22]，這是因為區塊鏈及其存儲方式應用于溯源系統時，需要多次遍歷區塊鏈來獲取數據，所以導致了溯源查詢效率低[23]，從而限制了區塊鏈在河豚供應鏈溯源中的應用。針對區塊鏈溯源效率低的問題，楊信廷等[24]通過區塊鏈溯源模型外接本地數據庫的方式存儲區塊號來實現快速溯源。但溯源的過程中采用本地數據庫會削弱區塊鏈的不可篡改性、去中心化、分布式的特點。

本文以提高基于區塊鏈的河豚供應鏈溯源模型的查詢效率為目的，將對河豚業務供應鏈信息進行分析，整理并提取供應鏈各業務環節主要信息；基于區塊鏈技術建立河豚供應鏈溯源存儲優化模型，設計多鏈快速查詢模式并制定供應鏈信息溯源智能合約，構建河豚供應鏈信息溯源系統；以江蘇省某河豚企業供應鏈信息為例，進行相應的性能對比測試，以期實現基于區塊鏈河豚供應鏈模型的快速溯源。

1 相關技術基礎

區塊鏈是一種分布式的數字賬本，可以通過區塊記錄多個交易信息，不依賴于單個節點進行安全維護，因此確保了信息的安全性[25]。區塊鏈由連續的多個區塊組成，區塊由區塊頭和區塊體組成，區塊頭中包含區塊號、當前區塊哈希值、前一區塊哈希值、時間戳等數據，區塊體中記錄了交易詳細信息，具體包括交易數量、交易標識碼(Identification，ID)、交易雙方地址等數據,交易數據通過Merkle樹逐級將哈希值傳遞到根節點，保證了交易具有防篡改特點[26]。由于區塊鏈計算能力和共識算法相應速度有限，當數據量增加時，其交易吞吐量會快速下降[27]。交易ID是由一串固定長度的隨機Byte種子+證書中的身份信息部分組成的哈希字符串[28]，交易ID具有唯一性并且具有對應的交易地址，并且采用交易地址可以更快速地查詢到相應的交易。

智能合約是運行在區塊鏈上的一段計算機程序，在預定條件滿足時，能夠自動強制地執行合同條款，實現“代碼即法律”的目標[29]。在以太坊公鏈中，智能合約可同時運行在全網所有節點，任何機構和個人都無法將其強行停止。在聯盟鏈中，因為節點數量的有限性，同時為了提高系統運行效率，節點之間不會競爭記賬權，而依據智能合約生成的交易直接記錄到區塊鏈中。智能合約擴展了區塊鏈的功能，豐富了區塊鏈的上層應用，依照商業邏輯編寫完智能合約代碼后，需要將其發布到區塊鏈網絡節點上[23]。

2 河豚供應鏈業務信息分析

河豚供應鏈的特點是環節眾多，廠商之間相互獨立，并且監管部門對河豚的溯源要求較高，導致業務信息數據結構不統一，需要記錄和傳遞的數據量大。本文針對河豚業務信息特點，對河豚供應鏈從溯源的角度分為養殖、加工、倉儲、物流、銷售5個階段，最后進入末端消費者手中，如圖1所示。將河豚供應鏈各環節業務信息分為溯源碼信息和一般產品信息。溯源碼信息可以實現一碼一物相互對應，消費者通過溯源碼即可查找到對應的產品信息。產品信息包括廠商信息、合格證明信息。以加工階段為例，加工廠商對河豚加工環節信息進行記錄，以加工批號作為加工階段溯源碼，通過加工溯源碼對加工階段的業務信息溯源。對河豚產品中河豚毒素殘留影響最大的是加工階段的解剖去毒環節，這個環節工藝水平將會直接影響后續河豚產品的食品安全。所以在加工階段所需要記錄的數據不僅有加工溯源碼、廠商名稱、加工時間、加工溫度等，還要記錄病原微生物、河豚毒素合格證明信息[30]。河豚供應鏈業務信息分析可以為后續建立河豚供應鏈溯源模型提供基礎。

圖1 河豚供應鏈溯源業務信息Fig.1 Tracing business information of pufferfish supply chain

3 多鏈河豚溯源優化模型構建

3.1 河豚供應鏈溯源優化模型架構

一般區塊鏈溯源模型在利用單鏈結構上鏈時，不同環節的數據需要分開上鏈，各環節上鏈數據不會連續地存在區塊上，導致查詢時需要順序遍歷整條鏈才能查找到全部溯源數據，隨著數據量的增加，順序遍歷的速度會線性增加，從而使得查詢速度變慢[31]。本文針對河豚供應鏈特點，結合實際溯源的需求，基于區塊鏈和智能合約技術，搭建河豚供應鏈信息溯源模型，如圖2所示。信息溯源模型統一管理供應鏈所有生產環節的信息，將映射關系根節點信息存儲到主鏈中，葉子節點信息存儲到子鏈中，來實現快速溯源查詢。模型在去中心化的環境中存儲了所有生產環節廠商的數據以及關聯信息，這樣既保障了溯源數據的防篡改性、可信性、安全性，同時保證了溯源查詢的高效性。

圖2 模型總體架構Fig.2 Overall model architecture

整個模型可分為3個模塊：供應鏈數據采集、數據處理、區塊鏈網絡。供應鏈數據采集由各環節廠商通過傳感器收集數據后經過規整成為最初的原始數據。數據處理模塊由數據上鏈、數據映射、數據查詢、數據驗證4部分組成，數據上鏈部分由各環節廠商節點進行同步上鏈操作，調用上鏈合約各個環節的數據上鏈到相應的子鏈，危害信息還需要調用校驗合約校驗顯著危害是否符合要求，限值信息是否超過限值，如果全部合格則正常上鏈，否則返回相應不合格報錯。數據查詢部分由消費者通過客戶端節點來進行查詢，通過主鏈查詢到映射關系，通過映射關系中的子鏈交易地址在各條子鏈中快速定位到交易數據，數據驗證部分對交易中的數據進行驗證，將所有的數據拼接成為完整的河豚溯源數據，校驗數據完整性。區塊鏈網絡模塊由子鏈和主鏈區塊文件、共識算法等組成，維護數據存儲和數據查詢。

數據上鏈時，廠商在采集信息之后將溯源信息通過上鏈合約調用數據加密模塊將明文數據轉換為密文數據，之后提交上鏈請求將密文數據傳輸給各自的子鏈，在子鏈存儲密文數據可以防止上下游數據泄露。子鏈在收到請求后將密文數據生成交易，然后將交易存儲在當前區塊中。子鏈上鏈合約會將交易哈希地址和河豚溯源碼返回給該環節節點，節點調用映射合約將溯源碼和各交易建立映射關系，最后將該河豚映射關系存儲到主鏈中。至此溯源信息上鏈階段完成。

數據溯源時消費者需要先將河豚包裝上的溯源碼輸入到客戶端節點，客戶端節點驗證溯源碼格式之后，傳輸至區塊鏈底層網絡。通過調用映射合約對主鏈進行查詢，獲取到映射關系并返回節點，通過映射關系得到各子鏈的交易哈希地址，節點分別對各子鏈通過交易地址索引查詢，通過交易地址可以直接定位到某個區塊的交易信息。獲取到各條子鏈的密文數據后，調用數據解密模塊將密文數據解密為明文數據，最后拼接成完整的河豚溯源信息并在客戶端展示。

3.2 多鏈存儲模式設計

根據圖1河豚業務流程分析設計出映射關系數據結構，如圖3所示，數據映射是本模型提高溯源查詢效率的關鍵，映射關系是一種類似于樹的數據結構，反映了產品溯源碼與交易地址之間的一對多關系。溯源時通過映射關系進行索引，查詢速度會較快。通過根節點記錄了產品溯源碼、各階段批號或單號和交易地址，通過交易地址尋址到葉子節點，子鏈中的交易ID具有唯一性，防止數據被篡改。葉子節點將廠商信息、產品信息、合格證明等信息分類存儲，圖3中省略號表示各階段的葉子節點。通過這一流程來實現市場監管和質量安全的需求，在河豚數據上鏈的過程中通過區塊鏈的時間戳實現了防篡改功能。

圖3 映射關系數據結構Fig.3 Mapping data structure

例如某河豚水產品具體信息映射關系根節點數據如表1所示，寫入區塊鏈的溯源碼包括養殖批號、加工批號、倉儲單號、物流單號、銷售單號。養殖批號同時作為河豚的產品溯源碼，溯源碼與子鏈存儲溯源信息的交易地址形成映射關系，溯源碼作為索引和唯一標識。

表1 主鏈映射關系根節點數據Tab.1 Root node data of main chain mapping relationship

3.3 多鏈快速查詢流程

在區塊鏈查詢過程中隨著數據量的增加查詢時間會線性增加，如何保證數據安全的同時提升溯源的查詢效率是研究重點。本文提出了一種多鏈快速查詢流程，主鏈僅存儲少量的映射關系數據，主要供應鏈信息存儲在子鏈中，并建立與子鏈交易之間的映射關系，避免大數據量的遍歷查詢。

如圖4所示，本河豚溯源模型的具體操作如下：建立區塊鏈網絡；客戶端節點注冊；河豚水產品溯源數據采集；編寫智能合約；河豚水產品溯源數據上鏈；河豚水產品溯源數據查詢。具體數據存儲如圖5所示，在上鏈操作前，通過智能合約將本環節數據標準化。上鏈時，任何環節出現顯著危害信息無合格證明或危害信息超限值都會報錯并及時終止生產。上鏈后需要對映射關系進行更新操作來維護映射關系的實時性。主鏈中會存儲映射關系，在子鏈傳來交易信息后主鏈會先查找是否已存在該溯源碼的映射關系。如果主鏈不存在記錄就新建該溯源碼的映射關系，將產品溯源碼和子鏈中的交易哈希地址建立起一對多映射關系。進行查詢操作時，首先在主鏈節點進行順序查找，找到一個批次號所在的交易地址，然后遞歸地在交易地址所指向的子鏈節點進行查找。直到查找到所有子鏈節點，然后在子鏈節點上進行交易數據查找，找出交易地址所對應的交易數據。消費者通過調用智能合約獲取該河豚全部溯源信息。

圖4 多鏈快速查詢流程圖Fig.4 Multi-chain quick query process

圖5 多鏈溯源查詢信息流Fig.5 Multi-chain traceability query information flow

鏈溯源查詢信息流如圖5所示， 供應鏈的各個階段將本階段的信息上鏈至相應子鏈，子鏈將信息存儲到交易中，當主鏈發送溯源查詢請求后，通過映射關系快速查詢到各階段信息后拼接成完整的全供應鏈溯源信息，傳遞給主鏈，主鏈通過智能合約將查詢結果傳遞給客戶端展示給消費者。

3.4 智能合約設計

數據上鏈通過上鏈合約實現，上鏈合約主要實現了河豚安全性判斷功能。通過對河豚顯著危害數據是否在限值內進行判斷，嚴格管控河豚的食用安全。以河豚供應鏈倉儲階段為例，各環節廠商以JavaScript對象簡譜( JavaScript object notation，JSON)格式將不同溯源信息調用相應的上鏈合約上傳至區塊鏈賬本中，返回交易哈希地址，倉儲信息上鏈具體上鏈算法為

輸入:河豚溯源碼 BatchCode，冷藏庫溫度 Temperature，金屬碎片大小 MetalSize

輸出：成功交易哈希地址 TxID，失敗返回錯誤原因

1. message= Stub.GetState(BatchCode) ∥查子鏈中是否存在 BatchCode 記錄

2. If (MetalSize大于金屬碎片大小限值)

3. return “金屬碎片過大”∥上鏈失敗，返回失敗原因

4. If (Temperature大于冷藏庫溫度限值)

5. return “生物的致病菌生長過度” ∥上鏈失敗，返回失敗原因

6. message. encryption();∥調用加密模塊加密

7. Stub．PutState (message) ∥將密文數據上鏈

8. return TxID ∥上鏈成功，返回交易哈希地址

映射關系通過映射合約建立并寫入主鏈，當該河豚產品尚未建立映射關系時，新建映射關系，當河豚產品已經存在映射關系則更新其映射關系。具體算法如下：各環節節點通過調用智能合約進行上鏈，智能合約首先將本環節的所有數據都上傳到相應的子鏈，然后將其中的溯源碼和子鏈交易哈希地址建立映射關系，映射關系中如果已有該溯源碼的數據，則更新相應的交易哈希地址，具體映射合約算法為

輸入：河豚溯源碼 BatchCode,交易哈希地址 TxID，更新各環節 Breed Procees Pransport Storge Sales

輸出：返回映射關系 Index

1. BatchCodeAsBytes:=stub.GetState(BatchCode)∥查詢主鏈中是否有映射關系

2. Index:= &Index{}∥沒有則新建映射關系

3. func UpdateIndex (args []string)∥有則更新映射關系

4. if updateItem == "Breed" {∥更新各環節交易哈希地址

5. Index.BreedTxId = TXID

6. }else if updateItem == "Process"{

7. Index.ProcessTxId = TXID

8. }else if updateItem == "Transport"{

9. Index.TransportTxId = TXID

10. }else if updateItem == "Storage"{

11. Index.StorageTxId = TXID

12. } else if updateItem == " Sales "{

13. Index. SalesTxId = TXID

14. }

15. stub.PutState(BatchCode, Index)∥將映射關系寫入主鏈

16. return Index

隨著全球經濟與科技飛速發展，科學的力量也愈加強大。因此，要想把移動學習與高職英語教學相融合，就一定要以科學的方法作為支持力量進行推動。

當用戶對河豚溯源查詢時，通過查詢合約輸入溯源碼查詢到子鏈上的信息，具體的查詢合約算法為

輸入：河豚溯源碼 BatchCode

輸出：返回子鏈溯源信息Ciphertext

1. Stub.GetState( BatchCode) ∥查詢主鏈中是否存在 BatchCode 記錄

2. (BreedTxId,ProcessTxId,StorageTxId,TransportTxId, SalesTxId)=GetMapping (BatchCode)∥存在映射關系，獲取映射關系中的交易哈希地址

3. Ciphertext.Breed=BreedChain.GetState(BreedTxId)∥根據交易哈希地址，請求養殖子鏈交易信息

5. Ciphertext.Storage=StorageChain.GetState(StorageTxId)∥請求倉儲子鏈交易信息

6. Ciphertext.Transport=TransportChain.GetState(TransportTxId) ∥請求物流子鏈交易信息

7. Ciphertext.Sales=SalesChain.Getstate(TransportTxId) ∥請求銷售子鏈交易信息

8. Ciphertext.Decrypt();∥調用解密模塊解密

9. return Ciphertext ∥返回溯源信息

4 河豚全供應鏈溯源系統實現

4.1 系統架構

基于河豚供應鏈的溯源優化模型，設計了河豚供應鏈信息溯源系統架構。該系統架構如圖6所示，分為Web應用層、接口層、智能合約層、存儲層、網絡層、業務層6層。

圖6 系統分層架構Fig.6 System layered architecture

應用層主要是將系統以可視化的界面展示在消費者面前，消費者可以通過前端輸入溯源碼進行河豚的溯源。接口層主要連接Web應用層和智能合約層，各環節的廠商通過程序接口調用智能合約的相關函數實行數據上鏈。智能合約層編寫數據查詢和數據上鏈函數，并被安裝到多鏈模型中，智能合約實現索引賬本和數據賬本的更新。存儲層存有多鏈模型的數據結構，主要包括索引賬本和數據賬本兩部分。網絡層包括Hyperledger Fabric區塊鏈的相關網絡節點、組織、共識算法、證書授權機構(Certification authority，CA)、Orderer節點等。業務層就是連接各環節原本供應商的信息系統，各環節廠商將溯源信息進行上鏈。

4.2 案例分析

在上述模型的基礎上，實現了基于區塊鏈的河豚供應鏈溯源系統，本系統基于江蘇省某河豚企業的河豚數據，在本數據的基礎上編寫相應的智能合約、接口及前端應用。本文研究成功應用于江蘇省某河豚產品供應鏈廠商，該廠商包括完整的河豚養殖、加工、倉儲、物流、銷售環節，相關環節的溯源記錄比較完整、清晰。如圖7所示，Web前端界面包括可信溯源、區塊鏈瀏覽器、交易查詢、節點監控等，與傳統的河豚溯源系統相比，區塊鏈技術保證數據的去中心化存儲，同時應用了本文提出的區塊鏈溯源優化模型和多鏈快速查詢模式，在應用后，溯源流程的溯源效率大大提升，且安全性得到保證，溯源信息的防篡改能力得到有效保障。

圖7 系統工作界面Fig.7 System working interface

5 性能比較分析

目前的區塊鏈溯源方法主要是單鏈存儲模型，性能分析時分別對單鏈存儲模型和本文提出的多鏈存儲模型建立實驗環境進行測試并對比結果。實驗硬件運行內存為32 GB，硬盤容量為1 TB,帶寬為100 Mb/s；環境基礎采用Ubuntu 16.04，Docker 19.03；區塊鏈架構使用Hyperledger Fabric 1.4.2。每次實驗的數據采用測試10次的平均值。設置區塊大小為10 MB，交易大小為512 KB，每10個交易打包生成一個區塊，出塊時間為2 s。共識算法采用Kafka，批處理信息閾值為16 KB，發送消息最大值為1 MB，等待請求響應的最長時間為30 s。本文采用性能測試工具Caliper v0.2.0對溯源系統進行性能測試。

如圖8所示，本文提供的查詢方法由主鏈查詢時間和子鏈查詢時間兩部分組成。當數據量增加到1 000條時，總查詢時間為0.161 s，主鏈查詢時間為0.08 s，子鏈查詢時間為0.081 s，當數據量增加到10 000條時查詢時間逐漸增加至0.196 s，其中主鏈查詢時間為0.086 s，占43.9%，子鏈查詢時間為0.11 s，占56.1%。

圖8 主鏈和子鏈查詢兩階段時間占比Fig.8 Proportion of time in two stages of main chain sub-chain query

若查詢某河豚溯源碼，在單鏈查詢中，針對5個追溯企業上傳的數據，需對整條鏈按溯源碼對內容遍歷查詢5次。在多鏈查詢中，整個過程分為主鏈查詢和子鏈查詢兩階段：主鏈查詢階段首先根據溯源碼到主鏈遍歷查詢映射關系，然后從映射關系得到子鏈交易哈希地址；子鏈查詢階段通過得到的交易哈希地址快速定位到子鏈的交易記錄。多鏈查詢速度快的原因有兩點：主鏈查詢階段采用遍歷查詢，但是主鏈僅存儲映射關系，區塊長度較短，單鏈模型中將所有溯源信息存儲到一條鏈上，區塊長度較長，所以主鏈的遍歷查詢比單鏈遍歷查詢要快很多；子鏈查詢階段是按映射關系中的交易哈希地址查詢，速度會遠快于單鏈中按內容遍歷查詢。

如圖9a所示，當數據量增加到1 000條時，多鏈查詢時間為0.161 s，單鏈查詢時間為0.372 s；當數據量增加到10 000條時，多鏈查詢時間逐漸增加至0.196 s，單鏈查詢時間為2.769 s。在上鏈數據量達到10 000條時查詢效率可以提升約92.9%。

圖9 兩種查詢方法對比Fig.9 Comparisons of two query methods

節點架構如圖10所示，單鏈查詢中，所有節點都是處于一個組織中，只維護同一條鏈。多鏈查詢中，將節點分為主鏈組織和子鏈組織，分別包含主鏈節點和子鏈節點，主鏈組織維護主鏈，子鏈組織同時維護5條子鏈。針對不同節點可能影響實驗結果，本文實驗對單鏈查詢和多鏈查詢分別設置2、4、6、8個節點進行實驗，多鏈查詢中節點分配情況如下： 2節點，主鏈組織1個節點，子鏈組織1個節點；4節點，主鏈組織2個節點，子鏈組織2個節點；6節點，主鏈組織3個節點，子鏈組織3個節點；8節點，主鏈組織4個節點，子鏈組織4個節點。

圖10 節點架構Fig.10 Node architecture

多節點測試采用網絡負載均衡的方式選擇不同的區塊鏈節點同步查詢。節點查詢吞吐量指直接從區塊鏈節點發起交易查詢、執行智能合約、收到節點查詢結果這一過程的吞吐量，這一過程僅在節點執行，所以吞吐量較大。客戶端查詢吞吐量指從客戶端瀏覽器發起交易到遠程的區塊鏈節點中查詢的吞吐量，需要將交易提交到節點，整個過程需要網絡傳輸信息，所以吞吐量較小。如圖9b所示，隨著節點數的增加，節點查詢吞吐量會逐漸增加，節點數分別為2、4、6、8時，單鏈節點查詢吞吐量分別為697、972、1 427、1 819 TPS(Transactions per second，每秒交易數)；多鏈節點查詢吞吐量分別為623、1 019、1 486、1 735 TPS，兩者差距不大。如圖9c所示，隨著節點數的增加，客戶端查詢吞吐量都會逐漸增加。節點數分別為2、4、6、8時，單鏈客戶端查詢吞吐量分別為61、104、125、141 TPS；多鏈客戶端查詢吞吐量分別為58、99、120、134 TPS。在客戶端查詢吞吐量方面，單鏈查詢比多鏈查詢稍高一些。

如圖9d～9f所示，針對2、4、6、8個節點的不同情況，分別在鏈上存儲1 000、2 000、3 000條數據。然后測試同時發起10次查詢，取單次查詢時間平均值。實驗顯示隨著節點數的增加，兩種方式查詢時間都會縮短，并且多鏈查詢時間都會小于單鏈查詢時間。

從測試結果可以看出，與傳統的單鏈存儲模型相比，在數據量較多時，多鏈存儲模型可以大大提升查詢效率，并且對吞吐量影響較小。

6 結論

(1)提出的多鏈溯源模型相比較以往的區塊鏈單鏈溯源模型，在數據記錄條數大于1 000條時，該模型查詢效率將高于傳統單鏈模型，在10 000條數據記錄上鏈后，較傳統單鏈模型查詢效率提高約92.9%。該模型可以實現完全的鏈上數據存儲，使得溯源數據的安全性得到保證，河豚供應鏈各環節和溯源模型的聯系更加緊密，減少了供應鏈各環節的孤島效應，各環節可以方便地進行數據上鏈，保證消費者可以查詢到完整、真實、全面的河豚溯源信息。

(2)基于Hyperledger Fabric框架結合河豚溯源案例實現了河豚溯源模型的應用，通過該應用驗證了本文提出的模型的可靠性和適用性，為河豚行業提供了一個安全的溯源模型，對消費者來說保證了河豚溯源信息的真實性，為監管者提供了一個方便有效的監管模型。