---
id: 13
title: 并行执行的三条路线：确定性、乐观与对象模型
slug: parallel-execution-approaches
date: 2026/08/27
summary: Solana 的 Sealevel、Aptos 的 Block-STM、Sui 的对象模型，是当前主流的三条并行执行路线。本文梳理确定性调度、乐观并发控制与对象模型各自的假设与代价，厘清它们的取舍逻辑。
keywords: 并行执行,Sealevel,Block-STM,对象模型,乐观并发控制
heroImage: /images/community-bg.png
---

以太坊一笔交易接一笔交易地执行，这个事实本身并不是缺陷，而是一种选择：用最简单的执行顺序换取最容易验证的确定性。但当行业开始认真对待"公链要不要能扛住真实经济活动"这个问题时，几乎所有试图突破单线程瓶颈的团队都会在同一个岔路口停下来：交易之间到底该由谁来判断"能不能同时跑"，是开发者提前声明，还是系统自己在运行时发现？

这不是一个技术细节，而是一条决定了整个平台开发者体验、兼容性边界和实际吞吐上限的路线选择。过去几年里，行业已经趟出三条相对成熟的路径：以 Solana Sealevel 为代表的确定性并行，以 Aptos Block-STM、Monad、Sei 为代表的乐观并发控制，以及以 Sui 为代表的对象模型。三者看似都在解决"如何让多笔交易同时跑"这一个问题，但对开发者的要求、对现有生态的兼容程度、以及在真实负载下的表现，差异相当大。理解这张地图，是理解后续所有并行 EVM 工程细节的前提。

## 确定性并行：把负担交给开发者

Solana 的 Sealevel 运行时是这条路线最典型的样本。按照 Solana 官方与多篇技术解析的描述，每一笔提交上链的交易都必须显式声明它将要读取和写入的账户列表，并且标注每个账户是只读还是可写。运行时拿到这份声明后，就能在执行之前构建出一张完整的依赖关系图：两笔交易如果不共享任何可写账户，就可以被安全地分派到不同核心并行执行；如果都只读同一个账户，也可以在同一个 PoH 条目里一起处理；只有当两笔交易都要写同一个账户时，才需要排队串行。这套机制配合 Solana 的 Cloudbreak 存储层，理论上可以做到无锁的并行状态访问，调度器不需要在运行时反复猜测谁和谁冲突，因为答案已经写在交易本身里。

这种设计的吸引力在于确定性：一旦交易被接受，它的执行路径就是可预测的，不存在"跑到一半发现冲突，推倒重来"的浪费。但代价同样直接，落在开发者肩上。每一笔交易都要在提交前枚举出完整的账户访问列表，这对简单的转账没有负担，但对逻辑分支复杂、状态访问路径依赖运行时条件的合约，意味着开发者要么做保守的过度声明，把不一定会用到的账户也写进去，要么冒着遗漏声明导致交易失败的风险。更麻烦的是，以太坊生态的 EVM 从设计之初就不要求这种预声明：一笔交易访问哪些存储槽，往往取决于合约内部的条件判断，只有真正执行到那一行代码才知道。这也是多位分析者反复提到的一点：给 EVM 交易强行加上访问列表声明，会直接破坏字节码级兼容性，逼着开发者为了适配新链而重写合约逻辑。

预声明机制也并没有在实践中兑现"完全消除冲突"的承诺。2025 年发表于 arXiv 的一项实证研究，通过分析 Ethereum 与 Solana 的历史区块数据，比较了两条链的交易冲突模式与理论并行度上限。结果显示，以太坊区块中独立交易的比例在超过半数的区块里可以达到 50% 以上，而 Solana 区块的冲突链长度平均占到区块规模的约 58%，远高于以太坊约 18% 的水平。换句话说，尽管 Solana 要求开发者提前声明账户访问，链上真实的应用交互模式，尤其是 DEX、借贷这类高频读写共享状态的场景，依然会产生大量相互依赖的交易序列。预声明解决的是调度阶段"知不知道谁和谁冲突"的问题，而不是应用层面"状态本身有没有热点"的问题。这提示了一个后续系列会反复回到的结论：并行度的真正瓶颈，很多时候不在执行引擎，而在合约设计本身有没有把状态拆散。

