基于Fabric 的海量交易數據上鏈預處理機制

劉穎，馬玉鵬，趙凡，王軼，蔣同海

（1.中國科學院新疆理化技術研究所，新疆烏魯木齊 830011；2.中國科學院大學，北京 100049；3.新疆民族語音語言信息處理實驗室，新疆烏魯 木齊 830011）

0 引言

區塊鏈作為一種分布式賬本，集成了P2P 網絡、密碼學、分布式共識協議、智能合約、數據庫和虛擬機等技術，具有去中心化、防篡改、可追溯、可共享、可信驗證和隱私保護等特點［1］。由于企業對不同應用場景的信任需求有所差異，使得區塊鏈需要權衡去中心化、一致性和擴展性之間的關系［2］。目前，由于聯盟鏈在隱私保護、訪問控制等方面的優勢，更適合多參與方數據交互的需求［3］，因此被應用于供應鏈、數據共享等領域，其中由IBM 開發的Hyperledger Fabric 是當前廣泛使用的聯盟鏈框架［4］。RAUCHS 等［5］研究表明，48%的聯盟鏈項目都是基于Fabric 平臺實現。因此，Fabric 在學術和工業上都具有較高的研究價值。

由于聯盟鏈基于共識的網絡環境［6］，智能合約的運行必須是確定性程序，在每筆交易和區塊處理后，所有節點都要達到相同的狀態［7］。聯盟鏈不允許不確定因素進入網絡，導致智能合約僅限于從區塊鏈網絡內部訪問數據，與第三方業務系統之間無法實現安全的數據交互，對不同企業或組織間的數據共享造成了阻礙。針對該問題，研究者引入了預言機，其負責從外界獲取數據并對數據進行驗證和預處理，相當于在聯盟鏈和外部世界之間形成安全通道，避免破壞鏈內數據的安全性［8］，預言機工作場景多為價格預測、IoT 等領域。但是，當預言機授權多個機構協同管理數據上鏈操作時，其數據更新周期較短、規模較大且存在并發沖突問題，即同一時間段內修改大量相同主鍵的交易數據。針對預言機獲取鏈外海量交易數據上鏈存在并發沖突的情況，Fabric 系統采用多版本并發控制（MVCC）機制解決該問題，通過快速讀取交易數據版本來提高讀取效率和并發性，導致大量并發沖突的交易數據被延遲發現并標記為無效。研究［9］表明，Fabric 處理并發交易數據時，成功率不足25%。目前改進方法有Fabric++［9］、StreamChain［10］和FabricSharp［11］，但仍不能完全解決沖突交易數據上鏈問題，且占用大量Fabric 系統計算和存儲資源。XU 等［12］提出LMLS算法，通過在Fabric 系統內對沖突交易數據的主鍵改為復合鍵的方式，在一定程度上解決了并發沖突問題，但其更改了賬本數據庫中業務的關聯性，影響歷史狀態數據庫信息，同時解碼復合鍵又增加Fabric的資源消耗，不適合實際業務場景應用。因此，合理解決并發沖突問題并提高交易成功率成為亟待解決的問題。

本文自主研發了Fabric 預言機作為測試平臺。在預言機中設計了海量數據預處理（MCPP）方法，通過實時監聽沖突交易數據在聯盟鏈中的上鏈完成度，減少高爭用對Fabric 造成的工作負載，提高了數據傳輸過程中Fabric 處理事務的高效性和安全性。

1 相關工作

1.1 預言機

預言機概念最早由圖靈提出，在計算機復雜理論與可計算理論中，用來研究圖靈機系統內確定性問題的黑盒子。區塊鏈領域借鑒了圖靈所提出的概念，將向區塊鏈提供確定性信息的人、硬件或軟件統稱為預言機［13］。預言機在獲取外部數據源的選取機制方面已經取得一定研究成果。SATA 等［14］在以太坊中提出一種人工智能與預言機相結合的機制。ADLER 等［15］提出一種基于投票博弈的預言機，解決獲取命題真假的問題。CAI 等［16］提出一種基于非線性鎖定規則，通過預測評分方案來選取結果。SOBER 等［17］和NELATURU 等［18］提出一種基于閾值簽名的投票預言機，通過參與者的投票情況來選取結果。MERLINI 等［19］提出一種預言機協議，解決配對問題中選民的懶惰均衡問題。

上述研究在預言機選取數據源上取得了進展，主要貢獻為獎懲機制、投票機制及信譽機制等，但局限于特定領域采取針對性措施來解決問題，并未考慮預言機獲取海量交易數據后，接入聯盟鏈的服務質量問題。

