Bitroot 定位：乐观并行 EVM 的高性能 Layer 1

一条公链如果只会讲吞吐量的故事，很快就会被下一条讲更大数字的公链盖过去。真正决定一条链能走多远的，是它选择站在生态位的哪个位置，以及这个位置是否经得起真实负载的检验。前几篇文章已经把地基打好：单线程 EVM 的天花板在哪里，扩容路线图上并行执行和 Rollup、分片各自解决什么问题，确定性、乐观、对象模型这三条并行路线的取舍逻辑是什么，乐观并发控制作为一种数据库世界验证过几十年的方法，又是如何被搬进区块链执行层的。到这一篇，该把这些分析框架收拢到一个具体项目上：Bitroot 在这张地图里选了哪个坐标，为什么是这个坐标。

一句话说清楚 Bitroot 是什么

Bitroot 是一条乐观并行 EVM 的高性能 Layer 1，目标场景是支付结算、可组合 DeFi 与大规模链上协作。这句话里每个词都有取舍含义。选择做 Layer 1 而不是 Rollup，意味着放弃了继承以太坊安全性的捷径，要自己搭建共识和验证者体系；选择乐观并行而不是确定性并行，意味着把依赖分析的负担从开发者转移到运行时系统；选择完整 EVM 兼容而不是设计新的对象模型或账户模型，意味着牺牲了一部分理论上的并行度上限，换取现有以太坊合约和工具链的直接迁移能力。

这种取舍在行业里并不孤单。同样走乐观并行加 EVM 兼容路线的项目里，Monad 的定位是让熟悉以太坊工具链的开发者获得接近 Solana 的速度体验，其架构包含共识与执行解耦的 MonadBFT、延迟执行以及自研的 MonadDb 数据库；Sei 在 2026 年的规划中明确要把自己变成纯 EVM 链，并把叙事从交易专用链转向面向自动化金融行为体的结算层，强调的是亚秒级最终性与两年多打磨过的并行 EVM。这两个案例说明一件事：高性能 L1 这个赛道，单纯比拼 TPS 数字的窗口正在关闭，真正被反复提及的关键词变成了结算层。Bitroot 选择的坐标与这个方向一致，但技术路径上有自己的组合方式。

技术组合：三块拼图缺一不可

Bitroot 的架构不是单点技术的堆砌，而是共识、执行、状态三层协同设计的结果，这与只优化其中单一层级的方案有本质区别。

共识层用的是 Pipeline BFT。传统 BFT 类共识按提议、预投票、预提交、提交四个阶段严格串行推进，一个区块的确认要等上一个区块完全走完全部阶段，验证者之间的消息复杂度还会随节点数量近似平方级增长。Pipeline BFT 把这四个阶段做成流水线，不同区块高度的阶段可以重叠推进，同时用 VRF 轮换出块领导者降低单点风险，用 BLS12-381 签名聚合把验证者签名合并成近乎常数级的验证开销。这套设计的直接后果是，扩大验证者集合不再意味着共识层的通信成本线性甚至平方级上升，这对后面要谈的去中心化和性能张力（参见第 9 篇）是关键支撑。

执行层是乐观并行 EVM 引擎，核心是动态交易分组加三阶段冲突检测。区块内的交易先按读写集构建依赖关系，尽量把无冲突交易分进同一批次并行执行，冲突检测则拆成执行前的静态依赖分析、执行中的版本冲突监控、执行后的状态根一致性校验三个阶段，而不是像早期朴素 OCC 那样只在执行结束后统一验证。这种分层检测的好处在系列 B 会展开讲，简单说就是能更早发现冲突、缩小重执行的代价范围，而不是一冲突就整批推倒重来。

状态层是分片。账户或存储槽按规则分区，分片内部并行执行、分片之间走明确的跨分片通信协议，热点数据靠分层缓存降低读延迟，体积较大的对象则链下存储、哈希上链，减轻全节点的存储压力。分片解决的是执行层并行化之后依然存在的另一重瓶颈：单机内存和单一状态树的容量上限。

三层之间的关系是解耦而不是拆分。共识层负责快速确定交易顺序，执行层在后台并行推进真正的状态转换，这样就不用等一个区块的所有交易都跑完才能开始下一个区块的共识，避免了"排队等执行"这种串行浪费。这也是为什么理解 Bitroot 不能只看执行引擎或只看共识协议，三者的协同设计才是完整的答案。

为什么不选对象模型，也不放弃 EVM 兼容

系列 A 第 3 篇梳理过，并行执行的设计空间大体分成三条路线：以 Solana Sealevel 为代表的确定性声明式模型，以 Sui 为代表的对象模型，以及乐观并发控制。Bitroot 落在第三条路上，而且坚持完整的字节码级 EVM 兼容，这背后是一个关于开发者生态成本的判断。

