基于區塊鏈的食品溯源存儲檢索方法應用研究

收稿日期：2023-12-01

DOI：10.19850/j.cnki.2096-4706.2024.03.014

摘" 要：區塊鏈在實際溯源場景中存在無法支撐大規模連續性數據高效存儲的問題，且單一的數據查詢方式無法滿足應用需求，不利于溯源應用在多樣化場景下的大規模落地。為探索溯源場景的高可拓展區塊鏈存儲引擎技術，通過基于數據連續性特點來優化數據存儲、優化默克爾B+樹結構、創建索引數據庫等創新手段，實現了溯源數據區塊鏈高效混合存儲和高效數據檢索，在食品安全溯源應用場景中提升了效率。

關鍵詞：區塊鏈；食品溯源；存儲；檢索

中圖分類號：TP311.1；TP393" 文獻標識碼：A" " 文章編號：2096-4706（2024）03-0064-05

Application Research on the Method of Food Traceability Storage and Retrieval Based on Blockchain

LIU Guanghui1， CHEN Honggu2， ZHANG Jiyin2， SONG Lyu2

（1.Archives Information Center of Chongqing Administration for Market Regulation， Chongqing" 401121， China;

2.Chongqing Qulian Digital Technology Co.， Ltd.， Chongqing" 400010， China）

Abstract： Blockchain has the problem of being unable to support efficient storage of large-scale continuous data in practical traceability scenarios， and a single data query method cannot meet application requirements， which is not conducive to the large-scale implementation of traceability applications in diverse scenarios. In order to explore the highly scalable blockchain storage engine technology for traceability scenarios， innovative methods such as optimizing data storage based on data continuity characteristics， optimizing Merkel B+tree structure， and creating index databases have been used to achieve efficient hybrid storage of traceability data blockchain and efficient data retrieval. This has improved efficiency in food safety traceability application scenarios.

Keywords： blockchain; food traceability; storage; retrieval

0" 引" 言

食品溯源數據主要從供應鏈業務流程中采集，常規供應鏈上下游鏈條長，數據收集流程復雜，數據與數據之間存在強連續性關系[1]。為便于溯源區塊鏈底層平臺與其他鏈的集成或方便企業使用，都會提供輕節點的功能來存儲少量數據，針對全量數據存儲的節點（例如以太坊、fabric等共識節點）存儲優化問題，它們會進行定期的數據遷移以減少線上LevelDB數據量，如果數據體量大則需要頻繁操作。隨著數據量的日益增大，數據庫存儲讀寫性能將會受到嚴重影響，特別是區塊鏈基礎信息的查詢（區塊查詢、溯源交易查詢）性能會急劇下降，導致用戶查詢延遲大幅增加[2]。

1" 方案設計

1.1" 設計概要

采取相應措施優化區塊鏈溯源存儲及其檢索性能。一是針對鏈上大規模數據存儲性能瓶頸問題，提出基于區塊鏈的混合存儲引擎結合數據類型設計數據存儲模式，運用默克爾B+樹存儲機制滿足輕量級節點驗證需求，實現區塊鏈數據的高效存取。二是為了解決數據查詢問題，搭建索引數據庫，采用可插拔存儲引擎將關鍵信息存儲在索引數據庫中，通過特殊的ID標識與關鍵內容進行映射，實現業務數據的快速索引功能[2]。在實際溯源場景中，通過優化區塊鏈性能來滿足試點市監大規模數據溯源性能需求，實現數據收集、數據存儲和數據處理性能的有效提升。

1.2" 技術要點

1.2.1" 優化連續性數據存儲結構

在溯源場景中，大多數上鏈數據屬于連續性數據，通過優化連續性數據存儲方案，實現大量連續性數據的效上鏈，助力溯源場景大規模落地。區塊鏈實際是一個賬本，記下來的賬目按區塊號向后追加，形成以區塊號為單位的連續性數據存儲模式，比如溯源場景中每發生一筆數據變動，在區塊鏈中對應一筆交易，該交易包含溯源哈希或源數據、回執數據等，這些數據都屬于連續性數據。然而，市面上所有成熟型區塊鏈產品（例如以太坊、fabric等）都沒有完全利用連續性數據的特點來優化該類型數據的存儲性能。

