平行執行聽起來像是「多核一開，吞吐量就上去」。對低衝突的工作負載，這句話大致成立：互不碰同一狀態槽的交易可以被不同的執行引擎同時消化，節點的多核利用率會明顯抬升。但公鏈上真正造成壅塞的負載，往往不是乾淨的點對點轉帳，而是反覆讀寫同一組熱帳戶或熱儲存槽的合約呼叫。這時平行度不是由 CPU 核心數決定，而是由衝突率決定。
理解這一點，才能正確解讀任何一條「平行 EVM」鏈給出的效能數字：同一套引擎，在不同工作負載下可以差出一個數量級以上。
低衝突與高衝突：兩種完全不同的遊戲
低衝突負載的典型形態，是大量互不相關的簡單轉帳、獨立 NFT 持有者之間的轉移，或對不同合約實例的唯讀查詢。這類交易的讀寫集幾乎不相交，樂觀平行可以接近「理想加速比」：N 個引擎大致吃下接近 N 倍的無衝突工作量，再付一小筆排程與版本校驗的固定開銷。
高衝突負載則相反。去中心化交易所的同一交易對、借貸協議的同一利率指數、熱門 NFT 的同一 mint 計數器，都會把大量交易擠進極窄的狀態集合。樂觀執行仍會先平行跑，但驗證階段發現版本衝突後，大量交易需要按串列次序重做。表面上看起來引擎很忙，有效吞吐量卻可能塌回接近單執行緒的水準，外加回滾與重新執行的額外成本。
因此，「平行 EVM 快不快」不是一個布林命題，而是「在什麼樣的衝突分布下快多少」。
為什麼 AMM、借貸與 NFT mint 特別傷吞吐量
自動化做市商（AMM）把流動性與價格擠在少量池合約的儲存槽上。同一區塊內的多筆 swap 往往讀寫同一個 reserve 或同一個與價格相關的槽位，天生高衝突。即便使用者地址各不相同，合約端的熱點已經足以把平行度壓扁。
借貸協議類似：利率指數、全域借款總量、與清算相關的共享參數，會成為跨使用者交易的交匯點。一筆看似「使用者 A 存款」的交易，可能與使用者 B 的借款、使用者 C 的清算讀到同一組全域變數。
NFT mint 則更極端：連續編號、總量計數、白名單位圖，經常是全網使用者在短時間內爭搶同一個寫入點。歷史上以太坊上的鑄造潮之所以把 Gas 拍賣推到荒謬區間，不只是「人多」，而是執行層無法把這些高度相關的寫入拆開平行處理。
讀寫集粒度：衝突率的隱形旋鈕
樂觀平行依賴讀寫集來判斷「這兩筆能不能算無衝突」。讀寫集可以粗到帳戶層級，也可以細到儲存槽層級。
- 粒度越粗，誤報衝突越多：兩筆其實碰的是同一合約的不同槽位，卻被當成衝突，白白串列化。
- 粒度越細，分析與版本管理成本越高：依賴圖更碎、中繼資料更龐大，但真正可並行的空間也更大。
工程上常見的取捨，是在帳戶層級的啟發式做法與槽位層級的精確之間找平衡，並在執行前做靜態依賴分析、執行中做版本監看、執行後做狀態根校驗（參見 《樂觀並行控制（OCC）入門》）。對應用程式開發者而言，含義很具體：把無關狀態拆到不同槽位、減少全域計數器、避免「所有人寫同一個 totalSupply 熱路徑」，往往比換一條更快的鏈更能改善自身交易的確認體驗。
峰值 TPS 如何在熱點下退化
基準測試喜歡構造可並行的合成負載，因為那樣曲線好看。真實區塊則混雜：一部分轉帳可平行，一部分 DeFi 互動擠在熱點上。有效吞吐量大致受下式約束（示意，非精確公式）：
有效吞吐量 ≈ 無衝突部分的平行收益 + 衝突部分的近串列吞吐量 − 回滾與重新執行的開銷。
當衝突部分佔比升高，後兩項就會主導結果。於是出現一種常見的行銷與工程錯位：宣傳材料引用「理想負載下的峰值 TPS」，而使用者在 mint 日或行情劇烈波動時感受到的，卻是確認變慢、失敗重試變多。正確的披露方式，是同時給出低衝突與高衝突兩組口徑，並標明硬體、客戶端版本與交易組成（參見 《效能指標詞典》）。
Bitroot 這類樂觀平行 EVM 鏈選擇正面處理可組合 DeFi，而不是只最佳化轉帳基準，意味著衝突偵測與動態分組的工程品質，會直接決定「宣傳吞吐量」和「使用者可感知吞吐量」之間的缺口有多大。
對合約與協議設計的可操作含義
- 辨識熱點槽：稽核時把高頻寫入的儲存布局畫出來；全域計數器、單一流動性池、共享配置位是第一嫌疑。
- 拆分狀態：能按使用者、按池、按分片隔離的寫入，盡量不要匯聚到同一個槽。
- 放棄隱含順序假設：依賴「同一區塊內隱含順序」的合約邏輯，在樂觀平行下更脆弱；應顯式編碼順序假設，或改為對衝突不敏感的設計。
- 用衝突率解讀基準：看到 TPS 數字時，先問交易組成；沒有衝突分布的峰值，參考價值有限。
收束：平行不是免費午餐
平行 EVM 能把多核用起來的前提，是工作負載裡存在足夠多的無衝突交易。熱點合約不會因為換了執行引擎就自動消失；它們只會把瓶頸從「單執行緒解譯器」挪到「衝突偵測與重新執行」。把這個問題講清楚，比再講一遍電梯簡報更有用：它決定開發者要不要改儲存布局，也決定讀者該如何懷疑下一條鏈的效能海報。