对象模型和声明式账户模型在理论并行度上限上确实更高，因为依赖关系在交易发起时就被显式声明或天然隔离，系统不需要靠猜测和事后验证。但代价是开发者必须用新的编程范式重新思考应用结构：Sui 用 Move 语言把资产建模成拥有对象和共享对象，Solana 要求交易提前声明将要读写的全部账户。这些设计对原生构建的新应用友好，对存量以太坊合约几乎不具备迁移路径，意味着一个项目要把自己的 DeFi 协议或 NFT 市场搬过去，基本等于重写。

而以太坊生态经过近十年积累的合约、审计工具、开发框架和用户习惯，是任何新链都难以复制的资产。Bitroot 的判断是，与其让开发者为了并行度上限而重写代码，不如把复杂度留在协议内部：通过更精细的冲突检测和动态分组，在保持 Solidity、Foundry、Hardhat 这套工具链原样可用的前提下，尽量逼近并行执行应有的吞吐水平。这与 Monad 团队公开表达的思路一致，即用软件工程手段让 EVM 本身跑得更快，而不是绕开 EVM 去设计新的执行环境。这是一种典型的把复杂度放在运行时而非开发时的选择，系列 A 第 4 篇讨论 OCC 时已经点出过这个权衡的本质。

结算层心智：比吞吐量更重要的定位

如果只看数字，乐观并行 EVM 赛道里已经有不止一个项目在喊高 TPS。真正拉开差距的，是这些吞吐能力最终服务于什么场景。Bitroot 把自己定位为支付结算、可组合 DeFi 与大规模链上协作的基础设施，而不是又一条靠代币叙事驱动的公链，这个定位选择决定了它在协议设计上会优先保证什么。

支付和结算场景对确认延迟和最终性的确定性要求，远高于对峰值 TPS 数字的要求。一条链哪怕理论峰值再高，如果确认延迟波动大、在高负载下容易出现执行拥堵，就无法承接真实商户结算或高频清算这类场景。这也是为什么 Bitroot 的架构里，共识与执行解耦、Pipeline 化真正要解决的问题，是让确认延迟保持在可预期的区间，而不只是提升吞吐。根据项目测试网口径的数据，单分片吞吐可达约 3,200 至 35,200 TPS 量级（不同批次测试条件下具体数字有差异，以当次测试的硬件与负载配置为准），多分片可线性扩展，确认延迟约 1.2 秒，作为对照，以太坊主网口径下约 15 TPS，确认时间在十余秒量级。这些数字都是测试网条件下的结果，不代表主网生产环境下的稳定表现，后续系列 F 会专门讨论如何正确解读和披露这类基准数据。

可组合 DeFi 是另一重考验。DeFi 协议之间高度互相调用，一笔交易可能牵涉多个合约的状态读写，这正是乐观并行执行最容易遇到冲突、吞吐最容易被热点拖累的场景（系列 B 第 25 篇会专门解剖 AMM、借贷、NFT mint 这类高冲突合约）。Bitroot 选择在这个场景上正面迎战，而不是回避，某种程度上也是结算层定位的必然要求：一个只能处理低冲突转账、遇到复杂合约就退化成串行执行的链，称不上真正的高性能结算基础设施。

大规模链上协作则指向更长期的方向，包括 DAO 治理、多方协同的链上流程，这类场景对状态规模和跨分片协同能力的要求会随参与方数量增加而持续上升，状态分片和跨分片通信协议（系列 D 会展开）在这里扮演关键角色。

一个仍在验证中的判断

需要说清楚的是，以上这套定位和技术组合目前仍处于测试网阶段的验证过程中，团队规模、测试用户数量、验证节点数量等社区侧数据会随时间变化，具体数字应以项目最新披露为准。技术路线的正确性最终要靠主网上线后的真实负载来检验，包括在高并发、高冲突场景下共识和执行两层能否维持稳定的延迟表现，以及验证者去中心化程度能否在追求性能的同时守住底线，这是第 9 篇要正面讨论的张力。

把 Bitroot 放回整张扩容地图里看，它不是在发明一种全新的范式，而是在乐观并行这条已经被 Aptos、Monad、Sei 等项目验证过可行性的路径上，用共识与执行解耦、三阶段冲突检测、状态分片这一组具体工程选择，去逼近一个具体目标：一条保留完整 EVM 兼容性、同时扛得住支付结算和高频 DeFi 负载的公链。这个目标能不能达成，接下来的文章会从 EVM 兼容的具体含义讲起，一层一层拆开看。

延伸阅读

• 前置阅读：《乐观并发控制（OCC）入门：数据库视角看区块链执行》
• 下一篇：《EVM 兼容意味着什么：字节码、预编译与工具链》
• 相关已有文章：《Bitroot并行化EVM技术解析：乐观并行化》、《深入解析Bitroot多引擎并行执行设计：突破EVM性能瓶颈》、《深入解析Bitroot：Pipeline BFT与多引擎并行执行的协同架构》、《深入解析Bitroot并行化EVM状态分片》