Aptos 和 Sui 都源自 Diem/Libra 项目，都用 Move 语言，都主打高吞吐。但它们在怎么实现并行这个问题上选择了不同的路。
Sui 换了数据模型（对象模型），Aptos 保留了账户模型但改变了执行引擎。这两条路的对比很有意思，因为它回答了一个问题：不改变数据模型，能不能实现并行。
Block-STM 的工作原理
Block-STM 的核心是乐观并行 + 冲突检测重执行。
流程如下：
第一步，乐观并行执行。 一个区块里的所有交易被分配序号，然后同时开始执行，不管它们之间有没有依赖。软件事务内存（STM）机制为每笔交易的读写建立记录。
第二步，验证并检测冲突。 执行完成后，检查每笔交易的读写集。如果两笔交易读写了同一个位置，就存在冲突。
第三步，重新执行冲突交易。 冲突的交易按照分配的顺序号重新执行，直到所有交易的结果与串行执行的结果一致。
这个方案的精妙之处在于乐观——它赌大多数交易之间没有冲突，所以并行执行能带来收益。只有冲突的交易才需要重跑。
与 Sui 对象模型的路径对比
| 维度 | Sui（对象模型） | Aptos（Block-STM） |
|---|---|---|
| 数据模型 | 对象，需明确所有权 | 账户，与传统区块链一致 |
| 并行方式 | 结构性并行（按对象划分） | 乐观并行（执行后检测冲突） |
| 免共识路径 | 有（单所有者对象交易） | 无（所有交易都排序） |
| 开发者负担 | 需设计对象所有权 | 与写普通智能合约类似 |
| 冲突处理 | 从设计上避免 | 运行时检测并重跑 |
| 可组合性 | 受所有权约束 | 与账户模型一致，更自由 |
Aptos 路线的核心优势是兼容性。开发者写合约的方式和以太坊类似（虽然语言是 Move），不需要理解对象所有权模型。这意味着生态迁移的认知成本更低。
Sui 路线的核心优势是理论上的并行上限更高。因为它从数据结构上消除了冲突的可能，而不是靠运行时检测。免共识路径对某些场景是结构性优势。
但 Aptos 的路线有一个 Sui 没有的问题：冲突检测和重执行本身有开销。如果区块里冲突很多，Block-STM 的性能可能还不如串行执行。这个开销在大负载下会更明显。
Block-STM 的实际效果边界
效果最好的场景：交易之间依赖关系少、读写集不重叠。比如批量转账（不同账户之间的）、独立的 NFT 操作。
效果受限制的场景：
高度竞争的共享状态。 如果大量交易都在修改同一个热门合约（比如一个热门 DEX 的池子），冲突率会很高，Block-STM 会反复重跑，收益被吃掉。
顺序依赖强的场景。 有些业务逻辑天然要求顺序执行（比如一个 NFT 系列的按顺序铸造），这时候并行无从谈起。
Gas 价格与执行开销。 Block-STM 需要额外的资源来维护读写集记录和检测冲突。这会增加节点运行的资源消耗。
度量的问题。Aptos 展示的 TPS 数字通常在合成负载下测得（大量独立转账）。在真实 DeFi 负载下，因为冲突集中，并行收益会明显降低。评估这类公链时，要区分"宣传的 TPS"和"实际应用下的 TPS"。
Move 语言在 Aptos 里的角色
与 Sui 一样，Aptos 用 Move。但 Aptos 的 Move 用法更接近 Diem 的原始设计，保留了全局存储 + 模块的结构：
- 模块（Module）类似于智能合约，包含函数和结构定义
- 资源存储在账户的全局存储下，通过 「move_to」/「move_from」 操作
- 资源类型保证资产不能被复制或丢弃
这个设计保留了 Move 的安全优势（资产是语言层面的一等公民），同时结构上更接近传统智能合约的开发习惯。
Aptos 的另一个特色是模块升级策略。Move 模块支持声明式的升级兼容性检查（比如新版本是否改变了函数签名），这在合约安全和可升级性之间提供了一个更精细的控制。
需要关注的风险
风险一：并行执行的正确性依赖实现质量。 乐观并行 + 重执行机制如果实现有 bug，可能导致状态不一致。这类 bug 的影响是系统性的，而非局部的。
风险二：节点资源需求较高。 高吞吐意味着高硬件要求。如果验证者的准入门槛过高，去中心化程度会受影响。
风险三：生态的真实需求。 大量交易量中，多少来自激励驱动的刷量？这个比例决定了"高 TPS"是真实需求还是人造数字。
风险四：Move 生态的审计资源。 Move 更安全，但生态中的审计师、形式化验证工具、最佳实践都还在积累。安全语言的收益需要配套的生态才能完全兑现。
风险五：与 Sui 的竞争关系。 两条 Move 公链在争夺同一批开发者和用户。资源分散可能让两条链的生态都不够厚。
怎么读 Aptos 的数据
看交易类型构成。 把交易按类型拆开：转账、NFT 操作、DeFi 交互、治理投票。如果大部分是低复杂度的操作，高 TPS 的说服力就要打折。
看实际应用的活跃度。 不是看有多少项目部署，而是看这些项目是否有持续的用户和真实的资金流。
看验证者集合。 数量、质押集中度、地理分布。
看平均交易费用与网络拥堵情况。 如果费用长期很低、没有拥堵，说明网络容量相对于需求有余量（也可能说明需求不足）；如果频繁拥堵，说明容量是瓶颈。
看冲突率相关的指标。 一些研究机构会分析区块内的冲突程度，这能直接反映并行执行的实际效率。
这两条路的启示
Aptos 和 Sui 的对比很有教育意义，因为它展示了同一个目标（并行执行）的两种实现路径：
- 结构性方案（Sui）：改变数据模型，从设计上消除冲突。上限高，但改变成本大、需要生态适配
- 运行时方案（Aptos）：保留现有模型，运行时检测冲突。兼容性好，但有检测开销、且在高冲突场景下收益衰减
这两种思路在工程上会反复出现。 结构性方案通常能拿到更高的理论上限，但要付出生态迁移的成本；运行时方案兼容性好，但天花板受限于现状。
哪个更优取决于具体的约束：如果你在从零构建一个新系统，结构性方案值得考虑；如果你需要兼容大量存量，运行时方案更务实。
对公链来说，这个选择还牵扯到生态——技术的优越性只有被生态接纳才能兑现。这也是为什么"技术更好的链"不一定能赢。
常见问题
Block-STM 是怎么实现并行的？
乐观并行：区块内所有交易同时开始执行，执行后检查读写集冲突，冲突的交易按序重执行，直到结果与串行执行一致。赌的是大多数交易之间没有冲突。
Sui 和 Aptos 的并行方案哪个更好？
取决于场景。Sui 从数据结构上消除冲突，理论上限更高且部分交易可免共识；Aptos 保留账户模型，兼容性好但需运行时检测冲突，高冲突场景下收益衰减。
为什么公链宣传的 TPS 通常高于实际？
因为测试多采用合成负载（大量独立转账），冲突少。真实 DeFi 负载下交易高度集中于共享状态，冲突率高，并行收益明显降低。评估时应区分两者。
Aptos 使用 Move 语言有什么好处？
Move 把资产作为语言层面的 resource 类型，不能复制或凭空创建，在语言层面杜绝双重支付、重复铸造类漏洞，安全性优于靠合约代码维护所有权的模型。