為了保證數據獲取的可用性、準確性和安全性，研究者們在預言機功能擴展方面進行了研究。GAO等［20］在預言機中增加選擇存儲功能，提高區塊鏈獲取數據的速度。WANG 等［21］提出一種對多源數據的提取和分析方法。ZHANG 等［22］提出一種數據聚合方案，對預言機獲取的數據加強了隱私保護。WANG 等［23］提出一種可擴展的安全分析框架，在攻擊發生之前檢測漏洞。KUMAR 等［24］提出一種處理金融數據的方法。

綜上所述，預言機的擴展功能發展至今，實現了對外部數據源的存儲、分析、聚合及檢測等方法，但預言機在獲取的海量交易數據存在并發沖突問題時，并未考慮不同規模數據對Fabric 網絡環境及服務質量的影響，缺少鏈上實際應用的運行與測試。

1.2 并發沖突

目前，在學術界與工業界中已有很多針對Fabric并發沖突交易數據上鏈的研究。GOEL 等［25］提出一種基于優先級的事務驗證模型，用于支持交易的差異化服務質量。GORENFLO 等［26］通過提高交易吞吐量更改Fabric 架構，減少交易排序和驗證期間的計算和I/O 開銷。RUAN 等［11］提出一種增強執行交易驗證架構的方法，通過生成沖突圖并對其進行序列化減少無效交易。THAKKAR 等［27］通過對背書階段的改進，將狀態數據庫的數據結構改為哈希表來提高吞吐量。SHARMA 等［28］提出用數據庫技術對事務重新排序和早期中止，以提高Fabric 性能，但沒有討論背書失敗和虛讀問題。SOUSA 等［29］通過在Fabric 中實現BFT-SMART 共識協議來提高吞吐量。RAMAN 等［30］提出一種有損壓縮的方式來降低背書和驗證階段的通信成本，但這種方法只適用于對有損壓縮不敏感的大型數據集存儲的場景。NASIRIFARD 等［31］提出用無沖突復制數據類型（CRDT）的概念來解決沖突，但該方法只適用于CRDT 建模的用例。

綜上所述，現有方法通過提高吞吐量來減少交易失敗數據數量，同時注重延遲的影響，即通過優化Fabric 中MVCC 機制，解決了沖突交易失敗的問題，而在實際應用場景中，通過犧牲Fabric 系統計算和存儲資源來解決并發沖突問題會降低Fabric 性能。因此，本文提出一種基于Fabric 預言機的數據上鏈預處理機制，將數據獲取和沖突檢測方法相結合，通過提前發現并對沖突交易數據進行預處理，保證海量交易數據完整上鏈。

2 基礎知識

2.1 Fabric 中EOV 技術流程

Fabric 平臺作為最具代表性的聯盟鏈，通過多個組織的聯盟組成網絡，并且為了提高系統并發能力，組織節點之間并發處理交易。Fabric 的MVCC 機制在處理并發沖突時會出現交易延遲中止現象，即在執行階段就已經違反驗證標準的交易直到驗證階段才被會發現，降低了系統性能。Fabric 的交易處理流程遵循EOV 三階段原則，具體如下：

1）執行階段。客戶端向背書節點發送交易請求，背書節點在本地獨立地驗證每一筆交易，然后將帶有驗證結果的交易返回給客戶端。

2）排序階段。客戶端首先將驗證結果發送給排序節點并建立全局順序，然后排序節點將交易結果按順序打包成規定交易數量的區塊，最后發送給驗證節點。

3）驗證階段。驗證節點獨立串行化驗證塊中的每筆交易，根據驗證系統鏈碼（VSCC）機制驗證交易是否遵循背書策略以及根據MVCC 機制驗證每個讀寫集密鑰的版本是否與當前世界狀態中密鑰的版本相同。

