--- id: 1 title: Bitroot 乐观并行化机制：检测、重执行与确定性 slug: bitrootevm- date: 2026/08/09 summary: 拆解乐观并行化在 EVM 上的工作方式：为何不能靠开发者预声明读写集、三阶段冲突检测如何缩小回滚面，以及确定性重放为何是区块链相对数据库 OCC 的额外约束。 keywords: 乐观并行化,OCC,冲突检测,并行EVM,Bitroot heroImage: /cms-media/file/2Deep%20analysis%20of%202Bitroot%20parallelized%20EVM%20technology.jpg --- 乐观并行化的一句话定义：先假设多数交易不打架，并行跑；发现读写冲突再按既定顺序重做，直到结果与串行一致。它不是「更快的魔法」，而是把冲突处理从预防挪到检测与恢复——在 EVM 不能强制账户访问列表时，这几乎是保留字节码兼容的主路。理论来源见 [《OCC 入门》](/zh/blog/optimistic-concurrency-control-intro)；路线比较见 [《并行执行的三条路线》](/zh/blog/parallel-execution-approaches)。架构位置见 [《并行 EVM 架构概览》](/zh/blog/bitrootevm) 与 [《Bitroot 定位》](/zh/blog/bitroot-positioning)。 ## 为什么 EVM 更难「确定性预声明」 Solana Sealevel 要求交易声明账户列表，调度器可在执行前构图。EVM 交易触及哪些 storage slot，常常要跑到条件分支才知道。强行加访问列表会破坏大量现有合约与工具链假设。因此 Bitroot 等项目选择：兼容优先，冲突交给运行时。兼容边界见 [《EVM 兼容意味着什么》](/zh/blog/evm-compatibility-explained)。 代价是：冲突率高时，重执行会吃掉并行红利。这不是实现「写错了」，而是乐观方法的固有曲线——热点合约上尤甚，见 [《并行 EVM 工作负载热点》](/zh/blog/parallel-evm-workload-hotspots)。 ## 三阶段冲突检测在做什么 Bitroot 材料中的三阶段，可以按职责理解（具体算法以节点实现为准）： 1. **执行前 — 静态/启发依赖分析** 用历史模式、静态分析或粗粒度读写估计，把明显冲突的交易错开并行窗口，降低「上来就撞」的概率。 2. **执行中 — 版本或读写集监控** 交易在私有视图上执行；若发现自己读过的版本已被排序更前的交易写入，尽早中止，避免把无效工作做完。 3. **执行后 — 状态根 / 可串行化校验** 对提交候选做一致性检查，确保并行合并结果与规范串行语义一致，挡住漏检与实现 bug。 与「整批跑完再统一验证」的朴素 OCC 相比，分层检测的目标是**更早失败、更小重执行集合**。这与 Block-STM 强调的协作调度同属一个问题家族，但调度器与中止粒度不必相同；不要用营销倍数替代冲突率曲线。 ## 回滚与重执行：选择性，而不是整块重来 高效实现通常只重跑受影响的交易及其依赖闭包，而不是区块内所有交易。仍必须遵守共识顺序：不能为了吞吐私下改序。共识先给出顺序、执行后收敛的分工，见 [《Pipeline BFT 与执行解耦》](/zh/blog/bitroot-pipeline-bft)；多引擎如何承载并行窗口，见 [《多引擎并行执行设计》](/zh/blog/bitroot-evm)。 对 Agent 与高频结算负载，这意味着：低冲突时确认可预期；热点池上应预期重执行上升，而不是假设「并行 = 永远快」。堆栈语境见 [《去中心化 AI 堆栈》](/zh/blog/aibitrootweb3ai)。 ## 确定性：区块链 OCC 多出来的那一层 单机数据库 OCC 只需本实例可串行化。链上每个诚实节点必须独立算出同一状态。因此禁止依赖：线程调度次序、本地时钟、不稳定浮点等非确定性来源。并行度变化时，规范结果仍应唯一。这是安全属性，不是性能彩蛋。 ## 和同赛道方案怎么比（克制） | 路线 | 代表直觉 | 对 EVM 存量 | |------|----------|-------------| | 确定性声明 | 执行前已知依赖 | 迁移成本高 | | 对象模型 | 用对象所有权隔离 | 需新语言/范式 | | 乐观 OCC | 运行时检测 + 重执行 | 最贴字节码兼容 | 公开材料中「相对传统 EVM 数倍吞吐」一类表述，应理解为特定负载与测试网条件下的工程观测；高冲突负载下倍数会收缩。读法见 [《性能指标术语表》](/zh/blog/performance-metrics-glossary)。验证者门槛如何限制可用并行度，见 [《去中心化与性能的权衡》](/zh/blog/decentralization-performance-tradeoff)。本文不构成投资建议。 ## 冲突率曲线比峰值倍数更重要 实验室里「相对串行 EVM 数倍」往往对应低冲突合成负载；把同一引擎丢进共享池热点，倍数会迅速收缩。因此对外沟通应优先给：冲突率—吞吐曲线、重执行占比、以及 p95 延迟。这比单一放大倍数更能帮助应用方判断自己的合约适不适合吃并行红利。热点解剖见 [《并行 EVM 工作负载热点》](/zh/blog/parallel-evm-workload-hotspots)。 实现细节因客户端而异，但评估清单可以共用：读写集粒度（账户级还是存储槽级）、中止后是立刻重跑还是进入等待队列、验证是否并行、以及状态根如何在并行合并后一次性确定。清单越具体，越不容易被「三阶段」四个字糊弄过去。数据库脉络见 [《OCC 入门》](/zh/blog/optimistic-concurrency-control-intro)；总架构见 [《并行 EVM 架构概览》](/zh/blog/bitrootevm)。 ## 冲突率曲线与工程调参 乐观并行的关键调参不是「引擎数越大越好」，而是：并行窗口宽度、中止策略、重执行调度优先级、以及启发分析的保守程度。窗口过大，冲突连锁更长；窗口过小，接近串行。启发过保守，吞吐上不去；过激进，重执行风暴更频繁。 公开测试应同时报告：无冲突基准、中等冲突合成负载、以及接近 AMM 热点的压力负载。只发布第一种数字，等于只展示乐观假设成立时的上界。术语与读数见 [《性能指标术语表》](/zh/blog/performance-metrics-glossary)；工作负载分类见 [《并行 EVM 工作负载热点》](/zh/blog/parallel-evm-workload-hotspots)。 ## 与数据库 OCC 的关键差异再强调一次 数据库可以在单主上提交后复制；链必须让所有诚实副本独立收敛到同一根。因此「差不多可串行」不够，必须确定性。浮点模型输出、依赖节点本地熵的随机、以及未约定顺序的并行归约，都不能进入规范状态转换——它们可以留在链下，再以证明或聚合签名锚定。 这也解释了为何 AI 推理不宜直接充当共识输入：概率输出与确定性重放冲突。正确模式是链下计算、链上结算与可选证明，见 [《去中心化 AI 堆栈》](/zh/blog/aibitrootweb3ai) 与 [《可信计算框架》](/zh/blog/trusted-computing-framework)。 乐观并行化的教学价值，在于把「快」翻译成可测量的冲突率与重执行占比。记住这一翻译，就不会被下一张更大的 TPS 海报轻易带走。实现细节仍以节点客户端与审计材料为准。 ## 正确性测试建议（概念层面） 除了吞吐基准，还应有：同一批次在不同并行度下状态根一致；故意注入读写冲突后最终仍等价于串行；崩溃恢复后重放不引入分叉；以及模糊测试生成的随机交易流在并行与串行模式下对比。通过这类测试，比再宣布一个峰值 TPS 更能说明乐观并行化已经工程化。客户端实现细节以仓库与审计为准。 检测、重执行与确定性是乐观并行的三角：缺检测则回滚过晚，缺选择性重执行则吞吐归零，缺确定性则安全模型破产。三角同时成立，TPS 数字才有解释力。 公开加速比请连同冲突率与重执行占比一并披露，避免孤立峰值；非投资建议。 具体算法以节点实现与审计报告为准，本文仅建立机制直觉。 ## 小结 乐观并行化让 Bitroot 在不强迫开发者重写访问模式的前提下榨取多核；它的上限由冲突率与重执行效率决定，而不是由白皮书形容词决定。理解检测分层与确定性约束，比记住任何一个 TPS 数字都更有用。 ## 延伸阅读 - [《OCC 入门》](/zh/blog/optimistic-concurrency-control-intro) - [《多引擎并行执行设计》](/zh/blog/bitroot-evm) - [《并行执行的三条路线》](/zh/blog/parallel-execution-approaches)