使用 Foundry 进行 Solidity 模糊测试与安全验证指南

引言

智能合约往往由于极少数临界参数下的逻辑失效（如整型向下溢出、负数条件判断缺失）而被黑客攻破。在过去，开发者依赖 Hardhat 编写基于 JavaScript 的常规单元测试。这种测试方式必须预先设定测试输入（如“测试 stake 10个币”），很难覆盖到那些超出常理的边界值。

为了建立可复查的代码质量基线，Northstar Protocol Studio 倾向于在适用项目中引入 Foundry 测试框架，并对核心资金流转代码开展模糊测试（Fuzzing Test）与不变性测试（Invariant Test）。

1. 什么是模糊测试 (Fuzzing Test)？

模糊测试（Fuzzing）是指通过向目标函数输入大量的随机随机数，来检测合约逻辑是否会崩溃。

1.1 传统测试 vs 模糊测试

• 传统单元测试：测试 withdraw(100) 和 withdraw(200)。
• 模糊测试：测试 withdraw(x)，其中 x 是由 Foundry 测试套件随机生成的成千上万个 uint256 随机数值（包括 0、1、type(uint256).max 等极端值）。

1.2 编写一个简单的 Fuzzing 测试

在 Foundry 中，编写模糊测试非常直观。只需在测试函数中声明一个输入参数，Foundry 会自动将该测试识别为 Fuzzing 模式，默认运行 256 次以上随机输入验证：

// Foundry 模糊测试用例示例
function testFuzz_Withdraw(uint256 amount) public {
    // 1. 限制随机数范围，使其符合基本物理规则
    vm.assume(amount > 0 && amount <= 10000 ether);

    // 2. 模拟用户存入代币
    stakingContract.deposit{value: amount}();

    // 3. 执行提现并验证合约状态
    uint256 balanceBefore = address(this).balance;
    stakingContract.withdraw(amount);
    uint256 balanceAfter = address(this).balance;

    assertEq(balanceAfter - balanceBefore, amount);
}

2. 深入不变性测试 (Invariant Testing)

模糊测试局限于单个函数的随机测试，而**不变性测试（Invariant Testing）**则是测试整个智能合约在任何可能的交易序列调用后，其底层的某些物理常数或“绝对真理”是否永远成立。

2.1 不变性的经典例子

对于一个去中心化借贷协议或 AMM DEX：

• 质押池不变性：全网用户本金余额之和 + 累积协议利息 ≡ 合约地址实际持有的 ERC20 代币余额。
• DEX 不变性：在没有充值和提取的情况下，流动性池的乘积常数 $x \times y = k$ 在任何 swap 交易后均不得减小。

2.2 不变性测试配置

Foundry 会通过内置的 Invoker 随机调用目标合约的任何暴露接口（如随机组合调用 stake、unstake、claim、transferOwneship），执行数千步操作，随后核对断言（Invariant Assertions）是否依然保持为真。一旦某个断言被打破，Foundry 会输出一条完整的调用栈（Call Sequence），指明在什么样的复杂操作路径下合约会崩溃，极大缩短了漏洞排查时间。

3. 从模糊测试到生产级交付

在 Northstar Protocol Studio，我们将 Foundry 测试流程整合在 GitHub Actions 中：

1. 覆盖率门槛：所有 Solidity 合约的分支测试覆盖率（Branch Coverage）必须超过 95%。
2. 模糊运行次数 (Runs)：对于极重要合约，将 foundry.toml 中的 fuzz.runs 配置为 10,000 次以上，以暴力测试找出微小的逻辑漏洞。
3. 静态分析：整合 Slither 和 Mythril 进行代码静态检测，过滤重入、自毁等常规漏洞。

结论

智能合约没有第二次机会。把代码交给安全审计公司之前，自己在本地通过 Foundry 进行高强度的模糊测试和不变性演练，是每个合格的 Web3 团队应该具备的工程底线。