Move 第一部分：Move安全性（Aptos）

你听说过 Move 吗？

Move 语言是区块链技术中的一项创新，旨在使智能合约编程更加安全。鉴于近年来在 DeFi 黑客攻击中损失的数十亿美元，区块链生态系统需要更安全的工具，才能真正扩展到大众市场。然而，实现这一目标绝非易事。我们探讨了 Move 是否能够解决这个问题。

为了提供背景，Move 语言源于 Meta 在 2019 年中止的 Diem 项目。参与该项目的团队希望保持这一构想的生命力，因此激发了独立的运动以实现这一愿景。今天，Aptos 和 Sui 两个团队构成了 Move 生态系统的主要部分，每个团队都属于原始 Diem 团队的某个子集。

为什么会有两个 L1 试图同时实现相同目标，并使用相对相同的基础技术？因为这是区块链，而这就是我们的做法。让我们对此进行进一步探索。

值得注意的是，Sui Move 与 Move 语言↗ 的工作方式略有不同，但基本概念仍然相同。本文及其内容将主要聚焦于 Aptos Move。

第0节：什么是 Move？核心概念

在其核心，Move 是一种专门为区块链设计的语言。它编译成 Move 字节码并在链上执行。存在一个验证器，用于验证字节码的内存安全（像 Solana 一样）和类型安全（与 Solana 不同）。

对于 Aptos，存在 Accounts，而不是直接的公/私钥对（例如 ETH/Solana）。Accounts 具有可以旋转的身份验证密钥，这些密钥用于签名来自该 Account 的交易。每个账户可能有多个身份验证密钥。

Move 中的主要区分因素是其线性类型系统。线性类型系统包含 resources。可以将 resource 想象为一种永远不能被复制或丢弃的类型，只能在账户和位置之间移动。想象它们像你可以在不同位置之间移动的实物对象。

每个 Account 包含 resources 和编译模块的组合。每个账户可以拥有多个 resources 和模块。官方的 Accounts ↗ 文档对此进行了更深入的介绍。

例如，Move 中的 Coin（ERC20 等价物）是一种存储在实际持有 Coins 的账户中的资源。而不是通过单一合约记账（ERC20 中的 balances），Coin 资源会在每次转账时进行移动（所有权转移）。这一范式看似简单，但对于组合性、可扩展性和安全性却具有深远的影响。

以下是你需要了解的关于资源的主要内容：

• 每个资源由定义它的模块管理。它对该资源及其属性拥有完全的控制和所有权。只有该模块可以将其分配给其他账户。
• 如果资源被分配给另一个账户，那么该账户将无法执行任何未在定义模块的 API 中暴露的操作。

有关 Aptos 上 Move 的更深入介绍，你可以参考官方指南 这里↗。

第1节：与 Solidity 的比较

让我们回顾一下 Solidity 的一些缺陷，看看 Move 在安全性方面的表现如何。

溢出/下溢

所有错误中的经典错误。如果你不熟悉，溢出/下溢发生在你超出了整数类型分配的最大值或最小值。

例如，uint8 的最大值可以是 255，因此加 1 应该溢出为 0（或者出错）。在绝大多数情况下，尤其是在区块链上，溢出回滚而不是环绕到 0 更为理想。

你不想要在将 1 加到 255 后拥有 0 个Coin，对吗？

让我们看看在 Move 中的表现：

#[test]
fun test_overflow(): u8 {
   let num: u8 = 255;
   num = num + 1;
   return num
}

VMError (如果有的话)： VMError {
  major_status: ARITHMETIC_ERROR,
  sub_status: None,
  message: None,
}

很好！它在虚拟机执行过程中被捕捉为“算术错误”。

但有一个警告。即使在 Solidity 0.8+ 中有溢出检查，位运算符中的溢出仍没有任何预防措施。让我们看看 Move 如何处理这个问题：

#[test]
fun test_overflow(): u8 {
   let num: u8 = 255;
   num = num << 2;
   return num
}

不太好。255 向左移动时溢出，但没有回滚。

这不是一个关键问题，因为这些位运算符没有你所说的日常算术运算那么普遍。

除法精度

与 Solidity 类似，我们没有浮点数的奢侈。这使得我们的除法截断，并为精度错误留出了空间。例如，在这里，我们可以看到 35 除以 6 等于 5（向下取整）。

#[test]
public fun division_precision() {
    let floored_div = 35 / 6;
    debug::print<u8>(&floored_div);
}

运行 Move 单元测试
[debug] 5

重入

