波宝pro苹果下载官网|同是MOVE语言，Sui 与 Aptos 开发技术谁优劣？

Sui 与 Aptos 都属于 Move 语系，而他们两者技术方面有什么不同？本文源自 Shark Team 团队的研究文章《Sui 与 Aptos 技术实现对比》，由 DeFi之道 整理。 （前情提要： Sui推出「永久」测试网，将持续运作、不再重置，预告Q2上线主网） （背景补充： Move系公链｜Sui预告Q2上线主网，如何埋伏空投、技术创新？）

本文目录

• 1. 共识机制
• 2. 帐户模型
• 3. 能力
• 4. 所有权
  • 4.1 Owned 所有权
  • 4.2 Shared 所有权
• 6. 初始化
  • 6.1 Aptos 初始化函式
  • 6.2 Sui 初始化函式
• 7. 安全性
  • 7.1 Overflow
  • 7.2 访问控制

近期，随着 Sui 主网即将上线，围绕 Aptos 和 Sui 的讨论也逐渐增加，社群也非常活跃，大家都在讨论 Aptos 和 Sui 的异同。其实公链技术并没有绝对的优势和劣势，主要还是看与业务的适用程度以及基础效能、安全性等。

SharkTeam 之前对 Aptos、Sui、StarCoin 等 Move 语言公链进行了深入研究，我们将进行一些对比和分享，这是第一期，希望对 Move 开发者选择适合自己业务的公链有帮助。

1. 共识机制

Aptos 和 Sui 都是 PoS 共识模型，但是两者细节实现有些不同。

Aptos 採用基于 BFT 的 HotStuff，在此基础上，Aptos 开发了 Block-STM  执行引擎。Block-STM 执行引擎提高了吞吐量降低了延迟。

Sui 採用了 Narwhal 和 Tusk。Narwhal 是基于 DAG 的记忆体池模组（mempool），主要负责交易资料的可用性。Tusk 是共识模组，主要是对负责交易进行排序。

2. 帐户模型

在以太坊中有两个帐户：EOA 和 合约帐户。帐户的本质是地址，在 Aptos 和 Sui 中，地址有所不同。

在 Aptos 中，每个帐户是由资源和模组组成，每个帐户可以拥有多个资源和模组。资源是储存资料，模组是储存程式码。

在 Sui 中，没有帐户这一说法。Sui 的最小单位是物件（Object），所有建立的物件都会在 0x0 地址上。该 0x0 地址，一般是建立的包。比如，我用 sui move new learn 建立的一个专案，在 Move.toml 中

3. 能力

Core Move 提供了四种能力： Copy、Drop、Store、Key。

Copy ：允许此型别的值被複制 Drop ：允许此型别的值被弹出 / 丢弃 Store ：允许此型别的值存在于全域性储存的某个结构体中 Key ：允许此型别作为全域性储存中的键 (具有 key 能力的型别才能储存到全域性储存中)

在 struct 中，Copy 和 Drop 可以用于建立类似 Solidity 中 event，来获取日誌资讯。拥有 Store 和 Key，可以被认为资源物件。

Aptos 和 Core Move 能力特性一样。

Aptos 使用 Core Move 中的全域性储存操作符（move_to，move_from 等）。使用全域性储存操作符必须具有相应的 acquires 关键字去注释全域性资源。

Sui 有 Sui 物件，没有 Aptos 的 acquires 关键字。Sui 物件要储存在链上必须要有 Key 并且 struct 中要有一个特殊的成员栏位 id，它的型别是 sui::object::UID。物件 UID 具有唯一性，它通过 object::new (&mut TxContext) 建立，并通过 object::delete (UID) 销燬。

Sui 和 Aptos（Core Move）不同，拥有 Key 能力，并不意味着能够全域性储存。

在 Aptos（Core Move）中，任意 struct 被 Key 修饰后都可以作为资源储存在帐户中。合约在执行的时候，无论是不是被访问帐户，都可以通过 borrow_global 等一些全域性资源操作符去访问。

