--- id: 1 title: Bitroot 樂觀平行化機制：偵測、重新執行與確定性 slug: bitrootevm- date: 2026/08/09 summary: 拆解樂觀平行化在 EVM 上的運作方式：為何不能靠開發者預先宣告讀寫集、三階段衝突偵測如何縮小回滾面，以及確定性重放為何是區塊鏈相對資料庫 OCC 的額外約束。 keywords: 樂觀平行化,OCC,衝突偵測,平行EVM,Bitroot heroImage: /cms-media/file/2Deep%20analysis%20of%202Bitroot%20parallelized%20EVM%20technology.jpg --- 樂觀平行化的一句話定義：先假設多數交易不打架，平行跑；發現讀寫衝突再按既定順序重做，直到結果與串列一致。它不是「更快的魔法」，而是把衝突處理從預防挪到偵測與恢復——在 EVM 不能強制帳戶存取清單時，這幾乎是保留位元組碼相容的主要路徑。理論來源見 [《OCC 入門》](/zh-Hant/blog/optimistic-concurrency-control-intro)；路線比較見 [《平行執行的三條路線》](/zh-Hant/blog/parallel-execution-approaches)。架構位置見 [《平行 EVM 架構概覽》](/zh-Hant/blog/bitrootevm) 與 [《Bitroot 定位》](/zh-Hant/blog/bitroot-positioning)。 ## 為什麼 EVM 更難「確定性預先宣告」 Solana Sealevel 要求交易宣告帳戶清單，排程器可在執行前建圖。EVM 交易會觸及哪些 storage slot，常常要跑到條件分支才會知道。強行加上存取清單會破壞大量現有合約與工具鏈的假設。因此 Bitroot 等專案選擇：相容優先，衝突交給執行環境。相容邊界見 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)。 代價是：衝突率高時，重新執行會吃掉平行紅利。這不是實作「寫錯了」，而是樂觀方法的固有曲線——在熱點合約上尤甚，見 [《平行 EVM 工作負載熱點》](/zh-Hant/blog/parallel-evm-workload-hotspots)。 ## 三階段衝突偵測在做什麼 Bitroot 資料中的三階段，可以按職責理解（具體演算法以節點實作為準）： 1. **執行前 — 靜態/啟發式依賴分析** 用歷史模式、靜態分析或粗粒度讀寫估計，把明顯衝突的交易錯開平行窗口，降低「一上來就撞」的機率。 2. **執行中 — 版本或讀寫集監控** 交易在私有視圖上執行；若發現自己讀過的版本已被排序更前面的交易寫入，就盡早中止，避免把無效的工作做完。 3. **執行後 — 狀態根 / 可序列化校驗** 對提交候選做一致性檢查，確保平行合併的結果與規範串列語意一致，擋住漏檢與實作 bug。 與「整批跑完再統一驗證」的樸素 OCC 相比，分層偵測的目標是**更早失敗、更小的重新執行集合**。這與 Block-STM 強調的協作排程同屬一個問題家族，但排程器與中止粒度不必相同；不要用行銷倍數替代衝突率曲線。 ## 回滾與重新執行：選擇性，而不是整塊重來 高效率的實作通常只重跑受影響的交易及其依賴閉包，而不是區塊內所有交易。仍必須遵守共識順序：不能為了吞吐量私下改序。共識先給出順序、執行後收斂的分工，見 [《Pipeline BFT 與執行解耦》](/zh-Hant/blog/bitroot-pipeline-bft)；多引擎如何承載平行窗口，見 [《多引擎平行執行設計》](/zh-Hant/blog/bitroot-evm)。 對 Agent 與高頻結算負載而言，這意味著：低衝突時確認可預期；在熱點池上則應預期重新執行上升，而不是假設「平行 = 永遠快」。堆疊語境見 [《去中心化 AI 堆疊》](/zh-Hant/blog/aibitrootweb3ai)。 ## 確定性：區塊鏈 OCC 多出來的那一層 單機資料庫 OCC 只需本實例可序列化。鏈上每個誠實節點必須獨立算出同一狀態。因此禁止依賴：執行緒排程次序、本地時鐘、不穩定的浮點運算等非確定性來源。平行度變化時，規範結果仍應唯一。這是安全屬性，不是效能彩蛋。 ## 和同賽道方案怎麼比（克制） | 路線 | 代表直覺 | 對 EVM 存量 | |------|----------|-------------| | 確定性宣告 | 執行前已知依賴 | 遷移成本高 | | 物件模型 | 用物件所有權隔離 | 需新語言/範式 | | 樂觀 OCC | 執行環境偵測 + 重新執行 | 最貼近位元組碼相容 | 公開資料中「相對傳統 EVM 數倍吞吐」這類表述，應理解為特定負載與測試網條件下的工程觀測；高衝突負載下倍數會收縮。讀法見 [《效能指標術語表》](/zh-Hant/blog/performance-metrics-glossary)。驗證者門檻如何限制可用的平行度，見 [《去中心化與效能的權衡》](/zh-Hant/blog/decentralization-performance-tradeoff)。本文不構成投資建議。 ## 衝突率曲線比峰值倍數更重要 實驗室裡「相對串列 EVM 數倍」往往對應低衝突的合成負載；把同一套引擎丟進共享池熱點，倍數會迅速收縮。因此對外溝通應優先給出：衝突率—吞吐曲線、重新執行佔比，以及 p95 延遲。這比單一放大倍數更能幫助應用方判斷自己的合約適不適合吃平行紅利。熱點解剖見 [《平行 EVM 工作負載熱點》](/zh-Hant/blog/parallel-evm-workload-hotspots)。 實作細節因客戶端而異，但評估清單可以共用：讀寫集粒度（帳戶層級還是儲存槽層級）、中止後是立刻重跑還是進入等待佇列、驗證是否平行，以及狀態根如何在平行合併後一次性確定。清單越具體，越不容易被「三階段」四個字糊弄過去。資料庫脈絡見 [《OCC 入門》](/zh-Hant/blog/optimistic-concurrency-control-intro)；總架構見 [《平行 EVM 架構概覽》](/zh-Hant/blog/bitrootevm)。 ## 衝突率曲線與工程調參 樂觀平行的關鍵調參不是「引擎數越大越好」，而是：平行窗口寬度、中止策略、重新執行的排程優先級，以及啟發式分析的保守程度。窗口過大，衝突連鎖更長；窗口過小，接近串列。啟發過於保守，吞吐量上不去；過於激進，重新執行的風暴更頻繁。 公開測試應同時報告：無衝突基準、中等衝突的合成負載，以及接近 AMM 熱點壓力負載。只發布第一種數字，等於只展示樂觀假設成立時的上界。術語與讀數見 [《效能指標術語表》](/zh-Hant/blog/performance-metrics-glossary)；工作負載分類見 [《平行 EVM 工作負載熱點》](/zh-Hant/blog/parallel-evm-workload-hotspots)。 ## 與資料庫 OCC 的關鍵差異再強調一次 資料庫可以在單一主節點上提交後再複製；鏈必須讓所有誠實副本獨立收斂到同一根。因此「差不多可序列化」不夠，必須具備確定性。浮點模型輸出、依賴節點本地熵的隨機，以及未約定順序的平行歸約，都不能進入規範狀態轉換——它們可以留在鏈下，再以證明或聚合簽章錨定。 這也解釋了為何 AI 推論不宜直接充當共識輸入：機率輸出與確定性重放互相衝突。正確模式是鏈下計算、鏈上結算與可選證明，見 [《去中心化 AI 堆疊》](/zh-Hant/blog/aibitrootweb3ai) 與 [《可信運算框架》](/zh-Hant/blog/trusted-computing-framework)。 樂觀平行化的教學價值，在於把「快」翻譯成可測量的衝突率與重新執行佔比。記住這個翻譯，就不會被下一張更大的 TPS 海報輕易帶走。實作細節仍以節點客戶端與稽核材料為準。 ## 正確性測試建議（概念層面） 除了吞吐基準，還應有：同一批次在不同平行度下狀態根一致；故意注入讀寫衝突後最終仍等價於串列；崩潰恢復後重放不引入分叉；以及模糊測試產生的隨機交易流在平行與串列模式下的對比。通過這類測試，比再宣布一個峰值 TPS 更能說明樂觀平行化已經工程化。客戶端實作細節以倉庫與稽核為準。 偵測、重新執行與確定性是樂觀平行的三角：缺偵測則回滾過晚，缺選擇性重新執行則吞吐量歸零，缺確定性則安全模型破產。三角同時成立，TPS 數字才有解釋力。 公開加速比請連同衝突率與重新執行佔比一併披露，避免孤立的峰值；非投資建議。 具體演算法以節點實作與稽核報告為準，本文僅建立機制直覺。 ## 小結 樂觀平行化讓 Bitroot 在不強迫開發者重寫存取模式的前提下榨取多核；它的上限由衝突率與重新執行的效率決定，而不是由白皮書的形容詞決定。理解偵測分層與確定性約束，比記住任何一個 TPS 數字都更有用。 ## 延伸閱讀 - [《OCC 入門》](/zh-Hant/blog/optimistic-concurrency-control-intro) - [《多引擎平行執行設計》](/zh-Hant/blog/bitroot-evm) - [《平行執行的三條路線》](/zh-Hant/blog/parallel-execution-approaches)