链上协议代码评审该看哪些细节
在 DeFi（去中心化金融）领域，代码就是资产本身。以太坊生态经过数年的演进，去中心化交易所（AMM）、借贷协议、流动性衍生品（LSD）以及收益聚合器（Yield Aggregator）的组合度越来越高。这种“金融积木”的特性在带来创新的同时，也让风险呈级数放大。
一份看似完善的 Solidity 代码，仍可能因预言机价格被操纵或闪电贷攻击而出现资金风险。DeFi 代码评审不能只做语法纠错，还应覆盖经济模型和极端市场条件。
评审时重点检查的三类金融逻辑风险
审查 DeFi 智能合约，审查者应把自己切换到“黑客”和“清算套利者”的双重视角。
1. 预言机操纵与点位价格依赖（Oracle Manipulation）
这是 DeFi 被攻击频率最高的致命点。许多项目直接用 UniswapV2Pair.getReserves() 或 Uniswap V3 的现货价格（Spot Price）作为资产清算或借贷额度的计算依据。黑客只要利用闪电贷在单个区块里强行改变 DEX 池中的 Token 比例，就能把预言机价格抬高或拉低几十倍，进而以极低成本借走协议里的全部资产。
评审关注点：必须确认协议使用的是经过时间加权平均的 TWAP（Time-Weighted Average Price）预言机，或者引入了 Chainlink 等多源去中心化预言机，且对 TWAP 的窗口时间（如 待项目确认的阈值）以及 Chainlink 的 updatedAt 心跳过时校验有严密约束。
2. K 值恒定乘积与精度损失（Precision Loss in AMM）
在类 Uniswap AMM 算法或收益分配逻辑里，经常出现复杂的乘除运算和开方计算。由于 Solidity 没有小数，一旦计算顺序不当，或者在计算 LP Share（流动性份额）时允许 totalSupply == 0 的初始状态被恶意操纵（即所谓的 ERC4626 首次存款攻击 / Inflation Attack），攻击者就能通过捐赠（Donation）极小额代币，让后续用户的存款份额全部被截断取整为 0。
评审关注点：首次存款是否有 Burn（销毁）一部分 Initial Shares 的机制？所有公式是否推导过 minAmountOut 滑点保护？
3. 清算门禁与 MEV 夹心攻击（Sandwich Attack）
DeFi 借贷协议靠清算人（Keeper）维护系统健康。但如果清算函数的奖励机制设计不合理，或者没有限制滑点（Slippage），清算交易在 Pending 状态时就会被 MEV Bot 盯上。MEV 机器人会通过 Front-running（抢先交易）和 Back-running（尾随交易）吃掉清算利润，甚至导致清算交易失败，协议产生坏账。
防预言机操纵与首次存款攻击的工程实战代码
下面的 Solidity 0.8.20+ 代码展示了一个生产级 DeFi 金库协议中，如何防御 ERC4626 首次存款膨胀攻击，并集成 Chainlink 预言机过时校验的标准实现。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
interface IChainlinkAggregator {
function latestRoundData() external view returns (
uint80 roundId,
int256 answer,
uint256 startedAt,
uint256 updatedAt,
uint80 answeredInRound
);
}
/**
* @title SecureDeFiVault
* @notice 具备防首次存款膨胀攻击与严密预言机校验的借贷金库
*/
contract SecureDeFiVault is ReentrancyGuard {
using SafeERC20 for IERC20;
IERC20 public immutable asset;
IChainlinkAggregator public immutable priceOracle;
uint256 public totalShares;
mapping(address => uint256) public sharesOf;
uint256 private constant MINIMUM_LIQUIDITY = 1000; // 防范 Inflation Attack 的最小永久锁仓量
uint256 private constant ORACLE_TIMEOUT = 3600; // 预言机心跳超时门禁：1小时
error InvalidPrice();
error OracleStalePrice();
error ZeroDeposit();
error SlippageExceeded();
constructor(address assetAddress, address oracleAddress) {
asset = IERC20(assetAddress);
priceOracle = IChainlinkAggregator(oracleAddress);
}
/**
* @notice 安全读取 Chainlink 价格，严格防范过时数据与异常负值
*/
function getLatestAssetPrice() public view returns (uint256) {
(
uint80 roundId,
int256 price,
,
uint256 updatedAt,
uint80 answeredInRound
) = priceOracle.latestRoundData();
// 1. 价格合法性检查
if (price <= 0) revert InvalidPrice();
// 2. 心跳与过时检查
if (updatedAt == 0 || block.timestamp – updatedAt > ORACLE_TIMEOUT) revert OracleStalePrice();
// 3. 轮次完整性检查
if (answeredInRound < roundId) revert OracleStalePrice();
return uint256(price);
}
/**
* @notice 用户存入资产获取份额（防范首次存款攻击）
*/
function deposit(uint256 amount, uint256 minSharesExpected) external nonReentrant returns (uint256 shares) {
if (amount == 0) revert ZeroDeposit();
uint256 totalPoolAsset = asset.balanceOf(address(this));
if (totalShares == 0) {
// 首次存款：强制销毁 MINIMUM_LIQUIDITY 份额到零地址，彻底断绝攻击者控制比率的可能
shares = amount – MINIMUM_LIQUIDITY;
totalShares = amount; // 包含死循环锁定的份额
sharesOf[address(0)] = MINIMUM_LIQUIDITY;
} else {
// 严格先乘后除计算份额，防止精度损失
shares = (amount * totalShares) / totalPoolAsset;
}
// 滑点与预期校验
if (shares < minSharesExpected) revert SlippageExceeded();
sharesOf[msg.sender] += shares;
asset.safeTransferFrom(msg.sender, address(this), amount);
}
}
审阅 DeFi 项目的代码质量门禁清单
除了 Solidity 代码层面，测试与工程构建配置同样是评审的一部分。评审时必须核查团队是否做到了以下几点：
- Fork 主网集成测试（Mainnet Forking Test）：单元测试不能只在干净的空本地网络跑。必须使用 Foundry 的 vm.createSelectFork，在模拟真实的 Uniswap/Curve 池子状态下跑测试，验证协议对真实主网流动性的耐受度。
- Foundry 不变性测试（Invariant Testing）：是否针对关键金融公式编写了 Invariant 断言？例如 vault.totalAssets() >= vault.totalSupply() * exchangeRate，并通过数千轮随机交易尝试去打破这个等式。
- 应急暂停与权限隔离（Pausable & Access Control）：当极端市场行情发生时，协议是否有 EmergencyPause 机制？暂停权限是否属于一个带有 待项目确认的阈值 Timelock 的 Gnosis Safe 多签钱包，而不是某个单签私钥？
- 代币 Approve 留存清理：在与外部协议（如 Compound / Aave）交互后，是否清理了对外部合约的无限 approve？防止第三方协议出事后殃及本金库。
DeFi 安全没有侥幸。每一行涉及资产计算的代码，都必须经过最严苛的数学推导与对抗性实验打磨，才能在残酷的链上丛林里安然无存。
