并行执行听起来像是「多核一开，吞吐就上去」。对低冲突工作负载，这句话大致成立：互不碰同一状态槽的交易可以被不同执行引擎同时消化，节点的多核利用率会明显抬升。但公链上真正赚钱、真正拥堵的负载，往往不是干净的点对点转账，而是反复读写同一组热账户或热存储槽的合约调用。这时并行度不是由 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 把多核用起来的前提，是工作负载里存在足够多的无冲突交易。热点合约不会因为换了执行引擎就自动消失；它们只会把瓶颈从「单线程解释器」挪到「冲突检测与重执行」。把这个问题讲清楚，比再讲一遍电梯演讲更有用：它决定开发者要不要改存储布局，也决定读者该如何怀疑下一条链的性能海报。