文章出自：区块链开发者 @cryptoalvatar，由律动 BlockBeats 翻译整理。

Aptos 和 Sui 是近期市场讨论度很高的两大公链，其原因不仅在于这两个均来自 Facebook 的团队都拿了高融资额，更在于他们都使用了 Move 编程语言对协议进行搭建。

**Aptos 和 Sui 都使用了他们自己的 Move 语言衍生版本，这有助于并行执行。**它是 Rust 风格的，具有静态强制和严格的资源所有权规则和形式验证。

Sui 版本的 Move 引入了一些修改，最明显的是所有权 API。它更简洁，也更清晰地展示了区块链设计。但是库（libraries）的开发感觉不如 Aptos。

Sui 使用基于 DAG 的内存池（Narwhal）+ Tusk 共识算法。然后在执行层利用 DAG 进行并行化（酷！）。与 Avalanche (Snowman++) 相比，在并行化方面它尚未释放 DAG 的全部功能。

Sui 版本的 Move 对对象的独有/共享及可变/不可变状态非常明确。这实现了直观的编程模型。此外，它使 Sui 能够使用可靠广播 (FastPay) 进行非共享对象交易，例如支付。

Aptos 使用 BlockSTM，它是高性能 HotStuff 算法的演进，并通过动态检测依赖关系和调度执行任务来引入并行化（灵感来自软件交易内存）。

很难说哪一个会在实践中表现更好，但我看好的是 Sui。Aptos 在优化当前设计方面已经做得很好，而 Sui 似乎还有更多空间。双路径实现拜占庭共识也让 Sui 占了上风。

值得注意的是，两条链都没有针对 home 验证者案例和大规模去中心化进行优化，而是归入了「最大化网络容量」阵营（即像 Solana 一样）。状态（State）增长可能是瓶颈。

**Sui 通过高效的存储分片来解决这个问题，专注于横向扩展资源。另一方面，Aptos 更加强调支持异构验证器（受限 CPU 和/或受限存储）。**我喜欢 Sui 的做法。

它们都处于相似的发展阶段，Aptos 有点领先。设置系统花费的时间比实际码代码 (我也恰好使用 NixOS）还要多。学习语言和环境也需要一些反复试验。

部署到 devnet 在这两种情况下都有些麻烦。幸运的是，单元测试库非常有用。

最糟糕的部分是晦涩难懂的编译器报错，以及毫无意义的 devnet 错误响应。这些应该马上解决。

文章出自：区块链开发者 @cryptoalvatar，由律动 BlockBeats 翻译整理。

Aptos 和 Sui 是近期市场讨论度很高的两大公链，其原因不仅在于这两个均来自 Facebook 的团队都拿了高融资额，更在于他们都使用了 Move 编程语言对协议进行搭建。

**Aptos 和 Sui 都使用了他们自己的 Move 语言衍生版本，这有助于并行执行。**它是 Rust 风格的，具有静态强制和严格的资源所有权规则和形式验证。

Sui 版本的 Move 引入了一些修改，最明显的是所有权 API。它更简洁，也更清晰地展示了区块链设计。但是库（libraries）的开发感觉不如 Aptos。

Sui 使用基于 DAG 的内存池（Narwhal）+ Tusk 共识算法。然后在执行层利用 DAG 进行并行化（酷！）。与 Avalanche (Snowman++) 相比，在并行化方面它尚未释放 DAG 的全部功能。

Sui 版本的 Move 对对象的独有/共享及可变/不可变状态非常明确。这实现了直观的编程模型。此外，它使 Sui 能够使用可靠广播 (FastPay) 进行非共享对象交易，例如支付。

Aptos 使用 BlockSTM，它是高性能 HotStuff 算法的演进，并通过动态检测依赖关系和调度执行任务来引入并行化（灵感来自软件交易内存）。

很难说哪一个会在实践中表现更好，但我看好的是 Sui。Aptos 在优化当前设计方面已经做得很好，而 Sui 似乎还有更多空间。双路径实现拜占庭共识也让 Sui 占了上风。

值得注意的是，两条链都没有针对 home 验证者案例和大规模去中心化进行优化，而是归入了「最大化网络容量」阵营（即像 Solana 一样）。状态（State）增长可能是瓶颈。

**Sui 通过高效的存储分片来解决这个问题，专注于横向扩展资源。另一方面，Aptos 更加强调支持异构验证器（受限 CPU 和/或受限存储）。**我喜欢 Sui 的做法。

它们都处于相似的发展阶段，Aptos 有点领先。设置系统花费的时间比实际码代码 (我也恰好使用 NixOS）还要多。学习语言和环境也需要一些反复试验。

部署到 devnet 在这两种情况下都有些麻烦。幸运的是，单元测试库非常有用。

最糟糕的部分是晦涩难懂的编译器报错，以及毫无意义的 devnet 错误响应。这些应该马上解决。