当前位置：首页 > article >正文

第 5 章 | Solidity 合约中的整数溢出与精度陷阱全解析

article 2025/3/26 10:17:51

🧮 第 5 章 | Solidity 合约中的整数溢出与精度陷阱全解析

——YAM 崩盘与算术误差复盘，如何正确使用 SafeMath 与 unchecked？

✅ 本章导读

在 Solidity 合约开发中，最危险的错误往往不是逻辑问题，而是你以为算对了，但其实错了。

合约里的资产转账、比例分配、利息计算、奖励发放，全都涉及到整数运算与精度控制。
一旦数值不准，不是项目经济模型失衡，就是直接被套利、爆仓。

本章我们将系统拆解 Solidity 合约中常见的数值问题：

整数溢出与下溢（0.8.x 以后真的安全吗？）
运算顺序导致的精度丢失（浮点错误在 Solidity 是常态）
decimals 精度管理误差（ERC20 中最常见的坑）
unchecked{} 的使用与滥用
真正安全的乘除方式写法模板
真实事故复盘（YAM、Balancer）

1️⃣ 什么是整数溢出 / 下溢（Overflow / Underflow）？

✅ 概念

Solidity 使用固定大小的整数类型，如 uint256（0 ～ 2²⁵⁶-1）
溢出（Overflow）：变量加法超过最大值 → 回绕成 0
下溢（Underflow）：减法减出负数（uint 无法表示） → 回绕成最大值

✅ 例子（Solidity 0.7.x 以下）

uint8 a = 255;
a += 1; // ❌ 溢出 → a = 0

uint8 b = 0;
b -= 1; // ❌ 下溢 → b = 255

✅ Solidity 0.8.x 后自动加入检查

// Solidity 0.8+ 中这段代码将 revert：
uint256 a = 2**256 - 1;
a += 1; // 报错：overflow

✅ 但为什么 0.8.x 依然可能出错？

因为很多开发者在 unchecked{} 中包裹运算：

function uncheckedAdd(uint a, uint b) public pure returns (uint) {
    unchecked {
        return a + b;
    }
}

⚠️ 如果不明原因使用 unchecked，你等于手动关闭了安全带。
在性能需求极高的情况下确实可用，但必须经过严格测试。

2️⃣ 精度陷阱：为什么 1e18 * 0.25 有时 = 0？

✅ Solidity 不支持浮点数

你必须使用整数来近似表示所有“浮点”数据。

例如：

uint reward = total * 0.25; // ❌ 错误，0.25 会变成 0

✅ 正确做法：

uint reward = total * 25 / 100;

或者用 18 位精度管理：

uint reward = total * 25e16 / 1e18; // 25e16 = 0.25 * 1e18

3️⃣ 乘除顺序陷阱：一换顺序，直接归零

❌ 错误示范：

uint result = 1000 * 1e18 / 1e20; // ➜ 结果为 0

解释：1000 * 1e18 = 1e21，再除 1e20，得到 10。
但如果你先 1e18 / 1e20 = 0，整个式子就变成 1000 * 0 = 0！

✅ 正确姿势：先乘后除
Never divide first. Always multiply first.

result = amount * ratio / scale;

4️⃣ ERC20 decimals 精度误差导致金额失真

✅ 案例 1：忘记考虑 token decimals

// 代币 A 有 6 decimals，但我们按 1e18 运算，结果发错数量
aToken.transfer(user, amount * reward / total); // ❌

解决方式：

uint tokenDecimals = 10 ** IERC20Metadata(token).decimals();
...
uint reward = total * userShare / poolTotal;
reward = reward / 1e18 * tokenDecimals;

5️⃣ 案例复盘：YAM 与 Balancer

💥 YAM 崩盘（2020）

问题： 在 rebase() 逻辑中执行复合计算
totalSupply = totalSupply * price / targetPrice
忘记更新精度乘数导致乘除顺序不当
结果出现整数溢出，DAO 无法投票提案修复

📎 结局：项目治理瘫痪，只能重启部署

💥 Balancer 被套利（2021）

问题： 奖励代币复利结算计算精度错误
攻击者通过 Flashloan 操控 ratePerSecond，精准制造浮点误差
每轮套利可稳定提取超额奖励

📎 教训：任何时间、利息、折扣计算都要使用 FixedPointMathLib 等高精度工具

✅ 推荐写法模板：安全数值操作

// 推荐使用 Foundry 的 fixed point math lib
import "solmate/utils/FixedPointMathLib.sol";

// 假设 reward = baseAmount * rate / 1e18
uint reward = FixedPointMathLib.mulDivDown(baseAmount, rate, 1e18);

或使用：

SafeMath.mul().div()

✅ 本章实战模板代码：安全乘除结构

function calculateReward(uint amount, uint rewardRate, uint base) public pure returns (uint) {
    // reward = amount * rewardRate / base
    // 避免精度丢失
    return amount * rewardRate / base;
}

或：

function safeMulDiv(uint a, uint b, uint denom) internal pure returns (uint) {
    return a * b / denom;
}

🛠 精度审计 Checklist（可直接用于项目自检）

检查项	✅/❌
是否统一使用了 18 位精度（或 token decimals）	✅
是否所有比例运算都使用“乘后除”结构？	✅
是否使用 FixedPointMathLib / SafeMath？	✅
是否所有乘除操作都在 0.8+ 安全检查下运行？	✅
是否误用 `unchecked{}` 封装关键运算？	✅

🧪 课后挑战

写一个 calcReward() 函数，接受 3 个参数：用户 stake、池子总量、奖励总额
- 实现高精度奖励分配
- 加入 decimals 参数支持不同 token
- 模拟 10000 用户参与下的极小精度误差（unit test）
模拟 YAM 的溢出 bug
- 创建一个带 rebase() 函数的合约
- 故意写错乘除顺序，复现溢出
- 修复后对比 Gas 与正确性