基于Hyperledger Sawtooth的農產品供應鏈追溯系統的研究與設計

曹祖晟，丁磊

（廣東工業大學計算機學院，廣州510006）

0 引言

近年來農產品的安全問題得到了社會的廣泛關注，劣質農產品給人們的生命財產安全帶來了巨大威脅，但事后的追責卻因為缺乏可靠證據或難以定位責任方而難以繼續，嚴重侵害了消費者的權益。在農產品供應鏈中，互信難的問題[1-2]使得參與方之間達成合作的成本升高，而參與方各自維護自己的數據倉庫，缺乏統一的標準體系，又使得農產品在不同流通環節中數據混亂，且中心化的運作方式易造成信息不透明，導致追溯信息可信度不高[3]。

區塊鏈是一種去中心化、無需信任的新型數據架構，目前已經發展到3.0時代,成為各行業去中心化數據管理的技術支撐[4]。區塊鏈由網絡中所有的節點共同擁有、管理和監督，不接受單一方面的控制，數據上鏈后被永久記錄，不能被篡改，在解決追溯系統可信度問題方面具有先天技術優勢，能夠實現可追溯性，有效解決上述農產品供應鏈中的問題。Kamble等人通過解釋結構模型等方法分析將區塊鏈技術運用到農產品供應鏈的驅動因素，結果也表明了可追溯性是采用區塊鏈技術最重要的原因[5]。近年來國內外學者運用區塊鏈技術在供應鏈領域進行了探索研究，如Tian等人運用區塊鏈與RFID技術相結合的方法實現了一個供應鏈追溯系統[6]；李明佳等人結合區塊鏈技術設計了食品安全溯源體系并論證了有效性[7]；方燚飚等人設計了基于區塊鏈的供應鏈交易系統，能夠實現更高效、透明的信息共享[8]；洪坤明等人結合GS1編碼標準，設計了基于聯盟鏈的水產養殖品質量追溯系統，使得追溯更高效[9]。在數據存儲方面，由于一般區塊鏈的鏈式存儲方式，查詢效率低下，為此，楊信廷等人提出了一種“數據庫+區塊鏈”鏈上鏈下追溯信息雙存儲方法，保證了追溯信息可靠性的同時保證了查詢效率[10]?，F在的研究大多都是基于常用的區塊鏈系統如Bit?coin、Ethereum、Hyperledger Fabric，對 于Hyperledger Sawtooth的研究較少。M.P.Caro等人分別用Ethereum和Sawtooth實現了同一種供應鏈系統，并對兩種方案實現的系統進行測試，結果顯示Sawtooth擁有更優的性能，但缺點是Sawtooth不如Ethereum成熟[11]。Fabric和Sawtooth都是Hyperledger下的項目，區別是在于Fabric注重隱私，而Sawtooth注重特定業務[12]，在農產品供應鏈業務頻繁的體系中，互信的商戶信息是公開的，對隱私性的要求較低，所以Sawtooth比Fabric更適合農產品供應鏈追溯系統。綜上，區塊鏈技術在解決供應鏈面臨的各種問題上具有顯著優勢。因此本文對Hyperledger Sawtooth和農產品供應鏈展開研究，結合GS1編碼體系，設計了一個農產品供應鏈追溯系統，完成農產品供應鏈交易并記錄數據，構建追溯鏈，解決農產品供應鏈面臨的參與方互信難、信息不對稱、產品質量和安全問題追責難等問題。

1 系統模型

本文系統采用的農產品供應鏈追溯模型如圖1所示，參與方有生產商、加工商、分銷商、零售商、消費者和擁有監管職權的監管部門。

圖1 供應鏈追溯模型

系統的架構分為物理層、數據層、區塊鏈層，如圖2所示。物理層主要包括供應鏈中的各參與方和資產，即生產商、加工商、分銷商、零售商、消費者和監管部門等實體以及商戶創建的產品等各項資產；數據層主要是各資產的屬性，如：所有者、產品類型、重量、采摘日期或屠宰日期等，屬性在系統中的表現方式為傳輸和存儲在系統中數據以及包含索引信息的二維碼；區塊鏈層是處理和存儲可追溯性數據的區塊鏈平臺，響應用戶的操作請求，并對數據進行持久化存儲。

