--- id: 5 title: Bitroot 平行 EVM 架構概覽：共識、執行與狀態如何協同 slug: bitrootevm date: 2026/07/30 summary: 從分層視角概述 Bitroot 平行 EVM：Pipeline BFT、樂觀平行執行、狀態分片與 BLS 聚合如何協同，以及如何用測試網口徑閱讀效能數字，避免把工程目標當成主網承諾。 keywords: Bitroot,平行EVM,架構概覽,Pipeline BFT,狀態分片 heroImage: /cms-media/file/6Design%20and%20Implementation%20of%20High%20Performance%20Blockchain%20Architecture.jpg --- 高效能公鏈最常見的失敗溝通方式，是一張 TPS 海報。真正有用的是回答三件事：交易順序誰定、狀態轉換怎麼平行、狀態規模怎麼成長。本文是 Bitroot 平行 EVM 的架構導覽——偏地圖，不偏參數競賽。更細的機制分別在 Pipeline BFT、多引擎與樂觀平行專文中展開；理論背景指向系列中的 OCC 與擴容地圖，避免在此重複長文。 ## 問題從哪裡來 經典 EVM 按區塊內順序一筆筆執行，正確性好懂，吞吐量受單核與串列語意約束。在擴容地圖上，平行執行只是選項之一，還要和 Rollup、分片等路線對照，見 [《區塊鏈擴容地圖》](/zh-Hant/blog/blockchain-scaling-map) 與 [《EVM 單執行緒瓶頸》](/zh-Hant/blog/evm-single-thread-bottleneck)。Bitroot 的選擇是：在完整 EVM 相容的前提下走樂觀平行，並把共識與執行解耦，而不是要求開發者預先宣告帳戶清單。 ## 三層協同，而不是三塊貼紙 | 層級 | 機制要點 | 解決什麼 | |------|----------|----------| | 共識 | Pipeline BFT、VRF 領導者輪換、BLS12-381 簽章聚合 | 階段串列與近似 O(n²) 訊息/驗簽開銷 | | 執行 | 樂觀平行、動態分組、三階段衝突偵測 | 單執行緒執行上限與衝突後重新執行的範圍 | | 狀態 | 帳戶/槽位分片、分層快取、大物件鏈下存雜湊上鏈 | 單樹容量與全節點儲存壓力 | 共識層負責盡快就交易順序達成一致；執行層在已排序的批次上盡量平行推進狀態轉換；狀態層避免「執行已經平行，磁碟與記憶體卻仍是單點」。三者缺一，海報上的數字就很難在真實負載裡站穩。產品座標說明見 [《Bitroot 定位》](/zh-Hant/blog/bitroot-positioning)。 ## Pipeline BFT：讓不同高度重疊推進 傳統 BFT 往往要等一個區塊走完提案→投票→提交，才開下一個高度。Pipeline BFT 把階段流水線化：高度 N 在預提交時，N+1 可以在預投票，N+2 可以開始提案。領導者用 VRF 輪換，降低可預測的操縱；BLS 聚合把多驗證者簽章壓成接近常數級的驗證成本，使擴大驗證者集合時，共識開銷不至於線性失控。細節與「為何要和解耦執行一起看」見 [《Pipeline BFT 與執行解耦》](/zh-Hant/blog/bitroot-pipeline-bft)。 解耦的含義很具體：共識不必等本區塊全部執行完，才推進下一個高度的排序工作。執行可以在背景追趕。代價是工程上要嚴格保證：無論平行度如何，最終狀態都必須與「按共識順序串列執行」一致——這是區塊鏈 OCC 相對資料庫 OCC 多出來的硬約束，背景見 [《OCC 入門》](/zh-Hant/blog/optimistic-concurrency-control-intro)。 ## 樂觀平行：相容 EVM，複雜度留在執行環境 確定性平行（例如顯式帳戶清單）與物件模型在理論平行度上常有優勢，但遷移成本高。樂觀路線假設多數交易無衝突，先平行再偵測；衝突則選擇性重新執行。Bitroot 強調執行前的依賴分析、執行中的版本監控、執行後的狀態根校驗這種分層偵測，目的是更早發現衝突、縮小回滾面。機制深挖見 [《樂觀平行化機制》](/zh-Hant/blog/bitrootevm-)；與產業三條路線的對照見 [《平行執行的三條路線》](/zh-Hant/blog/parallel-execution-approaches)。 多引擎排程、分片內平行與跨分片通訊，屬於執行與狀態的工程展開，見 [《多引擎平行執行設計》](/zh-Hant/blog/bitroot-evm)。熱點負載何時吃掉平行紅利，見 [《平行 EVM 工作負載熱點》](/zh-Hant/blog/parallel-evm-workload-hotspots)。 對 AI Agent 與任務結算合約而言，這一層提供的是可規劃的確認與吞吐預期；訓練本身通常不在共識的熱路徑上，見 [《去中心化 AI 堆疊》](/zh-Hant/blog/aibitrootweb3ai)。 ## 如何讀效能數字（含免責） 公開資料與測試網口徑中，曾出現過約數百毫秒級確認、單分片數千至數萬 TPS、多分片擴充等表述；不同批次依賴硬體、交易類型與衝突率，數字不可直接橫向對比，更不能外推為「主網保證」或任何財務收益預期。讀指標時建議同時看延遲分布、衝突率與可驗證重放成本，術語見 [《效能指標術語表》](/zh-Hant/blog/performance-metrics-glossary)。去中心化與效能的張力見 [《去中心化與效能的權衡》](/zh-Hant/blog/decentralization-performance-tradeoff)。EVM 相容邊界見 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)。 ## 儲存與網路別被海報省略 執行再快，也要把狀態落到儲存、把投票傳到網路上。大物件宜鏈下存、鏈上存雜湊；流水線越深，對尾端延遲越敏感。真實負載裡，熱點快取命中率與跨分片排隊，往往比純執行核心更早成為體感問題。讀者定位見 [《誰該讀平行 EVM》](/zh-Hant/blog/who-should-read-parallel-evm)。 相容性選擇的代價也要寫進同一張表：保留位元組碼層級的 EVM，意味著無法要求交易預先宣告完整的讀寫集，平行度上限更多由執行環境的衝突行為決定。這與物件模型鏈「用程式設計範式換平行」的取捨相反，詳見 [《平行執行的三條路線》](/zh-Hant/blog/parallel-execution-approaches) 與 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)。對遷移團隊而言，優先驗證的是：現有合約在熱點軌跡下的衝突率與 p95 延遲，而不是海報上的理論峰值。 ## 驗證者視角：重放成本才是去中心化預算 吞吐海報常忽略驗證者的重放成本。樂觀平行若產生大量投機路徑與重新執行，全節點的 CPU 與頻寬會被推高，最終表現為驗證者門檻上升——這正是去中心化與效能張力的執行側版本。設計上應追求：在平行加速的同時，誠實節點仍能以可接受的成本完成確定性重放並核對狀態根。 因此評估 Bitroot 或同類方案時，除了看領導者的出塊延遲，還應問：普通全節點同步與驗證的資源曲線如何；狀態成長與分片後的快照/剪枝策略是什麼。相關討論見 [《去中心化與效能的權衡》](/zh-Hant/blog/decentralization-performance-tradeoff)。誰該讀這些材料的路徑見 [《誰該讀平行 EVM》](/zh-Hant/blog/who-should-read-parallel-evm)。 ## 狀態成長與大物件策略為何算架構問題 執行平行解決 CPU 寬度之後，歷史狀態與大物件（長 calldata、中繼資料、證明附件）會變成磁碟與同步的瓶頸。把大物件放鏈下、鏈上存雜湊，是常見策略，但必須配套：可用性假設、挑戰期，以及輕節點如何驗證。否則「平行很快」只存在於空狀態的基準測試裡。 分片則引入跨分片延遲與原子性語意，應用程式開發者需要新的心智模型。這些內容在多引擎專文展開，見 [《多引擎平行執行設計》](/zh-Hant/blog/bitroot-evm)；在擴容地圖中的位置見 [《區塊鏈擴容地圖》](/zh-Hant/blog/blockchain-scaling-map)。 架構概覽的結論可以收束為一句：平行 EVM 是共識、執行與狀態三層的協同系統；只最佳化任何單層而不測量另外兩層，都會在真實負載裡暴露。後續請按需進入專文，而不是在概覽裡尋找全部參數。 ## 閱讀本概覽時請帶著的三個問題 交易順序在擁塞時是否仍可預期？衝突升高時吞吐量如何退化，而不是突然歸零？全節點的重放成本是否仍允許足夠分散的驗證者集合？三個問題都能在測試網材料裡找到帶條件的答案，架構敘事才站得住；否則仍只是一份模組名稱清單。專文與術語表是查證入口，概覽只負責把問題放對地方。 ## 小結 Bitroot 平行 EVM 的骨架是：流水線共識定序、樂觀平行做狀態轉換、分片管狀態規模，並用 EVM 相容降低遷移摩擦。架構概覽到此為止；需要某一層的細節時，請轉到對應專文，而不是指望一篇文章同時講完共識證明與排程器虛擬碼。 ## 延伸閱讀 - [《Pipeline BFT 與執行解耦》](/zh-Hant/blog/bitroot-pipeline-bft) - [《多引擎平行執行設計》](/zh-Hant/blog/bitroot-evm) - [《樂觀平行化機制》](/zh-Hant/blog/bitrootevm-)