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