Fabric 聯盟鏈作為典型的分布式系統，各節點在網絡中獨立部署和維護賬本，利用Gossip 通信實現狀態同步。根據分布式系統中的CAP 定理的原則，不能同時兼顧一致性、可用性、分區容錯性三要素。Fabric 在保證一致性和分區容錯性的前提下無法確保一致性，因此Fabric 直到驗證階段，通過節點共識和驗證來確保所有節點中世界狀態數據庫的最終一致性。Fabric 為滿足一致性原則，在高并發情況下，所有交易數據都執行EOV 流程，受到鏈碼邏輯復雜度、數據訪問頻率、排序算法效率、服務規模、背書策略的復雜度等因素產生的訪問延遲的影響，使其驗證階段的平均時延增加，主要原因為當前區塊校驗為順序串行執行，無法充分利用多核資源。因此，在同一出塊時間內，相同主鍵的交易數據只有一條驗證成功，并且直到驗證結束才會被發現，失敗交易數據需重復執行EOV 流程才能完成成功上鏈操作。在文獻［32］中開展了改變節點數量分析EOV 流程對Fabric 性能影響的實驗，實驗結果表明，當Peer 節點數量從1 增加到4 時，吞吐量僅增加了1.5 倍，而CPU 占用率增加了4 倍。這是由于每個Peer 節點都對塊中交易執行驗證流程而產生組織內的冗余工作。在EOV 流程中，只有驗證階段符合背書策略的交易才能實現負載平衡，因此高并發場景下會降低CPU 利用率。由于驗證階段進行多個簽名驗證和對磁盤的同步輸入輸出操作，成本高于執行階段，因此吞吐量的增量并不顯著：當超過每個組織4 個Peer 節點后，吞吐量沒有增加；當Peer 節點不變，CPU 數量從1 增加到16 時，吞吐量增加了5.5 倍，而CPU 利用率降低了55%。這是由于當CPU 較少時，執行階段與驗證階段對CPU 的爭奪導致其利用率較高。當CPU 數量增加時，驗證階段可利用多個CPU 并行處理事務從而提高吞吐量。此外，驗證階段提交的交易可能存在在執行階段更改世界狀態數據庫的情況，導致驗證階段讀取過時數據狀態。

綜上所述，通過添加Peer 節點來擴展Fabric 網絡可以幫助減少執行階段的工作負載，但對驗證和提交階段沒有太大幫助。此外，通過增加CPU 數量提升性能并增加額外基礎設施成本是不合理的。當多個組織協同工作時，組織內的冗余工作會增加，為了提高效率和降低成本，海量數據沖突預處理通過鏈下提前檢測沖突交易數據并對其重排序，利用分區歸并的思路，提升EOV 流程中驗證階段的一致性吞吐量，減少無效交易數據在執行、排序和驗證階段對CPU 的占用率和無效時延，避免了失敗交易數據重復執行EOV 流程，為Fabric 在海量交易場景下獲得了更高的成功率。

2.2 并發沖突原理

為了更加直觀地理解Fabric 中MVCC 機制處理沖突的原理和細節，通過圖1 進行詳細說明。

圖1 Fabric 沖突處理原理Fig.1 Principle of handling conflicts in Fabric

首先，客戶端在同一時間段內，分別發送兩條交易提案Tx1 和Tx2，且主鍵修改相同。客戶端根據背書策略將Tx1 和Tx2 打包發送給背書節點，通過驗證數字簽名來確定節點是否有權限執行該交易，驗證通過后模擬智能合約，將結果返回給客戶端。接著，客戶端依次驗證節點身份并對比返回的結果是否一致，當結果一致時將提案結果和之前的交易提案一起打包成交易并簽名，反饋給排序節點，否則中止處理。然后，排序節點將接收到的交易進行簽名驗證并按照共識策略排序，根據區塊生成策略將Tx1 和Tx2 打包生成新的區塊。最后，排序節點把這些區塊發送給記賬節點并對塊中每筆交易進行狀態校驗。Tx1 率先驗證，驗證成功后將結果寫入世界狀態數據庫，密鑰版本也隨之更新。當Tx2 到達驗證階段時，檢測到與Tx2 背書時的結果不同，導致Tx2 被標記為無效。Fabric 在執行排序之前模擬了事務所需運行的智能合約，影響了事務之間的序列化沖突交易數據的數量，使交易執行與交易提交分開處理，導致違反背書原則的交易直到驗證結束才被發現，如果想要全部交易數據成功上鏈，需要再次推送失敗交易重新執行EOV 流程，增加了高爭用給Fabric 帶來的工作負載，降低了數據傳輸過程中并發沖突交易數據的成功率。因此，本文提出的數據上鏈預處理機制在EOV 流程執行前檢測出沖突交易，避免無效交易占用系統資源，提高了Fabric 性能。

3 數據上鏈預處理機制

3.1 整體架構

