開源區塊鏈實驗平臺BlockEmulator使用指南編寫者：黃華威，葉光，殷昭伉黃華威研究組中山大學軟件工程學院Version:2024年12月31日3這本小冊子是BlockEmulator的官方中文版用戶指南，根據當前BlockEm-ulator1.0(December,2024)版本編寫，旨在為BlockEmulator的用戶，尤其是新手，提供一個易上手、足夠詳細的使用指南。該文檔技術部分撰寫的主要貢獻者為HuangLab（中山大學·InPlusLab·黃華威研究組1）的葉光與殷昭伉同學。二位均為在讀碩士生。他們也是BlockEmulator最新版本的主要貢獻者。BlockEmulator開源項目的部分貢獻者可以從官網上2查看，其實這個項目所有的貢獻者包括：林建入老師、葉光、殷昭伉、彭肖文、林岳、詹建洲、張深揚、黃振毅、李燦林、陳欽德、鄭簡、許淼泳、謝葆洲、吳均豪、羅肖飛博士、李濤濤博士、楊青林博士。此外，指導老師包括黃華威與鄭子彬。其中，林建入老師是全棧工程師，也是HuangLab的CTO，他有豐富的工程開發經驗，他同時也是中山大學軟件工程學院的區塊鏈實驗課授課老師。彭肖文、林岳、詹建洲、張深揚、黃振毅、李燦林是HuangLab已經畢業的碩士生，目前均在互聯網大廠工作。他們對BlockEmulator的早期版本做出了重要的貢獻。陳欽德與鄭簡是HuangLab在讀的Ph.D學生，許淼泳與謝葆洲是在讀的碩士生，吳均豪是本科實習生，羅肖飛博士與李濤濤博士是博士后研究員，楊青林是訪問研究員。他們目前正在深入研究BrokerChain分片區塊鏈的最新關鍵技術。他們的研究課題均會使用BlockEmulator當做實驗平臺，來驗證他們提出的最新區塊鏈協議與機制。在此，對以上所有對BlockEmulator做出過獨特貢獻的每一位teammember致以真摯感謝！黃華威2024年12月31日2，BlockEmulator主頁4BlockEmulatorBlockEmulator從入門到放棄HuangLabappreciatesthegreateffortsmadebyeverymember,thecurrentandthegraduated,whohasmadeauniquecontributiontothesuccessofBlockEmulator.51背景介紹11.1BlockEmulator項目簡介 11.2項目開源初衷 21.3BlockEmulator的亮點 31.4官方技術論文 31.5研究組產出的相關論文 31.6BlockEmulator第一年發展歷程.51.7BlockEmulator社區持續發展 82設計原理102.1設計思路 2.2架構與組件 2.3內置共識機制 3BlockEmulator技術論文483.1技術論文撰寫背景 483.2技術論文簡介 493.3技術論文的引用情況 4開始使用它做實驗574.1啟動方式 4.2事前準備 4.3啟動BlockEmulator 604.4運行結束后的數據收集 674.5手動編譯源碼運行BlockEmulator715BlockEmulator的其他分支735.1Fine-tune-lock分支 5.2tMPT分支 6可能會遇到的技術問題856.1用戶二次開發中遇到的Bug及解決方案 856.2PBFT共識間隔參數的異常設置866.3CLPACommitteeModule出現死循環926.4AddAccount函數拋出空指針異常977歷史版本更新1048BlockEmulator用戶社區維護1138.1微信群社區的問題解答 8.2GitHub項目Issues頁面的問答.1178.3用戶社區其他常見的問題匯總 9未來規劃1339.1BlockEmulator2.0版本 9.2BlockEmulatorDAO社區 11.1BlockEmulator項目簡介BlockEmulator是由中山大學·黃華威研究組（HuangLab1）開源的可支持多種共識協議的區塊鏈實驗平臺，可用于對用戶開發的自定義區塊鏈協議、算法與機制進行性能評估，其特色是支持區塊鏈跨分片機制。此實驗平臺開源的主要目的是為了幫助用戶（研究者、學生）快速驗證他們提出的新型區塊鏈共識協議、算法、機制、數據結構等等其他設計。BlockEmulator被設計為輕量化區塊鏈系統架構的實驗平臺。它簡化了工業級區塊鏈系統的實現流程，這是因為BlockEmulator只關注實現區塊鏈的核心功能，比如交易池、區塊打包、區塊共識、交易上鏈等核心環節，忽略了那些與區塊鏈體系架構不相關的細節。BlockEmulator支持常見的主流共識協議，例如拜占庭容錯協議PBFT (PracticalByzantineFaultTolerance)。特別地，BlockEmulator對主流的“區塊鏈分片機制”進行了系統底層級別的設計與實現。其中，BlockEmu- lator實現的“跨分片交易”處理機制包含以下兩個具有代表性的分片協議：Monoxide(NSDI,2019)中提出的“Relay交易機制”[14]，以及BrokerChain(INFOCOM,2022)中的“broker機制”[6]。1.2項目開源初衷DemandsBlockEmulatorDemandsNewconsensusNewconsensusConfigurationsNewalgorithmsConfigurationsNewprotocolsNewprotocolsstructuresoperationsObserved……圖1.1:ThedesignprincipleofBlockEmulator.如圖1.1所示，該實驗平臺主要面向區塊鏈研究人員，當他們需要對提出的新型區塊鏈共識、新算法、新機制進行驗證時，可以幫助他們快速搭建一個輕量化的區塊鏈底層協議驗證與性能測試平臺，并對實驗數據進行自動記錄，方便實驗人員繪制實驗圖。圖1.2:ThesloganofBlockEmulator.關于開源初衷，我們已經寫到了BlockEmulator的官網主頁，即“Mak-ingBlockchainExperimentsEasy（讓區塊鏈研究更簡單）”,如圖1.2所示。背景介紹31.3BlockEmulator的亮點1.輕量化：BlockEmulator是一個輕量化的區塊鏈實驗平臺。2.快速搭建：方便用戶進行快速搭建區塊鏈實驗平臺，并且支持遠程部署到云端運行。3.可定制化：BlockEmulator是基于Golang語言實現的區塊鏈實驗平臺，支持用戶定制化二次開發。4.易于實驗：BlockEmulator支持主流區塊鏈（如以太坊）的歷史交易數據的回放，可以自動輸出、保存各項區塊鏈實驗指標（如系統吞吐量、交易確認時延、交易池擁塞程度等等）以及系統運行的日志。這些功能非常便于科研人員與學生進行實驗數據的收集以及實驗圖的繪制。1.4官方技術論文為了提供一個嚴謹的官方技術文檔，我們從2023年開始撰寫了一篇技術論文，題目為“BlockEmulator:AnEmulatorEnablingtoTestBlockchainShardingProtocols”[7]，已經上傳到了預印本網站arXiv。請前往chapter3.1查看該技術文檔的詳細介紹。1.5研究組產出的相關論文從2021年開始，HuangLab使用自己開發的BlockEmulator各個時期的版本陸續產出了一些區塊鏈論文。隨著這些論文陸續發表，BlockEm-ulator的各項功能也逐漸完善。如下幾篇論文均使用了BlockEmulator作為實驗平臺。歡迎感興趣的同行查閱了解。?BrokerChain:ACross-ShardBlockchainProtocolforAccount/Balance-basedStateSharding[6](INFOCOM2022)【PDF1】【公眾號文章2】?Broker2Earn:TowardsMaximizingBrokerRevenueandSystemLiquidityforShardedBlockchains[1](INFOCOM2024)【PDF3】【公眾號文章4】?AccountMigrationacrossBlockchainShardsusingFine-tunedLockMechanism[4](INFOCOM2024)【PDF5】【公眾號文章6】【知乎文章7】?Justitia:AnIncentiveMechanismtowardstheFairnessofCross-shardTransac-tions[9](INFOCOM2025)【PDF8】【公眾號文章9】?SchedulingMostValuableCommitteesfortheShardedBlockchain[5](ToN2023)【PDF10】【公眾號文章】11?MVCom:SchedulingMostValuableCommitteesfortheLarge-ScaleShardedBlockchain[3](ICDCS2021)【PDF12】【公眾號文章13】?AchievingScalabilityandLoadBalanceacrossBlockchainShardsforStateShard-塊鏈跨分片協議—BrokerChain》7/p/670072518，《HuangLab兩篇區塊鏈論文被INFO-COM’24接收》8/archives/1371，《兩篇區塊鏈論文被頂會INFOCOM2025接收(附論文下載)》背景介紹5ing[11](SRDS2022)【PDF1】【公眾號文章2】?tMPT:ReconfigurationacrossBlockchainShardsviaTrimmedMerklePatriciaTrie[8](IWQoS2023)【PDF3】【公眾號文章4】1.6BlockEmulator第一年發展歷程（本文來源自黃華威老師在知乎上的專欄文章5。）2024年5月26日中午在BlockEmulator用戶群，有位來自北京理工大學的張同學問到了BrokerChain論文（“BrokerChain:ACross-ShardBlockchainProtocolforAccount/Balance-basedStateSharding”[6]）的系統原型實現代碼的細節，而且提到如何基于BlockEmulator6的早期版本做二次開發。隨后，BlockEmulator后期成熟版本的貢獻者之一殷昭伉同學回復了張同學的問題。不過，我發現昭伉還有BlockEmulator社區用戶普遍對BrokerChain[INFOCOM2022]與BlockEmulator的關系，以及BlockEmulator的誕生背景、歷史發展過程不太了解。趁此良機，我寫了這篇小作文，希望可以幫助BlockEmulator社區用戶還有讀者朋友們了解這個實驗工具的誕生背景與第一年發展歷程。5/p/699908738，《BlockEmulator誕生背景與第一年的發展歷程》，作者：區塊鏈黃博士6塊鏈仿真測試平臺》1.6.1BlockEmulator的誕生背景BrokerChain與BlockEmulator的關系BrokerChain是我們HuangLab在2021年設計并實現的分片區塊鏈(分片區塊鏈系統框架+獨特的Broker中間商機制)，論文正式發表在INFOCOM2022。BrokerChain論文中提到的實驗框架其實是BlockEmulator1的最早版本，是論文二作彭肖文同學2021年（當時他處于研一暑假期間）使用了 python和java寫的，比較簡陋，甚至某些非關鍵環節（比如PBFT協議的消息廣播過程）使用了simulation代碼來模擬。后來論文在2022年發表之后，黃華威老師帶領team把這個實驗框架逐步擴展并完善每一個重要模塊，開發語言換成了Go語言，后來就逐漸形成了BlockEmulator2。在2022年2023年逐步完善BlockEmulator的過程中，它的每個中間版本都分別用來支撐了HuangLab每一篇陸續發表出來的blockchain論文（論文列表請前往chapter1.5查看）。BlockEmulator項目開源隨著這些論文陸續發表，很多同學紛紛通過郵件向黃老師索要各個論文背后的代碼，于是黃華威老師帶領team在2023年5月11日正式開源了BlockEmulator，里邊嵌入了大部分研究組發表出來的論文的算法代碼。可以這樣理解：BlockEmulator是一個籃子，里邊陸續裝填了HuangLab若干區塊鏈論文中提出的機制與算法。2https://zhuanlan.zhihu.co塊鏈仿真測試平臺》背景介紹7黃老師開源BlockEmulator的愿景是希望它可以為在區塊鏈方向從事科研的同學提供一個方便做實驗的平臺，同時也希望大家一起把blockchainsharding這個小眾方向給帶起來。1.6.2BlockEmulator的發展演化開源的同時，HuangLab也陸續收到來自社區用戶的反饋，這對Block-Emulator也是一個接受檢驗與提高的過程。事實也的確如此，不少同學在各個平臺分別反饋了他們在使用過程中遇到的問題，比如在B站的block-Emulator視頻教程頁面1，在Github的issues頁面2紛紛留言。每一個技術問題黃老師都轉發給負責BlockEmulator代碼維護的同學，比如葉光、殷昭伉、陳欽德，有時也會讓林建入老師來回復。他們也各自做出了及時的反饋并提供了非常棒的解決方案。圖1.3:TheEng.versionhomepageofBlockEmulator.比起剛開源時，現在BlockEmulator更加穩定，而且各種使用文檔、初時，黃老師帶領team把官網從中文版改為了現在的英文版，如圖1.31/video/BV1go4y177JY,“BlockEmulator視頻教程”1.7BlockEmulator社區持續發展根據2024年12月的統計數據顯示（如圖1.4所示BlockEmulator官網已得到來自超過70個國家與地區用戶的訪問。圖1.4:ThevisitordataofblockEmulatorhomepage.Github項目頁面顯示（如圖1.5所示BlockEmulator項目已經獲背景介紹9得了250個星，65個forks.圖1.5:TheGithubprojectpageofblockEmulator.雖然BlockEmulator還未獲得世界范圍內的廣泛關注，但是HuangLab成員仍然為它能幫助一些同行而感到高興。之后，如果同學們在使用BlockEmulator的過程中遇到任何問題，可以先去Github的issues頁面（HuangLab-SYSU/block-emulator/issues）看一下你遇到的問題是否已經被前人問過了。如果沒有的話，歡迎在issues頁面或者在BlockEmulator用戶群里提出來，負責BlockEmulator維護的同學會第一時間給大家解答。感謝大家的關注，如果你認為BlockEmulator是個有用的實驗工具，歡迎轉告給其他正在區塊鏈方向默默耕耘的同學與朋友。順便，加入Block-Emulator社群的方法在官網的底部，感興趣的同學請自行探索。第二章設計原理2.1設計思路2.1.1BlockEmulator的定位是什么？BlockEmulator設計定位是一個可支持多種共識協議的區塊鏈實驗平臺，以支持區塊鏈跨分片機制為特色。該實驗平臺主要面向區塊鏈研究人員，當他們需要對提出的新型區塊鏈共識協議、新型跨分片機制進行驗證時，可以幫助他們快速搭建一個輕量化的區塊鏈底層協議的實驗平臺，并對實驗數據進行收集，方便繪制科研論文所需的實驗圖。BlockEmulator需要實現區塊鏈的各項底層模塊，它不僅可以幫助初學者快速入門理解區塊鏈底層原理，也能為有經驗的區塊鏈研究者提供一個便捷的區塊鏈新協議/算法/機制的開發測試環境。為此，它需要降低開發和測試的成本和難度，為開發人員和研究人員提供可定制化的二次開發環境，從而可促進區塊鏈技術的創新。2.1.2BlockEmulator能用來做什么？BlockEmulator的設計目標是為了幫助用戶（研究者、學生）快速實現并測試他們提出的新型區塊鏈共識協議和區塊鏈跨分片機制。它遵循了輕量化區塊鏈系統架構的設計理念，簡化了區塊鏈系統實驗環境的搭建流設計原理11程。這是因為BlockEmulator僅僅關注實現區塊鏈的核心功能，比如交易池、區塊打包、區塊共識、交易上鏈等核心環節，并且支持常見的幾種主流共識協議，如拜占庭容錯(PracticalByzantineFaultTolerance,PBFT)協議與工作量證明機制。特別地，BlockEmulator對主流的“區塊鏈分片機制”進行了系統底層級別的設計與實現。其中，“跨分片交易”機制包含以下兩個具有代表性的分片協議：Monoxide[14](NSDI,2019)方案中提出的“Relay交易機制”，以及BrokerChain[6](INFOCOM,2022)中的“broker機制”。因此，BlockEmulator可以支持用戶快速開發定制化版本的區塊鏈新機制/協議/算法，尤其支持對區塊鏈新型分片機制與協議的功能測試。2.1.3BlockEmulator有什么特點？?支持定制化二次開發：BlockEmulator采用Go語言實現，能夠定制化二次開發，滿足不同需求。?快速搭建：不僅可以在本地進行實驗，還可以遠程部署到云端運行。?易于實驗：BlockEmulator支持主流區塊鏈（如以太坊）歷史交易數據回放，可以自動輸出、保存區塊鏈實驗指標，如系統吞吐量、交易確認時延、交易池擁塞程度等等。?容易上手：無需復雜設置，用戶就能快速上手做實驗并收集數據繪制2.2架構與組件2.2.1系統架構設計BlockEmulator采用分層的方法進行設計，每一層都負責獨立的工作，并且盡可能的讓每一層都只與其鄰近層發生交互，實現系統層面的功能結構，幫助用戶快速熟悉系統并進行代碼復用和改造。GenerationTransactionInjectionExperimentalGenerationTransactionInjectionExperimentalResultsIntra-shardConsensusInter-shardIntra-shardConsensusPoWProtocolPBFTPoWProtocolPBFTProtocolMechanismMechanismBandwidthControlNodeCommunicationDataExchangeBandwidthControlNodeCommunicationDataExchangeStateTrieBlockchainCodecDataLayerAccountTransactionStateTrieBlockchainCodecBoltDBLevelDBBoltDBLevelDB圖2.1:BlockEmulator的分層系統架構設計。如圖2.1所示，BlockEmulator的整個架構可以劃分為具體的五個層。按照層次接近真實數據（交易數據）的遠近可以劃分為，存儲層、數據層、網絡層、共識層和控制層。各個層介紹如下。1.存儲層：存儲層將賬本數據存儲在磁盤上，包括生成的區塊鏈數據、進行實驗時生成的日志文件等。例如，共識節點保存已確認的區塊、交易、賬戶狀態和系統日志。存儲層的功能基于boltDB和levelDB設計原理13實現。特別地，我們在levelDB上采用了MerklePatricia樹（MPT以提供驗證功能。這一層的代碼有兩部分。一部分代碼位于./storage文件夾中。另一部分我們采用了以太坊的源碼。2.數據層：數據層在系統中建立了數據的基本結構，包括賬戶、交易、區塊、狀態樹和節點。數據層與存儲層進行交互。在運行BlockEm-ulator時，新生成的區塊會通過數據層不斷生成和編碼。這些新生成的區塊觸發狀態樹的修改，狀態樹中新生成的樹節點會被本地編碼保存。此外，當實驗完成后，可以通過存儲層查詢存儲在文件中的區塊數據。查詢到的區塊數據隨后可以通過數據層解碼還原為區塊。這樣，研究人員可以訪問生成的區塊和賬戶狀態樹。因此，用戶如果對BlockEmulator生成的交易執行結果的正確性有疑問，可以離線檢查賬戶狀態。3.網絡層：網絡層旨在支持部署在不同設備上的共識節點之間的通信。我們通過TCP實現了端到端的數據包傳輸機制，旨在節點之間交換數據。交換的數據包括交易、區塊、共識消息等。我們將TCP實現為長連接（Keep-Aliveconnection）的方式，以便在網絡中促進大量消息的交換。在這種方式下，兩個節點之間的TCP連接僅在整個實驗過程中初始化和關閉一次。另外，我們為每一個消息設計了傳輸頭，以便于節點在接收到TCP報文后能快速識別出是這個報文對應的是哪一類消息。確定了消息類型后，即可觸發對應的消息處理函數處理該消息。4.共識層：共識層負責使共識節點針對新區塊達成一致。在分片區塊鏈中，節點同時運行著分片內和跨分片的共識機制。分片內的共識機制（如PoW和PBFT）確保一個分片內的區塊達成共識。跨分片機制則保證不同分片之間的通信。例如，為了處理一筆跨分片交易，位于付款方和收款方分片的共識節點需要接收來自其他分片的消息。5.控制層：控制層負責系統的執行。在實驗開始之前，該層需要為實驗環境配置做準備。實驗環境的準備包括初始化指標測試線程、監聽消息、確定每個共識節點的IP地址等。當BlockEmulator運行時，控制層的supervisor節點將按照預定速率將交易注入到分片的交易池中。注入到BlockEmulator中的交易可以是來自任何區塊鏈的歷史交易，如以太坊。當BlockEmulator完成實驗后，用戶可以從日志中收集實驗結果進行分析。2.2.2BlockEmulator的系統角色BlockEmulator的共識體系主要包括兩類角色的節點，分別是worker節點和supervisor節點，如圖2.2所示，分別介紹如下。Worker節點Worker節點即負責打包交易、共識區塊和維護賬本數據的節點。這些節點通過共識機制，保證了區塊鏈的活性和安全性。在BlockEmulator中，這類節點都是“全節點”。設計原理15②Transactionpoolsofleadern②③…ObserverSupervisor⑤Worker…ObserverSupervisor⑤③Worker⑥①⑥Shard2Shard2(SimilartoShard1)⑤(e.g.,consensus,…network,etc.)…④Customized④Customizedprotocols①Initialize①Blockchains圖2.2:BlockEmulator的主要角色，與內部工作流程。Supervisor節點為了便于統計實驗數據、簡化開發代碼邏輯，我們在BlockEmulator中引入了supervisor節點。它融合了多個系統角色，具有以下功能：?交易發送者。Supervisor節點可以充當交易發送者，負責將交易不斷地發送到區塊鏈網絡中。?實驗數據觀測員。Supervisor節點可以充當區塊鏈網絡中的觀察者，可持續不斷地監聽區塊鏈數據，通過計算來統計區塊鏈的各項性能?共識協議中的committee。有些共識協議（如CLPA[11]）需要利用committee來計算分片區塊鏈重配置的結果，這時，supervisor可擔任這個稍微帶有中心化色彩的角色。?Broker角色。在BrokerChain協議[6]中，一筆跨分片交易會被某個broker賬戶拆分為兩筆耦合的子交易。Supervisor也可以擔任broker的角色，這樣可以減輕實驗代碼的開發量。2.2.3內部運行流程概述接下來，我們從系統內部運行的視角介紹當系統啟動后，supervisor與worker節點將會如何協作。請注意，這部分內容并不是介紹用戶如何啟動BlockEmulator，而是以區塊鏈系統底層的視角介紹BlockEmulator內部不同角色的節點是如何運作的。啟動BlockEmulator的方法請跳轉chapter4.1查看。如圖2.2所示，BlockEmulator內部的工作流程主要包括如下幾個步驟：?Step1:在啟動之前，用戶進行系統配置（包括共識、網絡等）。?Step2:Supervisor節點向worker分片的交易池中注入交易。?Step3:Worker分片的節點從交易池中讀取交易。?Step4:Worker分片根據用戶自定義開發的協議進行共識。?Step5:Worker節點們將共識完成后的區塊上鏈，并且更新狀態樹，將數據保存到本地。?Step6:Supervisor節點觀察區塊鏈網絡、并且收集區塊，根據區塊信息測量區塊鏈的各項性能指標。設計原理172.2.4支持測量的實驗指標Supervisor節點可測量的指標BlockEmulator中的大部分指標由supervisor節點來測量。因此，如果要在BlockEmulator中測量指標，需要在創建supervisor時，指定su-pervisor測量的指標名稱。通過選擇mearsureModName的:1methodID:=params.ConsensusMethod2varmeasureMod[]string4measureMod=params.MeasureBrokerMod6measureMod=params.MeasureRelayMod7}8measureMod=append(measureMod,"Tx_Details")910spv:=new(supervisor.Supervisor)11spv.NewSupervisor(supervisor_ip,chainConfig,committeeMethod,mearsureModNames...)目前開源的代碼中，包含了以下9個可測量的實驗指標。指標類型說明即每筆交易的詳細數據，適用于以下兩種跨分片交易處理模式。Tx__Details給出了每一筆交易的各種時間，用戶可以利用它統計各種細化的指標。Relay跨分片交易處理模式即每秒處理的交易量（transactionspersecond,TPS）。它是區塊鏈系統每秒處理交易的平均數目。該指標針對交易中繼（relay）機制，一筆跨分片需要上鏈兩次才算處理完成，所以每次上鏈的權重僅有1/2；一筆片內交易僅需一次上鏈便能處理完成，所以每次上鏈權重為1。即交易確認時延（transactionconfirmlatency,TCL）。某一筆交易的TCL是指該交易從進入交易池到最終確認上鏈所耗費的時間，而本指標測試的是一批交易的平均TCL。該指標針對交易中繼（re-以它的TCL包含了這兩次上鏈的排隊和共識時間。設計原理19指標類型說明即跨分片交易占比（Cross-shardtransactionratio）。它指的是跨分片交易占所有交易的比例。該指標針對交易中繼（relay）機制，一筆跨分片需要上鏈兩次，但是在統計跨分片交易占比時，每次上鏈的權重僅為1/2。即交易總數（Numberoftransactions）。它指的是區塊鏈在某一段時間內處理了多少交易。該指標可以用來檢驗區塊鏈是否正確處理了所有注入的交易。入交易總數”。Brokeraccount跨分片交易處理模式即每秒處理的交易量（transactionspersecond,TPS）。它是區塊鏈系統每秒處理交易的平均數目。該指標針對中間人賬戶（brokeraccount）機制，一筆跨分片需要被拆為兩筆broker交易，兩筆broker交易需要都上鏈才算處理完成，所以每次上鏈的權重僅有1/2；一筆片內交易僅需一次上鏈便能處理完成，所以每次上鏈權重為1。指標類型說明即交易確認時延（transactionconfirmlatency,TCL）。某一筆交易的TCL是指該交易從進入交易池到最終確認上鏈所耗費的時間，而本指標測試的是一批交易的平均TCL。該指標針對中間人賬戶（brokeraccount）機制，由于一筆跨分片需要被中間人賬戶拆分為兩筆，所以它的TCL包含了拆分操作的耗時、兩筆交易的排隊時間和兩筆交易的共識時間。即跨分片交易占比（Cross-shardtransactionratio）。它指的是跨分片交易占所有交易的比例。該指標針對中間人賬戶（brokeraccount）機制，統計時，一筆交易的權重取決于它需要上鏈的次數。即交易總數（Numberoftransactions）。它指的是區塊鏈在某一段時間內處理了多少交易。該指標可以用來檢驗區塊鏈是否正確處理了所有注入的交易。入交易總數”。Tips：?如果用戶想要新增自定義指標，可以在./super設計原理21量是如何生效的。Worker節點可測量的指標僅僅從supervisor這樣一個區塊鏈“觀察者”的視角，BlockEmulator無法對區塊鏈的全部性能指標進行統計與觀測。因此，worker節點被設計為也需要負責統計一些指標。具體來講，Worker節點會在出塊的時候進行統計某些指標，包括：指標類型說明當前區塊的高度出塊時，區塊鏈處于哪一個epoch出塊時，當前分片的交易池大小該區塊內的交易數目該區塊內的{Broker1,Relay1}交易的數目該區塊內的{Broker2,Relay2}交易的數目指標類型說明該區塊提出（即共識開始）的時間戳該區塊確認（即共識完畢）的時間戳所有交易的TCL之和所有{Broker1,Relay1}交易的TCL之和所有{Broker2,Relay2}交易的TCL之和Tip：設計原理232.2.5輸出的日志和實驗結果各個節點的日志查看下的文件組織如下：1/log2345678_Worker節點和supervisor節點的log格式均是以下格式：1（Worker節點）2S0N0:2024/12/0920:10:40messageHandle.go:141:S0N0:hasbroadcastthepreparemessage3（Supervisor節點）4Supervisor:2024/12/0920:10:42committee_clpa_broker.go:258:上述輸出，每一行的內容從左到右分別是：節點的名稱（包括分片序號和節點序號），打印日志的時間，觸發打印的代碼位置，打印的信息。Supervisor節點輸出的實驗指標默認情況下，Supervisor節點輸出的文件組織如下：1/supervisor_measureOutput23|––CrossTransaction_ratio.csv4|––Transaction_Confirm_Latency.csv56\各個文件包含了一個測試指標的細節，csv文件中的每一列數據均有對應的列名解釋。Worker節點輸出的實驗指標1/pbft_shardNum=42345csv。比如，Shard04.csv表示分片數目為4的區塊鏈系統中，序號為0設計原理25的分片所對應的結果。各個文件包含了每個分片leader節點輸出的指標，csv文件中的每一列數據均有對應的列名解釋。2.2.6可配置的系統參數經過若干次的迭代，BlockEmulator的系統參數配置功能被整理到了實驗參數配置實驗結果輸出路徑、帶寬控制等功能的參數。以下是這些參數的解釋：參數名參數描述共識節點采用的共識機制。0~3分別表示{“CLPA__Broker”,“CLPA”,“Broker”,“Relay”}。tPBFT共識中，如果一輪共識時間超過了change。實驗結果的數據輸出路徑。參數名參數描述交易大小是否采用“字節數為單位”。交易注入網絡中的速度。被注入的交易總數。每次發送的交易數目（較大時可以減少Brokerchain機制中，broker賬戶的數目。使用Relay機制時，是否采用MerkleProof驗證交易。數據集文件路徑。兩次reconfiguration階段的時間間隔。每隔ReconfigTimeGap秒，觸發一次重配網絡擾動（毫秒），以均勻分布進行波動。限制的帶寬大小。設計原理27IP地址配置./ipTable.json文件中包含了各個共識節點的IP地址。在用戶的實驗環境，請按需更改這些節點的IP地址。1{3"0"4"1"5},6"1"8"1"9},10"2147483647":{12}13}其中，json文件的第一級索引表示分片序號，第二級表示節點序號。按照上面代碼的邏輯，可知第0號分片的第0號節點的IP地址加端口為：特別地，第2147483647號分片的第0號節點（IP地址加端口為1272.3內置共識機制BlockEmulator內置了PBFT協議當做分片內使用的共識機制，此外還有3種原生的“跨分片共識協議”或機制，即交易中繼（transactionrelaying）機制[14]，BrokerChain協議的“做市商”交易機制[6]，與CLPA賬戶重劃分算法[11]。2.3.1跨分片交易中繼機制（TransactionRelaying）交易中繼（TransactionRelaying）機制的背景?交易中繼機制來源于Monoxide[14]，其采用消息傳遞的方式，由分片間消息傳遞進行跨分片交易的處理。?一筆跨分片交易需要被“源分片（sourceshard）”和“目標分片（des-tinationshard）”分別進行“上鏈”操作：i）源分片對該交易的發送方賬戶狀態進行更新；ii）目標分片對該交易接收方的賬戶狀態進行交易中繼機制工作流程的簡要描述1.Supervisor節點將每一筆交易發送到該交易發送者賬戶所在的分片。2.Worker節點生成區塊。如果區塊中的某一筆交易被判定為跨分片交易，則在這一步，該交易的“源分片”中的worker節點僅需要更新該跨分片交易發送者的賬戶狀態。3.當該跨分片交易上鏈之后，work節點將當前跨分片交易以消息的形式發送到交易接收者所在的分片（即“目標分片”）。4.該交易的目標分片內的worker節點收到該跨分片交易之后，會將該跨分片交易發送到交易池，等待打包上鏈。5.目標分片的某個worker節點將交易打包至區塊，這一步僅需要更新該跨分片交易接收者的賬戶狀態。設計原理296.至此，該跨分片交易第二次上鏈，則該交易的執行周期結束。交易中繼機制的代碼實現e.go兩個文件中，以下是代碼運行邏輯的大致介紹。1.節點交易池維護RelayPoo添加到指定分片的中繼池（RelayPool）中。2.當區塊鏈經過共識，準備將一個區塊上鏈之前，worker節點會檢測區塊中是否存在跨分片交易（節點會判斷交易的發起者與接收者是否屬于同一個分片：如果不是，那么這筆交易就是一筆跨分片交易）。如果一筆交易是跨分片交易且沒有被中繼處理（relaying）過，那么worker節點僅更新交易發起者的賬戶狀態。在這之后，節點會調用3.節點遍歷并處理區塊內所有交易后，將每個RelayPool中的跨分片交易分別打包為message.Relay消息，并分別發送到對應分片的節點中（PBFT中為leader節點）。1//代碼位于./consensus_shard/pbft_all/toolFuncs.go文件中。2(p*PbftConsensusNode)RelayMsgSend(){5fop.pbftChainConfig.ShardNums;sid++{7continue8}9relay:=message.Relay{10Txs:p.CurChain.Txpool.RelayPool[sid],11SenderShardID:p.ShardID,12SenderSeq:p.sequ13}14rByte,err:=json.Marsha1617}18msg_send:=message.MergeMessage(message.CRelay,rByte)19gonetworks.TcpDial(msg_send,p.ip_nodeTable[sid][0])20p.pl.Plog.Printf("S%dN%d:sendedrelaytxsto21}22p.CurChain.Txpool.ClearRelayPool()23}4.對應分片的worker節點收到message.Relay消息后，他們會將交易從消息中解析出來，然后將這些交易添加到當前節點的交易池中。1//代碼位于./consensus_shard/pbft_all/pbftOutside_module.go文件中。24func(rrom*RawRelayOutsideModule)handleRelay(content5relay6err:=json.Unmarshal(content,relay)8log.Panic(err)9}10pbftNode.ShardID11rrom.pbftNode.CurChain.Txpool.AddTxs2Pool(relay.Txs)12rrom.pbftNode.seqMapLock.Lock()13rrom.pbftNode.seqIDMap[relay.SenderShardID]=14rrom.pbftNode.seqMapLock.Unlock()15}5.同2，節點完成交易的打包、共識和上鏈。因為一筆已經被中繼處理過的跨分片交易不會再被放到RelayPool中，所以此時只需要更新交易接收者的賬戶狀態，便可以完成該跨分片交易的處理。2.3.2“做市商”跨分片機制（BrokerChainProtocol）Broker機制的背景BrokerChain協議提出的“做市商”跨分片交易處理機制，來自發表在INFOCOM2022的論文BrokerChain:ACross-ShardBlockchainProtocol設計原理31forAccount/Balance-basedStateSharding[6]。該論文針對分片區塊鏈系統中廣泛存在大量跨分片交易的現象提出了BrokerChain跨分片交易共識機制。按照該機制的設計，系統中存在某些特殊的broker賬戶（即“做市商賬戶”）。它們中的任意一個的賬戶狀態可以被分割為多份，并且每一份僅分布于一個分片之中。相當于每一個broker賬戶在多個分片中開設了“子賬戶”。Broker機制的原理ModifiedShardStateTreeofShardValues545Values545Shard#1ROOT:ExtensionNodeSharedROOT:ExtensionNodeSharedChar(s)NextNodea711355a77d337a77d3974LeafNodeExtensionNodeSharedChar(s)NextNodeExtensionNodeSharedChar(s)NextNodeStateRootTXMerkleRootBlockHeight…BlockHeaderTXsBlockBodyLeafNodewζHash(.)ζKey-endΨBlockHeaderTXsBlockBodyLeafNodewζHash(.)ζKey-endΨη//圖2.3:DatastructureofthemodifiedShardStateTree(mSST).盡管某個broker有多個“子賬戶”，但是這些歸屬于同一個broker賬戶的若干個“子賬戶”仍然共用同一個“外部賬戶”地址。如圖2.3所示，賬戶地址為“a711355”的broker賬戶狀態被分割到了兩個分片中，即Shard#1與#2。但是，從系統外部用戶的角度來看，這兩個子賬戶就是同一個賬戶，因為它們共用同一個賬戶地址“a711355”。只是在BrokerChain的協議層，它們會被判定為不一樣的“分賬戶”。為了達到上述效果，作者設計了圖2.3示的新型數據結構叫做“修改之后的分片狀態樹（modifiedShardStateTree，mSST）”。在mSST中，每個“外部賬戶”的葉子結點（LeafNode）的數據結構中被添加了一個擴展字段，即圖2.3中的Ψ字設計原理33段，它可以用來設置一個類似于id的標識符，以此來區分歸屬于同一個broker賬戶的多個子賬戶。例如圖2.3中，中間部位的葉子結點，Key-end為1355對應的Ψ字段為“1100”（四位數字代表系統中有4個分片；此處每個數字從左向右的位數代表第幾個分片；數字“1”代表在該分片上部署有子賬戶），意思是賬戶地址為“a711355”的broker的兩個子賬戶被分割到了第1號與第2號分片，即Shard#1與#2。按照上述“賬戶狀態分割機制”的設計，當分片間出現跨分片交易的時候，BrokerChain分片區塊鏈就可以使用這些broker賬戶來幫助處理這些跨分片交易。AB跨分片交易：A向B轉賬X代幣分片2分片分片2引入賬戶狀態分割機制做市商賬戶C“”分片2的片內交易：C向B轉賬X代幣分片1的片內交易：做市商賬戶C“”分片2的片內交易：C向B轉賬X代幣BABA圖2.4:BrokerChain跨分片協議中的“做市商”交易機制。圖2.4展示了“做市商賬戶”的跨分片交易處理機制。其中，“做市商賬戶”C就是一個broker賬戶。通過“賬戶狀態分割”機制，它在分片1與分片2存在兩個“分賬戶”。那么，當一筆交易的發起者向系統提交了一個原始交易時，這筆交易有較大概率會被協議判定為是一筆跨分片交賬交易時，這筆轉賬交易就是一筆跨分片交易。那么，在BrokerChain的協議層，這筆跨分片交易會被拆解為兩筆“耦合”的“片內”子交易:?子交易1：賬戶A向分片1內的broker賬戶C進行片內轉賬。?子交易2：分片2內的broker賬戶C向賬戶B進行片內轉賬。當這兩筆子交易完成后，系統就實現了那筆原始跨分片交易（A向B轉賬x數量的代幣）的上鏈處理。可見，通過借助做市商賬戶C，Broker-Chain分片區塊鏈系統可以大大減少跨分片交易的數量。BrokerChain協議中跨分片交易的處理流程簡述發起方A做市商賬戶C分片1分片2 步驟1:發送Θraw步驟2:發送Θ1Θ1} 步驟1:發送Θraw步驟2:發送Θ1Θ1} 成功圖2.5:BrokerChain協議中跨分片交易處理流程。圖2.5展示了一筆由broker賬戶服務的跨分片交易的執行時序圖，具體流程描述如下：?步驟1:SenderA發送原始交易消息θraw給BrokerC。?步驟2:BrokerC收到原始消息θraw后，分別給原始交易發送方賬戶和接收方賬戶所在分片（圖中Shard1、Shard2）發送θ1。?步驟3：Shard1節點接收到θ1后，判斷消息合法性，構建A和C之間的交易（Tx1如果交易上鏈，則向Broker發送Confirmθ1消設計原理35?步驟4：BrokerC接收到Confirmθ1消息，驗證消息的有效性后，向Shard2發送θ2。?步驟5：Shard2節點接收到θ2后，判斷消息合法性，構建C和B之間的交易（Tx2如果交易上鏈，則向BrokerC發送Confirmθ2消息完成跨分片交易。兩類角色在BlockEmulator框架中的實現邏輯上述跨分片交易處理流程中提到了兩個關鍵角色：Sender與Broker。它們在BlockEmulator代碼層面的實現邏輯分別解釋如下。?Sender：Sender理應為區塊鏈系統的客戶端。在BlockEmulator的代碼層面，目前Sender的角色由supervisor節點擔當。Sender負責檢測接收的交易是否為跨分片交易，如果是跨分片交易，則生成θraw，并發送給某個broker賬戶。?Broker：Broker的角色由supervisor節點擔當，負責處理跨分片交易的請求。1.在分片區塊鏈BrokerChain網絡中，每一個broker賬戶將會被分割到多個分片中，而且這些broker賬戶不參與區塊鏈網絡的狀態遷移。2.Broker接收到跨分片交易θraw后，Broker負責生成θ1，并將其發送給supervisor。隨后，supervisor驗證消息、生成片內交易Tx1，并添加Tx1到相應的分片交易池。3.Broker負責監控區塊鏈上鏈情況，當接收到Confirmθ1消息后，生成θ2并發送給supervisor，supervisor驗證消息、生成片內交易Tx2，并添加Tx2到對應分片交易池。4.Broker接收到Confirmθ2消息后，跨分片交易θraw處理完成。5.具體舉例說明：A為分片1中的賬戶，B為分片2中的賬戶，如果A，B之間發生了轉賬交易，記為?A→B?。Broker檢測到跨分片交易后，經過一系列信息交換，跨分片交易?A→B?被轉變為對應于分片1和分片2的兩筆片內交易，即?Tx1:A→Broker?和?Tx2:Broker→B?。Broker機制的代碼實現在BlockEmulator項目中，Broker機制的實現分為兩個部分：第一部分是Broker數據結構，第二部分是Broker相關消息數據結構的實現。Broker數據結構Broker實例包含了與Broker相關的變量，用來存儲交易處理過程中1typeBrokerstruct{2BrokerRawMegsmap[string]*message.BrokerRawMeg3ChainConfig*params.ChainConfig4BrokerAddress[]string5RawTx2BrokerTxmap[string][]string6}具體的變量說明如下：設計原理37變量說明θraw摘要和*BrokerRawMeg系統配置信息。Broker地址。原始跨分片交易和Broker產生的兩個片內交易的映射。同時Broker實例提供了處理跨分片交易必要的方法，代碼位于./su1//generateanewbroker2funcNewBroker(pcc*params.Chainconfig)35funcgetBrokerRawMagDigest(r*message.BrokerRawMeg)[]byte68funcfetchModifiedMap(keystring)uint64910//Handletherawmesssage11funchandleBrokerRawMag(brokerRawMags[]*message.BrokerRawMeg)1214funchandleTx1ConfirmMag(mag1confirms[]*message.Mag1Confirm)1516//Handlethetx217funchandleTx2ConfirmMag(mag2confirms[]*message.Mag2Confirm)1819//initbrokeraddress20funcinitBrokerAddr(numint)[]stringBroker相關消息的數據結構θraw：Sender向Broker發送的原始交易的消息。1typeBrokerRawMegstruct{2Tx*core.Transaction3Brokerutils.Address4Hlockuint64//ignore5Snonceuint64//ignore6Bnonceuint64//ignore7Signature[]byte//notimplementednow.8}θ1：Broker向原始交易的發起者所在分片發送的信息。1typeBrokerType1Megstruct{2RawMeg*BrokerRawMeg3Hcurrentuint64//ignore4Signature[]byte//notimplementednow.5Brokerutils.Address6}Confirmθ1：原始交易發起者賬戶所在分片將Tx1上鏈后，向Broker發送的確認信息。設計原理391typemag1Confirmstruct{2Tx1Hash[]byte3RawMeg*BrokerRawMeg4}θ2：Broker向原始交易的接收者所在分片發送的信息。1typeBrokerType2Megstruct{2RawMeg*BrokerRawMeg3Signature[]byte//notimplementednow.4Brokerutils.Address5}Confirmθ2：原始交易的接收者所在分片,將Tx2上鏈后，向Broker發送的確認信息。1typemag2Confirmstruct{2Tx2Hash[]byte3RawMeg*BrokerRawMeg4}我們在BlockEmulator項目中為上述消息的數據結構都提供了對應的處理方法，例如這里給出了一些相關方法的函數簽名：函數簽名說明Broker接收θraw，產生并發送θ1。函數簽名說明產生并發送θ2。記錄跨分片交易上鏈結客戶端判斷交易中賬戶所獲取注入交易中的跨分片交易，生成θraw發送給Broker。supervisor處理來自Bro-ker的θ1，生成片內交易Tx1，并加入對應分片交易supervisor處理來自Bro-ker的θ2，生成片內交易Tx2，并加入對應分片交易設計原理41函數簽名說明supervisor跟蹤區塊中交易記錄，分別產生發送給Broker。2.3.3CLPA賬戶重劃分算法由于傳統分片區塊鏈的賬戶劃分方式基本是靜態的，這會導致有些分片會出現交易負載過高（熱分片），而有些分片交易負載較小（冷分片）的情況。在這種時候，一個合適的賬戶重新劃分算法就能夠動態地調整某些賬戶所在的分片，以達到降低跨分片交易數量、均衡分片間負載的效果。BlockEmulator內置了賬戶劃分的功能，一個可選的賬戶劃分算法為CLPA（ConstrainedLabelPropagationAlgorithm）。此方法來自于發表在SRDS2022的論文AchievingScalabilityandLoadBalanceacrossBlockchainShardsforStateSharding[11]。CLPA的數據結構設計CLPA有關的數據結構均在packagepartition(./partition)中定義。由于CLPA本質上是一個圖劃分算法，因此實現CLPA之前，我們首先需要實現一個Graph的數據類，如下：2typeVertexstruct{3Addrstring//節點具體屬性4//其他屬性待補充5}6//圖7typeGraphstruct{8VertexSetmap[Vertex]bool//頂點集合9EdgeSetmap[Vertex][]Vertex//10}借助上述的Graph類，我們參考原文定義了如下的CLPAState類：2typeCLPAStatestruct{3NetGraphGraph//需運行CLPA算法的圖4PartitionMapmap[Vertex]int//記錄分片信息的5Edges2Shard[]int//Shard6