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