基于雙鏈架構與BBF-Merkle樹的高速公路事故救援數據共享方法

摘 要：針對現有區塊鏈數據共享方法在高速公路事故救援場景下面臨的效率瓶頸和安全性不足的問題，提出一種高效、安全的數據共享方法，旨在提高數據查詢性能，保證鏈下數據的防竄改能力。提出的數據共享方法結合公有鏈與聯盟鏈的優勢，采用雙鏈架構提升數據共享的安全性與效率。通過將公有鏈鏈上共享數據的摘要信息同步至外部數據庫，設計了基于BBF-Merkle樹的數據庫索引結構來優化查詢性能，同時保證鏈下數據的防竄改能力。設計了緩存-鏈下數據庫-公有鏈的分層查詢方案，降低整體查詢耗時。實驗結果表明，基于BBF-Merkle樹的外聯數據庫查詢耗時相較于其他方案表現最優，采用基于BBF-Merkle樹的緩存-數據庫-公有鏈分層查詢方案，相較于公有鏈智能合約查詢速度提高了七倍。所提出的數據共享方法在提升數據共享效率、降低查詢延遲的同時，確保了數據的安全性與防竄改能力，為高速公路事故救援數據共享提供了技術支撐。

關鍵詞：區塊鏈；數據共享；區塊鏈查詢優化；雙鏈架構

