HyperledgerFabric并發沖突消除機制

關鍵詞：HyperledgerFabric；交易沖突；映射；有向無環圖；沖突消除 中圖分類號：TP393 文獻標志碼：A 文章編號：1001-3695（2025）07-004-1948-08 doi：10.19734/j.issn.1001-3695.2024.11.0452

Abstract：HyperledgerFabricisa mainstreamconsortium blockchain platform.When facing multipleconcurrent transactions thatareinterrelated，theexistingarchitecturetendstogeneratealargenumberof invalidtransactionswhichsverelyrduces thesystem’sefectivetransactionprocessingcapability.Toaddressthisisse，thispaperproposedaconflicteliminationechnism that integrated map and directed acyclic graph（DAG），known as the FabricIMD（Fabric integrated with map and DAG） mechanism.The mechanism identified dependencies between transactions atthe per node（endorser）through map andconstructed theserelationshipsusingadirectedacyclicgaphtoadjust theendorsementorderoftransactions，therebyefectivelyavoiding transactionconflicts.Experimentsdemonstratethatwhentherearemultipleinterrelatedconcuenttransactions，FabricIMDmechanismcansignificantlyreduceinvalidtransactionscausedbytransactionconflicts.Withvaryingdegresofconflict among transactions，the system’s effective transaction throughput increased by 15.68% to 96.08% . Moreover，when dealing withunrelatedconcurrnttransactions，the introductionofthis mechanismdidnotsignificantlyimpact systemperfor-mance.In summary，FabricIMDmechanismnotonlyavoidstransactionconflictsbutalsoenhancesthesystem’seffectivetransaction throughout and significantly reduces the number of invalid transactions.

Key Words：Hyperledger Fabric；transactionconflict；map；directed acyclic graph（DAG）；conflict elimination

0 引言

區塊鏈起源于比特幣[1]，其實質是集合了對等（peertopeer，P2P）網絡、共識機制和密碼學等技術的分布式數據庫系統。區塊鏈具有去中心化、數據不易竄改和可追溯的優點，能有效建立多方信任以解決數據流通和交易的安全問題，已廣泛應用于智能電網[2]、車聯網[3]、物聯網[4]和邊緣計算[5]等領域。

