1. 课程导论：为什么Gas优化会引入安全漏洞？
说实话，我见过太多团队在Gas优化上栽跟头了。
Gas优化，说白了就是帮用户省钱。省Gas本身是好事，但问题在于——很多优化技巧，本质上是在「走钢丝」。你省下来的每一分Gas，可能都是用安全性换来的。
我个人习惯把Gas优化分成两类：安全的优化和危险的优化。前者只是改变代码写法，不影响逻辑；后者则直接改变了合约的执行流程或状态管理方式。嗯，后者就是我们今天要聊的「陷阱区」。
1.1 一个经典的例子：Shortcut带来的灾难
先看一个我实际审计中遇到的例子。
// 不安全的Gas优化版本
function withdraw(uint256 amount) external {
// 直接用msg.sender的余额减去amount，省了一次SLOAD
balances[msg.sender] -= amount;
// 然后转账
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
}
// 安全的常规版本
function withdraw(uint256 amount) external {
require(balances[msg.sender] >= amount, "Insufficient balance");
balances[msg.sender] -= amount;
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
}
你看出问题了吗？
第一个版本省掉了一个require检查。它假设调用者不会传入一个超过余额的amount。但问题是——如果合约里有其他函数可以修改balances[msg.sender]，或者存在重入攻击路径，这个假设就崩了。
我在项目中遇到过类似的情况。一个DeFi协议为了省Gas，把所有的余额检查都去掉了，结果被攻击者利用闪电贷+重入，一口气提走了池子里80%的资金。那次审计报告写得我头皮发麻。
1.2 为什么优化会引入漏洞？
核心原因其实就三个字：边界模糊。
正常的智能合约开发，讲究的是「防御性编程」——假设所有输入都是恶意的，所有外部调用都可能失败。但Gas优化恰恰相反，它要求你「信任」某些条件已经成立，从而跳过检查。
我总结了几种常见的「优化陷阱」：
| 优化类型 | 省Gas的原理 | 引入的风险 |
|---|---|---|
| 移除边界检查 | 省掉require/assert | 溢出、越界、逻辑错误 |
| 使用assembly | 跳过Solidity的安全层 | 内存错误、类型混淆 |
| 状态变量打包 | 减少SLOAD/SSTORE次数 | 脏数据、读写冲突 |
| 短路求值 | 利用||和&&的惰性求值 | 条件遗漏、状态不一致 |
| unchecked块 | 关闭溢出检查 | 整数溢出漏洞 |
你看，每一行都是「用安全换性能」。这不是说不能做，而是你要清楚——你在赌什么。
1.3 一个更隐蔽的例子：状态变量打包
很多人觉得状态变量打包只是把多个uint256塞进一个slot里，没什么风险。其实不然。
// 优化前：每个变量独立slot
uint256 public totalSupply;
uint256 public lastUpdateTime;
address public owner;
// 优化后：打包到一个struct里
struct State {
uint128 totalSupply;
uint128 lastUpdateTime;
address owner;
}
State public state;
表面上看，从3个slot变成了1个slot，省了2次SLOAD。但问题来了——totalSupply和lastUpdateTime被塞进了同一个128位空间。如果totalSupply增长超过2^128，就会溢出到lastUpdateTime字段。
你想想看，一个DeFi协议的totalSupply超过2^128，这概率其实不小。尤其是那些高通胀的代币模型。我曾经审计过一个项目，他们用uint128存totalSupply，结果上线3个月就溢出了，导致整个协议的时间戳逻辑全部错乱。
我曾经在审计一个借贷协议时，发现他们把用户的抵押品数量用uint128存储。当时我就问团队：「你们确定用户的抵押品永远不会超过2^128吗？」他们拍胸脯说没问题。结果我查了一下，协议里有个闪电贷功能，单笔借款就能达到2^130的量级。嗯，这个漏洞如果被利用，后果不堪设想。
1.4 Gas优化与安全性的本质矛盾
说白了，智能合约的安全模型是建立在「冗余检查」之上的。每一次require、每一次SafeMath、每一次显式的状态更新，都是在给合约加「保险丝」。Gas优化则是在剪掉这些保险丝。
我个人习惯把Gas优化分成三个安全等级：
- 安全级：只改变代码风格，不改变逻辑（如变量命名、函数排序）
- 谨慎级：改变执行路径，但保留核心安全检查（如使用assembly优化特定操作）
- 危险级：移除安全检查或改变状态管理方式（如去掉require、使用unchecked）
我建议团队在优化Gas时，先问自己三个问题：
- 这个优化会不会改变合约的「预期行为」？
- 如果某个假设被打破，合约会进入什么状态？
- 这个优化是否引入了新的攻击面？
如果三个问题里有一个回答是「不确定」，那就别优化。省那点Gas，不够赔一次攻击的。
1.5 知识体系总览
下面这张图，是我对本章核心逻辑的梳理。你可以把它当作整个课程的「地图」：
如果你刚开始接触Gas优化，先从「安全级」做起。等你对EVM的底层机制足够熟悉了，再碰「谨慎级」。至于「危险级」——除非你有十足的把握，否则别碰。我在审计中看到的绝大多数漏洞，都出自那些自以为很懂EVM的开发者之手。
好了，这一章的核心就这些。记住一句话：Gas优化不是炫技，是权衡。你省下的每一分Gas，背后都有一份风险在等着你。
公众号:蓝海资料掘金营，微信deep3321