这个经典错误一直困扰着以太坊……但 MoveVM 是否能缓解这个问题？

Move 提供的一个特性是没有动态调度（对泛型有一些警告）。这 本质上意味着函数是在编译时而不是运行时解析和链接的。考虑以下示例：

如果我们查看 Solidity 中的以下函数，就无法确定 arbitrary_call 将调用哪个函数。可以提供任何地址和数据：

function arbritrary_call(address addr, bytes calldata data) {
    addr.call{value: 1000}(data);
}

在 Move 中，这直接是不可能的。我们想要调用的任何外部模块都必须事先声明并导入（即使作为存根），且在运行时无法动态计算。

那么问题仍然是：这能防止重入吗？

在很大程度上是的。在链接阶段会进行循环依赖检查，这将捕获大多数（如果不是全部）重入情况。

以下代码和输出描绘了这一场景的一个示例：

module PropertyTesting::callback_module {
    use PropertyTesting::airdrop_module;

    public fun on_token_received() {
        file_4::claim_airdrop(@0x5, @0x7);
    }
}

module PropertyTesting::airdrop_module {

use PropertyTesting2::callback_module;
// use std::signer::{address_of};

struct Coin has key {
    value: u64
}

struct Airdrop has key {
    claimed: bool
}

public fun init(receiver: &signer, bank: &signer) {
    move_to<Airdrop>(bank, Airdrop {
        claimed: false
    });
    move_to<Coin>(bank, Coin {
        value: 100
    });
    move_to<Coin>(receiver, Coin {
        value: 10
    });
}

// receiver: 0x5 bank: 0x7

const ERROR_ALREADY_RECEIVED: u64 = 100;

public fun claim_airdrop(receiver: address, bank: address) acquires Coin, Airdrop {
    // 检查援助金是否已被领取
    let claimed = &mut borrow_global_mut<Airdrop>(bank).claimed;
    assert!(!*claimed, ERROR_ALREADY_RECEIVED);

    // 减少银行的余额
    let value = &mut borrow_global_mut<Coin>(bank).value;
    *value = *value - 10;

    // 增加用户的余额
    let value = &mut borrow_global_mut<Coin>(receiver).value;
    *value = *value + 10;

    // 通知用户事件已发生
    callback_module::on_token_received();

    // 不让他们声称两次……应该是？
    *claimed = true;
}

本质上，这是一个带有回调的空投合约，我们的 callback_module 的回调。

// 通知用户事件已发生
callback_module::on_token_received();

理论上，它应该不编译或链接，因为 callback_module 和 airdrop_module 之间存在循环依赖。

以下是输出结果：

它如预期那样失败。

值得注意的是，虽然从安全的角度来看，这对 Move 来说很不错，但这也是有限制的，因此存在取舍。

第2节：一般安全性

拒绝服务

与其他区块链一样，计算是需要消耗 gas 的。因此，无界计算可能导致拒绝服务问题。例如，增长过大的向量在 for 循环中可能会构成危险。所有循环都应该严格检查，以确保它们在 gas 限制以内。

#[test] // 本代码超时！
public fun long_loop() {
    let i = 1;
    let n = 1000000;

    while (i <= n) {
        i = i + 1;
    };
}

访问控制

我们在 Move 代码中看到的最简单的访问控制形式是简单地检查签名者是否为特定地址。例如，这是一个来自 Aptos Core 的代码片段：

public fun assert_vm(account: &signer) {
    assert!(signer::address_of(account) == @vm_reserved, error::permission_denied(EVM));
}

它断言调用该函数的者是某个特定地址。

虽然这是访问控制的最简单形式，但非常有限。例如，如果我们希望更改谁有权限调用此函数，该怎么办？

进入能力模式。

什么是能力模式？

能力（Cap）指的是资源—由能执行某一特定操作的账户所拥有的资源。

这种模式非常酷，因为用户可以在需要时将其能力转移给其他人。

例如，以下代码展示了能力如何工作，并且可以根据类型进行参数化，以创建更为复杂的访问控制形式。

module PropertyTesting::cap_tester {
    use std::signer::{address_of};
    struct Type1 has key {}
    struct Type2 has key {}
    struct Capability<phantom TYPE> has key{}

    public fun cap_1_need(_cap: &Capability<Type1>) {}

    public fun cap_2_need(_cap: &Capability<Type2>) {}

