「并行 EVM」四个字，对不同读者意味着完全不同的问题。Solidity 开发者首先担心自己的合约会不会静默改变行为；客户端与协议工程师关心调度器、冲突检测与状态树如何吃满多核；研究员则追问乐观并行有没有可核查的正确性边界，还是营销话术裹着一层数据库术语。三种关切都合理，混在一起讨论，却很容易变成谁也说不透的泛泛而谈。
因此有必要先分读者，不是制造门槛，而是承认并行执行横跨应用层、系统层与理论层：一篇试图同时讨好三类人的文章，往往三类都讲不深。前文 《EVM 兼容意味着什么》 说明了兼容性的工程含义；本文把「接下来读什么」收成三条可执行路径，且只链接本站已经发布的文章，不指向尚未存在的虚构篇目，也不使用「系列某字母第 N 篇」这类无法打开的引用。
路径一：合约开发者——行为会不会变，代码要不要改
对合约作者，并行改变的不是 Solidity 语法，而是执行时的冲突与重试体验。单线程 EVM 下，区块内交易按顺序解释，最终状态与顺序一一对应；乐观并行下，同一批次可能先并发预执行，再在验证阶段决定接受或回滚重跑。对低频、低共享状态的合约，过程通常透明；对 AMM、借贷、NFT mint 等反复读写同一组存储槽的合约，冲突率上升会表现为确认变慢、失败重试变多，以及某些依赖「同块隐式顺序」的逻辑更脆弱。
建议阅读顺序：
- 《EVM 兼容意味着什么》 — 先确认迁移时字节码、预编译、JSON-RPC 与工具链哪些必须对齐。
- 《乐观并发控制（OCC）入门》 — 建立「先执行、再验证、冲突则重做」的直觉，理解为何最终状态仍应对齐某个串行次序。
- 《冲突热点与工作负载》 — 看清 AMM / 借贷 / mint 为何特别伤吞吐，以及存储布局如何影响冲突率。
- 可选加深：《Bitroot 并行化 EVM 技术解析》、《多引擎并行执行设计》 — 了解生产向引擎如何组织分组与冲突检测，仍不必一开始就啃完所有系统细节。
可操作结论：先审计热点槽与全局计数器；能按用户或按池拆分的状态尽量拆分；不要把「同块内别人先执行」写成隐式不变量。多数合约无需为并行重写业务逻辑，但高冲突合约几乎肯定要从存储与交互设计上「对冲突不敏感」。若你的工作主要是把现有 Solidity 仓库迁到新链，兼容性四层验收往往比阅读执行引擎源码更能降低上线风险。
迁移排期上也可以更务实：第一周只做 Foundry fork 与预编译差分；第二周用生产类似负载做冲突感知压测；第三周再决定要不要改存储布局。把「读文章」嵌进排期，比一次性吞下全部并行理论更不容易半途而废。与工具链相关的细节仍以兼容性一文为准，与热点相关的细节以冲突热点一文为准，不必在开发者路径里重复啃共识层长文。
路径二：客户端 / 协议工程师——调度、状态与共识如何协同
这类读者已经熟悉节点实现，关心的问题更硬：依赖图怎么建、读写集粒度选账户还是槽、引擎池如何扩缩、冲突重执行如何避免活锁、共识出块与执行流水线如何解耦才不互相堵。单线程瓶颈的历史背景见 《EVM 单线程瓶颈》；路线分野见 《并行执行的三条路线》。
建议阅读顺序：
- 《EVM 单线程瓶颈》 — 明确「慢」慢在解释器串行，而不只是共识间隔。
- 《区块链扩容地图》 — 把并行执行放回 Rollup、分片、模块化等更大坐标，避免把执行层优化误当成整条扩容答案。
- 《并行执行的三条路线》 与 《OCC 入门》 — 弄清确定性声明、对象模型与乐观路径各自把复杂度放在哪一侧。
- 《Pipeline BFT 与多引擎协同》、《多引擎并行执行设计》 — 对照一套具体的共识—执行解耦与多引擎设计，看工程取舍如何落地。
- 读性能数字前：《性能指标词典》；评估硬件与集合规模时：《去中心化与性能的张力》。
- 用真实负载校准预期：《冲突热点与工作负载》。
可操作结论：把「吞吐」拆成调度效率、冲突重执行成本、状态读写放大、共识消息开销四段分别测量；任何只报理想负载峰值、不报冲突分布与硬件口径的基准，对客户端优化的参考价值都有限。实现时优先把冲突定义、重执行策略与可观测指标做成可配置、可导出的接口，否则线上只能看见「变慢了」而看不见「为什么变慢」。
调试顺序上建议固定：先确认区块内串行等价是否被破坏（正确性问题），再看冲突率与重执行队列（性能问题），最后才调 NUMA、绑核与缓存参数（效率问题）。把三类问题搅在一起，容易用微优化掩盖协议级回归。若你维护的是验证者客户端而非应用合约，去中心化一文里的硬件与地理维度，决定了你的性能补丁能不能被足够多的独立运营者跑起来。
路径三：研究员——正确性边界、模型比较与可证伪声明
研究员通常不需要另一份产品简介，而需要可证伪的问题：乐观并行的提交结果是否串行化等价于区块顺序？读写集近似（账户级 vs 槽级）如何影响安全性与性能？在何种冲突图下加速比退化到接近 1？与 Block-STM 类方案、确定性并行、对象模型相比，假设分别是什么？
建议阅读顺序：
- 《并行执行的三条路线》 — 先固定比较坐标系，再进入单一项目的实现细节。
- 《OCC 入门》 — 把区块链执行层映射回经典数据库并发控制词汇（读写集、验证、重执行）。
- 《冲突热点与工作负载》 — 用真实合约形态构造冲突图直觉，而不是只在转账基准上讨论加速比。
- 《性能指标词典》 — 统一 TPS / 延迟 / 最终性 / 冲突率口径，避免论文式数字与营销式数字混谈。
- 《去中心化与性能的张力》 — 把「更快」放回验证者门槛、地理与客户端多样性等可观测维度。
- 系统背景可选：《区块链扩容地图》、《Bitroot 定位》、《Pipeline BFT 与多引擎协同》。
可操作结论：要求任何性能或正确性声明附带工作负载描述、冲突定义、失败与重执行策略；没有这些附件的「并行 EVM 更快」，研究价值接近零。把声明写成可复现实验设计（硬件、客户端、交易生成器、冲突注入方式），比争论形容词更接近学术与工程共同语言。
比较不同项目的公开材料时，先用三条路线一文统一坐标系，再用指标词典统一口径，最后才看某一实现是否声称更接近 Block-STM、确定性调度或对象模型。缺少前两步的「横向对比」，往往会变成把营销峰值直接相减。研究者路径与合约开发者路径可以共享冲突热点一文，但关注点不同：前者要冲突图与加速比曲线，后者要可改的存储布局建议。
对照表：按角色跳转
| 读者画像 | 最关心的问题 | 优先阅读（均为已发布文章） |
|---|---|---|
| 合约开发者 | 行为会否变化、存储如何避热点 | 兼容性说明 → OCC 入门 → 冲突热点；可选 Bitroot 执行层两篇 |
| 客户端 / 协议工程师 | 调度、状态、共识如何实现与测量 | 单线程瓶颈 → 扩容地图 → 三条路线 / OCC → Pipeline BFT / 多引擎 → 指标词典与去中心化张力 → 冲突热点 |
| 研究员 | 正确性边界、模型比较、口径是否可证伪 | 三条路线 → OCC → 冲突热点 → 指标词典 → 去中心化张力；可选定位与 Pipeline BFT |
若只想建立公共底座，可按站点阅读链顺序前进：定位 → 兼容性 → 本文 → 指标词典 → 去中心化张力 → 冲突热点。三条角色路径是在这条主链上的「岔路」，不是另一套无法打开的目录。读完公共底座后，再按上表深潜，通常比从头通读所有技术长文更省时间。
迁移排期上也可以更务实：第一周只做 Foundry fork 与预编译差分；第二周用生产类似负载做冲突感知压测；第三周再决定要不要改存储布局。客户端工程师则建议先确认串行等价未被破坏，再看冲突率与重执行队列，最后才调微架构参数。把正确性、性能与效率三类问题分开处理，比一次性通读全部长文更不容易半途而废。
三条路径可以并行推进，但共享底座仍建议按阅读链顺序走完：定位、兼容性、本文、指标词典、去中心化张力、冲突热点。底座未齐时深潜单一角色材料，容易缺乏共同词汇。