--- id: 2 title: Bitroot 多引擎平行執行設計：排程、分片與衝突面 slug: bitroot-evm date: 2026/08/07 summary: 深入多引擎平行執行：引擎如何分攤交易、狀態如何分片存取、樂觀並行與三階段衝突偵測如何限制重新執行的範圍，並用測試網口徑說明如何閱讀加速比與衝突率。 keywords: 多引擎平行,EVM,狀態分片,衝突偵測,Bitroot heroImage: /cms-media/file/4In%20depth%20analysis%20of%20Bitroot.jpg --- 單執行緒 EVM 的瓶頸不在「Solidity 寫得慢」，而在執行語意預設串列、共享狀態上的鎖競爭無處安放。多引擎平行要回答的是工程問題：如何把一個區塊裡的交易分到多個執行上下文，又在衝突時不把整塊推倒。產業路線對照見 [《平行執行的三條路線》](/zh-Hant/blog/parallel-execution-approaches)；本文聚焦 Bitroot 側的多引擎設計。理論骨架見 [《OCC 入門》](/zh-Hant/blog/optimistic-concurrency-control-intro)，避免在此重講資料庫四階段。 ## 設計目標：平行，但結果可重放 多引擎架構通常堅持幾條原則： - 每個引擎有相對獨立的執行上下文，減少全域大鎖。 - 狀態按帳戶或儲存槽分區，引擎優先觸達本地分片，降低跨引擎同步。 - 排程器做預分析與批次處理，把可能相關的交易盡量放在同一引擎或同一批次，減少乒乓。 - 最終提交必須等價於共識給定順序下的串列執行（確定性重放）。 共識側如何盡快給出順序，見 [《Pipeline BFT 與執行解耦》](/zh-Hant/blog/bitroot-pipeline-bft)。執行側的樂觀假設與回滾細節，見 [《樂觀平行化機制》](/zh-Hant/blog/bitrootevm-)。架構總圖見 [《平行 EVM 架構概覽》](/zh-Hant/blog/bitrootevm)。 ## 排程：不是均勻撒交易 樸素的做法是 round-robin 分發交易，熱點合約一出現就會跨引擎打架。更合理的排程會估計： - 複雜度與 gas 量級（粗粒度）； - 可能觸及的狀態分區； - 優先級與批次親和性（相關交易同批，減少跨引擎狀態同步）。 排程本身也有開銷：預分析過粗會誤判，過細會變成串列瓶頸。實務上常見的折中是「靜態啟發 + 執行環境監控」：先按啟發式分組平行，再用衝突偵測糾正。DeFi 等熱點模式為何容易打穿平行度，見 [《平行 EVM 工作負載熱點》](/zh-Hant/blog/parallel-evm-workload-hotspots)。 ## 狀態分片：平行之後的下一道牆 執行平行之後，單一狀態樹與單機記憶體仍會成為上限。分片把狀態空間切開：分片內平行，跨分片走顯式訊息或非同步提交。大物件適合鏈下存、鏈上存雜湊，減輕全節點儲存。分片不是免費午餐——跨分片原子性與開發者的心智成本都會上升，需要在協議裡寫清楚，而不是留給應用碰運氣。 跨分片可組合 DeFi 往往是壓力測試：路由連續觸碰多個池時，寫入衝突與跨分片協議延遲會疊加。產品層面如何承認這一邊界，見 [《Bitroot 定位》](/zh-Hant/blog/bitroot-positioning)。 ## 衝突偵測：把爆炸半徑收小 樂觀平行的代價是衝突。Bitroot 公開資料強調三階段偵測： 1. **執行前**：依賴/讀寫啟發，盡量避免明顯衝突進入同一個平行窗口。 2. **執行中**：版本或讀寫集監控，盡早中止無效路徑。 3. **執行後**：狀態根一致性校驗，兜住漏網與實作缺陷。 目標不是「零衝突」，而是「衝突時可選擇性重新執行」。與 Aptos Block-STM 等「執行中協作排程」同屬樂觀家族，但實作細節不同；不要把不同專案的測試 TPS 直接橫比。 ## 如何讀「引擎數 ↔ TPS」曲線 測試環境中，增加引擎數量往往先近似線性加速，隨後因衝突率上升而彎曲。公開測試網口徑曾出現過：較少引擎時數千 TPS 量級，更多引擎時數萬 TPS 峰值、確認時間壓到亞秒級等描述——均依賴硬體、合約類型與衝突設定，是工程觀測而非主網 SLA，也不構成收益承諾。讀數時建議同時看：實際平行度、衝突率、重新執行佔比、延遲分位。術語見 [《效能指標術語表》](/zh-Hant/blog/performance-metrics-glossary)。 EVM 相容邊界（位元組碼、預編譯、工具鏈）決定「多引擎」是否對現有合約透明，見 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)。驗證者硬體與地理分布如何反噬平行紅利，見 [《去中心化與效能的權衡》](/zh-Hant/blog/decentralization-performance-tradeoff)。 ## 和共識層如何對齊節奏 多引擎再快，消費的也是共識已經排好的順序。若執行長期追不上出塊，就會堆積未確認的狀態視圖，應用側的體感變成「出塊很快但查詢/依賴交易仍慢」。因此披露時應同時給出執行滯後與確認分位，而不是只報引擎峰值。Pipeline 側見 [《Pipeline BFT 與執行解耦》](/zh-Hant/blog/bitroot-pipeline-bft)；產品座標見 [《Bitroot 定位》](/zh-Hant/blog/bitroot-positioning)。 對應用程式開發者而言，多引擎幾乎應該是透明的：不需要改 Solidity 語法去「宣告平行」。真正要改的是狀態布局與互動模式——減少全域單點計數器、避免所有使用者擠寫同一個 slot。否則引擎再多，也只能在衝突偵測裡忙著重新執行。工具鏈與相容邊界見 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)；誰該先讀這類材料見 [《誰該讀平行 EVM》](/zh-Hant/blog/who-should-read-parallel-evm)。 ## 快取、預取與跨引擎通訊稅 多引擎之外，分層快取與狀態預取決定「引擎是否真的在幹活」。本地分片命中率高時，平行接近 CPU 寬度；跨引擎頻繁拉取遠端槽位時，通訊稅會把加速比壓扁。排程器若只看 gas 而不看分區親和性，就會系統性地製造跨引擎流量。 實務上應監控：跨引擎讀寫比例、鎖等待或版本衝突次數，以及分片間訊息佇列深度。這些指標比單獨的引擎數量更接近真實產能。與共識解耦後，執行層追趕慢會表現為從確認到狀態根的間隙拉長，使用者感知仍是「鏈變慢」。總覽見 [《平行 EVM 架構概覽》](/zh-Hant/blog/bitrootevm)。 ## 對合約作者的可見影響 多數情況下，多引擎應對 Solidity 作者透明：不需要改寫法即可部署。仍有間接影響：依賴精確的區塊內時序，或「同區塊後半段必定看見前半段寫入」的假設，在平行投機窗口下更脆弱；開發者應依賴明確的事務邊界與事件，而不是未文件化的排程巧合。 工具鏈側，trace、gas 剖面與除錯器需要能解釋重新執行的路徑，否則線上事故難以檢討。誰該優先閱讀平行材料，見 [《誰該讀平行 EVM》](/zh-Hant/blog/who-should-read-parallel-evm)。相容邊界見 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)。 多引擎設計的評價標準應是：給定衝突率曲線，加速比是否可解釋、重新執行是否可觀測，以及對存量合約是否保持語意相容。滿足這三點，才談得上工程上的平行 EVM，而不是展示用的多執行緒解譯器。 ## 可觀測性：沒有度量就沒有平行 生產級多引擎需要暴露：每個引擎的利用率、跨分片訊息速率、衝突偵測各階段的命中次數、重新執行的交易佔比，以及從共識序到狀態根的時間分布。缺少這些曲線，維運只能看到「TPS 掉了」，而無法判斷是排程、熱點合約還是狀態 I/O 的問題。把可觀測性當成功能的一部分，而不是上線後的儀表板裝飾，是平行執行能否營運的前提。 排程、分片與衝突偵測必須一起看：只加引擎不加觀測，只會更快地重複同一類故障。把衝突率曲線納入發布說明，是對開發者與驗證者最小的誠實。 公開測試網數字請標註引擎數、負載類型與衝突率，並聲明非主網承諾、非投資建議。 ## 小結 多引擎平行把「能不能多核跑 EVM」落實成排程、分片與衝突控制三件套。它放大的是低衝突與可分割負載的吞吐量；在 AMM 共享池這類熱點上，再多引擎也會被迫近似串列——這是工作負載問題，不是再加一句行銷話術就能消掉的。 ## 延伸閱讀 - [《樂觀平行化機制》](/zh-Hant/blog/bitrootevm-) - [《Pipeline BFT 與執行解耦》](/zh-Hant/blog/bitroot-pipeline-bft) - [《平行 EVM 工作負載熱點》](/zh-Hant/blog/parallel-evm-workload-hotspots)