ERC-20 实战（上）：授权机制、漏洞剖析与最佳实践

📚 作者：Henry 🧱 系列：《ERC 系列标准全景图解》 · 第 3 篇 👨‍💻 受众：Web3 前端工程师 / 区块链开发者 / Web3入门者 👉 系列持续更新中，建议收藏专栏或关注作者

🧠 为什么 ERC-20 的授权机制容易出错？

ERC-20 是最常见的智能合约接口，但它的授权流程却常出错、易被滥用，甚至是攻击目标。本篇将系统讲透 ERC-20 的授权机制与背后的漏洞根源，并提供工程实战建议与测试策略。

ERC-20 授权机制的基本模型

📘 标准接口回顾：

function approve(address spender, uint256 amount) external returns (bool);
function allowance(address owner, address spender) external view returns (uint256);
function transferFrom(address from, address to, uint256 amount) external returns (bool);

这个组合形成了owner → spender 的授权花费机制，用于 DeFi 交互、合约自动扣款等。

授权流程图（approve → allowance → transferFrom）

1. 用户通过 approve(spender, amount) 授权某个地址可代为操作；
2. 授权信息被存入 allowance(owner, spender) 映射中；
3. spender 可随时调用 transferFrom 消耗额度。

⚠️ 安全隐患：Approve 重复授权攻击（Race Condition）

在未重置 allowance 为 0 的情况下，直接修改授权值存在竞争风险：

// ⚠️ 危险做法：
approve(spender, 100) → approve(spender, 200)

如果 spender 在两次 approve 之间抢先使用旧额度，就可能：

1. 使用旧额度 transferFrom(..., 100)；

2. 然后再获得新额度 200，最终获得 300 token 的使用权！

transferFrom 内部执行流程拆解

以 OpenZeppelin 的实现为例：

function transferFrom(address from, address to, uint256 value) public override returns (bool) {
    uint256 currentAllowance = allowance(from, _msgSender());
    require(currentAllowance >= value, "ERC20: insufficient allowance");

    _approve(from, _msgSender(), currentAllowance - value);
    _transfer(from, to, value);

    return true;
}

✅ 行为特点：

• 会先检查授权额度，再进行转账
• 调用成功后，授权额度被自动减少，可防重入攻击
• 若授权额度不足，则 revert

ERC-20 双重授权攻击（Approval Race Attack）

这是 ERC-20 最臭名昭著的问题之一

⚠️ 攻击流程：

1. 用户已授权某合约 spender 100 USDT
2. 想更新授权为 50 → 执行 approve(spender, 50)
3. 在交易未确认前，spender 抢先用旧授权转走 100
4. approve 成功后，用户以为授权变成 50，实则余额已空

📉 原因：

ERC-20 中 approve(spender, amount) 是覆盖而不是累加

如何安全处理授权操作？

OpenZeppelin 提供了推荐的做法：

✅ 方法 1：先设置为 0，再设置为目标值

token.approve(spender, 0);
token.approve(spender, 1000);

⚠️ 缺点：需要两次交易，gas 成本翻倍

✅ 方法 2：使用 increaseAllowance / decreaseAllowance

OpenZeppelin 在 ERC20 中实现了以下辅助方法：

function increaseAllowance(address spender, uint256 addedValue) public returns (bool)
function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool)

优势：

• 避免授权 race condition
• 合约内部安全控制额度变化

前端开发中的高频坑点

安全封装建议：使用 SafeERC20 库

OpenZeppelin 提供 SafeERC20 库来封装授权调用：

using SafeERC20 for IERC20;

IERC20(token).safeApprove(spender, amount);
IERC20(token).safeTransferFrom(from, to, amount);

优点：

• 自动处理非标准行为（如不返回值）
• 带 revert 检查，防止 silent failure

工程实践建议（前端 + 合约）

🧠 小结

• ERC-20 的授权机制基于 approve + transferFrom + allowance
• 该机制存在 race condition 漏洞，应避免直接覆盖授权值
• 建议使用 increaseAllowance / SafeERC20 来提升安全性与兼容性
• 工程落地中，应构建统一的授权交互与测试组件