中圖分類號：TP311"" 文獻標志碼：A""" 文章編號：1001-3695（2025）04-003-0987-08

doi： 10.19734/j.issn.1001-3695.2024.09.0292

Highway accident rescue data sharing method based on dual-chain architecture and BBF-Merkle tree

Wang Guanghui1，2， Guan Daowei1， Shen Lingfeng1，2， Ding Shuang1，2， Zhai Zhonghao3

（1.School of Software， Henan University， Kaifeng Henan 475000， China; 2.Henan International Joint Laboratory of Intelligent Network Theory amp; Key Technology， Kaifeng Henan 475000， China; 3.School of Computer Science amp; Software Engineering， Huaiyin Institute of Technology， Huai’an Jiangsu 223003， China）

Abstract：The existing blockchain-based data sharing methods in highway accident rescue scenarios face efficiency bottlenecks and security issues. This paper proposed an efficient and secure data sharing solution to improve data query performance and ensure off-chain data integrity. The method used a dual-chain architecture that combines the advantages of public and consortium blockchains to enhance the security and efficiency of data sharing. It synchronized the summary information of shared data from the public blockchain to an external database and designed a BBF-Merkle tree-based database indexing structure to optimize query performance while maintaining off-chain data integrity. The method introduced a layered query scheme consisting of cache， off-chain database， and public blockchain to reduce overall query time. Experimental results show that the query time of the external database based on BBF-Merkle tree indexing outperformed other solutions. The cache-database-public blockchain layered query scheme achieves a faster query speed by seven times compared to the public blockchain based on smart contracts. The method improves data sharing efficiency， reduces query latency， and ensures data security and integrity， providing strong technical support for highway accident rescue data sharing.

Key words：blockchain; data sharing; blockchain query optimization; dual-chain architecture

0 引言

目前，高速公路事故救援相關部門采取傳統的數據庫來存儲事故以及司乘人員相關信息，在有查詢數據需求時直接從數據庫中獲取所需數據。然而，各部門數據庫系統一般相互獨立，缺乏統一的標準和接口，并且權限管理異構，難以適應多部門協作的需求。這些問題使得高速公路事故救援數據共享變得更加困難，甚至無法實現，從而導致數據孤島問題。此外，傳統數據共享方案的數據處理和存儲過程不透明，用戶無法有效地追蹤和驗證數據的完整性和真實性，導致信任難以建立。區塊鏈技術的出現為傳統中心化共享方案面臨的問題提供了新的解決方案。盡管已有很多工作使用區塊鏈技術來解決數據共享問題，但在高速公路事故救援場景下應用區塊鏈技術解決數據共享仍存在諸多挑戰。

在高速公路事故救援場景下，共享方法必須具備高效的處理能力和快速的響應速度，確保各部門能夠及時獲取所需信息。同時，共享數據的可信度在救援過程中至關重要，任何數據的竄改或丟失都會對救援工作產生影響，數據共享必須能夠確保數據的完整性和防竄改能力。例如，事故中涉及的車輛身份或駕駛員信息可能被用于判定責任。如果這些信息被竄改，可能會導致錯誤的事故責任認定，影響后續的理賠或法律程序。此外，救援數據涉及個人隱私和敏感信息，這些數據需要在共享過程中得到保護，防止未經授權的訪問和泄露。綜上，高速公路事故救援數據共享所面臨的兩個核心問題是效率和安全。高效的數據共享方法能確保各部門迅速交換信息，提高救援響應速度；安全的數據共享方法則能保證數據的完整性、防竄改性和隱私保護，為救援工作提供堅實的保障。

現有基于區塊鏈的數據共享方法在效率和安全性之間難以取得平衡。區塊鏈系統可分為公有鏈、私有鏈和聯盟鏈。公有鏈具備強去中心化和高安全性，適合高信任和審計場景；聯盟鏈因網絡規模小，采用高效共識算法，性能優異，適合高頻交易場景。然而，現有方案［1～4］使用單一類型的區塊鏈架構進行數據共享。Yang等人［1］提出了基于單一區塊鏈架構的數據共享和交易的整體框架，通過區塊鏈去中心化、透明性等特點保證整個流程的安全性。Guo等人［2］提出了一種支持以區塊鏈作為物聯網復雜場景的底層平臺的數據共享方案，該方案通過鏈下存儲和鏈上搜索解決區塊鏈存儲問題。Chen等人［3］提出了一種基于Fabric的跨企業數據共享方案，數據擁有者和使用者通過區塊鏈網絡實現溝通，在鏈上完成數據共享的整個流程。在事故救援場景下這種單一區塊鏈架構的方案存在兩個問題：一方面，使用單一類型的區塊鏈很難在達到高效的同時兼顧安全性，因為高效通常依賴于較少的節點和較低的共識復雜度，這些因素可能削弱網絡的去中心化程度和抗攻擊能力，而安全性取決于各種去中心化和復雜的共識機制，這通常會降低處理速度和效率；另一方面，在事故救援場景中，如果只使用單一類型區塊鏈，不同功能的所在節點就不得不驗證和處理與自己無關的交易，這會導致效率低下。相比之下，雙鏈架構可以有效分擔這些工作壓力，讓各個獨立的功能模塊所在的區塊鏈節點專注于與自己相關的交易，提升整體處理效率［5～7］。針對高速公路事故救援數據共享所面臨的問題，本文結合公有鏈和聯盟鏈的優勢，提出了基于雙鏈架構的高效數據共享方法，公有鏈專注于提供去中心化的數據審計功能，而聯盟鏈則負責高效的數據索引和存取操作。這種分工明確的做法使得區塊鏈網絡能夠各司其職，并行處理彼此無關的交易，顯著提高了整體網絡的處理效率，進而加快事故救援相關數據在各部門間的共享效率。此外，數據的密文數據存儲在鏈下的IPFS中，而公有鏈和聯盟鏈分別存儲數據摘要和索引，有效減輕了鏈上的存儲壓力，避免了大規模事故救援數據存儲帶來的性能瓶頸和存儲成本。

為了提升數據審計效率，本文針對現有公有鏈存在的數據查詢效率低下問題提出了高效的解決方案。參與事故救援的各部門數據使用者收到共享數據后通過公有鏈對共享數據進行審計以保證數據的完整性。由于事故救援場景往往要求快速響應，審計查詢的低效可能會導致數據無法及時驗證，進而引發信息不一致、誤操作等問題，最終拖延救援進度，甚至可能危及生命安全。但實際上，目前的公有鏈查詢效率難以滿足事故救援場景下的高效審計查詢要求。這主要有以下幾個原因：首先，以太坊、比特幣等區塊鏈系統底層的數據存儲系統使用的是LevelDB［8］，它是一種針對寫密集型應用而設計的數據存儲系統，以犧牲數據讀性能為代價換取寫性能的提高。然而，事故救援共享中的查詢操作頻率遠高于寫入頻率，特別是在事故易發時段，各部門之間協作救援需要進行頻繁的查詢操作。此時LevelDB的寫入優勢也無法體現出來而讀性能卻不足，這成為限制公有鏈查詢性能的主要瓶頸。其次，公有鏈內部的數據結構也對查詢效率產生了重要影響，以以太坊舉例而言，Merkle Patricia Trie（MPT）作為其核心數據結構之一，負責存儲賬戶狀態和智能合約狀態。為了查找到某個鍵的值，必須從根節點開始，逐層遍歷到葉子節點，這種逐層遍歷的過程在樹的深度較大的情況下，有較高的I/O操作的延遲，存在查詢效率低的問題［9］。現有優化公有區塊鏈查詢性能主要有兩種思路：一種方案［10～12］是對公有區塊鏈內部數據結構進行改造提升查詢效率，然而在實際應用中難以推廣，因為這種修改會破壞區塊鏈現有的結構，增加了系統的復雜性和開發成本。另外一種是方案［13～18］在區塊鏈的基礎之上建立外聯數據庫，是一個較為通用且能夠提升查詢效率的有效方案。比如，文獻［13］提出了EtherQL系統將區塊數據同步到鏈下數據庫MongoDB中，查詢以太網區塊鏈數據時通過鏈下數據庫查詢，以提高查詢效率。但是傳統的數據庫索引在設計上主要關注高效檢索和數據組織，由于缺乏內置的防竄改機制導致無法確認數據是否未被竄改或偽造。為了提升查詢效率并且保證外聯數據庫的高效索引與防竄改能力，本文設計了BBF-Merkle樹索引結構，在實現高效檢索的基礎之上保證鏈下數據的不可竄改特性，并在此基礎之上提出緩存-數據庫-公有鏈的高效分層混合查詢方法。

總的來說，為解決在高速公路事故救援場景下數據共享面臨的上述挑戰，本文提出一種基于雙鏈架構與BBF-Merkle樹的高效事故救援數據共享方法 （efficient accident rescue data sharing scheme，Efficient-DSS）。其中，雙鏈架構整合了公有鏈的防竄改審計功能與聯盟鏈的快速數據檢索機制，BBF-Merkle樹索引結構則確保了鏈下數據防竄改性，從而有效應對高速公路事故救援場景下對數據安全和高效性的需求，提升了高速公路事故救援響應速度和數據安全性。本文主要工作如下：

a）雙鏈數據共享架構。通過整合公有鏈和聯盟鏈的優勢，實現了高效安全的數據共享。公有鏈存儲明文摘要以進行公開審計，確保數據的不可竄改性。聯盟鏈存儲IPFS地址以進行快速索引和檢索加密數據。鏈下的IPFS存儲密文，顯著減輕了鏈上的存儲負擔。

b）BBF-Merkle樹數據結構設計與鏈上鏈下分層查詢方法。為提升公有鏈查詢效率，設計不同觸發機制將鏈上數據批量轉移到外聯數據庫。為了保證外聯數據庫的高效索引與防竄改能力，設計了基于BBF-Merkle樹的索引結構，并提出緩存-鏈下數據庫-公有鏈的鏈上鏈下分層查詢方案，在實現高效查詢的同時保證了鏈下數據的防竄改特性。

c）實驗驗證與性能評估。對提出方法在事故救援數據共享方面開展了有效性和高效性實驗。對BBF-Merkle樹在數據庫層的查詢性能測試表明，BBF-Merkle樹的查詢效率優于現有外聯數據庫方案，并在數據量增加的情況下表現出顯著的性能優勢。對所提出分層查詢方案的性能測試顯示，Efficient-DSS分層查詢方案的查詢耗時低于現有方案。

1 基礎知識

1.1 區塊鏈類型

當前的區塊鏈系統按公開程度和是否有準入制大致分為公有區塊鏈、私有區塊鏈和聯盟鏈［19］三種類型。在公有區塊鏈中，所有記錄都是公開可見的，每個人都可以參與共識過程。在聯盟鏈中，只有一組預先選定的節點才會參與聯盟鏈的共識過程。公有鏈中所有的礦工都將參與共識，并且通過工作量證明或權益證明等復雜的共識機制達成共識［20］。因此，公有鏈是完全去中心化的，但同時鏈上交易也需要支付額外的手續費以獎勵礦工執行交易和維護網絡。聯盟鏈的中心化程度雖然不及公有鏈，但其速度通常比公有鏈更快，并且在聯盟鏈上執行合約操作數據不需要支付手續費。這些得益于聯盟鏈沒有使用像公有鏈那樣復雜的共識算法且擁有著更小的網絡拓撲結構［19］。

1.2 Merkle樹

Merkle樹是一種樹型數據結構，其主要特點是通過哈希函數將大量數據塊匯總為一個唯一的根哈希值（也稱為Merkle根），其核心優勢在于能夠高效且安全地驗證數據的完整性和一致性［20］。在Merkle樹中，每個葉子節點都存儲數據塊的哈希值，而每個非葉子節點則存儲其子節點哈希值的組合。最終，最頂層的節點，即根節點，代表了整棵樹的唯一哈希值。通過這種方式，Merkle樹能夠快速檢測出任何一個數據塊的變化，只需比較相應的哈希值即可。Merkle證明通過提供一條從目標數據塊到Merkle樹根的路徑，以及這條路徑上所有兄弟節點的哈希值，來證明目標數據塊的存在性或者完整性［21］。

2 系統模型與問題描述

2.1 事故救援數據共享模型

本文研究的事故救援數據共享框架如圖1所示，包含7個實體，分別是多授權中心、數據擁有者、數據使用者、去中心化文件存儲系統、聯盟鏈、公有鏈和外聯數據庫。在事故發生后，物聯網車輛采集事故數據并加密，將密文信息上傳至去中心化文件存儲系統，同時將數據摘要上傳至公有鏈，確保不可竄改性。聯盟鏈負責存儲加密數據在IPFS的索引，救援部門作為數據使用者通過聯盟鏈檢索并訪問相關數據，并通過分層審計驗證數據的完整性。外聯數據庫則同步鏈上數據至鏈下并提供快速查詢支持，確保數據高效可用。

各實體具體含義如下：

a）多授權中心。它包括中央授權中心（central authority，CA）與多個屬性授權中心（attribute authority，AA），負責密鑰生成和存儲。多授權中心是可信的密鑰分發機構，承擔了系統公共參數的生成，即在系統初始化時的主密鑰。當用戶向多授權中心發起注冊請求時，該實體會為請求注冊的用戶生成與其身份對應的屬性密鑰，同時還會為注冊的用戶生成假名，用于在交互中保護隱私和身份信息。

b）數據擁有者（data owner，DO）。它包括物聯網車輛以及駕駛員。物聯網車輛通過內置的傳感器和車載網關收集環境數據、車輛狀態等信息。駕駛員作為數據擁有者，提供與個人相關的數據，包括個人身份信息、醫療信息、保險信息等，用于事故后的處理和救援。

c）數據使用者（data user，DU）。它是事故救援的各個部門以及部門下的實體成員，包括但不限于交警部門、醫療機構、保險公司等。這些部門通過聯盟鏈中的通道機制進行數據共享，通過高效的分層審計查詢來驗證數據完整性。

d）去中心化文件存儲系統。該系統存儲數據擁有者上傳的加密數據，并返回存儲索引，通過索引可以高效地定位和檢索存儲的密文。本文使用IPFS作為去中心化文件存儲系統，其存儲數據并返回CID作為數據的唯一索引。

e）聯盟鏈。其由各部門共同維護，通過聯盟鏈通道機制，不同部門可以在獨立的通道中進行數據交換，從而確保數據的隔離。本文聯盟鏈使用 Raft 共識算法，可有效提高聯盟鏈事務發布及上鏈的速度，提高了數據共享的效率。

f）公有鏈。其用于存儲DO的共享數據摘要。公有鏈的去中心化和不可竄改性確保了數據摘要的真實性和完整性，為后續的數據驗證提供了可信基礎。

g）外聯數據庫。該數據庫將DO在公有鏈中存入的摘要信息以不同的機制同步到鏈下數據庫中，并設置查詢緩存以提升查詢效率。為了確保外聯數據庫的高效索引和防竄改能力，設計出新的高效索引結構，基于提出的索引結構設計出鏈上鏈下分層查詢方案，提升整體審計查詢效率。

本方法涉及的交通事故數據是指事故車輛收集的物聯網數據以及駕駛員的個人信息，這些數據被共享到參與數據救援的各個部門。整個共享方法的流程主要分為初始化階段（圖1中步驟①）、數據摘要上傳與鏈下同步階段（步驟②）、數據加密階段（步驟③）、數據共享階段（步驟④）和數據審計階段（步驟⑤、⑥），詳細的流程如圖2所示。其中，雙鏈之間的交互主要通過聯盟鏈與公有鏈之間的網關接口實現。具體來說，聯盟鏈會調用公有鏈對外暴露的查詢接口，以獲取鏈上存儲的數據哈希值以驗證數據的完整性。需要強調的是，公有鏈和聯盟鏈分別處理不同類型的數據：公有鏈專注于存儲事故數據的摘要信息，確保數據的不可竄改性；聯盟鏈則主要存儲 IPFS 中存儲的加密數據的索引，這種交互并不涉及數據跨鏈操作。

2.2 問題描述

在高速公路事故救援場景下，本文數據共享方法的核心目標是實現高效和安全的數據交換，以滿足多部門協作對數據獲取及時性和可信性的雙重需求。高效數據共享是指在多部門協作過程中，能夠以較低的延遲和高吞吐量來支持數據的快速分享與檢索，從而保障事故救援的及時性和有效性。安全數據共享是指在數據共享過程中，確保數據的完整性和可審計性。

3 高速公路事故救援數據共享方法

3.1 方法概述

本方法主要通過基于雙鏈架構的高效數據共享和基于BBF-Merkle樹的分層審計查詢，實現高速公路救援數據在多部門間的高效共享與安全審計。其中基于雙鏈架構的高效數據共享主要分為初始化階段、數據摘要上傳、數據加密階段與共享階段，主要完成數據共享工作。基于BBF-Merkle樹的分層審計查詢用于在DO收到數據后通過查詢來驗證收到數據的完整性，分為鏈下同步階段和數據審計階段。

3.2 基于雙鏈架構的高效數據共享

共享流程主要分為初始化階段、數據摘要上傳、鏈下數據同步階段以及數據加密和共享階段。在經過初始化后，DO計算共享數據的摘要，將摘要上傳至公有鏈，隨后使用加密算法對共享數據進行加密后將密文上傳到IPFS，再將密文在IPFS的索引共享到由各部門組成的聯盟鏈網絡，利用聯盟鏈的通道機制與高效性確保數據安全和訪問效率。各共享部門在獲取到索引后在IPFS中獲取密文并解密得到共享數據。

3.2.1 初始化

初始化階段主要對應圖1中的步驟①。初始化階段需要生成CP-ABE的系統參數、公私鑰對與用戶的屬性密鑰，算法的具體實現在現有方案［22］中有詳細說明。同時多授權中心還會隨機選擇一個隨機數γi，用于對用戶的身份進行匿名處理與還原。系統中的所有用戶，包括數據擁有者和數據使用者，想要通過系統進行安全的數據共享前必須向多授權中心發送請求注冊身份。用戶隨機選擇αi作為真實身份、再隨機選擇一個隨機數βi。將{αi、βi}通過安全通道發送給多授權中心。多授權中心計算用戶的匿名身份PIDi = αiHash（βi ‖γi）并返回給用戶，其中代表異或操作，Hash表示哈希函數，‖代表拼接操作。

3.2.2 數據摘要上傳與鏈下數據同步

數據摘要上傳與鏈下數據同步階段對應圖1中的步驟②。DO在對數據共享之前，計算hash =Hash {共享數據、PIDi、βi}，通過合約將hash存入公有鏈。在通過公有鏈的共識協議后，產生新的區塊。區塊鏈中每個區塊的結構由區塊頭和區塊體兩部分組成。區塊頭包含區塊編號、前一區塊的哈希值、時間戳等基本信息，用于維護區塊鏈的整體結構和安全性；區塊體包含了具體的交易數據，主要存入的數據可以表示為{PIDi、hash、βi、Timestamp}。其中：PIDi代表用戶的匿名ID；hash代表上傳到鏈上的摘要信息，確保數據的完整性與防竄改性；βi 是DO選取的隨機數，交通管理中心在鏈上發現數據被竄改時可以通過βi 還原DO的真實身份；Timestamp代表交易的具體發生時間。

本文設置兩種數據同步觸發機制將公有鏈鏈上數據同步到數據庫，分別是基于數據條數的觸發機制DVT （data volume trigger）與基于時間的觸發機制TIT（time interval trigger）。如果當前數據條數達到DVT閾值，將執行數據同步操作，將數據同步至鏈下數據庫。如果未滿足DVT觸發機制，則檢查當前時間與上次同步時間的間隔是否達到TIT閾值，若滿足條件，同樣執行數據同步操作。在短時間內有大量事故相關數據摘要上傳到公有鏈時，比如，在交通高峰期或惡劣天氣條件下，DVT機制確保鏈上數據能及時同步到鏈下數據庫，避免大量數據審計查詢需要在公有鏈層完成，影響查詢效率。當系統在某段時間內僅有少量數據上傳，TIT機制也能夠確保數據在設定的時間間隔內被及時同步到鏈下。

當同步機制被觸發后，公有鏈中的一批數據記錄會被同步到鏈下數據庫。同步到鏈下的一批摘要數據將根據BBF-Merkle樹的插入算法組織成一個樹型結構，并持久化到數據庫中。具體的過程將在3.3節介紹。

3.2.3 數據加密與共享

在多部門之間進行數據共享時，通過建立“共享通道”實現消息隔離。有共享需求的部門都可以加入一個通道，通道內的成員可以自由地共享和訪問數據，而不同通道之間是彼此隔離的。為了實現精細的訪問控制，從通道層面開始限制并且考慮到部門ID和用戶ID，設計了3種訪問策略類型，如表1所示。DO可以根據共享需求選擇不同的訪問策略對數據進行加密。例如，某部門下的用戶Peer1所屬部門是Org1，該部門加入了共享通道SharingChannel1，則它的屬性集合可以是{SharingChannel1、Org1、Peer1}。如果DO加密時所使用的策略為SharingChannel1 amp;amp; Org1，那么Peer1就能夠成功獲取密文并解密。注意，一個部門可能加入多個共享通道。

DO使用CP-ABE加密，通過定義的訪問策略（Policy）將{共享數據、PIDi、βi}加密為密文后上傳到IPFS，接收CID。接著將CID共享到由各部門維護的聯盟鏈網絡中。在聯盟鏈通過共識協議確認后生成的區塊體中，主要存入的數據可以表示為{PIDi 、CID、Policy、Timestamp}，其中PIDi代表用戶的匿名ID，CID代表密文在IPFS上的索引，Timestamp代表交易的具體發生時間。各部門可以檢索到所需數據的CID，然后通過CID在IPFS獲取到密文數據，最后使用密鑰對密文進行解密，得到共享數據。

3.3 基于BBF-Merkle樹的審計查詢

為了確保共享數據的完整性，DU需要對接收到的數據進行審計。在數據審計階段，DU計算解密后的共享數據摘要（hash′），通過對hash′與鏈上記錄的hash，可以確認接收到的數據是否與原始數據一致。為了提升公有鏈查詢效率，公有鏈上的摘要數據被批量同步到外聯數據庫，并設計了防竄改的BBF-Merkle樹鏈下索引結構以及插入查找算法，在高效檢索數據的同時保證數據的防竄改特性。基于BBF-Merkle索引結構，提出了緩存-數據庫-公有鏈的分層查詢方案。

3.3.1 BBF-Merkle樹

結合布隆過濾器、B+樹、默克爾樹等數據結構提出了BBF-Merkle樹索引結構，在實現高效查詢的基礎之上保證數據的不可竄改特性。BBF-Merkle樹數據結構定義如圖3所示。

圖3 BBF-Merkle樹結構Fig.3 Structure of BBF-Merkle tree

根節點RootNode=key， left， right， hash， valueList， min， max， BF，其中key代表數據的關鍵字，left和right分別代表左右子樹指針，hash代表子節點的哈希值，valueList代表存儲的數據摘要構成的鏈表，min和max表示該節點以及子樹的關鍵字的最小值和最大值，BF表示布隆過濾器。擴展節點ExtensionNode=key， left， right， hash， valueList， min， max，其含義與根節點保持一致。葉子節點LeafNode=key， left， right， valueList， min， max。元節點MetaNode=RootHash， BF， BlockHeight，其中RootHash代表根節點的摘要，BF表示布隆過濾器，BlockHeight代表元節點在公有鏈中的區塊高度。以此將BBF-Merkle樹和公有鏈建立聯系，保證索引結構的防竄改性。此時鏈下數據的數據竄改行為都會通過Merkle樹結構傳遞到元節點，而存入的區塊高度可以快速定位鏈上數據。

3.3.2 BBF-Merkle樹的插入

對于從公有鏈上同步的每一批摘要數據都會建立一棵BBF-Merkle樹。由于鏈上的hash都是毫無規律的數據摘要，并不方便鏈下數據索引的構建。首先計算key = hash mod k，其中key是上傳的數據摘要，k是一個自然數。得到的key和數據摘要構成一對key-value數據。然后，將同一批哈希數據在經過取模運算后得到的key-value數據構造出AVL樹結構，保證樹中每個節點左右兩個子樹的高度差的絕對值不超過 1，需要注意的是取模后的數據很有可能會有哈希沖突現象，對于這些沖突的數據使用鏈表將其順序連接。最后，從樹的最底部向上逐層構建，對左、右葉子節點取哈希并兩兩合并再求出新的哈希，如果僅有左節點或者右節點，則直接對該節點求哈希然后存入上層拓展節點。同時在上層拓展節點維護著指向葉子節點的左指針與右指針和key值的范圍。算法會不斷重復這個過程，直到達到頂端根節點，此時根節點記錄全部數據的key值范圍以及此批數據的頂層哈希，再將處理后的布隆過濾器值存儲到根節點的BF字段中，以便在后續查詢中使用布隆過濾器進行快速過濾。最終，BBF-Merkle樹被建立起來，過程如算法1所示。

算法1 BBF-Merkle樹建立算法

輸入：同步到鏈下的一批數據 dataBatch；模值 k。

輸出：BBF-Merkle樹的根節點 Root。

nodes =［］ /*初始化節點集合，用于存儲每個數據摘要的節點信息 */

for hash in dataBatch do // 遍歷每一條同步到鏈下的數據

node.key = hash mod k // 計算哈希值mod k，得到節點的key值

node.valueList = new List（hash） / *創建一個鏈表存儲每個數據摘要，初始時鏈表中只有當前數據的hash */

end for //完成所有數據摘要的處理

nodes.sortByKey（） //按照key值對節點進行排序

while （節點之間存在key沖突）

將key值相同的節點存儲的hash值合并到一個節點的va-lueList鏈表

end while

root = BuildTreeHelper（nodes） // 遞歸調用輔助函數構建樹

root.bf = BuildBloomFilter（nodes） /*計算布隆過濾器并存儲在bf字段中*/

return root // 返回構建好的BBF-Merkle樹的根節點

//構建樹的輔助函數，BuildTreeHelper（）

BuildTreeHelper（nodes）

if nodes is empty then /* 當前節點集合為空，已經沒有節點可以處理 */

return 1

end if

mid = len（nodes） / 2/* 計算中間節點的索引，決定當前樹的根節點 */

node = new Node（nodes［mid］.key， nodes［mid］.hash） // 創建根節點

node.left = BuildTreeHelper（nodes［0：mid-1］） /*遞歸構建左子樹 */

node.right = BuildTreeHelper（nodes［mid+1：len（nodes）-1］）

更新node的min、max，并進行平衡操作

node.hash = Hash （leftHash + rightHash） /*計算子節點的哈希值 */

return node

建立好一批數據的BBF-Merkle樹后，得到根節點的哈希RootHash，將RootHash和BF存入公有鏈，確保后續可以根據鏈上記錄的根節點哈希結合BBF-Merkle樹，實現對鏈下數據的竄改檢測，此時公有鏈上產生交易主要存入的數據包含{RootHash、BF、Timestamp}。隨后，將區塊高度、RootHash和BF一起寫入到元節點，每一批數據都會產生一個元節點，它和根節點一一對應并且彼此獨立。

3.3.3 分層查詢

DO通過IPFS獲取到密文并解密，得到{共享數據、PIDi、βi}，計算hash′=Hash{共享數據、PIDi、βi}并發出審計請求，驗證收到數據的完整性，整個流程如圖4所示。請求會逐層在緩存層、數據庫層和公有鏈層進行查詢操作，直到查詢到該hash′或者返回未查詢到的響應。如果查詢到hash′說明共享數據在整個共享過程中沒有被竄改，否則說明共享數據在共享過程中被竄改。下面將詳細說明查詢流程。

查詢請求依次經過緩存層、數據庫層，最后抵達公有鏈層。一旦查中數據，在滿足信任的情況下就會直接將查詢數據返回，不會一直將請求傳遞到公有鏈，并且每一層都擁有不同的信任滿足條件。緩存層的數據由滿足信任狀態下的數據庫和公有鏈寫入，因此緩存層默認為可信。公有鏈由于其擁有出色的去中心化與防竄改特性，其查詢結果也直接被視為可信。可見查詢流程的關鍵在于數據在數據庫層的查詢設計。

在數據庫層，依據BBF-Merkle樹索引結構進行查詢。具體來說，先計算key′=hash′" mod k。在進行索引查詢前，先通過每一批數據構建的BBF-Merkle樹的元節點中的BF排除掉不可能存在分支，這種“剪枝”可以進一步提升檢索效率。接著在一些可能存在的分支中根據key′按照BBF-Merkle索引結構進行查詢，BBF-Merkle檢索算法如算法2所示。算法從BBF-Merkle樹的Root節點開始檢索，key′等于Root的key直接遍歷該節點的ValueList，查詢hash′是否存在。如果key′不等于Root的key，則判斷key′是否在Root記錄的上下限范圍之內，如果key′不在記錄的上下限范圍之內，則直接排除該Root所在的分支，否則根據key′與Root節點key的大小關系決定取遞歸查找Root.left還是Root.right。在拓展節點中的查詢同樣遵循上述規則，通過key確認是否查詢該節點的ValueList，再根據key′與節點key的大小關系決定遞歸查找左子樹還是右子樹，直到查詢到葉子節點。如果通過索引查詢數據庫的結果為空，則繼續向公有鏈層查找。

如果在BBF-Merkle中查詢到與hash′對應的數據（執行算法2得到的是true），再根據元節點信息記錄的區塊高度去指定區塊檢索鏈上數據，對比元節點中存入的根哈希以及BF是否和鏈上數據保持一致：a）如果保持一致則說明數據庫中的數據沒有遭到竄改，鏈下數據庫數據達到信任條件，并且將BBF-Merkle的驗證路徑和查詢結果一同返回給用戶，用戶收到的響應數據同時包含查詢結果與對應的驗證路徑。由于BBF-Merkle包含Merkle結構，可以確保數據的完整性和不可竄改性，驗證路徑則提供了從鏈下數據庫到鏈上數據的一條可靠的Merkle Proof驗證路徑，用戶可以通過路徑自行計算并驗證摘要是否和鏈上保持一致。同時還會將查詢到的key-value數據寫入緩存層，并設置緩存的過期時間。b）如果元數據和鏈上數據不一致則認為數據庫的查詢結果不具備信任條件，同樣會繼續在公有鏈中進行查詢。

算法2 BBF-Merkle樹檢索算法

輸入：根節點Root、數據摘要hash′、需要查詢的鍵key′。

輸出：result（檢索的結果）、proofPath（Merkle Proof驗證路徑）。

currentNode = Root // 從BBF-Merkle樹的根節點開始檢索

proofPath =［］ //初始化Merkle proof路徑

while（currentNode ！= 1）

if（key′不在currentNode.bf的范圍內 ‖ key′currentNode.min ‖ key′ currentNode.max））

return False， proofPath // 未查中數據，返回查詢結果

end if

if（currentNode.key == key′ amp;amp; 在ValueList中檢索到hash′）

return true， proofPath // 查中數據，返回查詢結果

end if

//根據key′與currentNode.key的大小關系決定查找方向

if（key′ lt; currentNode.key） /* 如果key′小于當前節點的key值，則繼續查找左子樹 */

currentNode = currentNode.left

else /* 如果key′大于等于當前節點的key值，則繼續查找右子樹*/

currentNode = currentNode.right

end if

end while

return 1， proofPath

最終需要在公有鏈中的查詢分為兩種情況：一種是在數據庫中的查詢沒有達到信任條件需要進一步確認，另一種是在數據庫中的查詢結果為空。如果沒有達到數據庫信任條件并且在公有鏈中檢索到了hash′，還需要根據批次信息將該批數據重新構造BBF-Merkle樹，重新構造的過程可以根據Merkle樹的特性快速定位到被竄改的節點，修改數據庫中節點信息，進而快速構造BBF-Merkle樹以恢復數據庫的信任。如果是由于鏈上數據還未觸發同步機制導致的數據庫查詢結果為空，則直接將公有鏈的查詢結果返回給用戶并且在緩存層中寫入key-value數據，將緩存過期時間設置為TIT的觸發時間。需要注意的是，最終在公有鏈中仍然沒有查詢到hash′，說明DO收到的共享數據在共享流程中被竄改，此時該部門成員需要進一步向數據擁有者確認數據，這并不在本文共享方法的職責范圍內。

4 實驗驗證與性能分析

本章對所提方法進行仿真實驗，實驗所使用的本地機器為一臺Windows 11 家庭中文版64位電腦，其CPU為12th Gen Intel CoreTM i7-12700H，2.30 GHz，RAM為16 GB。Hyperledger Fabric 2.5聯盟鏈實驗環境，安裝在兩臺配置為4 GB RAM、2核處理器的Ubuntu 20.04操作系統的虛擬機上。在兩臺虛擬機上創建了包含三個排序節點、兩個組織，每組織包含兩個peer節點的多機網絡，Fabric網絡拓撲如圖5所示。實驗使用Fabric Gateway client API連接Fabric網絡，Go語言編寫聯盟鏈智能合約。以太坊Sepolia測試網絡作為公有鏈。實驗通過REMIX IDE進行智能合約的開發與部署，MetaMask錢包工具連接到更加接近真實的區塊鏈運行環境：Sepolia測試網絡。實驗采用應用二進制接口（application binary interface，ABI）生成Go語言代碼，使后端能夠與以太坊智能合約進行交互。鏈下存儲環境為 IPFS 0.4.19。使用Go語言實現了CP-ABE，該方案是基于現有工作［22］。使用Go語言實現了BBF-Merkle樹索引結構，并通過MongoDB數據庫對節點數據進行持久化，采用的緩存層技術為Redis。實驗數據源于真實數據集Brazilian traffic incidents-2007 to 2023［23］，隨機選取了1 000條數據用于數據共享。

4.1 安全性分析

方案通過雙區塊鏈結構、IPFS存儲以及BBF-Merkle樹的防竄改索引設計，確保數據在共享過程中的完整性和可審計性。

1）完整性 針對事故救援數據的完整性，本文從鏈上和鏈下存儲兩個方面進行分析。首先，公有鏈中的每個區塊通過其哈希值與前一區塊相連接，這意味著任何對事故救援數據的修改都會導致區塊哈希值發生變化，從而被全網節點或共識節點識別并拒絕。各救援部門維護的聯盟鏈節點是可信任的，即便某些節點遭到惡意控制，也可以通過公有鏈上的哈希值驗證共享數據的完整性。鏈下存儲方面，IPFS 保存的是加密后的用戶數據，依托于 IPFS 的去中心化存儲和內容尋址機制，能夠有效防止第三方對數據的竄改。在外聯數據庫中，本方案設計BBF-Merkle樹索引結構利用了Merkle樹的優勢，可以通過樹的哈希值快速檢測到任何數據竄改行為。在數據同步至以太坊區塊鏈時，每次生成的BBF-Merkle樹的根節點哈希值會存儲在以太坊上。當數據庫中的數據發生任何竄改，Merkle樹的哈希值會傳遞到根節點。由于以太坊上記錄的根哈希值與當前數據庫計算的哈希值不一致，系統能夠立即檢測到這種竄改行為，從而保證鏈下數據的安全性。

2）可審計性 公有鏈的防竄改特性為數據審計提供了強有力的基礎保障。所有的事故救援數據摘要都會以哈希值的形式記錄在公有鏈上，當參與救援的部門收到共享數據后可以通過緩存-外聯數據庫-公有鏈的分層審計查詢進行公開審計，驗證收到數據的真實性。利用Merkle樹的哈希驗證機制確保鏈下數據的防竄改性。如果查詢到的數據和鏈上數據（公有鏈中存儲的BBF-Merkle樹根哈希值）保持一致，說明數據庫數據未遭竄改，并將驗證路徑（Merkle Proof）一并返回給用戶，用戶可以通過驗證路徑審計數據的完整性。

4.2 基于雙鏈架構的數據共享性能分析

雙區塊鏈架構在數據共享和審計中展現出優勢。首先，雙鏈架構通過任務分工明確的設計，有效降低了單一鏈上執行所有任務的壓力。具體而言，聯盟鏈負責高頻次的數據共享任務，其高吞吐量和低延遲特性能夠滿足數據頻繁交互的需求；公有鏈則專注于審計和防竄改記錄，憑借其去中心化和高安全性保障數據的透明性和不可竄改性。通過這種分工，雙鏈架構避免了單條鏈需要處理過多無關交易的問題，大幅提升了整體性能與效率。其次，雙鏈架構在隱私保護與數據安全之間達到了良好的平衡。聯盟鏈通過權限控制和訪問管理，確保了數據在參與方之間的共享安全性，保護了敏感信息不被外部窺探。而公有鏈則作為審計記錄的存儲平臺，保障數據的完整性和公開審計的可信度。雙鏈架構不僅能夠實現高效的數據共享，還能提供強有力的審計支撐。

4.3 BBF-Merkle樹查詢性能測試

本節實驗中，為了測試BBF-Merkle樹的查詢性能，用戶分別執行50條、100條、200條、500條、1 000條和2 000條連續的查詢。其目的是模擬參與救援的相關部門在救援過程中或在事故后執行的數據驗證和審計操作在外聯數據庫層所消耗的時間，如救援過程中，交警、醫療救援團隊等部門需要快速獲取和驗證事故現場的關鍵信息或者保險公司需要對事故信息進行驗證。查詢未做任何查詢優化，均為單線程查詢。實驗與文獻［16～18］進行對比，其中文獻［16］在查詢上所做的優化操作是將數據同步到外聯數據庫，文獻［17］將同步到鏈下的數據按照時間戳進行排序使得每次計算摘要一致，通過全部的數據摘要來判斷數據是否被竄改。文獻［18］對外聯數據庫中的數據使用MPT樹進行存儲。實驗結果如圖6所示，本文方案模擬用戶進行審計查詢的效率優于上述方案，這主要是因為對數據使用分批處理，降低了索引樹的高度進而降低查詢時間開銷，并且通過布隆過濾器對數據查詢進行剪枝操作。文獻［17］在查詢時需要對數據進行排序并計算數據摘要，而本文方案雖然也需要計算摘要，但是不需要對數據進行排序。文獻［18］通過MPT存儲數據，借鑒了以太坊數據存儲的思想。然而，存儲的數據是摘要或哈希值，它們往往是隨機分布的，缺乏公共前綴，這會導致MPT的樹結構退化為接近線性的鏈表，進而導致查詢性能下降。

此外，還將BBF-Merkle樹的查詢性能和文獻［24］進行對比，在以太坊Sepolia測試網絡環境下對文獻［24］的共享流程進行復現，其查詢數據直接在以太坊中進行。結果如圖7所示，在外聯數據庫中的查詢所消耗的時間遠低于文獻［24］直接在以太坊中查詢所消耗的時間。根據圖7（a）中的數據可以看到，在查詢存在的數據時，BBF-Merkle樹的查詢時間顯著低于直接在以太坊Sepolia測試網絡上的查詢時間，尤其是在數據量增加的情況下。這種優勢在查詢不存在數據時更加明顯，如圖7（b）所示，當查詢2 000次不存在的數據時，以太坊的查詢時間高達1 994.3 s，而BBF-Merkle樹僅需要1.721 s。

4.4 基于BBF-Merkle的分層查詢性能測試

本節實驗對所提出Efficient-DSS的分層查詢的整體耗時進行實驗，不僅包含外聯數據庫的查詢消耗，還考慮到數據暫未同步到鏈下數據庫或者是由于數據庫層數據被竄改需要查詢以太坊的時間消耗（文獻［24］除外，其是使用原生以太坊查詢的查詢耗時）。實驗測量當用戶在進行審計查詢時，本文方案以及文獻［17，24］的時間開銷，分別執行50條、100條、200條、500條和1 000條連續的查詢進行性能測試。實驗結果如圖8所示，查詢耗時隨著次數增加。本文的分層查詢耗時最少， 1 000次查詢的耗時為50.32 s，而以太坊測試網絡中的查詢耗時達到437.1 s，文獻［17］的查詢耗時為57.12 s。需要到以太坊中查詢的概率是最低的，一方面以太坊摘要數據被不斷同步到鏈下數據庫中，另一方面大量的查詢都會在緩存和數據庫中命中，即使數據庫數據被竄改，也可以通過以太坊中存入的BBF-Merkle樹元節點數據檢測到。然后通過Merkle Proof路徑恢復數據庫的信任條件（還原被竄改的數據）。在實際的事故數據共享中，查詢的大多是熱點數據，無論是在哪一層的查詢命中，這些熱點數據會通過緩存存入Redis中，大大降低了后續查詢需要查詢以太坊的概率。

5 結束語

本文提出了一種基于雙鏈架構與BBF-Merkle樹的高效事故救援數據共享方案（Efficient-DSS），旨在解決高速公路事故救援數據共享中效率和數據安全難以平衡的問題；提出的雙鏈架構利用聯盟鏈實現數據高效共享，利用公有鏈保證共享數據的安全，雙鏈之間并發處理彼此無關的交易，提高共享效率。為了提升公有鏈審計查詢效率，設計了BBF-Merkle樹的鏈下索引結構與分層查詢方案，顯著提升了公有鏈的查詢效率，實現了鏈下數據庫的防竄改性與查詢結果的可驗證性。實驗結果表明，Efficient-DSS表現出優越性能，特別是在執行大規模查詢時，查詢時間顯著優于現有方案。該方案在事故救援場景中有效提升了救援響應速度，提高了多部門協作的效率，為實際應用提供了堅實的技術支持。目前，本文對于區塊鏈效率的提升主要集中在layer 2層，未來準備在layer 1層或者通過跨鏈技術進一步優化效率，推動更為高效、安全的區塊鏈應用。

參考文獻：

［1］Yang Jiachen， Wen Jiabao， Jiang Bin，et al. Blockchain-based sharing and tamper-proof framework of big data networking ［J］. IEEE Network， 2020， 34（4）： 62-67.

［2］Guo Shaoyong， Hu Xing， Guo Song， et al. Blockchain meets edge computing： a distributed and trusted authentication system ［J］. IEEE Trans on Industrial Informatics， 2019， 16（3）： 1972-1983.

［3］Chen C L， Yang Jiaxin， Tsaur W J， et al. Enterprise data sharing with privacy-preserved based on HyperLedger fabric blockchain in IIOT’s application ［J］. Sensors， 2022， 22（3）： 1146.

［4］劉揚， 胡學先， 周剛， 等. 基于多層次區塊鏈的醫療數據共享模型 ［J］. 計算機應用研究， 2022， 39（5）： 1307-1312， 1318. （Liu Yang， Hu Xuexian， Zhou Gang， et al. Multi-level blockchain-based model for medical data sharing ［J］. Application Research of Computers， 2022， 39（5）： 1307-1312， 1318.）

［5］Li Kunchang， Yang Yifan， Wang Shuhao，et al. A lightweight privacy preserving and sharing scheme with dual-blockchain for intelligent pricing system of smart grid ［J］. Computers amp; Security， 2021， 103： 102189.

［6］Zhang Yuqing， Ma Zhaofeng， Luo Shoushan，et al. DBSDS： a dual-blockchain security data sharing model with supervision and privacy-protection ［J］. Concurrency and Computation： Practice and Experience， 2023， 35（21）： e7706.

［7］Liu Linchen， Liu Ruyan，Lyu Zhiying， et al. Dual blockchain-based data sharing mechanism with privacy protection for medical Internet of Things ［J］. Heliyon， 2024， 10（1）： e23575.

［8］LevelDB ［EB/OL］. http：//LevelDB. Org.

［9］Przytarski D， Stach C， Gritti C，et al. Query processing in blockchain systems： current state and future challenges ［J］. Future Internet， 2022， 14（1）： 1.

［10］Mardiansyah V， Muis A， Sari R F. Multi-state Merkle Patricia Trie （MSMPT）： high-performance data structures for multi-query proces-sing based on lightweight blockchain ［J］. IEEE Access， 2023， 11： 117282-117296.

［11］Huang T L， Huang J. An efficient data structure for distributed ledger in blockchain systems［C］//Proc of International Computer Sympo-sium. Piscataway，NJ： IEEE Press， 2020： 175-178.

［12］Choi J A， Beillahi S M， Singh S F，et al. LMPT： a novel authenticated data structure to eliminate storage bottlenecks for high performance blockchains ［J］. IEEE Trans on Network and Service Management， 2024， 21（2）： 1333-1343.

［13］Li Yang， Zheng Kai， Yan Ying，et al. EtherQL： a query layer for blockchain system［C］// Proc of the 22nd International Conference on Database Systems for Advanced Applications. Cham： Springer， 2017： 556-567.

［14］Pratama F A， Mutijarsa K. Query support for data processing and analysis on Ethereum blockchain［C］// Proc of International Sympo-sium on Electronics and Smart Devices. Piscataway， NJ： IEEE Press， 2018： 1-5.

［15］Wang Sheng， Dinh T T A， Lin Qian， et al. ForkBase： an efficient storage engine for blockchain and forkable applications ［J］. Proc VLDB Endow， 2018， 11： 1137-1150.

［16］Zhang Zhaoyi， Zhong Yanru，Yu Xiaofan. Blockchain storage middleware based on external database［C］//Proc of the 6th International Conference on Intelligent Computing and Signal Processing. Piscata-way， NJ： IEEE Press， 2021： 1301-1304.

［17］隋源， 汪衛， 鄧雪. 一種面向區塊鏈的鏈下數據庫高吞吐量可驗證查詢方法 ［J］. 小型微型計算機系統， 2021， 42（6）： 1304-1312. （Sui Yuan， Wang Wei， Deng Xue. High throughput verifiable query method for blockchain-oriented off-chain database ［J］. Journal of Chinese Computer Systems， 2021， 42（6）： 1304-1312.）

［18］孫一萌， 范洪博， 彭慢煜， 等. 一種面向聯盟鏈的鏈下數據可驗證查詢方法 ［J］. 現代電子技術， 2023， 46（19）： 70-74. （Sun Yimeng， Fan Hongbo， Peng Manyu， et al. A method of off-chain data verifiable query for consortium blockchain ［J］. Modern Electro-nics Technique， 2023， 46（19）： 70-74.）

［19］Gad A G， Mosa D T， Abualigah L，et al. Emerging trends in blockchain technology and applications： a review and outlook ［J］. Journal of King Saud University-Computer and Information Sciences， 2022， 34（9）： 6719-6742.

［20］Krichen M， Ammi M， Mihoub A，et al. Blockchain for modern applications： a survey ［J］. Sensors， 2022， 22（14）： 5274.

［21］De Ocáriz Borde H S. An overview of trees in blockchain technology： Merkle trees and Merkle Patricia Tries ［M］. Cambridge， UK ：University of Cambridge， 2022.

［22］Lewko A， Waters B. Decentralizing attribute-based encryption［C］// Proc of Annual International Conference on Theory and Applications of Cryptographic Techniques. Berlin： Springer， 2011： 568-588.

［23］https：//www. kaggle. com/datasets/pedrogoncalv/brazilian-traffic-incidents-2007-to-2023［EB/OL］.

［24］Ullah Z， Raza B， Shah H，et al. Towards blockchain-based secure storage and trusted data sharing scheme for IoT environment ［J］. IEEE Access， 2022， 10： 36978-36994.