連續性數據存儲優化結構如圖1所示，該數據庫由多個log segment組成，每一個log segment由一個后綴為.log和一個后綴為.idx的文件組成，分別用于存儲數據和索引數據。每一個log segment的結構如圖2所示[3]。數據以文件的方式記錄到磁盤中，以log為后綴的文件記錄原數據的信息，以idx為后綴的文件記錄以log文件為單位的文件索引信息，用于快速定位需要查找的數據位置，每一個log文件都配有一個相同前綴的idx文件。文件名前綴為文件中存儲的第一條數據的偏移量數值。每一個log文件都有大小限制，文件超過該限制時將新打開一個文件用于后續數據寫入，以確保連續性數據的高效寫入。采用log segment中第一條數據的key值作為文件名，根據數據有序的特點，采用時間復雜度更低的二分查找法來快速確認某一條數據位于哪個log segment中。在這樣的數據結構下，數據的讀寫效率將變得非常高。

圖1" 連續型結構

在這樣的設計之下，一次數據寫入操作只需要兩次磁盤IO，一次數據讀取操作只需要三次磁盤IO（一次讀Index Entity、一次讀Log Entity的header、一次讀Log Entity的data）。相較于LeveDB復雜的數據格式，讀寫效率大大提高。此外，數據量的增大只會增加文件個數，即稍微增加二分查找的時間，計算時間的增加幾乎可以忽略不計，隨著數據的增大該數據庫的性能不會衰減。

其次在存儲架構上，優化默克爾B+樹葉子節點4 K存儲閾值，對于將節點限制在4 K大小這一點，本方案從磁盤讀取的角度提出優化思路，將索引節點與數據節點視為索引文件和數據文件，可以有效提高節點分叉數，降低樹高，進而降低磁盤IO次數[4]，默克爾樹結構如圖3所示。隨后新生成的節點信息插入到原父節點的子節點列表中，再遞歸檢查父節點即索引節點是否超過閾值，如果索引節點超過閾值將會重復分裂過程。由于默克爾B+樹在每個節點都存儲了哈希值，每次對狀態數據的增刪改查，都會造成底層數據節點的變動，進而影響數據節點到根節點路徑上的節點哈希值，最終實現數據可信存儲。在生成數據證明時，同樣是沿著樹根，通過鍵的比對向下索引，并把索引路徑上的節點打包成證明返回[5]。驗證數據證明的時候，可以在數據證明中的節點路徑進行同樣的索引操作，驗證索引路徑的一致性，并進行節點哈希值的正確性校驗，最后比對樹根的值。例如在溯源場景中，按供應鏈的環節信息數據上鏈，上下游參與者作為底層葉子節點進行數據錄入，在供應鏈核心環節進行數據的整合，逐步完善形成一棵溯源樹，最后通過溯源碼進行溯源查詢。

圖3" 默克爾B+邏輯圖

1.2.2" 優化索引數據庫標識緩解查詢時延

為緩解溯源查詢時的壓力，建立索引庫，提升區塊鏈索引效率。將原本存儲于同一位置的索引數據與賬本數據進行拆分，優化存儲效能。

然而，在溯源存證生產過程中，即便使用一個獨立的LevelDB作為索引數據庫，在數據量增大后讀寫性能也會出現一定程度的下降。究其原因，是LevelDB使用了LSM-Tree作為底層數據結構來組織數據庫，其設計思想源于順序操作的效率遠遠高于隨機操作。LSM-Tree是一種多層級的數據結構，包含一層內存結構與多層磁盤結構，每一層磁盤結構的空間上限呈指數級增長。在LevelDB中，數據的插入或更新將被緩存在內存中，當緩存達到預設上限時會以有序的方式將內存中的數據寫入磁盤，形成一個L0層的SSTable [6]。隨著寫入操作的不斷進行，L0層的SSTable數量會持續上升（SSTable之間可能存在重疊部分）。

目前區塊鏈中索引信息的鍵主要有區塊編號、區塊哈希與交易哈希，而區塊哈希和交易哈希是根據區塊和交易的內容通過哈希算法計算得到的無規則字符數組，且交易索引數據（如交易哈希到區塊編號）占據的數據量最大。如果所插入的數據key均為完全隨機的字符數組，那么LevelDB中每兩層的SSTable都會存在大量的重疊[7]。在數據量較大且讀寫頻繁的情況下，Compaction將會頻頻發生，并且在讀取索引數據時可能需要遍歷L0層的所有SSTable與其余層的對應SStable，效率同樣極低。

進一步分析發現，引入索引數據后性能降低的主要原因是完全隨機化的鍵使得讀寫效率急速下降。優化思路是基于區塊哈希與交易哈希的唯一標識特性，通過重新設計使其呈現出一定的順序性，并且通過將區塊哈希到區塊編號的索引信息直接編碼進區塊哈希中，完全去除這部分的索引存儲開銷。區塊哈希中的第一個字節為版本信息，后八個字節為區塊號，后綴字節為區塊內容哈希結果。經過這樣的編碼，在最理想的情況下，LevelDB內部的SSTable將不會有任何重疊的部分，從而避免compaction，以實現性能的最優化。索引節點中只存放了鍵，因此索引文件遠遠小于數據文件，通過mmap（內存映射）的方式將索引文件存儲到內存中，這樣對底層數據的讀取只需數據文件的一次磁盤IO即可，大大提升了讀效率，在讀多寫少的溯源場景下具有較大的優勢[8]。

