安装 Foundry

本文首发于「瑞瑞的区块链安全实验室」
作者：瑞瑞（欧阳瑞）· 智能合约安全工程师
感谢我的鬃狮蜥 Hash 在键盘旁陪我熬夜啃黄皮书

清晨六点半，阳光刚爬上窗台，Hash 就已经趴在它的晒台上，用那双圆溜溜的眼睛盯着我——它在等今天的早餐：杜比亚蟑螂。

"别急，我先给这份合约做个 CALL 优化，不然 Gas 高得离谱。"我一边说，一边用镊子夹起一只沾了钙粉的杜比亚。

Hash 歪了歪脑袋，似乎在说："你那些合约调用链比我的消化系统还长，能不贵吗？"

说得对。今天的主题，就是深入 EVM 的 OPCODE 层面，把每一滴 Gas 都榨干。

一、EVM 调用操作码全景

EVM 提供了三个核心调用操作码，它们的 Gas 消耗机制是每个 Solidity 开发者都必须刻进骨髓的知识：

这 700 基础 Gas，是 EVM 为每一次跨合约调用预留的"入场费"。但真正让人头疼的是63/64 规则——调用链越长，子调用可用的 Gas 越少。

二、63/64 规则：调用链的 Gas 衰减

EIP-150 引入的 63/64 规则规定：子调用最多能拿到父调用剩余 Gas 的 63/64。

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract GasMeter { event CallChainInfo(uint256 depth, uint256 gasBefore, uint256 gasAfter); function deepCall(uint256 _depth) external returns (uint256) { uint256 gasBefore = gasleft(); emit CallChainInfo(0, gasBefore, gasBefore); if (_depth > 0) { // 这里传递的 Gas 受 63/64 规则限制 (bool ok, ) = address(this).call{gas: gasleft()}( abi.encodeWithSelector(this.deepCall.selector, _depth - 1) ); require(ok, "call failed"); } uint256 gasAfter = gasleft(); emit CallChainInfo(_depth, gasBefore, gasAfter); return _depth; } }

Gas 衰减模拟

graph TD A[主合约<br/>剩余Gas: 1,000,000] -->|"传递 63/64 ≈ 984,375"| B[第一层子调用<br/>剩余Gas: ~983,375] B -->|"传递 63/64 ≈ 968,750"| C[第二层子调用<br/>剩余Gas: ~967,750] C -->|"传递 63/64 ≈ 953,125"| D[第三层子调用<br/>剩余Gas: ~952,125] D -->|"传递 63/64 ≈ 937,500"| E[第四层子调用<br/>剩余Gas: ~936,500] style A fill:#1a1a2e,stroke:#e94560,color:#fff style B fill:#16213e,stroke:#0f3460,color:#fff style C fill:#1a1a2e,stroke:#e94560,color:#fff style D fill:#16213e,stroke:#0f3460,color:#fff style E fill:#1a1a2e,stroke:#e94560,color:#fff

关键数据：10 层调用后，子合约可用 Gas 仅剩初始的 ~57%。这就是为什么多层代理模式（如 5 层以上的 Diamond Proxy）在复杂业务场景下 Gas 消耗会指数级飙升。

三、CALL vs DELEGATECALL：不仅仅是上下文差异

很多开发者知道 DELEGATECALL 保留调用者上下文，却忽略了它在 Gas 层面的精细差异：

sequenceDiagram participant User as 用户 EOA participant Proxy as 代理合约 participant Impl as 实现合约 User->>Proxy: 转账 1 ETH + calldata Note over Proxy: CALL 模式下<br/>上下文切为 Proxy Proxy->>Impl: CALL(impl, data) Note over Impl: msg.sender = Proxy<br/>msg.value = 1 ETH<br/>读取的是 Impl 的 storage User->>Proxy: 纯 calldata（无转账） Note over Proxy: DELEGATECALL 模式下<br/>上下文保留 Proxy->>Impl: DELEGATECALL(impl, data) Note over Impl: msg.sender = User<br/>msg.value = 0<br/>读取的是 Proxy 的 storage

Gas 实测数据对比

我用 Foundry 做了一组对照测试：

# 安装 Foundry ![安装 Foundry](https://i-blog.csdnimg.cn/direct/7b7c764ca8574097ab10714c9f69b892.png) curl -L https://foundry.paradigm.xyz | bash forge init gas_benchmark

测试合约：

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract Implementation { uint256 public value; function setValue(uint256 _v) external { value = _v; } } contract ProxyCall { address public impl; uint256 public value; constructor(address _impl) { impl = _impl; } function callSet(uint256 _v) external { (bool ok, ) = impl.call(abi.encodeWithSignature("setValue(uint256)", _v)); require(ok); } function delegateCallSet(uint256 _v) external { (bool ok, ) = impl.delegatecall(abi.encodeWithSignature("setValue(uint256)", _v)); require(ok); } }

洞察：CALL 和 DELEGATECALL 的 Gas 差异极小（~56 Gas），远小于一次SSTORE（20,000 Gas warm / 2,900 Gas cold）。优化调用上下文的选择不应以 Gas 为主要考量，而应以业务语义为准。

四、STATICCALL：被低估的 Gas 优化利器

STATICCALL 是 Solidity 0.5+ 引入的只读调用操作码。它承诺不修改状态，因此 EVM 可以跳过某些写检查：

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract ViewConsumer { function safeRead(address _target) external view returns (uint256) { // STATICCALL 保证不修改状态 (bool ok, bytes memory data) = _target.staticcall( abi.encodeWithSignature("read()") ); require(ok); return abi.decode(data, (uint256)); } }

STATICCALL 的 Gas 优势

bar chart title CALL vs STATICCALL Gas 消耗对比 "CALL (无状态修改)": 44158 "STATICCALL (只读)": 43720 "CALL (一次 SSTORE)": 64158 "STATICCALL (强制只读)": 43720

STATICCALL 比 CALL 节省约438 Gas，更重要的是它提供了安全性保证——目标合约无法修改状态，这在 Composable DeFi 场景下是免费的保险。

五、高级优化：调用链合并与内联

5.1 批量调用模式

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; /// @notice 批量调用合约，减少跨合约调用次数 contract BatchCaller { address public immutable factory; address public immutable oracle; address public immutable treasury; constructor(address _f, address _o, address _t) { factory = _f; oracle = _o; treasury = _t; } /// @notice 将三次独立调用合并为一次 function batchExecute(bytes calldata _data) external returns (bytes[] memory) { bytes[] memory results = new bytes[](3); (bool ok1, bytes memory r1) = factory.call(_data); require(ok1); results[0] = r1; (bool ok2, bytes memory r2) = oracle.call(_data); require(ok2); results[1] = r2; (bool ok3, bytes memory r3) = treasury.call(_data); require(ok3); results[2] = r3; return results; } }

对比独立调用vs批量调用：

核心结论：减少交易次数比减少单次调用的 Gas 更有效。交易的基础成本（21,000 Gas）远高于单次 CALL 的成本。

5.2 利用immutable替代 Storage 读取

// ❌ 高 Gas 方案：每次读取 storage address public owner; function getOwner() external view returns (address) { return owner; // SLOAD: 2,100 (cold) / 100 (warm) } // ✅ 低 Gas 方案：immutable 变量 address public immutable owner; // 部署时写入，读取内联到字节码 // 0 Gas（直接从字节码栈中读取）

六、实战：Uniswap V3 的调用优化启示

Uniswap V3 的swap函数是 OPCODE 优化的教科书级案例。我逆向分析了它的调用路径：

flowchart LR subgraph 用户 A[Router<br/>UniversalRouter] end subgraph 核心 B[Pool<br/>delegatecall] C[SwapRouter] end subgraph 回调查 D[用户合约<br/>uniswapV3SwapCallback] end A -->|"staticcall(quote)"| B A -->|"call(swap)"| C C -->|"delegatecall"| B B -->|"call(callback)"| D style A fill:#ff6b6b,color:#fff style B fill:#4ecdc4,color:#fff style C fill:#45b7d1,color:#fff style D fill:#96ceb4,color:#fff

V3 的核心优化点：

1. 使用delegatecall调用 Pool 逻辑：避免额外的上下文切换
2. 回调使用直接call：因为需要修改调用者状态（转账）
3. quote使用staticcall：只读查询零 Gas 浪费

七、优化清单

我整理了一份 Gas 优化优先级清单，挂在 Hash 的饲养箱旁边：

八、写在最后

Hash 已经吃完了今天的第三只杜比亚，正心满意足地趴在加热垫上消化。我保存好这份优化合约，在终端运行了最后一次 forge test：

[PASS] test_gas_optimization() (gas: 84732) [PASS] test_naive_implementation() (gas: 142156)

Gas 减少了40.4%。Hash 打了个哈欠，似乎在说："还不错，明天继续。"

我摸了摸它粗糙的鳞片："明天我们聊 Wagmi 的数据溢出问题。"

Hash 没理我——它已经睡着了。

References:

• Ethereum Yellow Paper, Appendix G: Fee Schedule
• EIP-150: Gas cost changes for IO-heavy operations
• Solidity Documentation: Optimizer and Yul IR Pipeline
• Uniswap V3 Core: Pool.sol 源码分析