圖2 系統架構

本文設計的農產品供應鏈追溯系統是在Hy?perledger Sawtooth基本框架中實現的，應用區塊鏈的分布式特征，每個節點都備份所參與鏈的相同賬本，共同維護賬本的完整性和不變性[13]?；贖yperledger Saw?tooth的區塊鏈是一種聯盟鏈，通過節點與節點雙向連接的方式形成可靠的區塊鏈網絡，參與方在整個網絡中共享數據，有效解決供應鏈中不同參與方所維護的數據不同步的問題。多節點的區塊鏈網絡保證了系統的安全性，當少量節點故障時不影響網絡的正常運作，當有新節點加入時也能通過其他節點獲取完整的賬本。農產品供應鏈的所有交易信息都將永久記錄在賬本中，通過查找賬本可以準確構建供應鏈的歷史過程，從而達到追溯的目的。

本文設計的系統結構模型如圖3所示。區塊鏈網絡中有多個Sawtooth節點，每個節點都擁有相同的驗證器、交易處理器、共識引擎和REST API，每個節點都能以可插拔的方式連接客戶端[14]?；贖yperledger Sawtooth的開發要求通過定義交易處理器的業務邏輯、客戶端的業務邏輯和數據模型構建交易族（TF，Trans?action Family）來完成特定業務需求。

圖3 Hyperledger Sawtooth區塊鏈網絡結構模型

2 系統設計

系統的設計細分為七個模塊，第一模塊系統角色設區分了本系統面向的用戶類型；第二模塊GS1編碼設計規定了用戶使用本系統時應該遵循的產品數據規范；第三模塊交易和批次，定義了交易和批次的數據結構，規定了客戶端打包用戶交易的規則；第四模塊區塊鏈結構規定了區塊的打包規則以及區塊鏈的鏈接方式；第五模塊尋址方案制定了State存儲空間的劃分規則及索引方式，提供了高效的數據庫查找方案；第六模塊交易邏輯設計描述了交易從發起到區塊產生的全過程；第七模塊追溯鏈構建設計了追溯鏈條的構建算法。

2.1 系統角色設計

本文系統中的角色主要包括系統管理員、業務管理員、操作員、追溯者四類，各角色說明如表1所示。系統管理員擁有管理節點的權限，能代表節點進行鏈上治理，驗證業務管理員的身份并管理其讀寫訪問權限；業務管理員是一個擁有的admin權限的參與方（組織）代理，擁有一個組織的所有操作權限，同時可以管理該組織操作員的權限；操作員也是組織下的代理，擁有組織授予的讀寫權限，可以進行相應的業務操作；追溯者擁有構建農產品供應鏈中歷史過程的權限，并查看產品相關歷史信息。各供應鏈商戶以組織的形式參與到區塊鏈系統中，業務管理員對應供應鏈中的商戶角色，操作員對應商戶中的員工角色，追溯者主要對應有追溯需求的消費者和監管部門。不同的角色登錄客戶端將打開不同的操作子集。

表1 角色說明

系統采用嚴格的身份認證機制，使用公私密鑰對進行身份標識，交易的產生、打包、處理、數據的寫入和讀取都會進行相應的簽名驗證，不符合權限的操作將被拒絕。

2.2 GS1編碼設計

為避免不同參與方的產品編碼規則不同，造成數據的混亂，系統采用標準化的編碼體系，使用GS1編碼體系對農產品相關信息進行唯一標識[15]，關鍵編碼如表2所示。GTIN-12碼唯一標識產品，GLN碼唯一標識了廠商的物理位置，編碼都內含了廠商識別碼，在區別產品和位置的同時也區別了廠商，為追溯鏈的構建提供了數據上的便捷。

表2 關鍵編碼

系統對owner、product_id、pre_product_id、dir_prod?uct_id、location、pre_location、dir_location七個字段進行了GS1體系的編碼，分別對應廠商識別碼、當前產品GTIN、來源產品GTIN、廠商GLN碼和來源廠商GLN碼，這七個字段伴隨著供應鏈階段的前進而更新。

