Sui / Aptos / Near：新一代 L1 对比

Sui、Aptos 和 NEAR 都试图提高 Layer1 容量，但路径不同。Sui 使用对象状态，Aptos 以 Block-STM 并行执行交易，NEAR 用 Nightshade 把状态和执行分片。

三者不能简单归为同一类高速链。Sui 与 Aptos 都使用 Move 体系却有不同对象和存储模型，NEAR 则采用账户模型、Wasm 合约和异步跨合约调用。

Sui 为什么以对象为中心？

Sui 把链上资产和状态表示为具有唯一 ID、版本和所有权信息的对象。对象可以由地址拥有、由其他对象拥有，或作为共享对象供多个用户访问。

交易明确列出输入对象。只涉及独立拥有对象的交易因果关系清楚，可以并行验证和执行；共享可变对象需要共识排序，避免不同交易同时写入冲突状态。

Sui 对象类型	处理特点
地址拥有对象	由拥有者授权，独立交易容易并行
对象拥有对象	支持组合资产和层级所有权
共享可变对象	多用户可写，需要排序和冲突处理
不可变对象	可被读取但不能修改

对象模型适合数字资产和组合所有权，但合约设计若把所有操作集中到一个共享对象，仍会失去并行优势。

Aptos 的 Block-STM 怎样并行执行？

Aptos 采用 Move 资源模型和账户状态。Block-STM 会乐观地并行执行一批交易，检测实际读写冲突后，让冲突交易重新执行，最终结果与确定顺序一致。

开发者不必像静态调度系统那样提前提供完整读写集合，但高冲突工作负载会增加回滚和重执行。理论并行能力不能直接代表热门应用的实际吞吐量。

AptosBFT 等共识组件负责交易顺序和提交，MoveVM 负责执行。Keyless Account、Sponsored Transaction 等账户功能属于用户体验层，不改变基础状态仍需由验证者达成一致。

NEAR 的 Nightshade 怎样分片？

NEAR 使用账户模型，每个账户和合约状态属于某个分片。Nightshade 把一个逻辑区块中的状态变化拆成多个 Shard Chunk，不同验证者处理对应分片的数据和执行。

跨账户和跨分片调用使用异步 Receipt。合约发出调用后，结果可能在后续区块返回，因此开发者要处理回调和部分完成状态。

网络	并行或扩容单位	冲突处理重点
Sui	对象与交易依赖	共享可变对象需要共识排序
Aptos	区块内乐观并行交易	检测读写冲突后重执行
NEAR	分片状态与 Shard Chunk	跨分片 Receipt 和数据可用性

NEAR 的命名账户和多访问密钥能改善应用登录，Wasm 运行时支持 Rust 和 JavaScript 等开发路径。分片扩容同时增加路由、状态同步和跨分片调试复杂度。

三条链应该怎样比较？

维度	Sui	Aptos	NEAR
主要语言与运行时	Sui Move	MoveVM	Wasm，常用 Rust 或 JavaScript
状态模型	对象	账户与 Move 资源	分片账户状态
扩容重点	对象级依赖与并行	Block-STM 乐观并行	Nightshade 状态与执行分片
跨应用调用	对象和 Move 调用	Move 模块调用	异步 Receipt
设计关注	资产所有权和低延迟	通用并行执行与账户体验	横向分片和易用账户

比较时应使用相同口径的成功用户交易、最终性、节点要求和状态增长。实验室峰值、共识投票或简单转账不能直接代表复杂合约负载。

与单链并行执行路线的代表可对照Solana 高性能公链，整体公链定位可回到2025 年主流公链生态全景图。

常见问题

Sui Move 和 Aptos Move 合约可以直接互相部署吗？

通常不能直接复制。两者共享 Move 语言来源，但框架、对象或账户 API、标准库和部署工具存在差异，需要针对目标链修改和测试。

并行执行是否会改变交易的确定性？

不会以牺牲确定结果为目标。调度器可以并行尝试执行，但冲突检测、排序或对象锁要保证所有验证者得到一致提交结果。

NEAR 分片后用户需要自己选择 Shard 吗？

普通用户通常按账户和应用交互，协议负责路由。开发者仍需理解异步跨分片调用和 Receipt 失败处理。

三条链的 TPS 可以直接横向比较吗？

不能只看一个数字。统计是否包含投票、失败交易、批量操作，以及测试硬件、交易复杂度和最终性定义都会改变结果。