    public fun get_cap_type1(person_1: &signer) {
        let cap_type_1 = Capability<Type1> {};
        move_to<Capability<Type1>>(person_1, cap_type_1);
    }
    public fun get_cap_type2(person_1: &signer) {
        let cap_type_2 = Capability<Type2> {};
        move_to<Capability<Type2>>(person_1, cap_type_2);
    }
    #[test(person_1 = @0x100)]
    public fun test_cap_1(person_1: &signer) acquires Capability {
        get_cap_type1(person_1);
        let cap: &Capability<Type1> = borrow_global<Capability<Type1>>(address_of(person_1));
        cap_1_need(cap);
    }
}

能力之所以有效，是因为只有声明该资源的模块才能将其分配给账户。该资源对于该模块是完全独特的，并且没有其他模块能够创建同样的资源，即使它们给了它同样的名称。在内部，这个规则是因为资源标识符与创建它的模块相关联。

以下是 Aptos 白皮书中的一个图片，展示资源标识符是如何从声明的模块派生的；例如，Coin资源名称从 0x3 开始，这是包的地址。

关键在于，如果你证明你拥有对一个资源的引用，这就足以证明某种身份，因为模块本身可以限制谁能够获取该资源（例如，模块可以编程，只将该资源分配给构造函数中的签名者或其他授权地址）。

我们的具体示例展示了更为复杂的用例，因为不仅用户通过调用 get_cap_1 或 get_cap_2 获得了能力，而且它们是按其提供的类型进行泛型化的，这在编译时进行了强制。

这意味着函数 cap_1_need 不能被传入一个引用 Capability 的人调用，因为在能力获取的类型上有额外的强制性。

奖励：资源警告

在我们对 Aptos 的研究中，我们发现了一种有趣的设计模式，其中某些有价值的资源被某种 holder 包装。这里有一个在 Coin.move↗ 中的示例。

// 代表账户保管的Coin/代币的主结构。
struct Coin<phantom CoinType> has store {
    /// 该地址拥有的Coin数量。
    value: u64,
}

// 特定Coin类型及相关事件处理的持有者。
// 这些被保存在单个资源中以确保数据的局部性。
struct CoinStore<phantom CoinType> has key {
    coin: Coin<CoinType>,
    frozen: bool,
    deposit_events: EventHandle<DepositEvent>,
    withdraw_events: EventHandle<WithdrawEvent>,
}

这是因为 Coin 具有 store 的类型能力，这意味着它不能直接存储在全局存储中。另一方面，CoinStore 具有 key，允许它存储在全局存储的顶层。

我们可以看到 CoinStore 包装了 Coin 以及一些元数据。这是一种常见的设计模式，为资源添加额外的信息，例如 Events。你可以将 Coin 视为真金白银，将 CoinStore 视为你的钱包。

这一切都是好的，但当需要从其他模块传递资源时，事情会变得有些复杂。问题在于 resource\ 只能通过其定义的\ module↗ 来操作。

然而，如果一个外部模块返回一个资源，我们可以将其包装在我们的包装资源中。虽然我们不能直接修改它，因为它没有在我们的模块中声明，但我们仍然可以获得对它的引用。这就是能力可以被外部账户存储，同时仍然保持可借用引用的方法。

回到 Coin 模块，我们发现这个属性可能会妨碍 冻结/销毁\ coins↗。

public fun burn_from<CoinType>(
    account_addr: address,
    amount: u64,
    burn_cap: &BurnCapability<CoinType>,
) acquires CoinInfo, CoinStore {
    // 如果金额为零，则跳过销毁。这不应该出错，因为它在交易手续费销毁时调用。
    if (amount == 0) {
        return;
    };

    let coin_store = borrow_global_mut<CoinStore<CoinType>>(account_addr);
    let coin_to_burn = extract(&mut coin_store.coin, amount);
    burn(coin_to_burn, burn_cap);
}

如我们所见，燃烧的Coin是从 CoinStore↗ 中提取的。

如果用户决定不将其Coin存放在 CoinStore 中，会发生什么？他们的Coin将会无法冻结/销毁。

一个账户可以定义自己的 Coin 包装

struct NotCoinStore<phantom CoinType> has key{
    coin: Coin<CoinType>
}

并实质上将 Coins 存储在 NotCoinStore 中。这将打破 coin.move↗ 中的大多数期望 Coins 存储在 CoinStore 中的功能，包括燃烧和冻结。

这可能导致 Coins 对 coin 模块变得不可访问，因为它无法借用 NotCoinStore 的引用。以下是一个小型测试用例来验证这个问题：

module PropertyTesting::file_2 {
    use PropertyTesting::file_1::{Self, USDC};
    // use aptos_std
    // use aptos_std::debug;
    use std::signer::{Self, address_of};
    use aptos_framework::coin::{Self, Coin, balance};

