两条网络使用 Move 生态理念，并不代表一笔交易引用的状态粒度和并行执行机制相同。区块链（43）：Cosmos 与 Avalanche 是两条不同的应用链路线强调应用链差异，本篇则对同一语言家族下不同的数据传播、共识、执行、检查点与同步路径分别作图。

Sui：按对象所有权切分输入

flowchart LR
  T[交易引用对象及版本] --> O{独占拥有还是共享?}
  O -->|拥有对象| F[按对象所有权检查/可并行的路径]
  O -->|共享对象| C[需要协调顺序的共识路径]
  C --> E[Move 执行/对象版本更新]
  F --> E
  E --> K[检查点与状态同步]

对象 ID、所有者和版本使独立对象可独立处理；共享对象仍需考虑竞争、排序与版本冲突。Narwhal/Bullshark 与 Mysticeti 是 Sui 共识历史和演进节点，不能从一篇发布说明断言 Mysticeti v2 在某个主网版本已启用。检查点证明、历史归档和状态同步各负责不同数据保留层；对象证明也不自动提供真实商品交付。

Aptos：账户资源与冲突检测

flowchart LR
  T[签名交易/账户资源] --> P[传播与存储队列]
  P --> B[AptosBFT/Jolteon 等投票与排序路线]
  B --> S[Block-STM: 推测并行执行/冲突校验]
  S --> A[账户与资源状态]
  A --> R[账本提交/状态同步]

Aptos 的 Move 资源与账户状态有不同于 Sui 对象拥有关系的并发粒度；Block-STM 可以先推测并行，再检测冲突并重试，不能把冲突交易永久当作可并行成功。Quorum Store、执行流水线、共识和状态同步是不同模块；白皮书介绍的是设计时期的组合，当前网络部署必须按具体客户端与 release 重核。历史阶段、已激活改变与未来路线目前无法取得逐网证据，不能用 Sui 的 Mysticeti 状态推断 Aptos。

两个订单为何不能只看“并行”标签

在 Sui 对象图里，如果买方与卖方分别持有不同订单对象，交易引用的对象版本不同，则执行和依赖跟踪可以按独立对象推进；两个订单若都写同一个共享托管对象，独立性消失，必须处理共享对象的排序和新版本。对象所有者变更后要重新检查授权边界，旧版本证明不等于对新版本的无限授权。同步新节点时，执行结果对应哪个检查点及可重放对象历史由该网络的实际规则决定；不能把单个对象事件当最终检查点。

在 Aptos 的账户/资源视图里，即使事务在 Block-STM 里先并发执行，读集一旦被前序提交改变，推测结果须按协议验证与重做。并行化只减少无冲突工作负载的等待，不能消除订单 ID 重复、nonce 失配或应用合约逻辑错误。订单服务还需将本地待发送记录、已执行的版本和已确认的账本状态分别标记。Mysticeti、Jolteon 或后续升级的工程代码和宣传页面都不能单独证明这两条主网现在运行相同算法。

练习一：两个 Sui 交易修改同一个共享对象，能仅因都使用 Move 而无需排序吗？答案：不能，共享状态需明确共识/冲突规则。练习二：Aptos 两笔交易的推测执行都读了同一可写资源，其中一笔提交后，另一笔能不检查就提交旧读结果吗？答案：不能，必须校验冲突并按执行协议重试或拒绝。

可迁移原则：共同语言并不推出共同的数据模型或终局协议。参考：Sui 架构、Mysticeti v2、Aptos 架构（当前激活、完整源码 SHA 与实测均 NOT_VERIFIED / NOT_RUN）；导航：区块链（43）：Cosmos 与 Avalanche 是两条不同的应用链路线 · 44 · 区块链（45）：钱包、RPC、预言机、扩容与应用的依赖地图。