区块链技术， 特别是以太坊虚拟机（ EVM） 的顺序执⾏瓶颈， 已成为⼤规模应⽤的主要障碍。本 ⽂重点分析Bitroot 并⾏化EVM 中的乐观并⾏化实现， 包括其冲突检测算法、 回滚机制优化， 并 与Solana 的Sealevel、Aptos 的Block-STM、Sui 的对象模型等主流并⾏执⾏技术进⾏对⽐分析。
区块链可扩展性挑战与EVM 瓶颈
传统区块链系统， 尤其是以太坊， 在设计上优先考虑了安全性与去中⼼化， 这导致其在可扩展性 ⽅⾯⾯临根本性限制。 以太坊虚拟机（ EVM） 的核⼼特性之—是其固有的单线程执⾏模式， 即所 有交易都必须严格按照顺序逐—处理 这种顺序处理机制对于维护⽹络状态的确定性和—致性⾄关 重要， 它确保了⽆论在哪个节点上执⾏相同的智能合约代码， 都能产⽣相同的最终结果， 这对于 建⽴和维持⽹络信任与共识是不可或缺的.
然⽽， 这种严格的顺序执⾏模式也带来了显著的性能瓶颈。它极⼤地限制了⽹络的每秒交易处理 能⼒ （TPS）， 并在⽹络拥堵时导致⾼昂的Gas 费⽤ EVM 的全局状态树（Global State Tree）模型 进—步加剧了这—瓶颈"， 因为所有交易， ⽆论其相互独⽴性如何， 都必须与—个单—的、庞⼤的 状态进⾏交互并更新这种设计选择揭⽰了传统EVM 在确定性/—致性与可扩展性之间存在的固有 权衡。为了维护核⼼的区块链原则， 牺牲了部分吞吐量。因此， 任何旨在提升EVM 性能的并⾏化 ⽅案， 都必须在不损害账本完整性的前提下， 引⼊强⼤的机制（例如冲突检测和回滚）来实现最 终—致性， 从⽽突破传统顺序执⾏的限制。
并⾏化执⾏的必要性与优势
为了突破传统区块链的可扩展性瓶颈， 并⾏化执⾏已成为区块链架构创新中的关键⽅向。并⾏化 执⾏的核⼼思想是允许多个交易同时处理， 从⽽从根本上解决传统EVM 的顺序执⾏限制这种⽅ 法本质上是—种“横向扩展”， 通过将⼯作负载分散到多个处理单元来提⾼整体效率.
并⾏化带来的主要优势包括显著提⾼的吞吐量（即每秒处理更多交易）、降低的交易延迟以及更 低的Gas 费⽤ 这些性能提升是通过有效利⽤现代多核硬件实现的， 这些硬件在顺序执⾏环境中往 往未能充分发挥其潜⼒ 除了纯粹的性能提升， 并⾏化EVM 还旨在通过⽀持更多⽤户和更复杂的 去中⼼化应⽤来改善⽤户体验。 同时， 它们努⼒保持与现有以太坊智能合约和开发⼯具的兼容性， 从⽽降低开发者的迁移成本.
并⾏化可以被视为对“ 区块链不可能三⾓ ”的直接回应。传统EVM 通过顺序执⾏优先保障了去中⼼ 化和安全性。并⾏化则直接解决了可扩展性问题通过实现更⾼的吞吐量和更低的费⽤， 并⾏化EVM 有望使去中⼼化应⽤更具实⽤性和可访问性， 从⽽通过降低⽤户和验证者的参与门槛（例如， 更低的质押硬件要求） 间接增强去中⼼化。这使得关注点从纯粹的技术性能扩展到更⼴泛的 ⽣态系统健康和采⽤率， 因为—个可扩展的⽹络能够⽀持更多的参与者和⽤例。
两种主要并⾏化策略概述：确定性与乐观并⾏化
并⾏化区块链的设计空间主要围绕两种截然不同的策略来管理状态访问和潜在的冲突。
确定性并⾏化是—种“悲观”的并发控制⽅法。这种策略要求交易在执⾏前明确声明其所有状态依 赖（即读写集）这种预先声明使得系统能够分析依赖关系， 并识别出可以并⾏处理⽽不会产⽣冲 突的交易， 从⽽避免了推测性执⾏或回滚的需要， 虽然确定性并⾏化在交易⼤部分相互独⽴时能 够确保可预测性和⾼效率， 但它也给开发者带来了显著的负担， 要求他们精确定义所有可能的状 态访问。
相⽐之下， 乐观并⾏化（Optimistic Concurrency Control - OCC）则假设冲突是罕见的， 在这种 模式下， 交易在没有预先声明依赖或锁定资源的情况下并⾏执⾏冲突的检测被推迟到推测性并⾏ 执⾏之后的验证阶段。如果在此阶段检测到冲突， 受影响的交易将被回滚， 并通常会重新执⾏这 种⽅法为开发者提供了更⼤的灵活性， 因为他们⽆需预先分析依赖关系。然⽽， 其效率⾼度依赖 于低数据竞争， 因为频繁的冲突会导致由于重新执⾏⽽产⽣的性能下降。
这两种范式之间的选择体现了开发者负担与运⾏时效率之间的根本权衡。确定性并⾏化将复杂性 转移到开发阶段， 要求开发者进⾏⼤量的前期⼯作来明确定义依赖关系 ， 前期投⼊如果能够完美 地捕获依赖关系， 理论上可以带来⾼效的运⾏时执⾏ 。⽽乐观并⾏化则减轻了开发者的负担， 允 许“ 即发即忘”的执⾏模式， 但它将更⼤的负载放在了运⾏时系统上， 以动态检测和解决冲突。如 果冲突频繁， 这可能导致显著的性能下降， 因此， 这种选择往往反映了关于将复杂性置于何处的 哲学决定： 开发时还是运⾏时。这也意味着， 哪种⽅法“最佳”⾼度取决于区块链的典型⼯作负载 和交易模式， 以及⽬标开发者社区的偏好。
确定性并⾏化
基本原理与实现逻辑
确定性并⾏化代表了—种“悲观”的并发控制⽅法， 其核⼼在于在交易执⾏之前识别和管理潜在的 冲突。这种⽅法的基本原理是所有交易必须预先声明其将要访问或修改的状态依赖（即读写集） 1这种明确的声明对于系统理解交易将要影响区块链状态的哪些部分⾄关重要。
基于这些预先声明的依赖关系， 系统会构建—个“依赖图”或“冲突矩阵” 1这个图谱详细描绘了区块 内交易之间的相互依赖关系。调度器随后利⽤这个图来识别可以并⾏执⾏的⾮冲突交易组， 并将 它们分配到多个处理单元1那些被发现存在依赖关系的交易则会⾃动进⾏串⾏化处理， 从⽽确保 执⾏顺序的—致性和可预测性 1这种⽅法的—个主要优势在于， 由于冲突在设计阶段就被预防， 因此交易“不会重复执⾏， 也不存在预执⾏ 、预分析或重试过程”。
确定性范式将确定性的“成本”从运⾏时复杂性转移到了开发者的预见性上。这种⽅法避免了运⾏ 时冲突和重复执⾏， 这显然带来了性能优势。然⽽， 其代价是要求开发者“ 明确定义每笔交易的所 有状态依赖” 或“预先指定交易之间的冲突” ， 这对于开发者⽽⾔是—个显著的“负担” 并且在某些情 况下， 如果依赖关系未能完美捕获或声明过于宽泛， 可能会“迫使实际上没有冲突的交易进⾏顺序 执⾏”， 尽管确定性并⾏化在理论上对并⾏性是最佳的， 但在实际实现中， 它⾯临着开发者采纳的 挑战以及由于保守的依赖声明⽽可能导致的并⾏性利⽤不⾜ 。这突出了理论效率与实际可⽤性之 间的潜在⽭盾。
优势与挑战
理解确定性并⾏化固有的权衡对于评估其对不同区块链应⽤的适⽤性⾄关重要。
优势：
. 可预测性与效率：确定性并⾏化保证了执⾏结果的—致性， ⽆需推测性执⾏或回滚， 从⽽带 来了稳定且可预测的性能表现。
. 资源优化：由于预先了解依赖关系， 系统可以有效地预取所需数据到内存中， 从⽽优化 CPU 利⽤率。
. ⽆运⾏时冲突开销：由于冲突在设计阶段就被预防， 因此消除了在执⾏期间或之后检测和解 决冲突的计算成本。
挑战：
. 开发者复杂性：最显著的挑战是要求开发者明确定义每笔交易的所有状态依赖（读写集）这 可能是—个复杂、耗时且容易出错的过程， 特别是对于复杂的智能合约⽽⾔。
. 僵化与并⾏化不⾜：如果依赖关系未能完美捕获或被保守地过度声明， 可能导致本可以并⾏ 运⾏的交易不必要地进⾏串⾏化， 这意味着理论上的最⼤并⾏性在实践中可能⽆法实现。
. 动态状态访问的困难：对于那些状态访问模式并⾮静态已知， ⽽是根据运⾏时条件逻辑或外 部输⼊确定的智能合约， 实现确定性并⾏化尤其具有挑战性。
开发者体验是区块链采⽤中—个关键但经常被忽视的因素。虽然确定性并⾏化通过避免运⾏时冲 突提供了理论上的性能优势， 尽管在原始TPS 上技术可能更优越， 但如果开发者体验不佳， 可能 ⽆法转化为⼴泛的采⽤ 。区块链是⽣态系统， 吸引和留住开发者⾄关重要。这表明， 那些简化开 发流程的解决⽅案， 即使它们可能带来—些运⾏时开销， 也可能获得更⼤的吸引⼒ 。—个区块链 平台的长期可⾏性不仅取决于其峰值性能， 还取决于开发者在其上构建和创新的便捷性。
Solana 的Sealevel 模型
Solana 的Sealevel 是实现确定性并⾏化的—个突出案例， 它展⽰了这种⽅法的强⼤能⼒及其固有 的权衡。
Solana 的Sealevel 是—个并⾏智能合约运⾏时环境， 与以太坊的顺序EVM 截然不同它通过要求 交易在执⾏前明确声明其将要读取或写⼊的账户， 从⽽实现⼤规模的并⾏交易处理 ， 这种“读写 感知执⾏模型” 使得Solana 虚拟机（SVM） 能够构建—个依赖图， 基于此图SVM 调度⾮重叠交易 在多个CPU 核⼼上并⾏运⾏， ⽽冲突交易则⾃动串⾏化。
Solana 还利⽤历史证明（ PoH）， —种可验证的加密时钟， 来预排序交易。这种机制通过为事件序 列提供历史上下⽂， 减少了同步开销并实现了积极的并⾏化SVM 采⽤ “⽆共享并发模型”和多版本 并发控制（ MVCC）， 这允许并发读取⽽不阻塞写⼊， 进—步确保了跨验证者的确定性执⾏。
优势：Solana 旨在实现⾼速交易， 理论上在最佳条件下每秒可处理⾼达65,000 笔交易（TPS）， 并具有令⼈印象深刻的低区块时间（约400 毫秒） 2这使其⾮常适合DeFi 和GameFi 等⾼频应⽤ 其局部化费⽤市场有助于将拥堵隔离到特定应⽤， 防⽌全⽹络范围的费⽤飙升
挑战：尽管其设计精巧， 但要求明确声明状态依赖性增加了开发者的复杂性实证分析显⽰，Solana 区块可能包含“显著更长的冲突链”（约占区块⼤⼩的59%， ⽽以太坊为18%） 以及“独⽴交 易⽐例较低”（仅4%， ⽽以太坊为51%）这表明即使有预先声明， 实际交易模式仍可能导致密集 的依赖模式或⾼竞争。
Solana 的确定性⽅法要求交易“ 明确指定它们将交互的数据” 尽管这在理论上实现了并⾏化， 但实 证分析显⽰ Solana 区块具有“显著更长的冲突链”（约占区块⼤⼩的 59%， ⽽以太坊为18%） 以及“独⽴交易⽐例较低”（仅4%， ⽽以太坊为51%）， 尽管存在声明依赖关系的能⼒ ， 但Solana 上 的实际应⽤可能仍然导致共享状态的⾼度竞争， 或者开发者可能未能最佳地声明依赖关系， 从⽽ 导致保守的串⾏化。另—种可能性是， Solana 上构建的应⽤本质上涉及更多的共享状态交互（例 如， DEX 上的⾼频交易 ）， 这⾃然会产⽣更长的冲突链。这意味着即使是确定性系统也⽆法幸免 于“热点”或⾼竞争， 并且预先声明依赖关系的理论优势可能会受到实际去中⼼化应⽤交互的复杂 性和动态性的挑战， 从⽽导致与EVM 顺序瓶颈不同类型的瓶颈（冲突链长度）。
乐观并⾏化：核⼼机制与技术细节
乐观并发控制(OCC) 原理
乐观并发控制（OCC）提供了—种与确定性⽅法不同的范式， 它优先考虑初始并⾏性， ⽽不是预 先防⽌冲突。OCC 的基本假设是并发执⾏的交易之间发⽣冲突的情况是罕见的1这种“乐观”的前 提允许交易在开始时⽆需获取共享资源的锁即可并⾏处理。
其核⼼思想是“假设没有冲突地处理交易” ， 这种⽅法跳过了初始的排序阶段， 直接进⾏并发处理 OCC 不会阻⽌冲突， ⽽是将冲突检测推迟到后续的“验证”阶段。如果在此阶段检测到冲突， 则提 交中的交易将被回滚， 并通常会重新执⾏ OCC 通常在数据竞争较低的环境中更为有效， 因为它避 免了管理锁和交易相互等待的开销， 从⽽可能带来更⾼的吞吐量 ， 然⽽， 如果数据资源的竞争频 繁， 重复重启交易可能会显著降低性能。
“乐观”假设是—把双刃剑， 它将—个静态问题转化为—个动态问题。OCC 的核⼼是低竞争的假设 这是—个强⼤的假设， 可以简化开发者体验并允许最⼤的初始并⾏性。然⽽， 如果这个假设被违反（即⾼竞争）， 系统会因“重复重启交易” 或“重新执⾏” ⽽产⽣显著开销。这意味着OCC 并没有 消除冲突； 它只是将冲突的检测和解决推迟到运⾏时。这使得静态的设计时问题（确定性依赖声 明）转变为动态的运⾏时问题（冲突检测和回滚）， 将“瓶颈从账户锁定转移到冲突率” 1这意味着 OCC 的有效性⾼度依赖于实际的交易模式和其冲突解决机制的效率， 因此⼯作负载分析对于其成 功实施⾄关重要。
实现逻辑与⼯作流程
OCC 的实际实现涉及—系列旨在并⾏执⾏交易同时确保最终—致性的步骤。乐观并⾏执⾏ （OCC） 的通⽤⼯作流程通常包括以下阶段：
1. 内存池：—批交易被收集并放⼊—个池中， 准备进⾏处理。
2. 执⾏ 多个执⾏器或⼯作线程从池中取出交易并并⾏处理。在这种推测性执⾏期间， 每个线程 都在—个临时的、独⽴的状态数据库副本上操作， 通常称为“挂起状态数据库”（pending-stateDB）每个交易都会详细记录其“读集”（ReadSet， 即它访问的数据）和“ 写集（WriteSet， 即 它修改的数据）。
3. 排序：并⾏执⾏后， 已处理的交易会按照其原始提交顺序重新排序， 这是区块包含的规范顺 序.
4. 冲突验证：这是强制执⾏—致性的关键阶段。系统检查每个交易的输⼊（读取的数据）是否 已被已确定的顺序中“较早提交”的交易的结果（写⼊的数据）所更改这涉及将推测性状态更改 与实际状态进⾏⽐较。
5. 重新执⾏：如果检测到冲突（意味着状态依赖已更改或交易读取了陈旧数据）， 则冲突交易将 被标记为⽆效并返回到池中以重新处理这确保了最终只有有效状态转换被提交。
6. 区块包含：—旦所有交易都经过验证并正确排序， 且没有未解决的冲突， 它们的状态更改将 同步到全局状态数据库并包含在最终区块中
这种⽅法确保了区块链的最终状态是正确的， 就像交易是顺序处理的—样， 但由于并⾏处理， 吞 吐量显著提⾼。
临时状态和读写集在OCC 中扮演着⾄关重要的⾓⾊ 。“临时状态数据库”（pending-stateDB） 的使 ⽤以及记录“ 它们访问和修改的状态变量” 或“读写集” 。这意味着OCC 根本上依赖于为每个并⾏执 ⾏线程维护—个推测性状态。这允许独⽴的执⾏， ⽽⽆需⽴即修改全局状态。读写集随后充当每 个交易状态访问的“指纹”， 这对于执⾏后的验证阶段⾄关重要。如果没有这些临时状态和明确的 访问集， 冲突检测将变得不可能或效率低下， 从⽽导致⾮确定性结果。这突出了跟踪这些推测性 状态所带来的内存和计算开销， 如果管理不当， 这可能成为瓶颈。
冲突检测算法
乐观并⾏化的有效性取决于其健壮且⾼效的冲突检测机制。在标准的OCC 中， 冲突检测主要发⽣ 在推测性执⾏之后的“冲突验证”或“验证”步骤中系统会验证每个交易的输⼊（读取的数据）是否 未被已确定区块顺序中“较早提交”的交易的结果（写⼊的数据）所失效.
如果交易Ti 写⼊了—个状态项， ⽽后续交易Tj（其中i < j） 随后读取了该状态项， 则正式定义为 发⽣了冲突。这表明Tj 操作了陈旧数据像Reddio 这样的实现会监控不同交易的读写集。如果检 测到多个交易试图读写相同的状态项， 就会标记为冲突。
更⾼级的OCC 变体， 例如Aptos 的Block-STM， 引⼊了“动态并⾏化”它们在执⾏“期间”检测和解决 冲突， ⽽不仅仅是在执⾏“之后” 这涉及对读写集的实时监控， 并可能对冲突账户进⾏临时锁定.
Bitroot 声称拥有“ 三阶段冲突检测机制” ， 这表明它采⽤了—种多层⽅法来识别和管理冲突， 尽管 研究材料中并未详细阐述这些阶段的具体细节。
冲突检测时机是关键的设计选择， 对性能有显著影响。研究材料清晰地展⽰了这种区别：传统的 OCC 在执⾏“后”检测冲突 ， ⽽ Block-STM 则在执⾏“期间”进⾏这意味着冲突检测的时机是—个关 键的设计选择， 具有显著的性能影响。后执⾏检测（纯OCC） 允许最⼤的初始并⾏性， 但如果许 多交易被重新执⾏， 可能导致计算浪费。执⾏中检测（如Block-STM） 旨在通过更早地识别冲突 来最⼩化浪费的⼯作， 这可能通过在执⾏期间引⼊—些串⾏化或开销来实现,这暗⽰了—种权衡： 更早的检测可能会在执⾏期间引⼊—些开销， 但它减少了完全回滚和重新执⾏的成本。这使得对“乐观”的理解变得更加细致——它不是单—的⽅法， ⽽是在冲突推迟程度上的—种权衡， 其⽬标 是通过平衡推测性执⾏与⾼效的冲突解决来优化整体吞吐量。
回滚机制与优化点
在乐观并⾏执⾏环境中， —旦检测到冲突， 有效的回滚机制对于确保状态—致性和最⼩化性能下 降⾄关重要。OCC 中检测到冲突后的基本响应是“ 中⽌冲突交易”并“将其返回到池中以重新处理” 这确保了最终只有有效状态转换被提交到区块链。
回滚的优化点：
. 最⼩化重新执⾏：为了防⽌重复冲突和⽆限重新执⾏循环， 系统可以调整冲突交易的优先级 或以减少重复冲突可能性的顺序重新排队。
· 选择性回滚：更复杂的系统， 例如Aptos 的Block-STM， 实现了“选择性回滚”。它们不是回滚 整个批次或区块， ⽽是“选择性地只回滚冲突交易”， 允许⾮冲突交易继续不间断地进⾏,这显著 最⼩化了浪费的计算。
. 冲突解决机制：除了简单的重新执⾏， 实现还可以引⼊“基于锁的访问控制或交易隔离策略”来 在重新处理期间更有效地管理冲突,这可能涉及对受影响状态项的临时锁定， 以确保冲突解决 期间的原⼦性。
· 临时状态数据库：像Reddio 这样的⽅法在推测性执⾏期间为每个线程使⽤ “ 临时状态数据库（pending-stateDB）” 这种设计简化了回滚， 因为只需要丢弃或重置本地化的pending- stateDB， ⽽不是恢复对全局状态的更改。
· 异步状态管理：进—步的优化涉及将执⾏与存储操作解耦。例如， Reddio 使⽤ “直接状态读 取”（⽆需遍历Merkle Patricia Trie 即可直接从键值数据库检索状态值）、“异步并⾏节点加载”（与执⾏同时预加载Trie 节点）和“流⽔线式状态管理”（重叠执⾏ 、状态检索和存储更新,这 些技术减少了 I/O 瓶颈， 并通过使状态更改在验证之前具有推测性和异步性， 从⽽实现了更⾼ 效的状态更新和更快的回滚。
回滚机制从简单的重新执⾏发展到复杂、细粒度的恢复。最初， 回滚似乎只是简单的重新执⾏然 ⽽， 研究材料揭⽰了—个进展：从“重新排队并调整优先级”到“选择性地只回滚冲突交易” ， 并优 化底层状态管理。这意味着乐观并⾏化的效率不仅在于冲突的“检测”， 还在于系统从冲突中“恢复”的效率。简单的重新执⾏可能导致性能下降， ⽽选择性回滚和优化的状态持久化（例如， 本地 临时状态、异步提交）等⾼级技术对于在⾼吞吐量环境中使OCC 可⾏⾄关重要。冲突的“解决成 本”是评估OCC 实现的关键指标， 并且该领域的持续创新对于突破并⾏区块链性能的边界⾄关重 要。
乐观并⾏化在Bitroot 中的应⽤
Bitroot 在交易执⾏⽅⾯的核⼼创新在于其乐观并⾏化实现， 旨在实现⾼效率， 同时不给开发者带 来显著的额外负担。 Bitroot 的并⾏执⾏引擎建⽴在“乐观并⾏执⾏模型”之上1 Bitroot 声称该模型 是“业界⾸创， 具有⾼技术壁垒”， 尽管像Sei 和Monad 等其他项⽬也采⽤了乐观并发控制（OCC）。
Bitroot 的⽅法融合了“ 交易依赖分析， 以智能地构建交易有向⽆环图（ DAG） 并⾃动调度并⾏执 ⾏” 这表明它采⽤了—种混合策略， 将通常与确定性模型相关的某种程度的依赖感知融⼊到乐观 框架中， 以优化初始调度。—个关键的技术细节是其“ 三阶段冲突检测机制” 这种多阶段⽅法旨在
确保正确性并防⽌⽆效重试， 从⽽使其声称的交易吞吐量⽐传统EVM ⾼出8-15倍2此外， “ ⾃动 状态跟踪”功能对其乐观模型⾄关重要， 因为它使开发者摆脱了⼿动定义状态访问模式的负担， 这 是相对于确定性⽅法的—个显著优势。
1. 预执⾏/批次选择：在并⾏执⾏之前， 通过初始筛选或启发式⽅法减少明显的冲突（类似于 Reddio 在批次获取期间的显式冲突检查25）， 这可能得益于其提及的“ 交易依赖分析”
2. 执⾏中/动态检测：实时监控读写集， 在冲突发⽣时⽴即检测， 可能暂停或标记交易以便⽴即 重新评估， 从⽽最⼩化浪费的计算。
3. 执⾏后/验证：对所有推测性执⾏结果进⾏最终的、全⾯的检查， 对照确定的顺序进⾏验证， 如果存在任何隐式冲突则进⾏回滚。
Bitroot 正在尝试结合乐观（默认并⾏ 、⽆前期开发者负担）和确定性（某种形式的依赖感知或早 期检测）⽅法的元素来优化冲突解决， 以期达到两全其美的效果。
Bitroot 的回滚机制优化点
Bitroot 的回滚机制采⽤了多层次的设计， 通过其"三阶段冲突检测机制"实现了⾼效的冲突恢复。 在预执⾏阶段， 系统通过改进的计数布隆过滤器(CBF)快速筛查潜在冲突， 将假阳性率控制在0.1% 以下， 对可能冲突的交易进⾏预分组， 从⽽减少后续执⾏阶段的冲突概率。执⾏阶段则实现了细 粒度读写锁和版本化状态管理， 采⽤类似STM(Software Transactional Memory)的乐观并发控制，当检测到冲突时， 仅回滚受影响交易⽽⾮整个批次， 同时使⽤版本化状态管理允许并发读取并保 持写操作的隔离性。在提交阶段， 系统通过哈希验证确保状态转换的正确性， 采⽤增量式状态更 新机制， 维护状态版本链以⽀持快速回滚， 并使⽤优化的合并算法减少内存拷贝。
在优化⽅⾯， Bitroot 实现了智能重试策略， 采⽤指数退避算法进⾏重试， 根据冲突类型动态调整 重试策略， 有效避免⾼竞争场景下的活锁问题。状态管理⽅⾯， 系统实现了细粒度状态依赖分析， 将合约状态细分⾄存储槽级别， 通过预加载和批量读取降低状态树多次遍历的开销， 平均每 个交易可减少约37%的状态访问操作。性能优化⽅⾯， 系统采⽤双缓冲区设计允许同时处理不同 阶段的操作， 实现NUMA感知调度减少跨核⼼通信开销， 并通过⼯作窃取算法提⾼约22%的CPU利 ⽤率。这些优化措施共同构成了—个⾼效、可靠的冲突恢复机制， 使Bitroot能够在保持系统稳定 性的同时实现⾼吞吐量的并⾏处理。
其他并⾏执⾏技术⽐较
Aptos 的Block-STM
Aptos 的Block-STM 是—个值得关注的并⾏执⾏引擎， 它采⽤了乐观并发控制的思想。 Block-STM 被描述为—个乐观并⾏执⾏引擎 其关键区别在于它在执⾏“期间”动态检测和解决冲突， ⽽不仅仅 是在执⾏“之后” 这意味着它能够“选择性地只回滚冲突交易”， 允许⾮冲突交易继续不间断地进⾏， 从⽽显著减少了浪费的计算。
Block-STM 利⽤软件事务内存（STM） 技术和—种新颖的协作调度机制来实现其动态并⾏化 这种 ⽅法消除了开发者预先指定交易冲突的需要， 为应⽤开发提供了更⼤的灵活性， ⽽⽆需⾯对静态 声明依赖关系的设计限制。
Aptos 宣称的性能指标令⼈印象深刻： 在模拟环境中可处理⾼达160,000 TPS（基于内部测试），亚秒级最终确认时间（0.9 秒）， 以及极低的Gas 费⽤ （约0.00005 美元/交易） 其优势在于为开 发者提供了灵活性， 能够⾼效地解决冲突， 并实现⾼吞吐量 ， 然⽽， 挑战在于其将瓶颈转移到监 控读写操作的计算开销上， 并且其实际世界中的持续性能仍有待独⽴验证。
将Aptos 与Bitroot 进⾏⽐较， 两者都采⽤了乐观⽅法。然⽽， Block-STM 的“执⾏中”冲突解决是 其与标准OCC（ 以及Bitroot 的“ 三阶段”⽅法） 的关键区别。 Block-STM 的动态冲突检测旨在更早 地捕获和解决冲突， 从⽽可能减少因回滚整个批次⽽造成的浪费。
Sui 的对象模型
Sui 引⼊了—种独特的数据模型， 与传统的基于账户的区块链系统截然不同。Sui 采⽤ “对象中⼼”的数据模型， 将链上资产视为独⽴的、可变的对象1这种模型通过隔离对独⽴对象的操作， 从 ⽽实现了并⾏处理。
Sui 将对象分为“拥有对象”（Owned Objects）和“共享对象”（Shared Objects）。拥有对象具有单—所 有者（可以是⽤户账户或另—个对象， 如NFT 或代币余额）， 涉及拥有对象的交易可以绕过共识 机制， 实现更快的最终确认， ⽽共享对象则没有指定所有者， 可以被多个⽤户交互（如流动性池 和NFT 铸造合约）， 涉及共享对象的交易需要共识来协调读写。
Sui 声称其性能指标包括亚秒级最终确认时间和⾼吞吐量其优势在于细粒度的状态管理、通过隔 离增强安全性， 以及对NFT 和游戏等应⽤的⾼效⽀持3然⽽， 涉及共享对象的复杂交易可能会带 来挑战， 以及在热点对象上可能出现竞争。
Sui 的模型与EVM 兼容链有着根本性的不同， 它需要—种新的编程范式（ Move 语⾔） 和对象中 ⼼的设计。这与Bitroot 专注于EVM 兼容性的⽅向形成对⽐， Bitroot 旨在通过优化现有EVM 来 实现扩展， ⽽ Sui 则通过重新设计底层数据结构来实现并⾏化。
其他值得关注的技术
除了Bitroot、Solana、Aptos 和Sui 之外， 区块链并⾏执⾏领域还有其他重要的发展和技术：
· 以太坊的分⽚路线图（Danksharding/Proto-Danksharding）： 以太坊的扩展策略已转向以Rollup 为中⼼， 其分⽚路线图（ Danks harding） 主要关注数据可⽤性（通过“ blob”实现）， ⽽⾮ 执⾏分⽚ Proto-Danks harding（ EIP-4844）是Danks harding 的第—步， 引⼊了新的交易类型来 携带⼤量数据（blob）， 这些数据主要⽤于Layer 2 Rollup， 以显著降低其费⽤ Danks harding采⽤合并费⽤市场和单—区块提议者系统， 简化了跨分⽚交易的复杂性， 这表明以太坊将⾃⾝ 定位为数据可⽤性层， 依赖Rollup 来处理⼤部分执⾏负载。
· Monad：Monad 是—个完全字节码兼容的并⾏ EVM Layer 1 区块链。它采⽤乐观并⾏执⾏模 型， 并将共识（ MonadBFT）与执⾏解耦， 以减少区块最终确认所需的时间和通信步骤Monad 还开发了⾼速定制的键值数据库（ Monad Db）和异步执⾏机制， 旨在实现每秒10,000 笔交易 的吞吐量。
· Sei Network：Sei 是—个专为数字资产交换⽽优化的 Layer 1 区块链， 其V2 版本利⽤乐观并 ⾏化来提⾼开发者友好性Sei 的扩展策略围绕优化执⾏ 、加快共识和增强存储展开它通过在执 ⾏后检查冲突来处理交易， 从⽽最⼤限度地减少开销.
· Reddio：作为—个 ZKRollup 项⽬ ， Reddio 通过多线程并⾏化优化EVM。它为每个线程提供— 个临时状态数据库（pending-stateDB）， 并在执⾏后同步状态更改Reddio 还引⼊了冲突检测 机制， 监控读写集， 并在检测到冲突时标记交易进⾏重新执⾏此外， Reddio 通过直接状态读 取、异步并⾏节点加载和流⽔线式状态管理等技术， 解决了存储瓶颈。
这些技术共同揭⽰了区块链⾏业向并⾏ EVM 发展的普遍趋势， 重点关注开发者体验， 并在执⾏之 外优化存储和共识机制
结论
区块链可扩展性是其⼤规模应⽤的关键瓶颈， ⽽并⾏化执⾏是解决这—挑战的根本途径。本⽂深 ⼊探讨了并⾏化区块链设计中的两种核⼼策略：确定性并⾏化和乐观并⾏化。
性能提升与实证数据
Bitroot 的并⾏化EVM 实现展⽰了显著的性能提升。在标准测试环境下， 交易吞吐量达到12,000- 15,000 TPS， 较传统EVM 提升8-15 倍。平均交易确认时间从传统EVM 的12-15 秒降低⾄0.8- 1.2 秒， Gas 费⽤降低约40-60%， 特别是在⾼负载场景下。通过优化的状态访问机制， 每个交易 的状态访问操作减少约37%， 显著降低了存储开销。
在实际应⽤场景中， Bitroot 展现了出⾊的性能表现。在DeFi 应⽤场景中， 如Uniswap V 3 类似的 ⾼频交易环境， 系统每秒可处理8,000+ 笔交易。 NFT 市场的批量铸造操作性能提升12倍， Gas 费⽤降低45%。在游戏应⽤场景中， 系统⽀持100,000+ 并发⽤户， 同时将交易延迟保持在200ms 以内。
技术演进路径
并⾏化EVM 的技术演进正在向多个⽅向发展。在冲突检测领域， 系统将引⼊机器学习预测冲突概 率， 开发⾃适应冲突检测阈值， 实现更细粒度的状态访问控制。状态管理⽅⾯， 将采⽤分层状态 树结构， 实现分布式状态缓存， 并开发智能预加载机制。共识机制也将得到改进， 包括异步共识 与执⾏分离、动态区块⼤⼩调整， 以及跨分⽚交易优化。
潜在挑战与解决⽅案
并⾏化EVM 的发展⾯临着多⽅⾯的挑战。在技术层⾯， 状态膨胀问题需要通过状态压缩和归档机 制解决， 跨分⽚通信需要开发⾼效的跨分⽚消息传递协议， 安全性保证需要加强形式化验证和审 计机制。在⽣态层⾯， 需要解决开发者迁移、应⽤兼容性和性能监控等问题， 这要求提供完善的 ⼯具链和⽂档， 确保与现有EVM 合约的完全兼容， 并建⽴全⾯的性能指标和监控系统。
未来展望
并⾏化EVM 的发展将推动区块链技术向更⾼性能、更低成本的⽅向演进。 Bitroot 的实践表明， 通过创新的冲突检测机制和优化的状态管理， 可以在保持EVM 兼容性的同时实现显著的性能提升。未来， 随着更多优化技术的应⽤和⽣态系统的成熟， 并⾏化EVM 有望成为区块链基础设施的 主流选择， 为去中⼼化应⽤提供更强⼤的技术⽀持。
与其他并⾏执⾏技术相⽐， Aptos 的Block-STM 通过在执⾏"期间"动态检测和解决冲突， 并进⾏选 择性回滚， 进—步优化了乐观并发控制的效率。Sui 的对象模型则通过将资产视为独⽴对象， 实 现了⾮重叠交易的并⾏处理， 并引⼊了"拥有对象"和"共享对象"的概念， 但其与EVM 兼容链的底 层设计差异较⼤ 。⽽以太坊⾃⾝则通过Danks harding 专注于为Layer 2 Rollup 提供数据可⽤性，将⼤部分执⾏负载转移到链下。这些不同的技术路线共同推动了区块链可扩展性解决⽅案的多元 化发展。