本節提出一種基于預言機的數據上鏈預處理機制，整體架構由三部分組成，分別為外部組織、預言機和Fabric，如圖2 所示。客戶端作為外部組織，負責提供可信的數據源。預言機作為第三方服務，負責接收外部組織和區塊鏈的數據交互請求，為Fabric提供安全可用的交易數據。預言機作為連接真實世界和Fabric 聯盟鏈的接口，將外部數據傳輸至聯盟鏈內和將鏈內數據發送給外部組織，具體功能包括：事件處理負責對數據過濾聚合，留痕服務保障交易數據的行為可追溯，訂閱推送實現了自動化調用智能合約等。Fabric 聯盟鏈內3 個節點部署了聯盟鏈智能合約和用于與預言機進行數據交互的智能合約，每個節點都要監聽和執行網絡中發生的事務。

圖2 整體架構Fig.2 Overall architecture

預言機作為Fabric 與外部世界進行數據互操作傳輸的基礎，為聯盟鏈與外部組織之間實現多種模式的數據交互提供了安全基礎，主要集成了兩種數據傳輸機制，分別為輸入式預言機和輸出式預言機，是區別于聯盟鏈的第三方服務，由權限管理、事件處理、留痕服務、訂閱推送和MCPP 這五部分協同組成。權限管理模塊負責對外部組織身份調用智能合約的權限進行驗證，以保障數據源可信和安全；事件處理模塊負責將預言機獲取的數據進行過濾、聚合等整合操作；留痕服務保證數據傳輸行為的可追溯性；訂閱推薦即自定義訂閱推送器，用戶通過設置參數，獲取鏈上數據周期，定時調用智能合約讀取鏈上數據，實現主動推送的輸出式預言機功能；MCPP 解決了海量上鏈交易數據中的并發沖突情況。

3.2 海量數據沖突預處理方法

在大量應用場景下有海量交易數據上鏈的需求，但Fabric 中MVCC 機制會使沖突交易延遲發現并被標記為無效，為減少無效交易占用Fabric 系統計算和存儲資源，解決上鏈事務在進入EOV 流程前可能觸發Fabric 中MVCC 機制的沖突問題，基于預言機提出一種基于加鎖和重排序的方法，將沖突交易數據按批次延遲處理，并將其緩存于預言機隊列中，從而確保交易數據總量的完整性和同主鍵交易數據的序列化一致性，以提高Fabric 處理沖突交易數據的成功率。

MCPP 通過檢測、監聽、延時提交、事務加鎖和重排序緩存方法實現塊內沖突交易數據數量的最小化。該方法解決海量交易數據上鏈中存在并發沖突現象的交易流程如圖3 所示。預言機獲取海量交易數據后，判斷交易主鍵是否加鎖，即是否為正在執行的交易，如果加鎖則對其序列化重排序加入緩存，否則對該主鍵加鎖再檢測下一條可執行交易，當可執行交易滿足批量打包交易數量時，推送至Fabric 中監聽上鏈完成度，監聽到上鏈成功后對加鎖主鍵解鎖。循環訪問緩存內不同主鍵的無沖突交易執行上鏈操作，直到緩存內交易為空。

圖3 MCPP 沖突處理流程Fig.3 Procedure of MCPP for handling conflicts

3.2.1 加鎖機制及交易延時提交

在本文所涉及的交易數據形式化定義中，T為交易，P為背書節點，KW為修改交易的主鍵，VW為修改交易的值，Ei為需要上鏈交易的寫集合，u為Ei中包含的KW主鍵數量，ci為Ei主鍵需要修改的次數，將每個交易主鍵成功交易的次數記為N。當交易總數一定時，KW越多，每條KW對應的交易沖突數越少，反之，KW越少，并發沖突的數據越多。當預言機獲取外部組織發送的數據集Ei后，由于每筆交易在Fabric的EOV 流程中并行獨立模擬，驗證階段會更新本地狀態數據庫，如果短時間內發起多筆同主鍵交易，可能導致世界狀態數據庫瞬時變化，因此直到驗證階段才發現背書響應中的讀寫集不匹配的無效交易，即如果交易Ti中的和交易Tj中的相等，則存在并發沖突，計算方法如下：

在重排序階段前，針對同一出塊時間內，如果相同主鍵的交易數據更新到同一個塊的賬本中，則會出現新交易正在讀取的數據版本號被執行階段的交易更新的現象，導致新交易讀取了無效數據版本號，從而上鏈失敗。通過在交易數據進入排序階段前，將當前事務要更新的主鍵執行加鎖并對該交易啟動監聽操作，將鎖定階段出現的同主鍵交易緩存在預言機內存中。當前交易在執行和驗證階段需要一段時間間隔，防止其他沖突交易讀取錯誤數據狀態版本號。為了保障對符合要求的主鍵交易加鎖的準確性，使用Semaphore 設置同主鍵交易中只允許一個許可的二元信號量方法。加鎖和解鎖過程調用AQS框架的共享模式鎖，其主要特點是不會出現阻塞線程的現象，只須判斷當前值與預期值是否相等即可。如圖4 所示，設定每個塊內最大交易數據的值為n，當n=10 時，在加鎖機制中索引交易主鍵的最大值即為10。通過循環塊內事務得到5 條無沖突交易數據，對其依次加鎖后執行上鏈操作，當檢索到同主鍵交易時，則加入重排序機制的待處理階段，防止這些沖突交易占用系統資源。