    struct NotCoinStore<phantom CoinType> has key{
        coin: Coin<CoinType>
    }

    #[test(signer = @PropertyTesting, random_account = @0x69)]
    #[expected_failure(abort_code = 0x5000A)] //因冻结而失败
    public fun coins_can_be_frozen(signer: &signer, random_account: &signer) {
        aptos_framework::account::create_account_for_test(signer::address_of(signer));
        aptos_framework::account::create_account_for_test(signer::address_of(random_account));

        coin::register<USDC>(signer);
        coin::register<USDC>(random_account);

        let coins = file_1::generate_coin(signer);
        coin::deposit<USDC>(signer::address_of(signer), coins);

        coin::transfer<USDC>(signer, signer::address_of(random_account), 1000);
        assert!(balance<USDC>(signer::address_of(random_account)) == 1000, 1);

        file_1::freeze_coins(signer::address_of(signer));

        coin::transfer<USDC>(signer, signer::address_of(random_account), 1000);
    }

    #[test(signer = @PropertyTesting, random_account = @0x69)]
    public fun unfreezable_coins(signer: &signer, random_account: &signer) acquires NotCoinStore {
        aptos_framework::account::create_account_for_test(signer::address_of(signer));
        aptos_framework::account::create_account_for_test(signer::address_of(random_account));

        coin::register<USDC>(signer);
        coin::register<USDC>(random_account);

        let coins = file_1::generate_coin(signer);

        let coin_holder = NotCoinStore {
            coin: coins
        };

        move_to(signer, coin_holder);

        //coin::transfer<USDC>(signer, signer::address_of(random_account), 1000);
        transfer<USDC>(signer, signer::address_of(random_account), 1000);
        assert!(balance<USDC>(signer::address_of(random_account)) == 1000, 1);

        file_1::freeze_coins(signer::address_of(signer));

        transfer<USDC>(signer, signer::address_of(random_account), 1000);
        assert!(balance<USDC>(signer::address_of(random_account)) == 2000, 1);
    }

    public fun transfer<CoinType>(from: &signer, to: address, amount: u64) acquires NotCoinStore {
        let coins = &mut borrow_global_mut<NotCoinStore<USDC>>(signer::address_of(from)).coin;
        let real_coins = coin::extract(coins, amount);

        coin::deposit<USDC>(to, real_coins);
    }
}

module PropertyTesting::file_1 {

    use aptos_framework::coin::{Coin};
    use std::signer;
    use std::string::{utf8};
    // use aptos_framework::account;

    struct Authorities<phantom CoinType> has key {
        burn_cap: BurnCapability<CoinType>,
        freeze_cap: FreezeCapability<CoinType>,
        mint_cap: MintCapability<CoinType>,
    }
    use aptos_framework::coin::{Self, MintCapability, BurnCapability, FreezeCapability};

    struct USDC has key {}

    public fun generate_coin(signer_1: &signer): Coin<USDC> acquires Authorities {
        let (burn_cap, freeze_cap, mint_cap) = coin::initialize<USDC>(signer_1, utf8(b"hey"), utf8(b"b"), 8, false);
        let authorities = Authorities {
            burn_cap,
            freeze_cap,
            mint_cap
        };

        move_to<Authorities<USDC>>(signer_1, authorities);
        let mint_cap_ref = &borrow_global<Authorities<USDC>>(signer::address_of(signer_1)).mint_cap;
        let ten_thousand_coins: Coin<USDC> = coin::mint<USDC>(10000, mint_cap_ref);
        ten_thousand_coins
    }

    public fun freeze_coins(person_1: address) acquires Authorities {
        let freeze_cap = &borrow_global<Authorities<USDC>>(person_1).freeze_cap;
        coin::freeze_coin_store<USDC>(person_1, freeze_cap);
    }