## 乐观并发控制：假设冲突是例外

如果说确定性路线把复杂性前置给了开发者，乐观并发控制（OCC）选择的是相反方向：先假设大多数交易之间没有冲突，直接并行跑起来，把校验和纠错留到执行之后或执行过程中处理。这条路线最有分量的工程样本是 Aptos 的 Block-STM。根据 Aptos Labs 发表并被 PPoPP 2023（第 28 届 ACM SIGPLAN 并行编程原理与实践研讨会）收录的论文，Block-STM 建立在软件事务内存（STM）与经典 OCC 思路之上：交易按照一个预先给定的顺序被乐观地并行执行，执行完成后系统校验每笔交易读到的数据是否被顺序中更靠前的交易改写过，如果是，则中止并重新执行，直到收敛到与串行顺序等价的结果。与传统 OCC 不同的是，Block-STM 引入了一套低开销的协作式调度器，能够在执行过程中就动态发现依赖关系并安排重执行，而不是等一整批交易全部跑完才做校验，这使得它能够只回滚真正冲突的交易，而不必牵连整个批次。Aptos 官方与 Medium 技术博客披露的测试数据显示，该引擎在其环境下每秒可处理超过 16 万笔非平凡的 Move 交易。

这条思路后来被多条 EVM 兼容链采纳，且理由高度一致：EVM 字节码天然不携带访问列表，想做到完全的字节码兼容，就不可能像 Sealevel 那样要求开发者提前申报读写集。Sei 在其 V2 版本的技术说明中明确指出了这一点：EVM 交易在被节点接收时，没人知道它最终会触碰哪些存储槽，只有真正执行才能揭晓，因此给 EVM 交易强加访问列表既不现实也会破坏兼容性。Sei 的选择是反过来做，默认假设交易之间存在依赖，先推测性地并行跑一遍，记录下每笔交易实际触达的状态范围，发现冲突后只把冲突的子集拿出来重新按顺序执行，其余交易不受影响。Sei 官方博客将 V2 称为"首个并行化 EVM 区块链"，其乐观并行结合快速的 Cosmos SDK 层共识，对外公布的吞吐目标达到万级 TPS。

Monad 走的是同一条路线的另一种工程实现。据 Monad 官方与多家研究机构的技术拆解，其执行引擎让每笔交易在一份状态快照上推测性执行，调度器再按规范顺序提交结果，如果两笔交易触碰了同一状态，后提交的一方会基于前者的输出重新执行。由于多数区块的实际冲突率较低，绝大多数交易可以一次通过。Monad 还把执行与共识做了解耦：共识层的 MonadBFT 采用流水线设计，在网络条件良好时可以一轮完成区块最终确认，把出块间隔压缩到约 300 毫秒量级，执行则在后台异步跟进，不需要等执行结果出来才能推进下一个区块的共识。这种"先排序、后执行、异步收敛"的架构，和 Aptos 依赖预设顺序做校验的思路在精神上是相通的：排序这件事一旦完成就足够稳定，执行层的乐观假设与重试机制负责兜住正确性。

乐观路线的核心风险，几乎所有实现者都承认：一旦真实负载的冲突率超出预期，重复执行带来的浪费会侵蚀掉并行带来的收益。这也是为什么后续讨论 Block-STM 类系统时，"选择性回滚"和"执行中检测"会被反复强调，因为它们是把乐观假设失效时的代价压到最低的关键工程手段，这部分细节将在本系列后面专门展开。

## 对象模型：换一套账本结构