1.3" 性能測試

針對上述優化內容，改進區塊鏈的底層設計，創建連續性存儲結構Filelog來優化存儲結構以及拆分索引數據庫優化查詢性能，并且進行產品性能測試。

1.3.1" 存儲性能測試

如圖4所示為本次設計的連續性數據庫Filelog與傳統LevelDB數據庫在不同的存儲大小下寫入、讀取方面的性能對比，從圖中可以發現，存儲量越大，兩者之間的性能差別越大，由此得出優化后的連續性數據庫Filelog的讀寫性能遠遠高于LevelDB。

1.3.2" 檢索性能測試

基于TPS（Transactions Per Second）關鍵指標進行檢索性能測試，TPS為每秒處理事務數，反映一個系統處理能力的指標（包括存儲、檢索等）。TPS=并發數/平均響應時間。從表1中可以看出，在溯源場景中，相同時間內并發數越大表明區塊鏈讀寫速度越快。無任何優化措施區塊鏈中的并發數為200，僅進行數據存儲結構優化后的并發數為400，同時實現數據結構優化和索引數據庫升級的并發數為600，從實驗中得出索引數據庫經過優化后，系統查詢等性能得以提升。

圖4" 數據庫性能對比

表1" 性能測試對比表

并發數 節點響應TPS 持續時間/s 等待時間/ms TPS

600 537.02 600 10 519.70

400 400.52 600 10 399.75

200 200.60 600 10 200.21

2" 實際應用

將上述優化策略應用于重慶市智慧食品安全監管追溯應用進行理論驗證。在食品監管體系中，食品本身的管理和流動軌跡溯源是溯源監管體系的兩大重要模塊，食品流通會產生大量的狀態數據，需要持續地將這些數據記錄下來，市級食品市場數據量粗略估計在百億級別，要滿足如此巨大規模狀態數據的存儲，極高的寫入吞吐、海量存儲規模、可控的存儲成本、高效數據索引成為關鍵問題[9]。

整個食品安全溯源過程涉及監管機構、相關市場主體等單位的參與，整體架構如圖5所示。市場監管局、農委和商務委等機構通過部署節點組成溯源監管聯盟鏈，部分重點企業以節點方式接入，其他主體以服務方式接入。

在區塊鏈溯源系統中通過權限體系保護數據隱私，權限體系所保護的資源一般可以從資源對區塊鏈系統的影響層級維度劃分成四類：對整個鏈運轉產生影響的鏈級權限、對單個智能合約運行產生影響的合約權限、對區塊鏈上單個賬號產生影響的賬號權限以及只對區塊鏈系統中單個節點產生影響的節點權限。不同角色接入區塊鏈的方式不同，例如監管者以節點形式接入、企業以賬戶或節點形式接入，消費者以賬戶形式接入[9]。

圖5" 食品安全溯源架構圖

對于溯源數據有效性問題，利用區塊鏈+物聯網模組的方式實現數據最后一公里真實可信；數據索引采用內嵌式索引數據庫，在保證檢索結果可信的同時，極大地提升了業務數據的檢索效率。最后按照溯源標準以溯源碼為載體整合區塊鏈上參與者的數據，實現產品全流程溯源。

區塊鏈食品溯源具體業務流程如圖6所示，將食品溯源上下游食品生產、流通以及消費等環節重要信息與區塊鏈溯源身份做數據綁定，形成追溯信息重要依據。在食品生產環節，結合生產智能設備和生產業務系統建立食品生產企業檔案基本信息庫（包括生產環境、生產原料、生產人員等信息）；在食品監督檢查環節，基于市監食品管理平臺建立市場監督檢查數據庫，食品監督人員借助監督檢查數據庫完成監督檢查任務；在食品流通環節，通過對接分銷或配送系統建立食品流通檔案基本信息庫，將流通中的配送信息（包括配送環節溫度、配送路線、配送人員等）、分銷信息（包括供應商、地點等）實時上鏈[10]；在食品消費環節，通過商品銷售結算系統將食品條碼、批次和臺賬建立關聯，所記錄的銷售終端信息（包括門店、時間、上貨時間等）、消費投訴信息均與溯源身份進行數據鏈接。為所有環節的參與者分配公私鑰，進行數據加解密操作以保證數據流轉過程中的安全性。在數據應用過程中，利用智能合約事先規范數據應用事件，例如溯源查詢等。通過智能合約完成數據鏈上操作，通過私鑰確認查詢對象數據權限，從而保證被查數據隱私安全。

