--- id: 17 title: 誰該讀平行 EVM：合約開發、客戶端工程、研究員三條路徑 slug: who-should-read-parallel-evm date: 2026/09/06 summary: 合約開發者、客戶端工程師、研究員關心平行 EVM 的角度完全不同。本文給出三條只指向已發布文章的閱讀路徑，幫不同背景的讀者迅速定位該讀什麼、不必讀什麼。 keywords: 平行EVM,合約開發,客戶端工程,區塊鏈研究,閱讀指南 heroImage: /images/community-bg.png --- 「平行 EVM」四個字，對不同讀者意味著完全不同的問題。Solidity 開發者首先擔心自己的合約會不會默默改變行為；客戶端與協議工程師關心排程器、衝突偵測與狀態樹如何吃滿多核；研究員則追問樂觀平行有沒有可核查的正確性邊界，還是行銷話術裹著一層資料庫術語。三種關切都合理，混在一起討論，卻很容易變成誰也說不透的泛泛之談。 因此有必要先分讀者，這不是製造門檻，而是承認平行執行橫跨應用層、系統層與理論層：一篇試圖同時討好三類人的文章，往往三類都講不深。前文 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained) 說明了相容性的工程含義；本文把「接下來讀什麼」收成三條可執行路徑，且**只連結本站已經發布的文章**，不指向尚未存在的虛構篇目，也不使用「系列某字母第 N 篇」這類無法打開的引用。 ## 路徑一：合約開發者——行為會不會變，程式碼要不要改 對合約作者而言，平行改變的不是 Solidity 語法，而是執行時的衝突與重試體驗。單執行緒 EVM 下，區塊內交易按順序解譯，最終狀態與順序一一對應；樂觀平行下，同一批次可能先並行預執行，再在驗證階段決定接受或回滾重跑。對低頻、低共享狀態的合約，過程通常透明；對 AMM、借貸、NFT mint 等反覆讀寫同一組儲存槽的合約，衝突率上升會表現為確認變慢、失敗重試變多，以及某些依賴「同區塊隱含順序」的邏輯更加脆弱。 建議閱讀順序： 1. [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained) — 先確認遷移時位元組碼、預編譯、JSON-RPC 與工具鏈哪些必須對齊。 2. [《樂觀並行控制（OCC）入門》](/zh-Hant/blog/optimistic-concurrency-control-intro) — 建立「先執行、再驗證、衝突則重做」的直覺，理解為何最終狀態仍應對齊某個串列次序。 3. [《衝突熱點與工作負載》](/zh-Hant/blog/parallel-evm-workload-hotspots) — 看清 AMM / 借貸 / mint 為何特別傷吞吐量，以及儲存布局如何影響衝突率。 4. 可選加深：[《Bitroot 平行化 EVM 技術解析》](/zh-Hant/blog/bitrootevm-)、[《多引擎平行執行設計》](/zh-Hant/blog/bitroot-evm) — 了解生產向引擎如何組織分組與衝突偵測，仍不必一開始就啃完所有系統細節。 可操作結論：先稽核熱點槽與全域計數器；能按使用者或按池拆分的狀態盡量拆分；不要把「同區塊內別人先執行」寫成隱含的不變式。多數合約無需為平行重寫業務邏輯，但高衝突合約幾乎肯定要從儲存與互動設計上做到「對衝突不敏感」。若你的工作主要是把現有的 Solidity 倉庫遷到新鏈，相容性四層驗收往往比閱讀執行引擎原始碼更能降低上線風險。 ## 路徑二：客戶端 / 協議工程師——排程、狀態與共識如何協同 這類讀者已經熟悉節點實作，關心的問題更硬：依賴圖怎麼建、讀寫集粒度選帳戶還是槽、引擎池如何擴縮、衝突重新執行如何避免活鎖、共識出塊與執行流水線如何解耦才不會互相堵塞。單執行緒瓶頸的歷史背景見 [《EVM 單執行緒瓶頸》](/zh-Hant/blog/evm-single-thread-bottleneck)；路線分野見 [《平行執行的三條路線》](/zh-Hant/blog/parallel-execution-approaches)。 建議閱讀順序： 1. [《EVM 單執行緒瓶頸》](/zh-Hant/blog/evm-single-thread-bottleneck) — 明確「慢」是慢在解譯器串列，而不只是共識間隔。 2. [《區塊鏈擴容地圖》](/zh-Hant/blog/blockchain-scaling-map) — 把平行執行放回 Rollup、分片、模組化等更大的座標，避免把執行層最佳化誤當成整條擴容的答案。 3. [《平行執行的三條路線》](/zh-Hant/blog/parallel-execution-approaches) 與 [《OCC 入門》](/zh-Hant/blog/optimistic-concurrency-control-intro) — 弄清確定性宣告、物件模型與樂觀路徑各自把複雜度放在哪一側。 4. [《Pipeline BFT 與多引擎協同》](/zh-Hant/blog/bitroot-pipeline-bft)、[《多引擎平行執行設計》](/zh-Hant/blog/bitroot-evm) — 對照一套具體的共識—執行解耦與多引擎設計，看工程取捨如何落地。 5. 讀效能數字前：[《效能指標詞典》](/zh-Hant/blog/performance-metrics-glossary)；評估硬體與集合規模時：[《去中心化與效能的張力》](/zh-Hant/blog/decentralization-performance-tradeoff)。 6. 用真實負載校準預期：[《衝突熱點與工作負載》](/zh-Hant/blog/parallel-evm-workload-hotspots)。 可操作結論：把「吞吐量」拆成排程效率、衝突重新執行成本、狀態讀寫放大、共識訊息開銷四段分別測量；任何只報理想負載峰值、不報衝突分布與硬體口徑的基準，對客戶端最佳化的參考價值都有限。實作時優先把衝突定義、重新執行策略與可觀測指標做成可設定、可匯出的介面，否則線上只能看見「變慢了」而看不見「為什麼變慢」。 ## 路徑三：研究員——正確性邊界、模型比較與可否證聲明 研究員通常不需要另一份產品簡介，而需要可否證的問題：樂觀平行的提交結果是否串列化等價於區塊順序？讀寫集的近似（帳戶層級 vs 槽層級）如何影響安全性與效能？在什麼樣的衝突圖下，加速比會退化到接近 1？與 Block-STM 類方案、確定性平行、物件模型相比，假設分別是什麼？ 建議閱讀順序： 1. [《平行執行的三條路線》](/zh-Hant/blog/parallel-execution-approaches) — 先固定比較的座標系，再進入單一專案的實作細節。 2. [《OCC 入門》](/zh-Hant/blog/optimistic-concurrency-control-intro) — 把區塊鏈執行層映射回經典資料庫並行控制的詞彙（讀寫集、驗證、重新執行）。 3. [《衝突熱點與工作負載》](/zh-Hant/blog/parallel-evm-workload-hotspots) — 用真實合約形態構造衝突圖的直覺，而不是只在轉帳基準上討論加速比。 4. [《效能指標詞典》](/zh-Hant/blog/performance-metrics-glossary) — 統一 TPS / 延遲 / 最終性 / 衝突率的口徑，避免論文式數字與行銷式數字混談。 5. [《去中心化與效能的張力》](/zh-Hant/blog/decentralization-performance-tradeoff) — 把「更快」放回驗證者門檻、地理與客戶端多樣性等可觀測維度。 6. 系統背景可選：[《區塊鏈擴容地圖》](/zh-Hant/blog/blockchain-scaling-map)、[《Bitroot 定位》](/zh-Hant/blog/bitroot-positioning)、[《Pipeline BFT 與多引擎協同》](/zh-Hant/blog/bitroot-pipeline-bft)。 可操作結論：要求任何效能或正確性聲明附帶工作負載描述、衝突定義、失敗與重新執行策略；沒有這些附件的「平行 EVM 更快」，研究價值接近零。把聲明寫成可重現的實驗設計（硬體、客戶端、交易產生器、衝突注入方式），比爭論形容詞更接近學術與工程的共同語言。 ## 對照表：按角色跳轉 | 讀者畫像 | 最關心的問題 | 優先閱讀（均為已發布文章） | |------|----------|---------------------------| | 合約開發者 | 行為會否變化、儲存如何避開熱點 | 相容性說明 → OCC 入門 → 衝突熱點；可選 Bitroot 執行層兩篇 | | 客戶端 / 協議工程師 | 排程、狀態、共識如何實作與測量 | 單執行緒瓶頸 → 擴容地圖 → 三條路線 / OCC → Pipeline BFT / 多引擎 → 指標詞典與去中心化張力 → 衝突熱點 | | 研究員 | 正確性邊界、模型比較、口徑是否可證偽 | 三條路線 → OCC → 衝突熱點 → 指標詞典 → 去中心化張力；可選定位與 Pipeline BFT | 若只想建立公共底座，可按站點閱讀鏈的順序前進：定位 → 相容性 → 本文 → 指標詞典 → 去中心化張力 → 衝突熱點。三條角色路徑是在這條主鏈上的「岔路」，不是另一套無法打開的目錄。讀完公共底座後，再按上表深潛，通常比從頭通讀所有技術長文更省時間。 ## 延伸閱讀 - 前置閱讀：[《EVM 相容意味著什麼：位元組碼、預編譯、JSON-RPC 與工具鏈》](/zh-Hant/blog/evm-compatibility-explained) - 下一篇：[《效能指標詞典：TPS、BPS、確認延遲、最終性、衝突率》](/zh-Hant/blog/performance-metrics-glossary)