圖4 主鍵加鎖原理Fig.4 Primary key locking principle

3.2.2 重排序緩存

當同一區塊中包含多筆交易時，前一筆交易在后一筆交易前提交并更改了數據狀態的版本號，導致后一筆交易在執行階段讀取了舊版本的數據，則這樣的交易數據構成了依賴關系，存在并發沖突現象。在面臨高并發沖突情況時，Fabric 系統中的EOV 流程效率較低的根本原因是大量沖突交易在驗證階段耗時長且直到驗證結束才被發現。本文在預言機中提出的MCPP 對交易數據集Ei中檢測到的沖突交易進行序列化重排序緩存，確保相同主鍵的數據以非沖突的全局序列化順序提交至鏈上。在預言機中提前檢測到并發沖突交易，有效預防沖突交易進入Fabric 排序階段生成在同一塊內，減少多次執行失敗交易的次數，且MCPP 在不影響同一主鍵串行執行順序的情況下，以最佳全局順序實現重排序。排序后的交易以鍵值對的形式存儲在預言機緩存中，沖突的交易數據以序列化方式延時提交上鏈。當緩存內交易上鏈成功后及時刪除交易數據信息，避免重復上鏈操作。

如圖5 所示，假設在同一出塊時間內發起6 筆交易，其中第1、2、3 筆交易和第4、5、6 筆交易存在兩組并發沖突現象。當T1 到達時，由于K1 第1 次出現，滿足待上鏈交易要求，根據依賴關系，T2、T3 沖突交易進入重排序沖突交易緩存中。同理，在與主鍵K2相關的T4、T5、T6 交易中，T4 為無沖突交易且可直接上鏈，T5、T6 進入重排序沖突交易緩存中且待上鏈。在重排序緩存中，建立同主鍵索引循環，防止多個沖突交易上鏈后再次觸發MVCC 機制，通過循環索引重排序緩存中不同主鍵的無沖突交易數據，對其執行上鏈操作，并在成功上鏈后刪除緩存中該筆交易記錄。綜上分析，該重排序緩存方法只需對所有待上鏈交易數據執行單次遍歷，利用線性規模的緩存空間對無沖突交易和待排序沖突交易進行預處理，并分批執行上鏈操作，因此該算法的時間復雜度和空間復雜度均為O（n），其中，n為交易數據總量，表明了該算法在處理大規模海量沖突交易數據時具有良好的擴展性。

圖5 依賴關系圖Fig.5 Dependency graph

本文研究了重排序緩存方法對基于Fabric 的海量交易數據上鏈預處理機制的整體實時性的影響，通常用延遲時間作為衡量標準。重排序緩存方法通過對沖突交易預處理并循環上鏈無沖突主鍵的交易數據，減少無效交易進入EOV 流程，提高了交易處理效率和吞吐量。通過分析重排序緩存方法的時間復雜度可知，對整體流程的實時性影響主要取決于同主鍵沖突交易數據的數量、系統特性等因素。當沖突交易較多時，重排序緩存方法通過有效降低鏈碼執行、交易排序、驗證等環節的訪問延遲，從而提高海量交易數據整體上鏈的實時性能。

通過序列化重排序緩存機制，在驗證階段發生前使用重排序方式識別無效交易，并且在不影響相同主鍵序列化順序的前提下，所有交易僅執行一次EOV 流程就實現成功上鏈，使Fabric 系統中上鏈成功的有效事務數量顯著增加，減少了不必要的EOV流程對Fabric 的資源消耗。

3.2.3 核心算法描述

算法1 給出了MCPP 的沖突檢測與解決方法，該算法將檢測到的沖突交易數據緩存在預言機中待處理，防止主鍵相同的交易觸發MVCC 機制導致交易失敗的問題，實現了相同主鍵的交易在Fabric 內的執行順序為串行序列化，保障了同主鍵交易發起順序不被改變。

算法1MCPP 算法

3.3 數據傳輸保障措施