2.3 交易和批次

系統中任何事件都通過交易的方式進行，如創建產品、記錄產品信息、修改產品信息、創建代理、更新代理權限等。一個或多個交易在客戶端中被打包成一個批次，通過REST API提交至驗證器進行處理。一個批次的數據結構如圖4所示，一個批次包括批次（Batch）、批次頭（BatchHeader）、交易（Transaction）和交易頭（TransactionHeader）。在批次中，header是經過序列化的批次頭，在交易處理器中進行反序列化后將得到簽名 公 鑰（signer_public_key）和 交 易 列 表（transac?tion_ids），驗證簽名密鑰（header_signature）是否與簽名公鑰匹配，從而驗證批次的合法性，交易列表對應每一筆交易（Transaction）。交易與批次的結構類似，交易頭中包含了打包批次的公鑰（batcher_public_key），輸入（inputs）和輸出（outputs）分別表示交易需要讀取的狀態地址和交易寫入的狀態地址，有效負載（payload）記錄了交易的具體參數。

圖4 批次（Batch）數據結構圖

2.4 區塊鏈結構

交易以批次的形式提交到驗證器，一個或多個批次的交易被驗證和執行成功后被打包成區塊并發布，區塊和批次的嵌套數據結構與交易和批次的數據結構類似，在此不再贅述。區塊鏈的結構示意圖如圖5所示，區塊包含區塊頭和區塊體兩部分，區塊頭中包含前一個區塊的哈希值、區塊號、簽名公鑰、時間戳、批次列表、狀態根哈希值和本區塊的哈希值。所有交易的相關數據以Merkle-Radix樹的形式存儲在驗證器的狀態（State）中，區塊打包時將State的當前狀態也打包進區塊。數據存放在樹最下層的葉子節點，葉子節點不斷向上層節點進行哈希運算，最終得到樹的根哈希，區塊一旦被驗證，任何數據的改變都將導致根哈希的改變，僅檢驗根哈希值就能保證數據的完整性[16]。

圖5 區塊鏈結構示意圖

2.5 尋址方案設計

Merkle-Radix樹能夠以索引的方式迅速定位數據的物理存放地址，如圖6所示。地址是35字節的十六進制編碼字符串，共70個字符，每個字節向下索引一個葉子節點，從根節點到葉子節點，深度最多可以達到35。

圖6 尋址方式示意圖

根據業務邏輯需求設計尋址方案。完成農產品供應鏈相關功能的交易族被命名為APSChain，使用SHA512算法對APSChain編碼，取哈希值的前六位“f20ac0”作為命名空間地址的前綴，所有APSChain相關存放在狀態中的數據的地址都以此前綴開頭。如圖7所示，前6位是命名空間地址前綴，緊接在后面的兩個十六進制字符用來對具有相同結構的數據進行分組，分組情況如表3所示。

圖7 尋址地址結構

表3 尋址地址分組

剩余62個索引字符將根據分組屬性進一步靈活劃分，如User分組的62個字符中，前兩個用于區分用戶在系統中的身份，11、12、13、14分別對應系統管理員、業務管理員、操作員和追溯者四種用戶角色，最后60個字符取用戶公鑰進行SHA-512后的前60位。再如Product分類，產品對象在系統中更新的頻率很高，為了達成追溯目的，需要長久且完整地存儲產品的所有歷史記錄，所以將命名空間的最后4個十六進制字符規定為分頁地址。屬性本身存儲在以0000結尾的命名空間中，屬性的歷史記錄按時間戳的先后順序存儲在0001至ffff的分頁中，每當屬性進行更新，0000中的數據將加入到歷史記錄分頁中，并將0000中的數據更新為最新的數據。交易處理器將這些分頁視為環形buffer，當ffff分頁被填充后，下一次更新將覆蓋0001分頁，在此方案下，可以在記錄被覆蓋之前存儲162*(1 64-1)=16776960個歷史分頁，充分滿足了記錄產品歷史屬性的需求。分頁地址之前的58個字符取產品的GTIN-12編碼經過SHA-512后的前58位，最終生成了特定產品對象的完整命名空間。

2.6 交易處理和區塊上鏈

