高性能公链最常见的失败沟通方式，是一张 TPS 海报。真正有用的是回答三件事：交易顺序谁定、状态转换怎么并行、状态规模怎么长。本文是 Bitroot 并行 EVM 的架构导览——偏地图，不偏参数竞赛。更细的机制分别在 Pipeline BFT、多引擎与乐观并行专文中展开；理论背景指向系列中的 OCC 与扩容地图，避免在此重复长文。
问题从哪里来
经典 EVM 按区块内顺序一笔笔执行，正确性好懂，吞吐受单核与串行语义约束。扩容地图上，并行执行只是选项之一，还要和 Rollup、分片等路线对照，见 《区块链扩容地图》 与 《EVM 单线程瓶颈》。Bitroot 的选择是：在完整 EVM 兼容前提下走乐观并行，并把共识与执行解耦，而不是要求开发者预声明账户列表。
三层协同，而不是三块贴纸
| 层级 | 机制要点 | 解决什么 |
|---|---|---|
| 共识 | Pipeline BFT、VRF 领导轮换、BLS12-381 签名聚合 | 阶段串行与近似 O(n²) 消息/验签开销 |
| 执行 | 乐观并行、动态分组、三阶段冲突检测 | 单线程执行上限与冲突后的重执行范围 |
| 状态 | 账户/槽位分片、分层缓存、大对象链下存哈希上链 | 单树容量与全节点存储压力 |
共识层负责尽快就交易顺序达成一致；执行层在已排序的批次上尽量并行推进状态转换；状态层避免「执行并行了，磁盘和内存却是单点」。三者缺一，海报上的数字很难在真实负载里站稳。产品坐标说明见 《Bitroot 定位》。
Pipeline BFT：让不同高度重叠推进
传统 BFT 往往等一个区块走完提议→投票→提交，才开下一个高度。Pipeline BFT 把阶段流水线化：高度 N 在预提交时，N+1 可以在预投票，N+2 可以开始提议。领导者用 VRF 轮换，降低可预测操纵；BLS 聚合把多验证者签名压成接近常数级验证成本，使扩大验证者集合时共识开销不至于线性失控。细节与「为何要和解耦执行一起看」见 《Pipeline BFT 与执行解耦》。
解耦的含义很具体：共识不必等本块全部执行完才推进下一高度的排序工作。执行可以在后台追赶。代价是工程上要严格保证：无论并行度如何，最终状态必须与「按共识顺序串行执行」一致——这是区块链 OCC 相对数据库 OCC 多出来的硬约束，背景见 《OCC 入门》。
乐观并行：兼容 EVM，复杂度留在运行时
确定性并行（如显式账户列表）和对象模型在理论并行度上常有优势，但迁移成本高。乐观路线假设多数交易无冲突，先并行再检测；冲突则选择性重执行。Bitroot 强调执行前依赖分析、执行中版本监控、执行后状态根校验的分层检测，目的是更早发现冲突、缩小回滚面。机制深挖见 《乐观并行化机制》；与行业三条路线的对照见 《并行执行的三条路线》。
多引擎调度、分片内并行与跨分片通信，属于执行与状态的工程展开，见 《多引擎并行执行设计》。热点负载何时吃掉并行红利，见 《并行 EVM 工作负载热点》。
对 AI Agent 与任务结算合约而言，这层提供的是可规划的确认与吞吐预期；训练本身通常不在共识热路径，见 《去中心化 AI 堆栈》。
如何读性能数字（含免责）
公开材料与测试网口径中，曾出现过约数百毫秒级确认、单分片数千至数万 TPS、多分片扩展等表述；不同批次依赖硬件、交易类型与冲突率，数字不可直接横向对比，更不能外推为「主网保证」或任何财务收益预期。读指标时建议同时看延迟分布、冲突率与可验证重放成本，术语见 《性能指标术语表》。去中心化与性能的张力见 《去中心化与性能的权衡》。EVM 兼容边界见 《EVM 兼容意味着什么》。
存储与网络别被海报省略
执行再快也要把状态落到存储、把投票传到网上。大对象宜链下存、链上哈希；流水线越深，对尾部延迟越敏感。真实负载里，热点缓存命中率与跨分片排队，往往比纯执行内核更早成为体感问题。读者定位见 《谁该读并行 EVM》。
兼容性选择的代价也要写进同一张表：保留字节码级 EVM 意味着无法要求交易预声明完整读写集，并行度上限更多由运行时冲突行为决定。这与对象模型链「用编程范式换并行」的取舍相反，详见 《并行执行的三条路线》 与 《EVM 兼容意味着什么》。对迁移团队，优先验证的是：现有合约在热点轨迹下的冲突率与 p95 延迟，而不是海报上的理论峰值。
验证者视角：重放成本才是去中心化预算
吞吐海报常忽略验证者重放成本。乐观并行若产生大量投机路径与重执行，全节点 CPU 与带宽会被推高，最终表现为验证者门槛上升——这正是去中心化与性能张力的执行侧版本。设计上应追求：并行加速的同时，诚实节点仍能以可接受成本完成确定性重放并核对状态根。
因此评估 Bitroot 或同类方案时，除了看领导者出块延迟，还应问：普通全节点同步与验证的资源曲线如何；状态增长与分片后的快照/剪枝策略是什么。相关讨论见 《去中心化与性能的权衡》。谁该读这些材料的路径见 《谁该读并行 EVM》。
状态增长与大对象策略为何算架构问题
执行并行解决 CPU 宽度后，历史状态与大对象（长 calldata、元数据、证明附件）会变成磁盘与同步瓶颈。把大对象放链下、链上存哈希，是常见策略，但必须配套：可用性假设、挑战期、以及轻节点如何验证。否则「并行很快」只存在于空状态基准测试。
分片则引入跨分片延迟与原子性语义，应用开发者需要新的心智模型。这些内容在多引擎专文展开，见 《多引擎并行执行设计》；扩容地图中的位置见 《区块链扩容地图》。
架构概览的结论可以收束为一句：并行 EVM 是共识、执行与状态三层的协同系统；优化任何单层而不测量另外两层，都会在真实负载里暴露。后续请按需进入专文，而不是在概览里寻找全部参数。
阅读本概览时请带着的三个问题
交易顺序在拥塞时是否仍可预期？冲突升高时吞吐如何退化而不是突然归零？全节点重放成本是否仍允许足够分散的验证者集合？三个问题都能在测试网材料里找到带条件的答案，架构叙事才站得住；否则仍只是模块名清单。专文与术语表是查证入口，概览只负责把问题放对地方。
小结
Bitroot 并行 EVM 的骨架是：流水线共识定序、乐观并行做状态转换、分片管状态规模，并用 EVM 兼容降低迁移摩擦。架构概览到此为止；需要某一层细节时，请转到对应专文，而不是指望一篇文章同时讲完共识证明与调度器伪代码。