盡管聯盟鏈技術受到關注和推廣，但目前并未被全面應用于各個領域，大部分構想仍處于測試階段，并且聯盟鏈技術中的共識機制限制了其吞吐量和實時效率，導致大部分有價值信息仍存儲在鏈外世界。如果不同外部組織或機構能夠有效利用聯盟鏈技術協同管理系統，合理利用鏈內與鏈外數據，增強多領域信息交互并擴大資源共享范圍，則將有利于構建相互融合的價值生態。因此，如何在不影響聯盟鏈系統特點的前提下，使外部組織安全合理地調用鏈碼從而實現數據傳輸成為亟待解決的問題。本文改進了文獻［33］的數據遷移機制，通過綜合考慮外部組織行為的信任度和當前鏈內環境的安全性，對外部組織的身份增加了規范的權限認證，限制了外部組織調用智能合約的身份。同時，在預言機中設計不同節點間使用非對稱加密技術建立密鑰，保障數據傳輸過程中的安全性和完整性。

3.3.1 外部組織權限驗證

評估和驗證外部組織行為的信任度指聯盟鏈網絡中外部組織與其他機構或企業進行數據互操作行為的真實性、合法性和有效性。身份認證要確保參與者身份可信、數據訪問受限、接口調用受控，數據交互要確保數據的一致性和可追溯性。對外部組織信任度研究有助于提高Fabric 網絡的安全性、互操作性和可擴展性，促進了聯盟鏈與其他領域的融合和創新。因此，本文通過AES 算法來加密令牌，當外部組織調用預言機拉取或推送數據時，需要攜帶預言機發放的令牌，以確保外部組織的行為經過預言機授權，實現了外部組織對Fabric 中鏈碼調用行為的合法性限制。預言機驗證令牌通過后處理外部組織的業務請求。

3.3.2 數據傳輸安全性保障

為了保證數據傳輸過程的安全性，通過RSA非對稱算法來加密外部組織與預言機之間的通信數據，預言機和外部組織分別擁有一對密鑰。當聯盟鏈請求預言機獲取可信外部組織的數據時，聯盟鏈向預言機發送外部數據上鏈請求，通過預言機的公鑰對傳輸的數據加密，預言機收到數據后，使用本地保存的私鑰進行解密數據內容，利用TLS 技術產生的密鑰加密執行上鏈操作。當通過預言機將聯盟鏈內數據輸出給可信外部組織時，預言機調用智能合約讀取數據后，使用外部組織的公鑰加密數據，當外部組織收到數據后，使用本地保存的私鑰進行解密操作，保證了數據傳輸過程的安全性。

同時，為了保障數據傳輸過程中鏈內環境安全，在設計數據傳輸保障措施的過程中，主要從以下3 個方面進行考量：1）在聯盟鏈內部實施身份認證和權限控制機制，確保每個外部組織通過預言機與Fabric 進行數據交互時，都具有合法的數字證書和訪問權限，從而防范偽造、冒充和篡改等惡意行為；2）在聯盟鏈中編寫和執行安全的鏈碼，確保智能合約能夠正確安全地調用預言機中的數據，從而避免智能合約的漏洞問題；3）在聯盟鏈內部對其行為進行監督和審計，確保交易的可驗證性和可追溯性。因此，在數據交互過程中，不僅需要平衡數據隱私和業務效率，而且需要考慮鏈內不同層次和角度的安全措施。

如圖6 所示，以輸入式預言機為例，詳細解釋在數據傳輸過程中如何保證數據上鏈過程的完整性和安全性。在準備階段，預言機利用AES 算法將權限令牌的ID 加密后分發給不同的外部組織，用來設定外部組織調用聯盟鏈內鏈碼的合法權限，預言機和外部組織之間利用RSA 產生一對密鑰，用來保證數據傳輸過程的安全性和完整性。在執行過程中：首先聯盟鏈向預言機發起數據請求命令，預言機將請求發送給外部組織，外部組織通過公鑰PK1 將事先發放的權限令牌和數據加密發送給預言機；然后預言機通過自身私鑰PR1 解密令牌和數據，再利用AES 解密令牌id 驗證外部組織身份是否合法，在驗證通過后，聯盟鏈和預言機之間通過TLS 產生的通信密鑰PK2 將數據加密傳遞給聯盟鏈；最后聯盟鏈利用PR2 進行解密，Fabric 獲取數據并完成上鏈操作。

圖6 數據傳輸保障措施Fig.6 Data transmission guarantee measure

4 實驗與結果分析

4.1 環境設置

