智能合约 Gas 优化总览

在以太坊虚拟机（EVM）中，计算与存储资源受到严格的物理约束，用户执行交易必须为其消耗的计算步骤（Opcodes）和存储状态支付 Gas 费用。合理的 Gas 优化不仅能够大幅降低终端用户的交互成本，还能提升系统抵御拒绝服务（DoS）的韧性，并精简合约部署字节码体积（Contract Size）。

然而，Gas 优化并非盲目追求指令削减，必须在安全性、可维护性、复杂度与经济性之间取得严格平衡。

优化哲学：空间换时间与业务确定性

在合约设计中，“浪费”有时恰恰是最高维度的优化。

最经典的工程案例莫过于 Uniswap V2 Factory 的币对索引设计：

function createPair(address tokenA, address tokenB) external returns (address pair) {
    require(tokenA != tokenB, 'UniswapV2: IDENTICAL_ADDRESSES');
    (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
    require(token0 != address(0), 'UniswapV2: ZERO_ADDRESS');
    require(getPair[token0][token1] == address(0), 'UniswapV2: PAIR_EXISTS');
    
    bytes memory bytecode = type(UniswapV2Pair).creationCode;
    bytes32 salt = keccak256(abi.encodePacked(token0, token1));
    assembly {
        pair := create2(0, add(bytecode, 32), mload(bytecode), salt)
    }
    IUniswapV2Pair(pair).initialize(token0, token1);
    
    // 双向存储记录
    getPair[token0][token1] = pair;
    getPair[token1][token0] = pair; // 反向冗余记录
    allPairs.push(pair);
    emit PairCreated(token0, token1, pair, allPairs.length);
}

架构权衡解析

• 物理上的“浪费”：对于每个币对，getPair 映射中同时存储了 (token0, token1) 和 (token1, token0) 两个方向的引用，多消耗了一次 SSTORE 存储槽。
• 全局上的“优化”：所有外部调用者与路由器在查询币对流动性时，完全无需在链上先执行一次大小排序比较，直接使用 getPair[tokenA][tokenB] 即可常数级查出，将计算复杂度从所有的查询端转移并消除，极大降低了整个生态系统的交互复杂度与集成 Gas。

模块导读索引

本专题将 Gas 优化划分为五个循序渐进的工程模块：

1. 变量打包与存储优化：EVM 256 位槽位打包规则、结构体字段对齐、存储数据位置（storage vs memory vs calldata）的开销对比。
2. 循环展开与边界优化：数组长度缓存、unchecked 计数器、内存指针连续遍历，以及破除所谓的“笛卡尔积扁平化”伪优化陷阱。
3. 算术运算与位操作优化：移位替代 2 次幂乘除、常量折叠与编译期预计算、代数等价防溢出比较、单字位图（Bitmask）状态压缩。
4. 内联汇编 (Yul) 极致优化：复用草稿空间实现零分配哈希、4 字节 Custom Error 极简回滚、Optimism SafeCall 内存隔离防炸弹、Solady SafeTransferLib 全兼容极速代币划转。
5. 内存扩张与瞬态存储 (EIP-1153)：内存二次方扩展成本推导、避免循环内动态内存泄漏、TSTORE/TLOAD 100 Gas 重入锁、Uniswap V4 单例闪电记账（Flash Accounting）。