---
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/blog/optimistic-concurrency-control-intro)）。对应用开发者而言，含义很具体：把无关状态拆到不同槽位、减少全局计数器、避免「所有人写同一个 `totalSupply` 热路径」，往往比换一条更快的链更能改善自身交易的确认体验。

## 峰值 TPS 如何在热点下退化

基准测试喜欢构造可并行的合成负载，因为那样曲线好看。真实区块则混杂：一部分转账可并行，一部分 DeFi 交互挤在热点上。有效吞吐大致受下式约束（示意，非精确公式）：

有效吞吐 ≈ 无冲突部分的并行收益 + 冲突部分的近串行吞吐 − 回滚与重执行开销。

当冲突部分占比升高，后两项主导结果。于是出现一种常见的营销与工程错位：宣传材料引用「理想负载下的峰值 TPS」，而用户在 mint 日或行情剧烈波动时感受到的是确认变慢、失败重试变多。正确的披露方式，是同时给出**低冲突与高冲突**两组口径，并标明硬件、客户端版本与交易构成（参见 [《性能指标词典》](/zh/blog/performance-metrics-glossary)）。

Bitroot 一类乐观并行 EVM 链选择正面处理可组合 DeFi，而不是只优化转账基准，意味着冲突检测与动态分组的工程质量，会直接决定「宣传吞吐」和「用户可感知吞吐」之间的缺口有多大。

## 对合约与协议设计的可操作含义

1. **识别热点槽**：审计时把高频写入的存储布局画出来；全局计数器、单一流动性池、共享配置位是第一嫌疑。
2. **拆分状态**：能按用户、按池、按分片隔离的写入，尽量不要汇聚到同一槽。
3. **接受语义约束**：依赖「同一区块内隐式顺序」的合约逻辑，在乐观并行下更脆弱；应显式编码顺序假设，或改为对冲突不敏感的设计。
4. **用冲突率解读基准**：看到 TPS 数字时，先问交易构成；没有冲突分布的峰值，参考价值有限。

## 收束：并行不是免费午餐

并行 EVM 把多核用起来的前提，是工作负载里存在足够多的无冲突交易。热点合约不会因为换了执行引擎就自动消失；它们只会把瓶颈从「单线程解释器」挪到「冲突检测与重执行」。把这个问题讲清楚，比再讲一遍电梯演讲更有用：它决定开发者要不要改存储布局，也决定读者该如何怀疑下一条链的性能海报。

## 延伸阅读

- 前置阅读：[《去中心化与性能的张力：验证者门槛、硬件与地理分布》](/zh/blog/decentralization-performance-tradeoff)
- 相关：[《并行执行的三条路线：确定性、乐观与对象模型》](/zh/blog/parallel-execution-approaches)
- 相关：[《乐观并发控制（OCC）入门：数据库视角看区块链执行》](/zh/blog/optimistic-concurrency-control-intro)
- 相关：[《性能指标词典：TPS、BPS、确认延迟、最终性、冲突率》](/zh/blog/performance-metrics-glossary)