Sui 提供了第三种答案，而且是从数据模型层面下手，而不是在现有账户模型上加调度技巧。根据 Sui 官方文档，链上所有资产在 Sui 里都被建模为对象，每个对象拥有全局唯一 ID，并被明确划分为归属对象和共享对象两类。归属对象只能被其所有者签名的交易使用，由于写者唯一，这类交易可以绕过共识排序，直接走一条延迟更低的"快速路径"完成最终确认；共享对象没有单一所有者，任何人都可以读写，因此涉及共享对象的交易必须经过共识层排序，以协调多个潜在写者之间的顺序。

这套设计把并行度问题转化成了对象归属问题：大部分转账、NFT 持有这类天然只有一个所有者的资产，可以在不经过全局排序的情况下并行处理，只有 DEX 资金池、拍卖合约这类真正需要多方共同读写的场景，才需要付出共识排序的代价。学术界对此也有实证跟踪，一篇分析 Sui 智能合约中共享对象使用情况的论文指出，共享对象虽然只占对象总量的一小部分，却是决定链上应用能否吃到并行红利的关键变量，热点共享对象仍然会成为竞争焦点，这与 Solana 上高频交易场景导致长冲突链的现象，本质上是同一类问题的不同表现形式。

Sui 的代价也很直接：它需要一门新的智能合约语言 Move，以及一套完全不同于账户模型的编程范式。这意味着以太坊生态里已经写好的 Solidity 合约、已经跑熟的 Foundry 和 Hardhat 工具链，没有办法直接搬过来，开发者要为了并行度重新学习一套心智模型和资产所有权表达方式。对于一个庞大且路径依赖很强的 EVM 生态而言，这是一笔不小的迁移成本。

## 三条路线放在一起看：兼容性才是真正的分水岭

把三种方案并排摆开，取舍变得清晰：

| 路线 | 代表项目 | 冲突处理时机 | 对开发者的要求 | 对 EVM 兼容性的影响 |
|------|----------|--------------|------------------|----------------------|
| 确定性并行 | Solana Sealevel | 执行前，依赖已知 | 必须显式声明账户读写集 | 与 EVM 字节码语义不兼容 |
| 乐观并发控制 | Aptos Block-STM、Monad、Sei | 执行中或执行后校验 | 无需预声明，近似"即写即发" | 可保持字节码级兼容 |
| 对象模型 | Sui | 按对象归属划分快速路径与共识路径 | 需采用新语言与对象编程范式 | 放弃账户模型，不兼容 EVM |

这张表格背后有一条清晰的规律：凡是把"完全兼容以太坊现有合约与工具链"当作硬约束的项目，几乎都不会选择确定性声明或对象模型这两条路，因为它们各自要求开发者改变书写合约的方式，前者要求预声明依赖，后者要求换一门语言。留给这类项目的现实选项，基本收敛到乐观并发控制：在不改变 EVM 语义、不要求开发者做任何额外声明的前提下，把发现依赖、处理冲突的工作，全部交给运行时来做。这不是因为 OCC 在理论上天然优于另外两条路线，Solana 和 Sui 各自的生态证明了另外两条路线同样可以跑出很高的吞吐，而是因为一旦"字节码兼容"被写进产品定位，可选的工程空间就被大幅收窄了。

理解了这一点，再去看 Bitroot 为什么选择乐观并行作为执行引擎的底层范式，以及为什么它在乐观框架里还要叠加交易依赖分析和三阶段冲突检测，答案会变得顺理成章：这是在"必须兼容 EVM"这个前提下，对乐观路线本身能做到多精细的一次工程回答。至于乐观并发控制具体如何定义读写集、如何检测冲突、如何决定谁该被回滚，这些问题需要从数据库领域的经典理论讲起，也是下一篇要展开的内容。

## 延伸阅读

- 前置阅读：[《区块链扩容地图：L1 并行、L2、分片与 DA，到底谁在解决什么问题》](/zh/blog/blockchain-scaling-map)
- 下一篇：[《乐观并发控制（OCC）入门：数据库视角看区块链执行》](/zh/blog/optimistic-concurrency-control-intro)
- 相关已有文章：[《Bitroot并行化EVM技术解析：乐观并行化》](/zh/blog/bitrootevm-)