為了驗證研究方案的可行性、安全性和高效性，通過實驗模擬了海量交易數據上鏈的場景，將原始Fabric 系統處理的海量交易數據與基于Fabric 預言機獲取的海量交易數據進行比較。設計并實現MCPP 并測試了3 組實驗，對預言機在短時間內處理海量交易數據的有效性進行全面分析。由于目前在聯盟鏈領域沒有權威的數據集作為參考，因此實驗通過數據生成器生成交易集合，在該集合中每條數據代表一條交易，每筆交易以鍵值對的形式存儲。實驗環境所使用的服務器配置與Fabric 網絡配置如表1 所示。

表1 服務器與Fabric 網絡配置Table 1 Server and Fabric network configuration

實驗評價指標為：1）總時間，表示處理所有交易數據的時間成本；2）交易成功率，表示成功寫入賬本的交易與所有交易數據的比例；3）交易到達率，表示單位時間內成功寫入賬本的交易數據量。

4.2 MCPP 對Fabric 性能的影響

為了驗證數據上鏈預處理機制在沒有并發沖突場景下對整體性能的影響，設定交易數據總量為5 000～20 000，該數據集中所有交易數據的主鍵都不同，即短時間內沒有相同的交易修改同一筆數據，不存在并發沖突。

如圖7 所示，測試兩種方法處理不同交易數量的時延情況，分別為Fabric 中MVCC 方法直接處理交易和使用MCPP 處理交易的時延。實驗結果表明，在沒有并發沖突的情況下，兩種方法隨著交易總數的增加，MCPP 與MVCC 的時延相差不多。盡管MCPP 增加了檢測沖突交易的流程，但沒有沖突交易存在時系統不會增加額外開銷，與Fabric 系統中MVCC 方法處理交易時所需的時間相比效率沒有明顯降低。因此，MCPP 適用于沒有并發沖突的海量交易數據場景。

圖7 不同交易數據總量的時延對比Fig.7 Comparison of delay of total amount of different transaction data

4.3 海量交易數據大規模和常規沖突

為了更好地模擬高并發實例中，在海量交易數據中用戶主題較少的場景，即同一時間段內出現大量的交易數據對相同主鍵進行修改操作的情況。對不同的交易到達率進行實驗，即每秒從客戶端發送的事務總數分別為50、250、500 和1 000，大規模交易數據總量為20 000，涉及的交易主鍵數量K分別為250、500、1 000 和2 000，每個主鍵中交易數據量分布相對均勻。

如圖8 所示，交易中主鍵數量越多，即同一時間段內需要修改的相同主鍵的交易數量越少，兩種方法處理交易的總時間相對越多。由于K越大所產生的沖突交易數量越少，導致同主鍵沖突交易所占用塊內空間減少，為避免觸發MVCC 機制，沖突交易分在不同塊內上鏈，因此當K越大時，MCPP 機制為解決沖突交易數據成功上鏈，耗時相較于Fabric 中的MVCC方法增多。通過分析得出，MCPP 的實際時間與Fabric處理交易數據的時間有關，形式化定義如下：

圖8 不同交易到達率下總時延和交易成功率對比Fig.8 Comparison of total delay and transaction success rate under different transaction arrival rates

其中：Tb為出塊時間；BTx為塊內最大交易數據量；Tm為MCPP 處理交易時延；Tf為Fabric 系統處理交易時延。出塊時間誤差來源于預言機中其他數據處理模塊在處理數據時的額外開銷。

由圖8 可知，隨著交易到達率的增加，不同K值下MCPP 的交易成功率接近100%，但Fabric 的成功率僅為10%。這表明在大規模沖突情況下通過預言機獲取海量交易數據時，無論交易中包含多少主鍵，都可以解決海量沖突數據成功上鏈的問題。由圖8中時延曲線可知，MCPP 雖然犧牲了一些時間，但在可接受范圍內，MVCC 雖然處理了所有交易數據，但將大部分并發交易數據都被標記為無效。因此，在海量交易數據高并發場景下MCPP 性能優于MVCC。

為了更直觀地驗證MCPP 在實際應用中解決常規并發沖突的有效性，實驗模擬了海量交易數據存在常規沖突情況下兩種方法處理交易的時延情況，即海量交易數據中只存在少量沖突交易數據。該實驗大規模交易數據總量為20 000，設計包含不同沖突主鍵數量的數據集，分別為20、50、100 和200，每條主鍵包含的沖突數據量為2，沖突交易分布相對均勻。

