---
id: 17
title: 谁该读并行 EVM：合约开发、客户端工程、研究员三条路径
slug: who-should-read-parallel-evm
date: 2026/09/06
summary: 合约开发者、客户端工程师、研究员关心并行EVM的角度完全不同，本文提供三条阅读路径，帮不同背景的读者迅速定位自己该读的部分。
keywords: 并行EVM,合约开发,客户端工程,区块链研究,阅读指南
heroImage: /images/community-bg.png
---

并行 EVM 这个话题最近两年迅速升温，但它对不同的人意味着完全不同的问题。一名 Solidity 开发者读到"并行执行"四个字，第一反应往往是自己写的合约会不会出错；一名协议工程师关心的是调度器和冲突检测怎么实现才能吃满多核；一名研究员则想知道，所谓的乐观并行到底有没有严谨的正确性证明，还是营销话术裹着一层数据库理论的外衣。这三种关切都合理，但混在一起讨论，很容易变成谁也说不清楚的泛泛而谈。

这也是为什么在展开一百篇关于并行 EVM 的系列之前，有必要先把读者分开。不是为了制造门槛，而是因为并行执行本身就是一个跨越应用层、系统层和理论层的话题，任何一篇试图同时讨好三类读者的文章，最后大概率谁都讲不透。

## 合约开发者：你的代码会不会变

以太坊生态的合约开发者群体规模远超外界的直观印象。根据 Electric Capital 发布的年度开发者报告，以太坊生态目前拥有 31,869 名总活跃开发者，是排名第二的 Solana（17,708 名）的近两倍；仅 2025 年前九个月，以太坊就新增了 16,181 名开发者，增速在所有公链中排名第一。另一项反映网络效应的数据同样能说明问题：在跨链开发的工程师中，有 74% 会接触 EVM 兼容链，这意味着任何声称"EVM 兼容"的新链，天然对接的是一个数量级最大、迁移成本理论上最低的开发者池。

但兼容不等于无感。对合约开发者而言，并行执行改变的不是 Solidity 语法，而是执行时的行为语义。一笔转账在单线程 EVM 下，执行顺序和最终状态是完全确定的；放到乐观并行环境里，同一批次内的交易可能被并发预执行，再在验证阶段决定谁的结果被采纳、谁被回滚重跑。对大多数低频交互的合约，这个过程完全透明；但对 AMM、借贷协议、NFT mint 这类高频读写同一存储槽的合约，冲突率会显著上升，进而影响 Gas 计量方式与失败重试后的用户感知延迟，甚至波及某些依赖交易间隐式顺序假设的合约逻辑。这些内容会在系列 B（读写集与冲突检测）和系列 C（多引擎执行架构）里逐篇拆解，尤其是第 25、26 篇关于热点合约与低冲突负载的对照分析，以及第 96 篇的开发者迁移指南，会直接回答"我的代码要不要改"。

## 客户端与协议工程师：调度器、锁与状态树怎么落地

如果说合约开发者关心的是"结果会不会变"，协议工程师关心的就是"这套机制怎么造出来"。这是一个高度工程化的问题域：交易依赖图怎么构建，批次怎么切分，细粒度锁加在账户级还是存储槽级，死锁怎么检测，NUMA 架构下怎么绑核才能避免跨 socket 通信拖慢整体吞吐。

这类话题在协议工程社区的讨论热度，从公开渠道就能观察到。以太坊研究社区 Ethereum Magicians 上，围绕执行层并行化的提案持续出现，例如聚焦"帧交易"（Frame Transaction，EIP-8141）的提案明确提出，依赖关系可以并行处理：当访问的状态被静态声明时由内存池层推理状态相关依赖，纯计算依赖则在内存池层统一处理一次。更早之前，Vitalik Buterin 也在该论坛提出了一个多阶段方案，探讨用 RISC-V 替代 EVM 以简化执行层并提升证明效率，这类讨论虽然出发点是零知识证明而非并行执行，但同样指向执行层架构正在被重新审视这一大趋势。这说明并行执行不是某个新兴项目的孤立主张，而是整个以太坊工程共同体正在认真对待的方向。