    public fun burn_coins(person_1: address) acquires Authorities {
        let burn_cap = &borrow_global<Authorities<USDC>>(person_1).burn_cap;
        coin::burn_from<USDC>(person_1, 10000, burn_cap);
    }
}

这里发生了什么？ PropertyTesting::File_1 正在初始化Coin并将能力交给各自的签名者。

PropertyTesting::File_2 让我们看到了燃烧和冻结的限制。

让我们看一下测试用例 _coins_can_befrozen。用户向随机账户发送Coin，它正常工作，这通过检查余额的断言得到了体现。然后使用冻结能力冻结转账，因此用户的转账尝试失败。

#[test(signer = @PropertyTesting, random_account = @0x69)]
#[expected_failure(abort_code = 0x5000A)] //因冻结而失败
public fun coins_can_be_frozen(signer: &signer, random_account: &signer) {
    aptos_framework::account::create_account_for_test(signer::address_of(signer));
    aptos_framework::account::create_account_for_test(signer::address_of(random_account));

    coin::register<USDC>(signer);
    coin::register<USDC>(random_account);

    let coins = file_1::generate_coin(signer);
    coin::deposit<USDC>(signer::address_of(signer), coins);

    coin::transfer<USDC>(signer, signer::address_of(random_account), 1000);
    assert!(balance<USDC>(signer::address_of(random_account)) == 1000, 1);

    file_1::freeze_coins(signer::address_of(signer));

    coin::transfer<USDC>(signer, signer::address_of(random_account), 1000);
}

一切都按预期进行。

然而在测试用例 _unfreezablecoins 中，用户生成Coin并将其保存在自己的资源 NotCoinStore 中，而不是 Coin 模块提供的默认 CoinStore 中。

#[test(signer = @PropertyTesting, random_account = @0x69)]
public fun unfreezable_coins(signer: &signer, random_account: &signer) acquires NotCoinStore {
    aptos_framework::account::create_account_for_test(signer::address_of(signer));
    aptos_framework::account::create_account_for_test(signer::address_of(random_account));

    coin::register<USDC>(signer);
    coin::register<USDC>(random_account);

    let coins = file_1::generate_coin(signer);

    let coin_holder = NotCoinStore {
        coin: coins
    };

    move_to(signer, coin_holder);

    //coin::transfer<USDC>(signer, signer::address_of(random_account), 1000);
    transfer<USDC>(signer, signer::address_of(random_account), 1000);
    assert!(balance<USDC>(signer::address_of(random_account)) == 1000, 1);

    file_1::freeze_coins(signer::address_of(signer));

    transfer<USDC>(signer, signer::address_of(random_account), 1000);
    assert!(balance<USDC>(signer::address_of(random_account)) == 2000, 1);
}

他们仍然可以通过以下方法执行Coin操作，例如转账：

public fun transfer<CoinType>(from: &signer, to: address, amount: u64) acquires NotCoinStore {
    let coins = &mut borrow_global_mut<NotCoinStore<USDC>>(signer::address_of(from)).coin;
    let real_coins = coin::extract(coins, amount);

    coin::deposit<USDC>(to, real_coins);
}

它们没有受到冻结的影响。正如在这个测试用例中所看到的，即使在冻结后，_randomaccount 的余额仍然上升，使其变得无效。

该示例可以轻松调整为拥有 unburnable coins，即用户将其Coin not 存放在默认 CoinStore 中，因此不能被烧毁。

对于像 USDC 和 USDT 这样的稳定币，冻结资产是一个重要的监管措施。我们将看到生态系统如何演变以应对此类问题。

值得注意的是，实际上，其影响可能与 ETH/SOL 上的包装资产类似，因为它们的支持库也无法被冻结。

结论

在我们的调查中，我们注意到 Move 具有许多安全属性，使其成为安全且有用的智能合约编程语言。显然，该语言的设计旨在同时缓解我们在其他区块链语言中观察到的一些缺陷。它定义了一种创建和管理数字资产的新模式。尽管如此，仍然存在一些基本问题可能需要解决。总体来说，我们非常期待看到生态系统如何成熟，以及开发人员采用何种设计模式。

在即将到来的系列中，我们还将关注 Move prover，它可以正式验证智能合约，提供最终的安全保障。我们还将探索 Aptos 核心中的其他设计模式，请保持关注！

你想在没有审计的情况下发布你的 Move 合约吗？希望不是。如果你希望发现编码错误、设计缺陷和经济问题，请填写我们的 联系表单↗。我们很乐意提供帮助。

关于我们

Zellic 专注于保护新兴技术。我们的安全研究人员已经发现了在来自《财富》500 强公司到 DeFi 巨头的最有价值目标中的漏洞。

开发人员、创始人和投资者信任我们的安全评估，以便快速、自信地交付，同时不会存在关键漏洞。凭借我们在现实世界攻击性安全研究中的背景，我们发现了其他人遗漏的东西。

‍请 联系我们↗，进行更好的审计。真实审计，而不是走过场。

• 原文链接： zellic.io/blog/move-fast...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～