如圖9 所示，當處理20 000 條交易數據且存在少量沖突交易數據時，MCPP 處理交易時延與MVCC 平均時延相似。如表2 所示，在MCPP 中沖突交易數據全部上鏈成功，MVCC 則將沖突交易數據標記為無效。這表明MCPP 在處理少量沖突數據時沒有降低系統交易效率，成功率接近100%，而Fabric 通過MVCC 方法對沖突交易數據處理的上鏈成功率幾乎為0%，即將所有同主鍵沖突交易數據標記為無效。由于在實驗過程中沖突交易數據隨機分布，當帶有沖突的交易主鍵數量增加時，處理沖突交易數據所觸發的鎖機制和重排序緩存占用了系統資源，同時網絡時延產生的不穩定性對系統執行交易的總時間產生了影響，使得MCPP 在測試過程中的平均時延略高于MVCC，但MCPP 的執行時間較為穩定，在可接受范圍內。

表2 成功上鏈的交易數據對比Table 2 Comparison of successful up-chain transaction data

圖9 常規沖突時延分析Fig.9 Delay analysis of conventional conflicts

4.4 數據傳輸保障措施安全性分析

在實驗環境下模擬海量數據上鏈操作，測試身份認證和通信密鑰在協同工作時數據的完整性和安全性。數據由誠實設備生成，在所有交易數據有效的前提下，為了保護數據信息的完整性，采用AES和RSA 加密算法對傳輸數據加密保護，經實驗運算后，當惡意節點偽造認證信息攻擊有效信息時，由于無法獲取由預言機管理者生成的私鑰，惡意節點最終無法通過認證。此外，當預言機向聯盟鏈發布交易數據時，通過TLS 技術避免了惡意用戶實施攻擊。

為了進一步評估數據傳輸保障措施在數據傳輸過程中的性能，分別對5 000、10 000、15 000、20 000條的交易數據規模進行實驗，并與未采用權限驗證方法的外部組織進行對比分析。由表3 可以看出，通過實驗評估發現，數據傳輸保障措施能夠有效地保證交易數據在鏈外的處理結果為完整密文，并且數據的一致性和安全性得到保障，同時引入驗證外部組織身份的方法對時延的影響非常小，且在可接受范圍內，不會影響系統整體性能。

表3 權限驗證時延分析Table 3 Delay analysis of permission verification

4.5 對比實驗

為了進一步驗證MCPP 在檢測沖突交易數據時的性能優勢，與LMLS［12］在處理不同規模的交易數據下進行對比實驗，且每個主鍵中包含的沖突交易數量分布相對均勻。由圖10 可以看出，當交易數據規模達到1 000 時，MCPP 運行時間比LMLS 縮短了38%，當數據規模達到10 000 時，MCPP 的運行時間縮短了21.4%，因此MCPP 在處理大規模交易數據存在沖突時的性能顯著優于LMLS。這是因為LMLS需要占用鏈上的Fabric 系統資源檢測和處理沖突交易數據，并在EOV 流程中對沖突交易數據創建副本緩存，同時改變了沖突交易的存儲方式，導致重復上鏈沖突交易的時間開銷增加。相比之下，MCPP 無需修改Fabric 中底層代碼，就能實現對沖突交易的檢測和處理，具有較高的可擴展性和靈活性，且其優勢隨交易數據規模增大更加明顯。此外，MCPP 還增加了對交易數據的保障機制，在保證交易數據安全上鏈的同時，不影響系統整體性能。

圖10 MCPP 與LMLS 運行時間對比Fig.10 Comparison of running time of MCPP and LMLS

5 結束語

本文設計并實現一種基于Fabric 預言機的數據上鏈預處理機制，在不影響相同主鍵串行執行順序的情況下，通過對沖突交易數據檢測、監聽、延時提交、事務加鎖、重排序緩存等方式，在EOV 流程開始前檢測出沖突交易數據，使得多沖突的交易數據完整上鏈，提高了不同機構或組織協同管理交易數據的工作效率。實驗結果表明，在確保交易數據有效的基礎上，MCPP 在處理海量交易數據執行上鏈時，無論上鏈交易數據存在大規模沖突還是常規沖突的現象，數據上鏈預處理機制都可以有效提高沖突交易數據的成功率，且在處理無并發沖突的海量交易數據時保持高效性，同時在傳輸過程中保障交易數據的安全性和完整性。MCPP 通過實驗得到有效驗證后，在中科興疆鏈供應鏈管理系統中進行實際應用，主要運用于工業互聯網、司法協同等數據共享管理業務，在處理復雜事件時同一時間段內推送至鏈上的交易數據接近20 000 條。下一步將對比分析不同的聯盟鏈并結合預言機特點，改進適用于不同聯盟鏈的高性能通用并發處理技術，加強系統擴展性。