根據節點是否可以自由加入，區塊鏈分為公有鏈、聯盟鏈和私有鏈。HyperledgerFabric[作為聯盟鏈的代表之一，具有開源、高度模塊化、可定制、可插拔的特點，在數字化業務場景中受到廣泛關注[7]。HyperledgerFabric采用“執行-排序-驗證-提交”的架構，雖然提升了系統交易吞吐量，也帶來了一些問題。這是因為：在模擬執行階段，交易并發且相互隔離，若多筆交易同時讀取和修改數據庫中同一數據將會產生沖突；在驗證階段，由于采用多版本并發控制（MVCC）機制來保證數據庫中數據的一致性，這些沖突的交易大多是無效的[8]，導致大量網絡資源和存儲資源的浪費。目前解決HyperledgerFabric并發沖突的方法主要有兩種：一是在排序階段之前減少交易沖突的產生；二是在排序階段及驗證階段，最小化沖突交易的數量。

在排序階段之前減少交易沖突產生方面，Zhang等人在客戶端處采用緩存策略，對滿足背書條件的交易進行沖突分析。無沖突時，交易直接提交至排序節點；有沖突時，交易被暫存至沖突隊列，待沖突解決后重新執行。然而，該方法并不適用于多客戶端環境中的交易并發沖突。王盛姣等人[10提出一種背書節點緩存策略，用于存儲待驗證交易的寫集。在交易模擬執行時，背書節點通過比對交易背書結果與緩存信息識別沖突。無沖突時，背書結果返回至客戶端；否則，給客戶端返回背書失敗信息。但該方案未考慮客戶端對背書失敗交易的處理機制。若客戶端對失敗交易實施重發，將導致頻繁的客戶端與背書節點間的通信，這可能增加網絡負載并占用關鍵通信資源，對區塊鏈網絡性能構成潛在影響。 Xu 等人[11]在客戶端處引入鎖機制以檢測交易沖突，通過為沖突交易創建臨時數據庫索引，并在驗證通過后與原索引歸并。然而，此方案只適用于單客戶端場景，而且在異步區塊鏈系統中實現節點同步的鎖服務將增加額外的通信成本[10]

在排序階段及驗證階段最小化沖突交易數量方面，Sharma等人[8提出一種基于交易重排序的策略，該策略通過構建區塊內交易依賴關系圖，識別并消除循環依賴，以優化交易排序。然而，此策略僅緩解了區塊內的交易沖突，未能解決跨區塊的沖突問題，且可能引起交易提前終止。 Xu 等人[12]提出了一種節點排序策略，通過交易按鍵分組并結合余額驗證，實現沖突交易的有效合并，以避免驗證失敗。然而，該方法對賬戶余額的依賴可能限制智能合約的靈活性。吳海博等人[13]為解決區塊內交易沖突，提出了一種高效的事務調度機制，通過依賴鏈和危險結構檢測來識別并中止潛在循環依賴的事務。同時，為解決區塊間沖突，建議在排序節點構建緩存區進行交易沖突檢測。但這種方法可能削弱了系統的隱私保護優勢。Gorenflo等人[14]提出了一種\"執行-排序-執行”的交易流程，通過依賴性分析在驗證階段識別沖突交易，并基于最新數據庫狀態重新執行，然后更新賬本。這種機制繞過了MVCC驗證機制，可能影響系統安全性。Nasirifard等人[15]提出了FabricCRDT方法，結合HyperledgerFabric與CRDT。在背書節點驗證時，對CRDT交易跳過MVCC驗證，使用CRDT技術合并提交。但這種方法需要定義特定數據結構，且繞過MVCC機制可能限制其適用性。

可見，現有在排序階段之前減少交易沖突產生的方法通常限于單客戶端環境或缺乏對背書失敗交易的客戶端處理機制，導致適用性不強。而在排序階段及驗證階段最小化沖突交易數量的方法，如在排序節點處采用交易重排序策略，雖然解決了沖突問題，但可能需要對系統架構進行調整，影響隱私性。事實上，原HyperledgerFabric架構中的排序服務通過不參與交易的驗證與執行，實現了共識與交易處理的分離，既增強了共識部分的模塊化，也確保了交易隱私[。因此，迫切需要一種新的沖突消除機制，它應具有廣泛的適用性，同時不改變系統架構。

沖突的本質在于交易之間的相互依賴性，而有向無環圖（directedacyclicgraph，DAG）是表征這種依賴性的有力工具。例如，文獻[16，17]通過考慮每筆交易執行時所需的互斥資源，構建了DAG來確定區塊內交易的執行順序。每筆交易執行后，依賴于此交易的其他交易的人度將減少1。當交易的入度降至0時，表明其依賴的所有前置條件均已滿足，這些交易可以獨立并發執行，從而充分利用多核CPU的計算資源。

受到上述研究的啟發，本文提出一種融合映射與DAG的沖突消除機制FabricIMD，旨在減少系統中因交易沖突導致出現無效交易的同時最大程度保留系統在隱私保護方面的優勢。該機制適宜于采用“執行-排序-驗證\"架構的系統，因為在執行階段便能獲取交易需要讀取或者修改的賬戶信息，用于識別交易間依賴關系。相較之下，在遵循“排序-執行\"架構的平臺上，通常需要增加額外機制，如文獻16]所述由智能合約開發者定義接口的互斥參數，或文獻[17]中提出對智能合約進行標記的方法，以判定交易的依賴性。本文的主要貢獻有：

a）提出一種融合映射與DAG的交易沖突消除機制Fa-bricIMD。該機制通過鍵值對映射的方法追蹤系統中賬戶的變動情況，記錄引起賬戶變動的交易信息，并確定交易間的依賴關系。然后，將所有未完成交易之間的依賴關系構建為DAG，并根據DAG確定交易的背書順序。此機制能夠在保持系統高吞吐量的同時，顯著減少因交易沖突而產生的無效交易數量。

b）搭建實驗測試系統，驗證了在無交易沖突條件下，引入FabricIMD機制對系統性能的影響較小；在存在不同程度交易沖突的情況下，FabricIMD機制能有效提升系統有效交易吞吐量，并減少無效交易。

1HyperledgerFabric交易流程及沖突問題分析

1.1HyperledgerFabric交易流程簡介

在HyperledgerFabric框架中，交易流程由客戶端發起，向背書節點提交交易提案。滿足背書策略要求后，交易被發送至排序節點，該節點負責按時間順序和通道ID對交易進行排序并打包成區塊，隨后分發至所有對等節點。對等節點在此架構中扮演多重角色，包括背書、提交、主節點和錨節點，分別負責交易背書、賬本更新、區塊廣播及跨組織通信。賬本由“世界狀態\"和“區塊鏈\"構成，前者存儲當前賬本狀態，后者記錄所有交易變更。組織由信任的對等節點組成，至少包含一個背書節點，其背書行為體現了組織的交易認可。背書策略明確了交易背書的組織要求，確保了交易的合法性和有效性。

HyperledgerFabric交易流程如圖1所示，包括執行、排序和驗證階段。

a）執行階段：客戶端向組織內的背書節點提交交易提案，提案中包括客戶端簽名、調用的鏈碼及其參數等信息。背書節點根據提案中的參數，調用本地部署的鏈碼與賬本進行交互，模擬執行交易提案，但在此階段不對賬本進行更新。

b）排序階段：排序節點收到客戶端提交的交易后，不驗證交易的有效性，而是根據交易所屬通道和到達時間等因素，對交易進行排序并打包成區塊。排序節點之間就生成的區塊達成共識，隨后將區塊發送至各對等節點。

c）驗證階段：對等節點接收排序節點發送的區塊，依次對區塊內交易進行驗證。首先，執行VSCC（驗證系統鏈碼）以檢查交易是否符合背書策略。接著，利用MVCC機制，驗證交易讀集中的鍵版本號是否與賬本中的世界狀態一致。驗證通過后，對等節點將有效交易的寫集更新至世界狀態數據庫，并最終將區塊記錄到區塊鏈賬本中。

1.2 交易沖突問題分析

在進行沖突問題分析前，先給出兩個基本概念：

a）讀寫集[18：在基于最新賬本狀態的背景下，背書節點通過模擬執行交易提案中的參數，生成交易的讀寫集。讀集囊括了模擬執行中訪問的所有唯一鍵及其對應的已提交版本號。寫集記錄了模擬執行期間對鍵的更新，包括鍵的新值和若被刪除的標志。

b）交易依賴：如果有兩筆交易 T_Xi 和 Tx_j，Tx_i 寫集中的鍵與Tx_j 讀集中的鍵重疊，則交易 T_xi 和交易 Tx_j 之間存在交易依賴。

HyperledgerFabric在執行階段支持節點并發處理來自一個或多個客戶端的交易。然而，在存在交易依賴的情況下，如果多筆交易同時執行，系統中可能出現交易沖突問題，導致在驗證階段大量交易被標記為無效，從而影響系統性能。

產生上述現象的原因在于，當存在依賴關系的兩筆交易T_Xi 和 Tx_j 并發執行，若交易 Tx_i 在交易 Tx_j 之前完成驗證并更新世界狀態數據庫，則交易 T_xj 在驗證階段因讀集中鍵的版本與當前世界狀態中的版本不一致，即交易 Tx_j 與交易 T_xi 產生“讀-寫\"沖突，從而被標記為無效。當這兩筆交易被納入同一區塊或分別進人不同區塊時，將分別觸發區塊內交易沖突和區塊間交易沖突問題。

2 融合映射與DAG的沖突消除機制FabricIMD

2.1 交易流程

FabricIMD機制分為背書和提交兩個階段。引入該機制后，交易流程如圖2所示。

2.2 FabricIMD機制-背書階段

該階段在背書節點部署映射和構建DAG。

2.2.1 部署映射

1）映射背書節點根據交易背書結果讀寫集中的鍵來判斷當前交易與之前的交易是否存在依賴。若只構建DAG，背書節點需要遍歷DAG中所有頂點對應的交易才能判斷依賴性，導致效率很低。通過構建讀寫集映射，無須遍歷DAG中的所有頂點就能判斷當前交易與之前交易的依賴關系，因此需要建立讀寫集映射以提高檢索效率。

此外，在交易背書結果中，還存在讀集和寫集中的鍵不一致的情況。如果僅構建寫集鍵映射而不構建讀集鍵映射，可能會產生沖突。例如，交易 Tx_i 因與之前交易存在依賴關系需等待DAG更新之后再執行。背書節點收到新的交易 Tx_j ，其讀集中的鍵與之前所有待處理交易的寫集中的鍵均不相同，但其寫集中的鍵與交易 T_xi 讀集中的鍵相同。在僅構建寫集鍵映射的情況下，該交易將會被判斷為沒有依賴性，直接進入后續交易流程。但實際上，由于交易 Tx_j 寫集中的鍵與交易 T_xi 讀集中的鍵相同，若這兩筆交易同時執行，將產生沖突。考慮到這個問題，FabricIMD機制中不但建立寫集鍵映射，還需要建立讀集鍵映射。

2）構建映射映射分為讀集鍵映射和寫集鍵映射，使用交易讀寫集中的鍵作為鍵，交易的集合作為值，從而追蹤當前時刻的鍵讀寫操作。背書節點獲取新交易 T_xi 的背書結果后，對讀寫集映射進行如下處理：

a）背書節點首先遍歷背書結果讀集中的鍵。

（a）在讀集鍵映射中獲取該鍵對應的值，即當前讀取該鍵狀態的交易集合 TxSet={Tx_a，Tx_b，Tx_c，…} ;

（b）將交易 Tx_i 加入到該交易集合中，即 TxSet={Tx_a ，Tx_b，Tx_c，…，Tx_i} ，并將其作為該鍵在讀集鍵映射中的值。

b）接下來，背書節點遍歷背書結果寫集中的鍵。

（a）在寫集鍵映射中獲取該鍵對應的值，即當前修改該鍵狀態的交易集合 TxSet₁={Tx_d，Tx_e，Tx_j，…} ：

（b）將交易 T_xi 加入到該集合中，即 TxSet₁={Tx_d，Tx_e ，Tx_j，…，Tx_i} ，并將其作為該鍵在寫集鍵映射中的值。

2.2.2 構建DAG

令每筆交易對應DAG中的每個頂點，背書節點根據交易的依賴關系在DAG中動態添加有向邊，構建并更新圖結構。

如算法1所示流程，背書節點獲取新交易 T_xi 的背書結果后，在DAG中新增與其對應的頂點 V_n ，并將依賴關系檢測碼初始化為0，然后啟動對此筆交易的處理。

a）背書節點首先遍歷背書結果讀集中的鍵。

（a）若寫集鍵映射中該鍵對應的值存在，表明當前交易T_Xi 與映射中交易 Tx_m 存在依賴關系。背書節點定位交易 T_Xm 在DAG中對應的頂點 V_m 。

（b）若頂點 V_m 與新增頂點 V_n 之間不存在有向邊，則在DAG中添加頂點 V_m 指向頂點 V_n 的有向邊，并將依賴關系檢測碼更新為1。

（c）遍歷過程中，背書節點對讀集鍵映射進行更新。

b）接下來，背書節點遍歷背書結果寫集中的鍵：

（a）若讀集鍵映射中該鍵對應的值非空，表明當前交易與之前的交易存在依賴關系。背書節點執行與上述相同的操作。

（b）遍歷過程中，背書節點對寫集鍵映射進行更新。

c）遍歷結束后，如果依賴關系檢測碼為0，該筆交易的背書結果將返回至客戶端，否則等待后續處理。

算法1FabricIMD機制—背書階段

輸人：交易 T_xi 的讀寫集 TxRwSet ；讀集鍵映射RKM;寫集鍵映射WKM;交易間依賴關系 DAG 輸出：讀集鍵映射RKM；寫集鍵映射WKM;交易間依賴關系DAG；依賴關系檢測碼Code。初始化 Code=0，DAG 頂點 V_n for鍵 key_i∈TxRwSet 的讀集doif鍵 key_i 在WKM中對應的值非空dofor交易 T_xm∈ 鍵 key_i 在WKM中對應的值doV_m 為交易 T_xm 在DAG中對應的頂點；if V_m 與 V_n 之間不存在有向邊then在DAG中添加頂點 V_m 指向頂點 V_n 的有向邊；end ifend for（204號 Code=1 ：end if將交易 T_xi 添加到鍵 key_i 在RKM對應的值中；end forfor鍵 key_j∈TxRwSet 的寫集doif鍵keyj在RKM中對應的值非空thenfor交易 T_xa∈ 鍵 key_j 在RKM中對應的值doV_a 為交易 Tx_a 在DAG中對應的頂點；if V_a 與 V_n 之間不存在有向邊then在DAG中添加頂點 V_a 指向頂點 V_n 的有向邊；endifend forCode=1 end if將交易 T_Xi 添加到鍵 key_j 在WKM對應的值中；end forreturnRKM，WKM，DAG，Code;

c）下面將通過舉例和圖形化的方式展示DAG的變化過程。

背書節點先后收到交易1＼～5共5筆交易，每筆交易讀集與寫集中的鍵如表1所示。

DAG構建過程如圖3所示。

（a）交易1為首筆交易，新建其對應的頂點 V₁ 后，該筆交易直接進入后續交易流程。

（b）對于交易2，由于需要基于交易1對鍵 K₂ 和 K₃ 的狀態更新，所以在DAG中添加從頂點 V₁ 指向頂點 V₂ 的有向邊。同理，鑒于交易3依賴于交易1和2，因此在DAG中分別添加頂點 V₁ 和 V₂ 指向頂點 V₃ 的有向邊。

（c）交易4與前面三筆交易不存在交易依賴，因此新建該筆交易對應的頂點 V₄ 后，交易可以直接進入后續交易流程。

（d）交易5分別與交易2和4存在交易依賴，因此在DAG中分別添加頂點 V₂ 和 V₄ 指向頂點 V₅ 的有向邊，同時交易5需要等待后續處理。

2.3 FabricIMD機制一提交階段

背書節點接收到區塊后，首先驗證區塊內交易并更新賬本，隨后對區塊內交易進行遍歷以更新映射和DAG。過程如下：

a）更新映射。背書節點分別遍歷交易讀集和寫集的鍵，并依據鍵在映射中移除該筆交易。

b）更新DAG。背書節點刪除DAG中該筆交易所對應的頂點及其指向其他頂點的有向邊，然后檢查是否新增入度為0的頂點。若有，重新模擬執行該新增頂點所對應的交易并將背書結果返回給客戶端；否則，等待DAG的后續更新。

算法2FabricIMD機制—提交階段

輸人：區塊 B ；讀集鍵映射RKM;寫集鍵映射WKM;交易間依賴關系 DAG 輸出：讀集鍵映射RKM;寫集鍵映射WKM;交易間依賴關系 DAG 。for交易 T_Xi∈B dofor鍵 key_i∈Tx_i 的寫集do將 T_Xi 從鍵 key_i 在WKM對應的值中刪除；end forfor鍵 key_i∈Tx_i 的讀集do將 T_Xi 從鍵 key_j 在RKM對應的值中刪除；endforV_i 為交易 T_xi 在DAG中對應的頂點；for頂點 V_n 為 V_i 的后繼頂點do刪除DAG中頂點 V_i 指向頂點 V_n 的有向邊；if頂點 V_n 的入度為0then模擬執行頂點 V_n 對應的交易 T_xn ，并將背書結果返回給客戶端；end ifend for在DAG中刪除頂點 V_i end forreturnRKM，WKM，DAG;c）圖形化示例DAG更新過程。DAG更新過程如圖4所示。

（a）背書節點在驗證并提交包含交易1和4的區塊后，從DAG中移除頂點 V₁ 和 V₄ 及這兩個頂點指向其他頂點的有向邊。

（b）此時頂點 V₂ 不再有來自其他頂點的有向邊，即入度為0，表明此時交易2與系統中正在執行的交易不存在沖突。因此，交易2可以重新執行。頂點 V₃ 和 V₅ 的入度不為0，所對應的交易3和5需要等待后續處理。

（c）當交易2完成后，在DAG中刪除頂點 V₂ 指向其他頂點的有向邊及該頂點自身，此時頂點 V₃ 和 V₅ 的人度變為0，可以同時執行交易3和5。

2.4FabricIMD機制的復雜度和安全性分析

2.4.1 復雜度分析

設每筆交易讀集和寫集中鍵的數量分別為 n₁ 和 n₂ 。對于任意特定鍵，通過讀寫集映射進行值的查找操作具有 O（1） 的時間復雜度。該值是一個交易集合，反映了當前正在讀取或者修改該鍵狀態的交易，設該交易集合的大小平均為 m 。

在構建讀寫集映射和DAG階段，外層循環首先遍歷 n₁ 個讀集中的鍵，對于每個鍵，內層循環遍歷其在寫集鍵映射中關聯的 ∣m∣ 筆交易，判斷每筆交易對應的頂點是否與當前交易對應的頂點間存在有向邊。若無，則在DAG中添加有向邊；若有，則向下進行。此判斷步驟旨在防止因當前交易讀取的兩個或多個鍵與之前某筆交易需要修改的鍵相同，從而導致在對鍵遍歷的過程中重復添加有向邊的情況出現。內循環中每次進行判斷和添加有向邊操作的時間復雜度為 O（1） 。在整個循環過程中進行判斷操作的次數為 n₁?m_* 每次內層循環結束后將當前交易添加到讀集鍵映射中，所需的時間復雜度為 O（1） 。綜上所述，對每筆交易讀集中鍵的操作所需的時間復雜度為 O（n₁? m ）。對交易寫集中鍵的操作與讀集中類似。因此，在該階段對每筆交易操作的整體時間復雜度為 O（（n₁+n₂）?m） 。

在更新讀寫集映射和DAG階段，外層循環首先遍歷 n₁ 個讀集中的鍵，對于每個鍵，內層循環遍歷其在讀集鍵映射中關聯的 m 筆交易，以移除當前已完成的交易。類似地，遍歷寫集中的鍵，其數量為 n₂ 。對于每個鍵，循環遍歷其在寫集鍵映射中關聯的 m 筆交易，以移除當前已完成的交易。因此，在更新讀寫集映射時所需的時間復雜度為 。接下來，在DAG中遍歷當前交易對應頂點指向其他頂點的有向邊，其數量為 Q ，并逐一刪除這些邊。刪除每條有向邊的操作所需的時間復雜度為 O（1） ，因此總的時間復雜度為 O（Q） 。最后，刪除當前交易對應的頂點，所需的時間復雜度為 O（1） 。綜上所述，在此階段對每筆交易操作的整體時間復雜度為 O（（n₁+ 。

2.4.2安全性分析

在HyperledgerFabric中，背書節點接收到來自客戶端的交易提案后將進行一系列驗證。這些驗證包括交易提案的格式是否正確、通過核對賬本數據檢查交易是否被重復提交過以防范重放攻擊、交易提案簽名是否有效以及客戶端是否有權限執行鏈碼操作[18]。如果驗證通過，背書節點將調用智能合約模擬執行交易提案。本文所提的FabricIMD機制是在模擬執行交易提案步驟后實施，即該交易提案已經被驗證通過。因此，該機制不會對系統的安全性問題造成影響。而且，無論是經過沖突消除機制處理后直接進人后續交易流程的交易，還是等待DAG更新后重新執行的交易，都將和未引人該機制時的系統一樣需要經過排序和驗證階段，從而減少對系統的安全性影響。

3 實驗和分析

為驗證所提出方法的有效性，構建了一個實驗系統。該系統基于HyperledgerFabric的“執行-排序-驗證”架構，由以下主要組件構成：

a）客戶端：用于與系統進行交互。b）排序部分：五個節點組成，負責交易的排序打包過程。c）組織：三個組織，每個組織內各包含一個背書節點，用

于交易背書。d）共識算法：排序節點間采用Raft共識算法。系統部署在服務器上，具體配置如下：a）處理器：Intel@ CoreTMi7-9700 CPU @ ，共8

個核心；b）內存：16GBDDR4RAM;c）操作系統：Ubuntu22.04.2LTS;d）開發環境：使用Go1.21.3Linux/amd64;此外，通過端口映射技術，在單一服務器上模擬多節點運

行環境。鑒于本文主要關注“讀-寫\"交易沖突問題且只讀交易

通常不會被提交至排序服務節點[18]，因此在實驗中設置的交

易均涉及對賬本的讀寫操作。為了量化實驗效果，采用以下指

標作為系統性能評價指標：a）有效交易吞吐量：一段時間內，系統平均每秒提交的有

效交易數量。b）平均有效交易時延：客戶端發起交易到收到交易成功

上鏈信息所需的時間。

c）無效交易數量：一段時間內，系統內產生的無效交易數量。

本章測試了在不同交易沖突程度和背書策略下，引入FabricIMD機制后系統性能的變化。

3.1 無交易沖突

在組織中的節點處初始化生成10000個賬戶。令客戶端在同一時間發送的交易訪問不同的賬戶，因此避免了交易沖突。系統參數配置如表2所示。

如圖5所示，無交易沖突時，引入FabricIMD機制后，系統有效交易吞吐量略有下降。這是因為引人FabricIMD機制后，在背書階段增加了沖突消除的操作，而此時系統中又沒有沖突交易，導致相比于未引入時，系統在相同時間內完成的交易數量減少。盡管如此，當區塊大小從20增加至100時，有效交易吞吐量的降低幅度最高僅為 2.94% 。原因在于本文提出的Fab-ricIMD機制能夠有效地處理交易，同時對系統資源的占用保持在較低水平。如表3所示，FabricIMD機制對每筆交易的處理時間在 6～9μs ，且該機制所占用的內存空間較小且保持穩定。

如圖6所示，引人FabricIMD機制后，有效交易的平均時延未有顯著波動。上述表明，盡管引人FabricIMD機制可能會引入額外的處理開銷，但其對系統整體性能的影響是有限的。

3.2 不同程度交易沖突

3.2.1不同Zipfian分布參數對系統性能的影響

本實驗旨在測試在不同程度交易沖突條件下，引入Fa-bricIMD機制后系統的性能。此外，實驗還將評估無沖突消除機制的兩種情況（無效交易不重發和無效交易重發），以及Fabric ++^[8] 和FabricDT[10]兩種方案的性能，作為對比分析。其中，Fabric ⁺⁺ 為在排序節點處進行交易沖突處理的經典方法，FabricDT與FabricIMD一樣，均在背書節點對交易進行處理。

在表2的系統配置基礎上，本實驗將區塊內最大交易數量固定為20，通過Zipfian分布函數[19選擇交易訪問的賬戶。表4為不同Zipfian分布參數下的交易沖突程度。隨著Zipfian分布參數的增加，交易間出現沖突的概率增加。

如圖7所示，隨著Zipfian分布參數的增加，五種方案下的有效交易吞吐量均呈現下降趨勢。這一現象的根源在于系統處理交易的能力是有限的。在無沖突處理機制時，無效交易的數量隨著交易間沖突概率的增大而增多，導致有效交易占比下降。加人沖突處理機制后，由于需要分配額外的資源來檢測和消除沖突交易，也導致了有效交易吞吐量的下降。盡管如此，在FabricIMD機制下，系統有效交易吞吐量下降最少，隨著Zipfian分布參數從1.01增加到10，吞吐量僅下降了 10.93% ，遠低于無沖突消除機制（無效交易不重發）的 47.46% 和Fa-bricDT的 30% 。當Zipfian分布參數為10時，引入FabricIMD機制后，系統的有效交易吞吐量是無沖突消除機制且無效交易不重發時的1.96倍，是FabricDT的1.44倍。如表5所示，交易在FabricIMD機制部分的處理耗時始終在微秒級別。

如圖8所示，無沖突消除機制（無效交易不重發）、FabricDT和Fabric ++ 方案的平均有效交易時延隨Zipfian分布參數的增加而降低，而FabricIMD機制的平均有效交易時延隨Zipfian分布參數的增加而略微增加。這是因為對比方案在交易流程的驗證階段或之前因交易沖突而提前中止了大量交易，從而加速了有效交易的處理。而引入FabricIMD機制后，由于部分沖突交易的背書順序被調整，需等待其前置交易執行完畢，導致處理時延增加。與無效交易重發相比，當Zipfian分布參數小于4時，引人FabricIMD后的時延與其相當；當Zipfian分布參數大于4時，引入該機制下的額外時延約為 2s （20

盡管如此，引人FabricIMD機制的系統在無效交易產生數量上始終為零，優于其他方案，如圖9所示。這是因為Fabric-IMD機制通過優化交易背書順序，確保交易在無沖突環境下進行背書。這一策略不僅避免了因交易沖突而產生無效交易，還減少了無效交易重發導致的系統交易沖突加劇問題，從而提高了系統的整體效率。

3.2.2區塊大小對系統性能的影響

為評估區塊大小對系統性能的影響，實驗以步長40將區塊內最大交易數量從40增加到200，觀察五種方案下系統各項指標。在測試過程中以Zipfian分布參數為4來選擇交易修改的賬戶，使系統中保持一定的交易沖突。

圖10和11為系統在不同區塊大小下的有效交易吞吐量和無效交易數量。隨著區塊內最大交易數量的增加，系統的有效交易吞吐量上升。然而，區塊大小的增大也加劇了交易間的沖突，從而增加了無效交易的產生，此情形在無沖突消除機制的系統中尤為明顯。

在資源受限的環境下，對區塊內交易采用交易重排序策略的Fabric +θ+θ 方案由于需要更多的計算資源而遭遇了性能瓶頸。與此同時，FabricDT方案通過在背書節點拒絕對更多的沖突交易背書來減少無效交易的產生，展現出良好性能。相比之下，引入FabricIMD機制的系統在背書節點處通過對交易背書順序進行調整，相比于其他方案擁有更好的表現。

實驗結果表明，當區塊大小從40增加到120時，引入Fa-bricIMD機制的系統其有效交易吞吐量是無該機制時的1.48倍，并且相較于FabricDT方案提升了 24%～28% 。然而，當區塊大小超過120時，由于FabricIMD需要更多時間來調整交易背書順序以滿足出塊條件，使有效交易吞吐量有所下降。盡管如此，在區塊大小為160和200時，引入FabricIMD機制的系統的有效交易吞吐量仍然比無沖突消除機制且無效交易不重發時高出 30% 以上。此外，該機制確保系統不產生無效交易，避免了其他方案中因無效交易而需進行的后續處理，從而減少了資源浪費。

3.2.3共識節點數量對系統性能的影響

在本項實驗中將共識節點數量從3個逐步增加到15個，Zipfian分布參數固定為4，以評估共識節點數量對系統性能的影響。隨著共識節點數量從3增加至15，如圖12和13所示，五種方案下系統的有效交易吞吐量均降低，同時平均時延均增加。這是因為隨著共識節點數量的增加，排序節點達成交易共識的時間延長。對于FabricIMD機制來說，共識時間的延長導致背書節點處的映射和DAG更新速度減緩。但是如圖12所示，FabricIMD機制的有效交易吞吐量遠優于對比方案。與無沖突消除機制（無效交易不重發）相比，所提方案有效交易吞吐量提升了 37%～77% ;與FabricDT相比，有效交易吞吐量增加了 16%～50% 。

3.3 不同背書策略

本節實驗旨在評估引人沖入消除機制后，不同背書策略對系統性能的影響。實驗環境擴展至包含三個客戶端和五個組織，Zipfian分布參數固定為2。變量 k 表示需要對交易進行背書的組織數量。如圖14和15所示，引人FabricIMD機制顯著增強了系統在不同背書策略下的有效交易吞吐量，提升幅度為13.08%～36.79% ，并且顯著降低了無效交易產生數量。此外，如圖16所示，由于增加FabricIMD機制對交易的處理，系統的平均有效交易時延略有上升。在背書策略調整過程中，引人FabricIMD機制對系統的有效交易吞吐量和無效交易數量產生了以下影響：

在 k=1 時，有效交易吞吐量相比無沖突消除機制時有所提升，同時也有無效交易產生。這歸因于在此背書策略下，每個背書節點僅收到部分交易信息，限制了FabricIMD機制識別交易依賴的能力，導致部分交易在驗證階段被中止。隨著 k 值的增加，FabricIMD機制對交易間依賴關系識別能力得到增強。例如，當 k=2 時，系統的有效交易吞吐量比 k=1 時提高了5.26% ，無效交易數量減少了 54.5% 。

當 k=3 時，至少有一個組織的背書節點能夠收到所有客戶端發出的交易信息，從而全面識別交易間依賴關系并調整背書順序，避免了交易沖突。然而，由于交易僅需部分組織背書，某些交易可能需要多輪背書。具體而言，當交易提交至三個組織時，兩個組織的背書節點可能因缺少全部交易信息而對該交易進行背書。但第三個組織中的背書節點由于擁有全部交易信息，若識別該筆交易與之前交易存在交易依賴，則調整其背書順序。隨著DAG的更新，第三個組織中的背書節點基于最新賬本狀態對該筆交易重新背書，但可能與前兩個背書節點的背書結果不一致，導致交易需要重新背書。因此， k=3 和 k=4 時，系統有效交易吞吐量出現下降。

當 k=5 時，每個組織中的背書節點都擁有來自客戶端的全部交易信息，避免了部分交易需多次背書的情況。相比 k= 4時，有效交易吞吐量提高了 17.01% 。

4結束語

本文對HyperledgerFabric中交易并發沖突產生的原因進行了分析，并提出一種無須修改現有系統架構的沖突消除機制FabricIMD。該機制在背書節點處引入，通過融合映射與DAG，對交易間依賴關系進行識別，并使用DAG對此關系進行構建，以調整交易背書順序，從而使無依賴關系的交易并發執行，存在依賴的交易等待后續處理。引入此機制顯著提升了系統性能，相比無此機制時，有效交易吞吐量的增幅最高提升至96.08% ，同時顯著降低了無效交易的數量。此外，本文還探討了不同背書策略下該機制的性能表現。分析表明，無論采用何種背書策略，引人該機制均能有效提升有效交易吞吐量，減少無效交易。當背書策略要求超過組織數量的 60% 需對交易進行背書時，引入FabricIMD機制可完全消除因交易沖突導致的無效交易。在后續工作中，筆者計劃針對多樣化的交易場景，進一步驗證FabricIMD機制的優勢和局限性，并進行優化，例如采用圖形數據庫來構建DAG，以此減少對系統內存的占用并保證數據的訪問速度，或者采用動態識別DAG規模的方法，當其達到設定的閾值后對后續識別到依賴關系的交易拒絕背書，待DAG的規模隨著不斷的更新減小后再重新對交易進行FabricIMD機制處理。此外，還將深入分析該機制在不同網絡規模下的有效性和適用性。

參考文獻：

[1]Nakamoto S.Bitcoin：a peer-to-peer electronic cash system[EB/OL]. （2008-10-31）[2024-10-31].https：//bitcoin.org/bitcoin.pdf.

[2]MollahMB，ZhaoJun，NiyatoD，etal.Blockchain for future smart grid：a comprehensive survey[J]. IEEE Internet of Things Journal， 2021，8（1）：18-43.

[3]包俊，張新有，馮力，等.一種基于區塊鏈的車聯網安全認證協議 [J].計算機應用研究，2023，40（10）：2908-2915，2921.（Bao Jun，ZhangXinyou，FengLi，etal.Securityauthenticationprotocol for Internet ofVehiclesbased onblockchain[J].ApplicationResearch ofComputers，2023，40（10） ：2908-2915，2921.）

[4]Li Lang，Huang Dongyan，Zhang Chengyao.An eficient DAG blockchain architecture for IoT[J]. IEEE Internet of Things Journal， 2022，10（2） ：1286-1296.

[5]Fan Wenhao，Hao Zhibo，Tang Bihua，et al. Resource matching for blockchain-assted edge computing networks[J]. IEEE Internet of Things Jourmal，2024，11（8）：14460-14471.

[6]Androulaki E，Barger A，Bortnikov V，et al. Hyperledger Fabric ：a distributed operating system for permissioned blockchains[C]//Proc of the13th EuroSys Conference.New York：ACM Press，2018：1-15.

[7]馬超群，姚錚，盧新國，等.Hyperledger Fabric 分布式賬本技術原 理與應用[M].北京：科學出版社，2022．（MaChaoqun，Yao Zheng，Lu Xinguo，etal.Hyperledger Fabric： principlesandapplications of distributed ledger technology[M]. Beijing： China Science Publishing amp; Media Ltd.，2022.）

[8]Sharma A，Schuhknecht FM，Agrawal D，et al. Bluring the lines between blockchains and database systems：the case of Hyperledger Fabric[C]//Proc of International Conference on Management of Data. New York：ACM Press，2019：105-122.

[9]Zhang Shenbin，Zhou Ence，Pi Bingfeng，et al. A solution for the risk ofnon-deterministic transactionsinHyperledgerFabric[C]//Proc of IEEE International Conference on Blockchain and Cryptocurrency. Piscataway，NJ： IEEE Press，2019：253-261.

[10］王盛姣，董建亮，熊航，等.基于緩存機制的 Hyperledger Fabric 并 發沖突檢測方法[J].信息技術與網絡安全，2022，41（6）：94-101， 108.（Wang Shengjiao，Dong Jianliang，Xiong Hang，etal. Hyperledger Fabric concurrency conflict detection method based on caching mechanism[J].Information Technology and Network Security，2022，41（6） ：94-101，108.）

[11]Xu Lu，Chen Wei，Li Zhixu，et al. Solutions for concurrency conflict problem on Hyperledger Fabric[J].World Wide Web，2021，24 （1）：463-482.

[12] Xu Xiaoqiong，Wang Xiaonan，Li Zonghang，et al. Mitigatingconflicting transactions in Hyperledger Fabric-permissoned blockchain for delay-sensitive IoT applications[J]. IEEE Internet of Things Journal，2021，8（13） ：10596-10607.

[13］吳海博，劉輝，孫毅，等.一種面向聯盟鏈 Hyperledger Fabric 的并 發沖突事務優化方法[J].計算機研究與發展，2024，61（8）：2110- 2126.（Wu Haibo，Liu Hui，Sun Yi，et al.A concurrent conflict transaction optimization method for consortium blockchain Hyperledger Fabric[J].Journal of Computer Research and Development， 2024，61（8）：2110-2126.）

[14]Gorenflo C，Golab L，Keshav S.XOX Fabric：a hybrid approach to blockchain transaction execution[C]//Proc of IEEE International Conference on Blockchain and Cryptocurrency.Piscataway，NJ：IEEE Press，2020：1-9.

[15]Nasirifard P，Mayer R，Jacobsen HA.FabricCRDT：a conflict-free replicated datatypes approach to permissioned blockchains[C]//Proc of the0thInteatioalidlewareConerec.NeYork：Cres， 2019：110-122.

[16]李輝忠，李陳希，李昊軒，等.FISCO BCOS 技術應用實踐[J].信 息通信技術與政策，2020，46（1）：52-60.（Li Huizhong，Li Chenxi，Li Haoxuan，et al.An overview on practice of FISCO BCOS technology and application[J]. Information and Communications Technology and Policy，2020，46（1）：52-60.）

[17]王行行，鄧浩，丘志杰，等.基于沖突檢測的區塊鏈交易執行方法： 中國，CN202210718485.2[P]. 2022-10-11.（Wang Hanghang，Deng Hao，Qiu Zhijie，et al.Blockchain transaction execution method based on conflict detection：China，CN202210718485.2[P].2022-10-11.）

[18]Hyperledger.Hyperledger Fabric documentation[EB/OL].[2024-10- 31]. ttps ：//hyperledger-fabric. readthedocs.io/en/release-2.5.

[19]Go Authors. zipf. go[EB/OL].[2024-10-31]. htps：//github.com/ golang/go/blob/master/src/math/rand/zipf. go？ name release#37 .