試點運行階段選擇重糧米業—東北長粒香米作為溯源試點對象，重糧米業擁有完善的信息化基礎設施，不僅儲備有充足的重慶本地自產優質大米，更有來自全國優質糧產區口感豐富的“人和”品牌大米，品牌溯源價值高。目前，已實現對該產品年銷量250噸的產品溯源信息上鏈存儲，存儲數量3萬條，溯源校驗查詢記錄7萬多條。溯源查詢展示部分頁面如圖7所示。

3" 結" 論

基于區塊鏈存儲結構優化以及高效檢索方案，實現在塊間和塊內使用不同存儲模式進一步優化檢索速度。在空間占用上也實現了一定的優化，相同數據量下，可以顯著降低鏈上數據的空間占用。通過理論和實踐的驗證，本次優化的數據庫針對不同的數據類型設計了相應的存儲模式，并利用默克爾B+樹存儲機制實現了輕量級節點的驗證，從而實現了區塊鏈數據的高效存取。在實際的食品溯源查詢業務中，產業鏈上不同環節企業作為存儲結構樹的最小節點單位，隨著溯源數據的寫入，優化單個節點數據存儲閾值，最終構建一棵溯源樹，并將樹根值映射為溯源查詢碼，同時將關鍵信息建立在索引數據庫中，查詢時優先查詢索引數據庫，從而有效降低數據讀取的延時，提升用戶滿意度。

基于本次區塊鏈存儲與查詢優化方案，在實際食品溯源場景中的存儲效率和檢索能力上都有不錯的表現，但隨著信息技術和區塊鏈的快速發展，針對未來數據更加海量化、應用領域更加復雜的情況，本方案需要做進一步的完善。從目前來看，還有以下提升空間：

1）增強系統的穩定性和安全性。在提高系統性能的前提下，重點提高系統的穩定性和安全性，確保數據存儲和檢索過程中的完整性和機密性。

2）支持跨鏈合作，突破多結構化數據存儲能力，優化系統使得不同區塊鏈網絡之間可以相互連接和共享數據。在食品溯源領域，通過跨鏈合作實現不同企業、不同地區之間的信息共享和協同工作，提高溯源的準確性和全面性。

3）完善溯源數據標準化和法規遵從。符合相關法規和標準的優化系統可以更好地服務于食品溯源場景。標準化工作的開展，可以促進食品溯源信息的互聯互通，提高溯源的可信度和有效性。

參考文獻：

[1]楊曉，秦一浪，王進磊.果品質量安全溯源管理系統設計 [J].現代農業科技，2018（16）：245-247.

[2] 段冉陽，周文輝，魏驍，等.基于Hyperledger Fabric的食品溯源系統設計與實現 [J].電子技術應用，2021，47（3）：55-60.

[3] 楊信廷，王明亭，徐大明，等.基于區塊鏈的農產品追溯系統信息存儲模型與查詢方法 [J].農業工程學報，2019，35（22）：323-330.

[4] 陳飛，葉春明，陳濤.基于區塊鏈的食品溯源系統設計 [J].計算機工程與應用，2021，57（2）：60-69.

[5] 王仕棟，孫建明，李昭，等.基于區塊鏈技術的農產品質量溯源系統 [J].包裝學報，2020，12（6）：80-85.

[6] 禹忠，郭暢，謝永斌，等.基于區塊鏈的醫藥防偽溯源系統研究[J].計算機工程與應用，2020，56（3）：35-41.

[7] 王千閣，何蒲，聶鐵錚，等.區塊鏈系統的數據存儲與查詢技術綜述 [J].計算機科學，2018，45（12）：12-18.

[8] 張德鈺.基于分布式存儲的區塊鏈上高效檢索的研究 [D].西安：西安電子科技大學，2022.

[9] 王健佐.基于區塊鏈技術應用于綠色有機食品溯源系統的探索 [J].農村實用技術，2019（8）：58-59.

[10] 關于進一步做好冷鏈食品追溯管理工作的通知 [J].中華人民共和國國家衛生健康委員會公報，2020（11）：123-128.

作者簡介：劉光惠（1973—），女，漢族，重慶江津人，高級工程師，博士研究生，研究方向：計算機軟件與理論；陳虹谷（1994—），女，漢族，重慶南岸人，工程師，本科，研究方向：信息管理與信息系統；張吉印（1992—），男，漢族，重慶巴南人，項目管理，本科，研究方向：通信工程；宋呂（1990—），男，漢族，重慶九龍坡人，工程師，本科，研究方向：通信工程。