Solidity方案：回调与运行时检查

闪电贷作为DeFi基础原语，允许无抵押借贷但需在同一交易内还款，历来是把双刃剑。尽管为合规用户提供套利和债务重组机会，但也常被攻击者利用以放大盗取资金规模。我们发现Sui的Move语言通过用"烫手山芋"模型取代Solidity依赖的回调与运行时检查，在语言层面显著提升闪电贷安全性。

Solidity传统实现模式

Solidity闪电贷协议传统采用回调模式，虽提供最大灵活性但将安全责任完全置于开发者肩上。典型流程包含：

借款合约调用借贷协议的flashLoan函数
协议将代币转移至借款合约
协议调用借款合约的onFlashLoan函数
借款合约使用借入代币执行逻辑
借款合约偿还贷款
原始借贷协议检查余额确认还款，若未归还则回滚交易

这种基于回调的模式要求协议开发者在函数末尾实现余额检查（图2）。由于协议需对借款合约进行外部调用，开发者必须谨慎管理状态以防重入风险。Fei Protocol在2022年因黑客利用系统缺陷（未遵循检查-效果-交互模式）损失8000万美元。

1
2
3
4
5
6
7
8


function flashLoan(uint256 amount, address borrowerContract) external {
    uint256 balanceBefore = token.balanceOf(address(this));
    token.transfer(borrowerContract, amount);
    borrowerContract.onFlashloan();
    if (token.balanceOf(address(this)) < balanceBefore) {
        revert RepayFailed();
    }
}

此外，早期缺乏标准接口导致碎片化问题。尽管EIP-3156后来提出单资产闪电贷标准（贷款方从借款方拉回资金而非等待推送），但尚未被所有主流DeFi协议采纳，且自带安全挑战。

Sui Move方案：可组合安全性

Sui的闪电贷实现根本性不同，其利用平台三大核心特性——独特对象模型、可编程交易区块(PTBs)和字节码验证器，在语言层面提供安全保证。

Sui对象模型与Move能力系统

理解Move安全保证需先掌握Sui对象模型。在以太坊账户模型中，代币余额仅是账本（ERC20合约）中的数字记录，用户钱包并不直接持有代币。相反，Sui以对象为中心的模型将每个资产（代币、NFT、管理权或流动性头寸）视为独立对象，用户账户直接拥有这些对象，无需中央合约账本。

Move能力系统通过编译时属性定义对象使用方式：

key: 允许对象作为存储键使用
store: 允许对象存储在具有key能力的对象中
copy: 允许对象被复制
drop: 允许对象在交易结束时被丢弃

闪电贷的关键优势来自能力省略。无能力的对象无法存储、复制或丢弃，成为必须在同一交易内被消耗的"烫手山芋"收据。若未被消耗，交易将无效执行。

PTB工作机制

在以太坊中，与DeFi协议交互需多个独立交易（如代币批准与交换），而Sui的PTB允许将多个操作链接为原子交易。关键区别在于PTB允许前序操作的输出作为后续操作的输入，全部在同一区块内完成。

1
2
3
4
5
6
7
8


# 该PTB在一个原子交易中完成借贷、两次交换和还款
$ sui client ptb \
--move-call $DEEPBOOK::vault::borrow_flashloan_base @$POOL 1000000000 \
--move-call $CETUS::swap result(0,0) @$CETUS_POOL \
--move-call $TURBOS::swap result(1,0) @$TURBOS_POOL \
--move-call 0x2::coin::split result(2,0) 1000000000 \
--move-call $DEEPBOOK::vault::return_flashloan_base @$POOL result(3,0) result(0,1) \
--transfer-objects [result(2,0)] @$SENDER

字节码验证器

Move字节码验证器在模块发布时执行静态验证，强制类型、资源、引用和能力约束。其工作流程分两阶段：编译器对源码进行类型检查并生成字节码，随后字节码验证器在字节码层级再次执行检查，拒绝任何类型错误或不安全代码，防止手工字节码绕过"烫手山芋"限制。

实战中的烫手山芋模式：DeepBookV3

DeepBookV3的闪电贷实现使用该模式创建无需回调或运行时余额检查的安全系统。流程简洁：

用户调用borrow_flashloan_base
函数返回两个对象（Coin<BaseAsset>, FlashLoan）：借贷资金币对象和闪电贷收据对象
用户使用币对象执行操作
用户调用return_flashloan_base，传回借贷资金和收据
最终函数消耗收据，交易成功完成

关键在于FlashLoan结构体定义故意省略能力：

1
2
3
4
5


public struct FlashLoan {
    pool_id: ID,
    borrow_quantity: u64,
    type_name: TypeName,
}

由于该结构体是"烫手山芋"，交易有效的唯一方式是通过将其传递给return_flashloan_base函数进行消耗：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


public(package) fun return_flashloan_base<BaseAsset, QuoteAsset>(
    self: &mut Vault<BaseAsset, QuoteAsset>,
    pool_id: ID,
    coin: Coin<BaseAsset>,
    flash_loan: FlashLoan,
) {
    // 验证逻辑
    self.base_balance.join(coin.into_balance<BaseAsset>());
    let FlashLoan { ... } = flash_loan; // 消耗收据
}

烫手山芋模式如何确保还款

该模式结合PTB原子性创建内置安全保证。Move字节码验证器防止无效字节码执行，例如：

若交易调用borrow_flashloan_base但未消耗返回的FlashLoan对象，因结构体缺乏drop能力无法丢弃，交易无效
若开发者构建PTB时省略最终还款调用，MoveVM识别未处理的"烫手山芋"并中止整个交易

未能还款不再是开发者需防范的风险，而是系统通过设计防止的逻辑不可能。有效可执行交易必须包含还款逻辑。

通过设计实现安全

Sui Move使语言本身成为主要安全卫士。Solidity要求开发者实现运行时检查和谨慎状态管理，而Move类型系统首先使不安全代码难以编写。可与Rust安全模型类比：正如Rust编译器保证内存安全，Sui Move类型系统通过字节码验证器保证资产安全。该模型将安全执行从开发者实现的运行时检查转移至语言自身的字节码验证规则。