交易處理流程如圖8所示。交易由客戶端發起，經過序列化的一筆或多筆交易被打包成批次，通過REST API發送到驗證器。驗證器是Sawtooth節點的核心組件，負責檢驗交易的合法性，其過程包括對交易信息完整性的檢測和對上下文完整性的檢測，被篡改或不符合權限要求的交易將被丟棄；若上下文不完整，則向區塊鏈網絡中請求上下文信息，在規定時間內未獲得上下文信息的交易也將被丟棄。完成交易合法性驗證的交易批次將在區塊網絡中進行廣播，然后被發送至對應的交易處理器。交易處理器定義了處理交易的業務邏輯，即智能合約。收到交易內容的交易處理器首先對交易內容的有效負載進行反序列化，接著按照智能合約的業務邏輯對交易進行處理，同時根據尋址方案找到驗證器中存放數據的狀態地址，并改變狀態。狀態存儲了區塊鏈的所有數據，狀態完成更新后，驗證器將當前狀態的哈希值和批次打包成區塊，添加到當前區塊鏈的鏈頭。其他收到廣播的節點也將根據批次的內容進行合法性檢驗、執行智能合約、改變狀態和區塊打包等，從而保證了區塊鏈分布式賬本的統一性。

圖8 交易處理流程圖

2.7 追溯鏈構建

追溯分為“追”和“溯”兩個過程，即“向上溯源”和“向下追尋去向”兩個過程。由于農產品在供應鏈中通常以散裝稱重進行交易，所以一批農產品可能被分為多批流向供應鏈下游，所以“追”的過程不能像“溯”的過程一樣簡單視為一條單鏈，應構造樹狀的追溯鏈。本文采用基于深度優先搜索算法（Depth First Search，DFS）的追溯鏈構建算法如下：

算法1追溯鏈構建算法

利用該算法在狀態中查找農產品相關的所有信息構建追溯鏈。

3 系統實現

3.1 系統啟動測試

開發與測試平臺如下：Ubuntu 18.04操作系統、Intel Core i5-4210M處理器，內存8G，部署Docker 18.03-ce、docker-compose 1.24.0、Nodejs v12.20.1。

運用Docker技術，將客戶端和運行APSChain智能合約的交易處理器與Sawtooth組件在測試環境下一起運行，運行成功顯示如圖9，Docker容器的啟動情況如圖10。

圖9 系統啟動成功示例圖

圖10 Docker容器啟動情況

系統運用在生產環境中還應考慮商業環境下供應鏈參與方維護區塊鏈節點的成本和收益，采用合適的共識機制，將devmode-engine替換為其他共識引擎，達成共識后，區塊鏈網絡中的各節點都將運行功能相同的docker容器。

3.2 追溯結果

追溯者使用移動設備掃描二維碼進行追溯鏈的構建，二維碼信息需包含農產品的GTIN-12編碼和時間戳。以上信息將攜帶追溯者的公鑰以批次的形式被發送至驗證器，并啟動追溯者的操作子集，結果將打印在追溯者的客戶端界面。如圖11所示，以追溯者在供應鏈中的階段為原點，向供應鏈上游溯源出一條鏈式結構的鏈，向供應鏈下游追尋出一個樹狀結構的鏈，兩條鏈拼接在一起即是一條完整的供應鏈追溯鏈。

圖11 追溯鏈示例

4 結語

本文針對農產品供應鏈情景下參與方互信難、信息不對稱、產品質量和安全問題追責難等問題，研究并設計了一種農產品供應鏈追溯系統。本文首先對供應鏈系統的研究現狀進行分析，論述了區塊鏈技術用于供應鏈追溯的有效性，并選取了性能較優的Hy?perledger Sawtooth框架進行進一步研究，然后確定了系統的整體模型，接著對系統的用戶角色、GS1編碼體系、交易批次的數據結構和尋址方案等模塊進行細節的設計，最后運用“追”與“溯”的追溯鏈構建算法，實現了農產品追溯鏈的構建。經過系統的運行測試和追溯鏈構建測試，系統能夠穩定運行并構建追溯鏈，可滿足農產品供應鏈的追溯需求。