对这类读者，系列 C（多引擎执行架构，第 29 至 48 篇）是主战场，内容覆盖执行流水线分层、引擎池扩缩容、共享状态锁排序、内存模型与缓存一致性、NUMA 绑核等具体工程决策；系列 D（状态、存储与分片，第 49 至 64 篇）则进一步深入到状态树并发写入、分片模型选型、跨分片消息传递这些更底层的存储与网络问题。这两个系列的文章会大量出现具体的数据结构选择和权衡分析，而不是停留在"我们做了并行"这个层面。

## 研究员：模型的边界在哪里

第三类读者的问题更抽象，但也更容易戳破营销话术里的漏洞：一个声称"乐观并行"的系统，到底满足哪种正确性定义，冲突可串行化还是视图可串行化？它的证明是形式化的，还是"跑得通就算数"？

这方面的学术产出正在变得密集。Aptos 团队关于 Block-STM 的论文发表于 ACM SIGPLAN PPoPP 2023，论文显示该引擎在 Diem 基准测试下达到约 11 万 TPS，在 Aptos 基准测试下达到约 17 万 TPS，相较 32 线程下的串行基线分别提升约 20 倍和 17 倍；其核心创新在于用多版本数据结构规避写写冲突，并且验证过程并非相互独立，而是必须按预设顺序逻辑推进，一笔交易验证失败，意味着所有排在它之后的交易只有在后续重新验证通过后才能被提交。这类细节正是研究员真正关心的部分：不是吞吐数字本身，而是数字背后的调度算法能否被证明保持了与某种串行执行等价的正确性。

近两年学术界围绕这个方向的产出还在加速。2025 年 AFT（Advances in Financial Technologies）会议收录了关于区块链交易高效并行执行的研究，同年也出现了如 NEMO 这样针对高竞争工作负载优化并行执行的新方案，以及聚焦操作级并发的 ParallelEVM 研究成果发表于 EuroSys 2025。这说明"乐观并行 EVM 是否正确、多正确、边界在哪里"已经形成了一个持续产出论文的学术子领域，而不是几家公链项目各说各话的宣传战场。系列 B 中第 22、23 篇关于串行化等价与正确性证明草图，以及系列 G 的安全审计清单，是为这类读者准备的入口。

## 三条路径，一张地图

三类读者的问题不同，但共享同一套底层机制，这也是为什么值得用一个系列把它们串起来，而不是拆成互不相关的三份文档。下表是一个粗略的对照，方便按需跳转：

| 读者画像 | 最关心的问题 | 系列入口 |
|---|---|---|
| 合约开发者 | 我的合约行为会不会变，要不要改代码 | 系列 B（12–28）、第 96–98 篇 |
| 客户端/协议工程师 | 调度、锁、状态树怎么实现，性能瓶颈在哪 | 系列 C（29–48）、系列 D（49–64） |
| 研究员 | 正确性边界在哪，和 Block-STM 等模型如何比较 | 系列 B 中 22–23 篇、系列 G（89–94） |

如果只想快速建立整体认知，系列 A 本身（第 1 至 10 篇）已经覆盖了问题定义、扩容全景图、三条并行路线的取舍，以及统一的性能指标口径，读完这十篇基本能判断自己下一步该扎进哪个系列。系列 E（共识与执行协同）和系列 F（横向对比与基准）则是三类读者都会用到的公共知识：前者关系到并行执行和共识层怎么配合才不互相拖累，后者提供了判断任何"TPS 数字"是否可信的方法论。

并行 EVM 不是一个单一答案的技术，而是一组需要在开发者体验、工程复杂度和理论正确性之间做权衡的设计空间。接下来的文章会按照这三条路径逐步展开，不追求每篇都面面俱到，但求每篇都对得上号。

## 延伸阅读

- 前置阅读：[《EVM 兼容意味着什么：字节码、预编译与工具链》](/zh/blog/evm-compatibility-explained)
- 下一篇：[《性能指标词典：TPS、BPS、确认延迟、最终性、冲突率》](/zh/blog/performance-metrics-glossary)