跳到主要内容

Move VM 内存安全 vs EVM 重入：为什么 Aptos 和 Sui 的资源模型消除了整类智能合约漏洞

· 阅读需 11 分钟
Dora Noda
Dora Noda
Software Engineer

2016 年的 The DAO 攻击在短短一个下午就从以太坊（Ethereum）中抽走了 6000 万美元。九年后，重入攻击（reentrancy attacks）依然让 DeFi 协议蒙受巨大损失，仅 2024 年就在 22 起独立事件中造成了 3570 万美元的损失。尽管经过多年的开发者教育、审计工具完善和实战检验的模式，同一类漏洞——攻击者在合约状态更新之前再次调用合约——依然困扰着 EVM 生态系统。

Aptos 和 Sui 均基于 Move 语言构建，它们采用了从根本上不同的方法：通过设计使整类漏洞变得不可能。

根本原因：EVM 重入攻击是如何发生的​

为了理解为什么 Move 不同，首先需要了解为什么以太坊上会发生重入攻击。

Solidity 合约可以在执行过程中调用外部合约。当合约 A 调用合约 B 时，执行权完全转移给 B。B 随后可以再次调用 A（即“重入”），而此时 A 尚未完成其内部状态的更新。如果 A 的提现逻辑如下所示：

// 易受攻击的模式
function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}(""); // 先进行外部调用
    balances[msg.sender] -= amount;                         // 后进行状态更新
}

攻击者的合约可以在回调中接收 ETH，立即再次调用 withdraw，并在 balances[msg.sender] 被递减之前取走资金。这正是 The DAO 攻击中发生的事情——攻击者的合约在循环中递归调用了提现函数 360 万次。

修复方案听起来很简单：在进行外部调用之前更新状态（即“检查-生效-交互”模式）。但开发者会忘记，审计员也会疏忽。这种模式只是一种依靠人为尽职调查而非语言本身强制执行的惯例。

Move 的方法：资源无法被复制或销毁​

Move 从底层设计上就旨在通过类型系统层面防止此类错误。其核心概念是线性类型系统（linear type system）和资源类型（resource types）。

在 Move 中，资源是一种特殊的值：

  • 不可复制——它只能在存储位置之间移动。
  • 不可丢弃——它必须被显式消费或存储在某处。
  • 在任何给定时刻只有一个所有者——由虚拟机（VM）跟踪，而非通过映射（mapping）跟踪。

这听起来很抽象，但影响却非常具体。考虑代币转账的工作原理：

  • 在 Solidity 中，代币余额是映射中的一个 uint256 数值。如果更新顺序错误，该数值理论上可以被操纵。
  • 在 Move 中，代币是存在于账户存储中的实际资源对象。你物理上将其从一个位置移动到另一个位置——不存在资源同时存在于两个地方或无处存在的中间状态。

Move 虚拟机在字节码级别强制执行这些不变性，而非在源代码级别。即使开发者写出了有问题的代码，虚拟机也会拒绝任何试图复制或静默丢弃资源的交易。

为什么重入攻击在 Move 中在结构上是不可能的​

重入攻击需要两个条件：在执行过程中调用外部代码的能力，以及在回调期间可以被操纵的可变共享状态。Move 打破了这两个条件。

Move 不允许像 Solidity 那样进行动态分派（dynamic dispatch）。它不存在将控制权传递给未知代码的任意外部调用。函数必须进行静态调用——调用目标在编译时就是确定的。这意味着攻击者无法部署一个在回调期间重入你模块的合约，因为你的模块绝不会将执行权交给未知的外部合约。

此外，Sui 和 Aptos 上的 Move 对象模型使用所有权系统，对象被显式地传入和传出函数。一个被“移动进入”函数的对象在函数返回之前，在其他任何地方都无法访问。在单个交易中并发访问同一个资源是根本不可能的。

2025 年发表的研究证实：“在 Move 中，由于无法进行动态回调，重入是不可能的——这是与 Solidity 的根本区别，在 Solidity 中重入仍然是一个主要威胁。”

无需互斥锁的双花防护​

在基于 EVM 的系统中，双花保护（double-spend protection）依赖于谨慎的编程。开发者必须通过勤奋地跟踪状态更新，手动确保一个代币在一次交易中不会被消费两次。

Move 的线性类型系统使双花在结构上变得不可能。因为资源无法被复制，消费一枚代币会将其从你的账户存储中彻底移除。在一次交易中无法消费同一个资源两次，因为在第一次消费后，该资源已不再受你控制。这是由虚拟机强制执行的——它不是一种惯例，而是一种约束。

这也延伸到 Sui 上的权限（Capability）对象。一个 Capability 资源一旦被消费，就无法再次使用。相比之下，EVM 的访问控制模式通常是将权限编码为布尔值或地址映射中的角色，这可以被多次检查。

