---
id: 20
title: 衝突熱點與工作負載：平行 EVM 何時真的變快
slug: parallel-evm-workload-hotspots
date: 2026/09/13
summary: 平行 EVM 的吞吐量上限很少在轉帳基準裡露餡，卻常在 AMM、借貸與 NFT mint 上被打回原形。本文解釋衝突熱點如何形成、讀寫集粒度如何影響衝突率，以及峰值 TPS 在真實負載下如何退化。
keywords: 平行EVM,衝突熱點,工作負載,讀寫集,AMM,TPS
heroImage: /images/community-bg.png
---

平行執行聽起來像是「多核一開，吞吐量就上去」。對低衝突的工作負載，這句話大致成立：互不碰同一狀態槽的交易可以被不同的執行引擎同時消化，節點的多核利用率會明顯抬升。但公鏈上真正造成壅塞的負載，往往不是乾淨的點對點轉帳，而是反覆讀寫同一組熱帳戶或熱儲存槽的合約呼叫。這時平行度不是由 CPU 核心數決定，而是由**衝突率**決定。

理解這一點，才能正確解讀任何一條「平行 EVM」鏈給出的效能數字：同一套引擎，在不同工作負載下可以差出一個數量級以上。

## 低衝突與高衝突：兩種完全不同的遊戲

低衝突負載的典型形態，是大量互不相關的簡單轉帳、獨立 NFT 持有者之間的轉移，或對不同合約實例的唯讀查詢。這類交易的讀寫集幾乎不相交，樂觀平行可以接近「理想加速比」：N 個引擎大致吃下接近 N 倍的無衝突工作量，再付一小筆排程與版本校驗的固定開銷。

高衝突負載則相反。去中心化交易所的同一交易對、借貸協議的同一利率指數、熱門 NFT 的同一 mint 計數器，都會把大量交易擠進極窄的狀態集合。樂觀執行仍會先平行跑，但驗證階段發現版本衝突後，大量交易需要按串列次序重做。表面上看起來引擎很忙，有效吞吐量卻可能塌回接近單執行緒的水準，外加回滾與重新執行的額外成本。

因此，「平行 EVM 快不快」不是一個布林命題，而是「在什麼樣的衝突分布下快多少」。

## 為什麼 AMM、借貸與 NFT mint 特別傷吞吐量

自動化做市商（AMM）把流動性與價格擠在少量池合約的儲存槽上。同一區塊內的多筆 swap 往往讀寫同一個 `reserve` 或同一個與價格相關的槽位，天生高衝突。即便使用者地址各不相同，**合約端的熱點**已經足以把平行度壓扁。

借貸協議類似：利率指數、全域借款總量、與清算相關的共享參數，會成為跨使用者交易的交匯點。一筆看似「使用者 A 存款」的交易，可能與使用者 B 的借款、使用者 C 的清算讀到同一組全域變數。

NFT mint 則更極端：連續編號、總量計數、白名單位圖，經常是全網使用者在短時間內爭搶同一個寫入點。歷史上以太坊上的鑄造潮之所以把 Gas 拍賣推到荒謬區間，不只是「人多」，而是執行層無法把這些高度相關的寫入拆開平行處理。

## 讀寫集粒度：衝突率的隱形旋鈕

樂觀平行依賴讀寫集來判斷「這兩筆能不能算無衝突」。讀寫集可以粗到帳戶層級，也可以細到儲存槽層級。

- 粒度越粗，誤報衝突越多：兩筆其實碰的是同一合約的不同槽位，卻被當成衝突，白白串列化。
- 粒度越細，分析與版本管理成本越高：依賴圖更碎、中繼資料更龐大，但真正可並行的空間也更大。

工程上常見的取捨，是在帳戶層級的啟發式做法與槽位層級的精確之間找平衡，並在執行前做靜態依賴分析、執行中做版本監看、執行後做狀態根校驗（參見 [《樂觀並行控制（OCC）入門》](/zh-Hant/blog/optimistic-concurrency-control-intro)）。對應用程式開發者而言，含義很具體：把無關狀態拆到不同槽位、減少全域計數器、避免「所有人寫同一個 `totalSupply` 熱路徑」，往往比換一條更快的鏈更能改善自身交易的確認體驗。

## 峰值 TPS 如何在熱點下退化

基準測試喜歡構造可並行的合成負載，因為那樣曲線好看。真實區塊則混雜：一部分轉帳可平行，一部分 DeFi 互動擠在熱點上。有效吞吐量大致受下式約束（示意，非精確公式）：

有效吞吐量 ≈ 無衝突部分的平行收益 + 衝突部分的近串列吞吐量 − 回滾與重新執行的開銷。

當衝突部分佔比升高，後兩項就會主導結果。於是出現一種常見的行銷與工程錯位：宣傳材料引用「理想負載下的峰值 TPS」，而使用者在 mint 日或行情劇烈波動時感受到的，卻是確認變慢、失敗重試變多。正確的披露方式，是同時給出**低衝突與高衝突**兩組口徑，並標明硬體、客戶端版本與交易組成（參見 [《效能指標詞典》](/zh-Hant/blog/performance-metrics-glossary)）。

Bitroot 這類樂觀平行 EVM 鏈選擇正面處理可組合 DeFi，而不是只最佳化轉帳基準，意味著衝突偵測與動態分組的工程品質，會直接決定「宣傳吞吐量」和「使用者可感知吞吐量」之間的缺口有多大。

## 對合約與協議設計的可操作含義

1. **辨識熱點槽**：稽核時把高頻寫入的儲存布局畫出來；全域計數器、單一流動性池、共享配置位是第一嫌疑。
2. **拆分狀態**：能按使用者、按池、按分片隔離的寫入，盡量不要匯聚到同一個槽。
3. **放棄隱含順序假設**：依賴「同一區塊內隱含順序」的合約邏輯，在樂觀平行下更脆弱；應顯式編碼順序假設，或改為對衝突不敏感的設計。
4. **用衝突率解讀基準**：看到 TPS 數字時，先問交易組成；沒有衝突分布的峰值，參考價值有限。

## 收束：平行不是免費午餐

平行 EVM 能把多核用起來的前提，是工作負載裡存在足夠多的無衝突交易。熱點合約不會因為換了執行引擎就自動消失；它們只會把瓶頸從「單執行緒解譯器」挪到「衝突偵測與重新執行」。把這個問題講清楚，比再講一遍電梯簡報更有用：它決定開發者要不要改儲存布局，也決定讀者該如何懷疑下一條鏈的效能海報。

## 延伸閱讀

- 前置閱讀：[《去中心化與效能的張力：驗證者門檻、硬體與地理分布》](/zh-Hant/blog/decentralization-performance-tradeoff)
- 相關：[《平行執行的三條路線：確定性、樂觀與物件模型》](/zh-Hant/blog/parallel-execution-approaches)
- 相關：[《樂觀並行控制（OCC）入門：資料庫視角看區塊鏈執行》](/zh-Hant/blog/optimistic-concurrency-control-intro)
- 相關：[《效能指標詞典：TPS、BPS、確認延遲、最終性、衝突率》](/zh-Hant/blog/performance-metrics-glossary)