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