Sui 上发生的一个真实案例凸显了一个细微差别：某 DEX 被发现存在缺陷，其提现逻辑未能对权限的“可变引用（mutable reference）”执行单次使用约束，而不是权限对象本身。这表明虽然 Move 的资源模型消除了整类漏洞，但开发者在处理引用而非拥有资源时，仍可能引入逻辑错误。威胁面已大幅缩小，但并非为零。

整数溢出：Move 默认解决的另一个问题​

在早期的 Solidity（0.8.0 版本之前）中，整数算术在发生溢出时会静默回绕。这使得攻击者能够通过触发溢出条件来操纵代币余额——这种漏洞导致了数起备受关注的 DeFi 攻击事件。

Solidity 0.8.0 引入了自动溢出检查，但这发生在造成多年损害之后。Move 自诞生之初就包含了这种保护：任何导致整数溢出的交易都会自动终止。Move 没有退出机制，默认情况下没有等同于 unchecked 的操作，也没有需要担心的旧行为遗留合约。

形式化验证：Move Prover 与 EVM 审计​

Move 的安全特性不仅限于语言本身，还扩展到了其工具链。Move Prover 是一个与语言本身同步构建的形式化验证工具，而非事后的补救措施。

借助 Move Prover，开发者可以使用规范语言直接在 Move 源文件中编写规范（Specifications）。随后，这些规范会针对实现进行数学验证。例如，一个规范可以断言：“该函数执行后，代币总供应量保持不变。” Prover 要么确认这在任何情况下都成立，要么提供一个确切说明失败情况的反例。

这与大多数 Solidity 审计的工作方式有本质区别：

维度Move ProverSolidity 审计工具
验证类型数学证明模式匹配 / 模糊测试
覆盖范围完整（在规范范围内）尽力而为
集成方式语言工具链的一部分第三方工具（Slither, Certora）
时间节点开发阶段部署前审计
成本免费，库内自带昂贵的人工审计

像 Slither 这样的 Solidity 工具执行静态分析并检测已知的漏洞模式。用于 Solidity 的 Certora Prover 确实支持形式化验证，并且可以表达更广泛的属性——包括跨交易的不变量。但 Certora 要求使用单独的语言编写规范并运行独立的流水线，使其成为一个专门的审计步骤，而不是日常开发工具。

Move Prover 更紧密的集成意味着 Aptos 和 Sui 开发者可以在开发期间在本地运行形式化验证，而不仅仅是将其作为一个昂贵的审计关卡。Aptos 框架本身为其标准库附带了 Move Prover 规范，为应用开发者继承安全性奠定了基础。

残留风险：Move 无法消除的问题​

Move 的设计并非万能的安全保证。对 Move 合约的实际审计显示，开发者仍可能引入：

  • 业务规则中的逻辑错误（最常见的类别）
  • 使用可变引用而非所有权资源时的访问控制漏洞
  • DeFi 协议中的经济设计缺陷（价格预言机操纵、闪电贷攻击）
  • 多个模块以意外方式交互时的跨模块交互漏洞

2024 年的一项研究手动审计了 652 个 Move 合约，并识别出 8 种缺陷类型，其中一半是以前未报告过的。攻击面虽然比 Solidity 小，但仍然存在。

在 Aptos 和 Sui 上最佳的安全实践是结合 Move Prover 规范、第三方审计和经济安全分析，而不仅仅是依赖语言的内置保护。

为什么这对于 2025 年的 DeFi 构建者至关重要​

数据说明了一个严峻的事实。2024 年，智能合约漏洞导致 DeFi 领域损失超过 14 亿美元。其中，重入攻击贡献了 3570 万美元——如果是在具有等效 TVL 的基于 Move 的链上，这一类别的损失在结构上将为零。

对于构建金融应用的开发者来说，选择虚拟机（VM）实际上是选择默认的威胁模型。在 EVM 上构建意味着必须将“检查-效果-交互”（Checks-Effects-Interactions）模式作为一项强制性的纪律。在 Move 上构建意味着重入攻击根本不在你的威胁模型中——你的团队可以将安全注意力集中在逻辑错误和经济设计上。

这并非细微的差别。当威胁面更小时，形式化验证工具的效果更好。当审计人员不需要在已知的漏洞类别上耗费精力时，他们可以进行更深层次的挖掘。当语言自动强制执行关键的不变量时，开发者编写正确代码的认知负荷就会降低。

基础设施层​

只有当开发者能够大规模地在这些链上构建时，安全保证才有意义。运行自己的 Aptos 或 Sui 节点以访问网络涉及巨大的运营开销——硬件配置、软件升级、监控和事件响应。

BlockEden.xyz 为 Aptos 和 Sui 提供企业级 API 访问，让开发者在利用 Move 的安全保证的同时，无需管理节点基础设施。探索我们的服务 以构建更安全的 Web3 应用。

内存安全语言、结构化重入防护和集成的形式化验证相结合，使 Aptos 和 Sui 成为高风险 DeFi 应用极具吸引力的平台。Move 不仅降低了编写安全智能合约的难度，它还使某些类别的灾难性故障在数学上成为不可能。

参考资料：

Share on Twitter