在 Sui 中，物件是 sui -> move 中直接传递，不能借助全域性操作符。比如，在 Sui 中储存物件必须通过函式 transfer::transfer (object, address) 进行储存。但是，该函式智慧在 entry 函式中使用。因为 entry 函式是用来物件资源交易入口函式。

4. 所有权

4.1 Owned 所有权

4.2 Shared 所有权

在 Aptos（Core Move）中 Shared 的所有权主要通过建立资源帐户，并且繫结资源帐户，合约之间间接共享。

在 Sui 中的某些物件不能被任何人修改，这些物件可以被读取。比如 Sui 中所有已释出的包和模组都是不可变物件。

transfer::freeze_object(obj)

在 Sui 中还有一种共享物件可以被任何人读取或修改，并且该共享物件交易需要通过共识协议进行全域性排序。

transfer::share_object(obj)

5.Signer 和 TxContext

在 Aptos 中，一个交易的签名者（signer）被直接作为一个引数传递到从 Move 外部呼叫的函式中。

签名者（signer）是 Move 内建的资源型别。签名者（signer）是一种允许持有者代表特定地址（address）行使权力的能力（capability）。你可以将原生实现（native implementation）视为：

struct signer has drop { a: address }

std::signer 标準库模组为 signer 提供了两个实用函式：

signer 有点像 Unix UID ，因为它表示一个通过 Move 之外的程式码（例如，通过检查加密签名或密码）进行身份验证的使用者。

在 Sui 中，TxContext 型别可以像对待 signer 一样被宣告为一个函式的引数，并且可以使用一个库函式从 TxContext 中获得签名者（signer）。此外，TxContext 还用于在 Sui Move 中建立 UID 。

6. 初始化

6.1 Aptos 初始化函式

Aptos 在 module 部署时，採用 signer 传入 init_module。

init_module(account: &signer)

6.2 Sui 初始化函式

Aptos 支援在具有类似签名的 module 部署时呼叫的初始化函式。 Sui 将在 module 部署时呼叫使用类似签名宣告的 init 函式。

init（&mut TxContext）

7. 安全性

7.1 Overflow

整数溢位问题，出现在 Solidity 0.8 之前版本中。Solidity 0.8 之前採用的是 SafeMath 安全库去处理溢位问题，Solidity 0.8 之后溢位问题在语言层面不在出现，Solidity 自带溢位处理。如果发生溢位，将会 revert。

那么，在 Move 中是否纯在溢位问题。我们简单写了一个测试例子。

从测试结果中可以得知，Move 在语言层面处理了溢位问题。如果发生溢位，Move 会出现 arithmetic error。

在 Solidity 0.8 之后，位运算不精确使用也会发生数值问题。

Move 中的位运算也同样存在相同问题。

适当的使用位运算可以节省 gas，但是同时要保证精确计算，否则会发生数值问题。

7.2 访问控制

在 Solidity 中，对于基本的访问控制，Openzepplin 提供了一个合约安全模板 Ownable。在该合约中，帐户的所有者可以被赋予特定的独佔访问许可权。

在 Move 中提供了一些 ability（key/store），通过 ability 对资源物件进行授权操作。同时，Move 中也有常用的设计模式，它允许以资源物件为中心来进行适当的访问控制。这种设计模式类似于有一个相应许可权的 “帽子”（Cap），我将一个 struct 赋予 key 能力但是不赋予 store。如下所示：

struct AdminCap has key{}

在 Aptos（Core Move）中，Cap 的设计如下：

在 Sui 中，Cap 的设计如下：

在 AdminCap struct 中，Sui 和 Aptos 相比，Sui 多了 UID 型别的 id。Sui 是没有帐户地址的概念，只能使用 id 进行索引物件。

在 init 函式中，我们建立了一个 AdminCap 的一个副本，将其传送到释出者的地址，让释出者拥有 Cap。

在 create_and_send 函式中，传入 AdminCap 并且立即採用_未使用变数符号对它使用。由于是引用物件，所以原来物件未变化。这时候，只有 AdminCap 拥有者才能进行呼叫执行该函式。