Gas 优化

什么是 Gas 优化？

Gas 优化是减少部署或执行加密货币智能合约所需区块链资源的过程。

在 Ethereum 上，每笔交易和每项 Ethereum Virtual Machine 操作都会消耗一定数量的 Gas。

交易发送方通常需要根据计费 Gas 和每个 Gas 单位的实际价格支付网络费用。

基本计算公式为：交易费 = 计费 Gas × 实际 Gas 价格。

Gas 优化通过提高合约代码、存储使用、交易数据和执行路径的效率，减少计费 Gas 数量。

它不会直接控制 Gas 价格；Gas 价格会随区块链容量需求变化。

经过适当优化的合约可以降低代币转账、去中心化金融操作、治理操作、NFT 活动和其他加密货币交易的成本。

不过，Gas 优化绝不能移除安全检查，也不能让合约行为变得难以理解。

目标是以安全、可验证的方式，只执行应用所需的最低限度链上工作。

Gas 优化的工作原理

Ethereum 会根据不同类型的计算工作和状态操作收取不同数量的 Gas。

简单计算通常成本较低，而持久存储变更、合约创建、密码学操作和外部调用的成本可能高得多。

Ethereum 官方Gas 文档说明，Gas 用于衡量处理区块链交易所需的计算工作量。

Gas 优化首先要找出消耗 Gas 最多的操作，并判断应用能否在不改变预期行为的情况下减少工作量。

开发者可以减少重复的存储读取、合并状态变更、缩短交易数据、移除重复计算，或使用效率更高的 EVM 功能。

编译器也可以将 Solidity 源代码转换为更高效的字节码。

部分优化能够降低合约部署成本，其他优化则能降低每次用户交互的成本。

最合适的方法取决于合约的部署次数及其函数的调用频率。

Gas 优化与 Gas 价格优化

Gas 优化和 Gas 价格优化针对交易费用的不同部分。

Gas 优化会减少交易消耗的 Gas 单位数量。

Gas 价格优化则尝试在每个 Gas 单位费用较低时提交交易。

消耗 100,000 Gas 的合约，其计算成本仍高于使用 60,000 Gas 完成相同安全任务的合约。

不过，网络拥堵或 ETH 价值较高时，成本较低的合约仍可能产生较高的本国货币费用。

用户有时可以等待网络需求下降来降低 Gas 价格，但开发者可以通过合约和应用设计控制 Gas 使用量。

结合使用这两种方法，比单独依赖其中一种更有助于降低总交易成本。

Gas 优化为何对加密货币领域很重要

即使加密货币应用提供的服务很有用，高昂的交易成本仍可能阻止用户使用该应用。

如果同一函数执行数千次或数百万次，微小的 Gas 节省也会带来显著的经济价值。

降低 Gas 使用量可以提高余额较少用户的可用性。

这也有助于时效性交易在竞争纳入区块时避免支付过高的总费用。

对于自动化加密货币策略，Gas 效率尤为重要，因为执行成本可能超过交易或强制平仓的预期利润。

高效合约也会占用更少的有限区块容量，使网络可用资源能够容纳更多交易。

因此，优化既有利于个人用户，也有利于整个区块链生态系统。

修改代码前先测量 Gas

开发者应先测量 Gas 消耗，再决定合约的哪些部分需要优化。

看起来效率低下的源代码，编译器可能已经做了简化。

源代码层面的简写也可能生成成本高于清晰实现的字节码。

Gas 报告应涵盖合约部署、成功交易、回滚交易、最大规模输入和少见的执行分支。

某个函数对单个用户来说成本较低，但处理大型数组或多个存储条目时可能变得费用高昂。

自动化 Gas 快照可以比较不同软件版本的成本，并发现意外增加。

执行跟踪可以找出高成本的操作码、存储槽、内存扩展和外部合约调用。

Solidity 编译器文档介绍了编译器可生成的输出、优化设置和 Gas 估算值。

开发者应将估算值视为参考，因为动态循环和外部调用会使准确的 Gas 使用量取决于区块链状态。

优化智能合约架构

Gas 节省最多的做法通常是调整合约架构，而不是重写单个表达式。

即便算术运算高度优化，存储了不必要信息的合约仍会十分昂贵。

开发者应确定哪些信息必须在链上强制执行，哪些信息可以在合约之外计算或建立索引。

关键余额、权限、所有权记录和抵押品数据通常需要持久链上状态。

如果未来合约执行无需读取展示信息、历史活动和分析数据，可考虑将其记录在事件日志中。

开发者还应考虑能否用一个累计值或记账索引来表示多次状态更新。

更简单的状态模型通常需要更少的存储操作，也更容易审计。

减少持久存储写入

持久存储是 Ethereum 智能合约可用资源中成本最高的资源之一。

交易完成后，存储数据仍会保留在 Ethereum 状态中。

网络节点必须处理并维护每个新增或更改的存储值。

合约应避免写入能够根据现有状态安全计算的信息。

如果所需的值已经存储，合约也应避免重复写入。

有时可以先完成所有计算，再只写入一次最终存储值，以替代多次中间更新。

除非重复存储相同数据确有必要的安全或性能优势，否则开发者不应保存重复副本。

与小幅调整算术运算相比，减少存储写入通常能节省更多成本。

缓存重复的存储读取

如果某个值在执行期间保持不变，反复从存储中读取该值可能会浪费 Gas。

合约通常可以将该值读取一次并存入局部变量，供后续计算重复使用。

根据 EIP-2929，Ethereum 对冷状态访问和热状态访问采用不同的费用。

交易期间首次访问账户或存储槽，通常比之后再次访问同一位置的成本更高。

不过，即便是热存储读取，其成本也可能高于使用已有的堆栈值或内存值。

如果外部调用可能在使用缓存值之前改变相关合约状态，就应避免缓存。

只要状态可能跨外部交互被缓存，就应检查重入和回调行为。

打包状态变量

Ethereum 存储由宽度为 32 字节的槽组成。

如果变量大小和顺序允许，Solidity 可以将多个较小的值类型变量放入同一个槽。

Solidity 官方存储布局文档介绍了变量如何分配到存储槽中。

谨慎安排变量顺序可能减少合约所需的槽数量。

例如，多个较小的整数或布尔值可能放进一个槽，而不必分别占用多个槽。

由于 EVM 通常使用 256 位字执行算术运算，使用较小整数并不会自动降低运行时 Gas。

多个打包值经常一起读取或写入时，打包的效果最好。

只更新打包槽中的一个字段，可能需要额外的掩码和组合操作。

开发者不得在可升级合约中重新排列现有存储变量，否则可能破坏之前保存的数据。

使用常量和不可变变量

永不改变的值不应作为普通的可变状态变量存储。

Solidity 允许使用

关键字声明编译时确定的值。

在合约构造期间确定、之后固定不变的值，通常可以使用

关键字。

常量和不可变变量的值会嵌入合约字节码或通过字节码引用，因此无需正常读取存储。

Solidity 常量和不可变变量文档介绍了这些声明方式之间的区别。

常见示例包括永久地址、固定限制、数学数值，以及部署后无法更改的配置。

如果应用确实需要治理或授权管理人员更新某个变量，该变量就应保持可变。

选择正确的数据位置

Solidity 数据可以根据使用方式存放在 storage、memory、calldata 或 transient storage 中。

Storage 会在不同交易之间保留数据，通常也是最昂贵的数据位置。

Memory 是临时数据，只在当前执行期间有效。

Calldata 包含随交易或合约调用传入的只读外部输入。

Transient storage 会在单笔交易中的多个调用之间保留数据，并在交易结束时自动清除。

选择成本过高且不必要的数据位置，会在不增加功能的情况下提高交易成本。

Solidity 数据位置文档介绍了这些位置对数据复制、可变性和生命周期的影响。

只读外部输入使用 Calldata

无需修改的外部函数参数通常可以保留在 calldata 中。

使用 calldata 可以避免将大型数组、字符串、字节序列或结构体复制到内存中。

如果函数只需检查提交的值，这样可以减少 Gas。

如果合约需要修改输入或创建新的内存值，使用 memory 仍然合适。

开发者还应尽量减少不必要的交易数据，因为每个 Calldata 字节都会增加交易内在 Gas 成本。

如果合约已经存储了完整配置，有时可以用简短标识符替代重复值。

应谨慎测量压缩效果，因为解码所需的计算可能超过节省的成本。

考虑当前的 Calldata 定价

Ethereum 的 Pectra 升级于 2025 年 5 月 7 日启用，其中包含会影响数据密集型交易经济性的变更。

EIP-7623 为携带大量 Calldata、但 EVM 执行量相对较少的交易设置了更高的 Gas 下限。

这项规则旨在限制数据密集型区块的最大大小，并增强网络韧性。

开发者不应认为计算量很少的交易一定成本低廉，因为交易可能包含大量 Calldata。

发送证明、签名、批次或压缩交易信息的应用，应针对当前协议行为进行基准测试。

新的网络升级可能改变 Calldata、计算、存储和其他资源的相对成本。

临时状态使用瞬态存储

瞬态存储适用于必须在单笔交易期间保留、但之后无需持续保存的信息。

Ethereum 通过 EIP-1153 引入了

和 操作码。

交易结束时，瞬态值会自动丢弃。

由于数据无需永久保存，瞬态存储比持久存储便宜。

常见用例包括在单笔交易中的多个内部或外部调用之间共用重入锁。

瞬态存储还可用于临时记账、回调和交易范围内的权限。

余额或必须在之后的交易中继续可用的信息不能用瞬态存储代替。

在可组合的加密货币应用中使用瞬态存储前，开发者必须了解其在普通调用和委托调用中的行为。

使用 Solidity 优化器

Solidity 优化器可以简化表达式、移除不必要的操作、合并计算并缩小字节码。

Solidity 官方优化器文档介绍了生成代码时采用的多种优化阶段。

优化器可以降低部署 Gas、运行时 Gas，或同时降低两者。

runs 设置表示开发者估计已部署代码会执行的频率。

较低的 runs 值通常更侧重于缩小部署字节码。

较高的 runs 值通常允许部署体积更大，以换取更低的重复执行成本。

没有适合所有智能合约的理想 runs 设置。

开发者应根据合约的实际部署和使用预期比较不同配置。

基于 IR 的编译流程可能产生与旧流程不同的结果，应通过完整测试进行评估。

使用当前且经过验证的编译器

Solidity 编译器版本可能带来 Gas 优化、新 EVM 支持、漏洞修复和安全改进。

选择用于生产部署的编译器前，开发者应查看 Solidity 官方网站。

除非项目有特定兼容性原因，否则 Solidity 文档通常建议使用当前发布的编译器。

开发者还应查阅Solidity 编译器已知漏洞官方列表。

应在构建流程中固定编译器版本和优化设置。

使用不同编译器重新编译相同源代码，可能生成不同的字节码并改变 Gas 表现。

使用自定义错误

与冗长的回滚字符串相比，自定义错误通常更省 Gas。

回滚字符串会增加部署字节码，并在交易失败时生成编码文本。

自定义错误使用简短选择器，并可包含结构化参数。

Solidity 自定义错误文档介绍了合约如何定义并返回自定义错误。

错误信息仍应提供足够信息，帮助钱包、用户和开发者了解失败原因。

为了节省极少量 Gas 而移除有用的失败信息，会增加应用支持和审计的难度。

优化循环

如果循环次数取决于可能无限增长的集合，循环可能变得危险地昂贵。

无界循环最终可能需要超过单笔交易可提供的 Gas。

如果可行，应将大型工作量拆分为可预测的批次。

如果缓存的信息在执行期间不会变化，循环可以缓存数组长度或反复使用的值。

如果从数学上可以证明不会溢出，有时可以对循环计数器使用未检查算术。

未检查代码应配有测试和清晰的安全说明。

现代编译器已经优化了许多常见循环模式，因此应测量手动修改的效果，而不是假设它一定更便宜。

减少外部合约调用

外部合约调用会产生账户访问、参数编码、返回数据处理以及被调用合约执行所需的 Gas 成本。

如果一次安全调用就能获得所需值，合约应避免重复调用相同的外部函数。

有时可以将多个相关操作合并到一次调用或一笔交易中。

不过，批处理可能增加 Calldata、执行复杂度，以及某一步失败时回滚的工作量。

外部调用还会带来与重入、恶意返回数据、Gas 消耗和意外失败有关的安全问题。

Gas 优化绝不能移除返回值检查或安全交互模式。

适当情况下使用事件代替存储

事件可以将区块链活动记录下来，供链下钱包、界面、分析系统和索引器使用。

与将相同信息存储为持久合约状态相比，记录事件通常成本更低。

如果未来智能合约执行无需读取或强制执行相关信息，就适合使用事件。

交易历史、活动通知和描述性元数据可能适合写入日志。

余额、权限、债务、抵押品和所有权不能只存入事件，因为正常的 EVM 执行无法搜索历史日志。

合约必须将未来决策所需的信息保存在可访问的状态中。

降低合约部署成本

部署合约需要为其初始化逻辑和运行时字节码的存储消耗 Gas。

未使用的函数、重复代码、嵌入数据和冗长错误消息都会增加部署成本。

开发者应移除不可达代码；如果大型库只有一小部分会用到，也应避免引入整个库。

库可以减少多个合约中的重复字节码，但外部库调用会带来运行时成本和依赖。

如果需要部署许多相似的合约实例，工厂和克隆模式可以降低部署成本。

代理模式也可以共享实现代码，但会引入委托调用开销、升级权限和存储布局风险。

选择架构时应考虑安全性和生命周期需求，而不应只看部署 Gas。

设置正确的 EVM 版本

Solidity 编译器可以根据所选 EVM 版本生成不同的字节码。

较新的 EVM 版本可能支持旧网络无法执行的高效指令。

例如，EIP-3855 引入了简短的

指令，用于将 0 压入栈中。

EIP-5656 引入了

，用于更高效地复制内存。

如果针对正确的网络进行配置，当前编译器可以自动使用受支持的指令。

如果某个网络尚未启用所需升级，针对较新 EVM 编译的合约可能无法运行。

因此，开发者必须选择与目标部署链兼容的 EVM 版本。

了解 Gas 退款

符合条件的存储操作可能产生 Gas 退款，从而减少最终计费的 Gas。

Ethereum 当前规则将协议级退款限制为总 Gas 使用量的 20%。

EIP-3529 降低了清除符合条件存储的退款，并取消了此前针对

的退款。

清除存储仍可能带来有限收益，但不会让创建和删除状态变成免费操作。

开发者不应为了稍后获得退款而写入不必要的数据。

退款也会在执行后应用，因此无法避免 Gas 耗尽导致的失败。

不是现代 Gas 优化方法，并且根据 EIP-6780，其行为受到限制。

谨慎考虑批处理

将多个操作合并为一笔交易，可以避免重复支付交易开销。

这也可以减少钱包确认次数，改善用户体验。

不过，每个操作仍然需要消耗执行自身计算和状态变更所需的 Gas。

大型批次可能接近交易 Gas 上限，或导致成本高昂的“全部成功或全部失败”问题。

应用应明确子操作失败时是回滚整个批次，还是允许部分完成。

应谨慎设计授权，因为范围过广的批处理签名可能允许超出用户预期的操作。

Pectra 的 EIP-7702 支持外部拥有账户将执行委托给智能合约代码，从而实现批处理和 Gas 代付等钱包功能。

对控制加密货币的委托账户逻辑，应像其他合约一样仔细审查。

使用 Layer 2 网络进一步降低成本

智能合约优化可以减少应用所需的计算量。

在合适的 Layer 2 网络上部署，可以进一步降低用户为计算和相关数据支付的价格。

Rollup 会在 Ethereum 主网之外处理交易，并将数据或证明发布回 Ethereum。

Dencun 升级通过 EIP-4844 引入了 Blob，为 Rollup 提供独立的临时数据市场。

Layer 2 费用较低，并不意味着不再需要优化 Gas，因为低效合约仍会浪费容量，且成本高于同一网络上高效的合约。

开发者还必须评估跨链桥安全性、提现规则、流动性、最终确定性和网络特定的费用计算方式。

避免过早进行底层优化

开发者不应在测量普通 Solidity 代码之前就开始使用内联汇编或复杂位操作。

编译器可能已经能从清晰的高级语言实现中生成高效字节码。

汇编有时可以降低特定操作的 Gas，但会绕过多项语言级保护机制。

汇编错误可能导致内存损坏、编码错误、不安全调用或用户资金损失。

底层优化应有可读的参考实现，并通过测试证明行为一致。

如果汇编处理余额、签名、权限或外部调用，独立安全审查尤其重要。

不要为了节省 Gas 而牺牲安全性

如果攻击者可以窃取合约中的加密货币，那么成本再低也没有用。

不得仅为降低 Gas 使用量而移除访问控制、输入验证、重入保护、滑点检查、截止时间和记账检查。

只有在所有可达条件下都不可能溢出或下溢时，才应使用未检查算术。

压缩存储可以节省 Gas，但可能增加位级错误的发生概率。

代理可以降低部署成本，却可能带来中心化升级控制或存储冲突。

链下签名可以省去一笔交易，但会引入 Nonce、有效期、重放和域分隔等要求。

优化决策应接受安全性、可读性、可升级性和运维风险审查。

Gas 优化测试

每项优化都应与原始实现进行对照测试。

功能测试应确认两个版本产生相同的状态变更和输出。

Gas 测试应测量平均使用量、最大支持使用量和失败条件。

模糊测试可以探索不常见输入，从而发现成本高昂或错误的执行路径。

不变量测试可以确认优化后关键记账和安全属性仍然成立。

开发者还应使用计划用于生产环境的确切编译器版本、优化器设置和 EVM 目标进行测试。

应保留 Gas 快照，防止后续开发悄然抵消优化效果。

常见的 Gas 优化错误

一种常见错误是认为所有较小的整数类型都能降低 Gas。

另一种错误是没有实际需要，却将只读外部数据从 calldata 复制到 memory。

开发者还可能针对存储集合创建无界循环，导致应用增长后循环无法执行。

有些团队优化很少使用的函数，却忽略了每笔用户交易都会重复产生的小额成本。

另一些团队则没有测试部署与运行时权衡，就选择优化器设置。

还有人尚未确定实际高成本操作，就开始加入手写汇编。

开发者也可能在 Ethereum 升级重新调整操作价格后，仍依赖过时的 Gas 计算表。

最危险的错误，是为了得到漂亮的 Gas 基准数据而移除必要的安全检查。

如何制定 Gas 优化策略

Gas 优化策略应从明确定义合约行为和安全要求开始。

开发团队应先创建完整测试，再修改实现方式。

然后在符合实际情况的条件下测量部署成本和交易成本。

应优先处理成本最高的存储操作、循环、Calldata 载荷和外部调用。

在重写底层代码之前，应先考虑简化架构。

应测试并记录编译器设置和目标 EVM 版本。

每项优化都应接受功能、Gas 和安全审查。

最终部署应使用固定工具和依赖版本构建可复现的字节码。

常见问题

简单来说，什么是 Gas 优化？

Gas 优化是指在安全执行智能合约时，减少所需的区块链计算、存储和交易数据。

Gas 优化会降低 Gas 价格吗？

不会。它减少的是 Gas 使用量，而 Gas 价格由网络需求和交易费用设置决定。

最有效的 Gas 优化是什么？

减少不必要的持久存储操作和简化合约架构，通常能带来最大的节省。

存储比内存贵吗？

是。持久存储通常更贵，因为交易结束后数据仍保留在区块链状态中。

Calldata 比 memory 便宜吗？

对于只读外部输入，Calldata 可能更便宜，因为无需将完整数据复制到内存中。

较小的整数类型总能节省 Gas 吗？

不能。通常只有在多个值可以打包到同一个存储槽时，它们才能显著节省存储成本。

什么是瞬态存储？

瞬态存储是按交易范围生效、会自动清除的 EVM 存储，可以降低临时合约状态的成本。

Solidity 优化器总能降低成本吗？

不能。某种优化器配置可能降低运行时 Gas，却增加部署成本，因此应测量每种配置。

优化器 runs 是什么意思？

runs 设置会影响编译器在缩小部署字节码和降低重复执行成本之间的权衡。

自定义错误比回滚字符串便宜吗？

通常更高效，因为自定义错误使用简短选择器和编码参数，而不是冗长文本字符串。

事件可以代替存储吗？

只有在未来智能合约执行无需读取或强制执行相关信息时，事件才可以代替存储。

清除存储会产生 Gas 退款吗？

符合条件的存储清除操作可以产生有限退款，但退款有上限，无法退还原存储成本的全部金额。

Gas 退款可以避免 Gas 耗尽导致的失败吗？

不能。Gas 退款在执行后计算，交易运行期间无法依靠退款获得额外 Gas。

批处理总能节省 Gas 吗？

不能。批处理可以减少重复交易开销，但可能增加 Calldata、复杂度和失败风险。

开发者应使用内联汇编进行优化吗？

只有在性能分析确认存在瓶颈时才应使用内联汇编，因为它可能带来严重的安全和维护风险。

Layer 2 网络可以代替 Gas 优化吗？

不能。Layer 2 网络可能降低费用，但在同一网络上，低效合约仍会比优化后的合约消耗更多资源。

Gas 成本为什么会随时间变化？

Ethereum 升级可能引入新操作码、重新调整现有操作的费用、改变 Calldata 规则或扩大网络容量。

开发者如何测量 Gas 使用量？

开发者可以使用 Gas 报告、交易回执、执行跟踪、编译器输出、自动化快照和符合实际情况的测试。

消耗 Gas 最少的实现总是最好的吗？

不是。合约的安全性、正确性、可读性和可维护性比少量 Gas 节省更重要。

用户可以在不更改合约的情况下优化 Gas 吗？

用户可以选择需求较低的时段或合适的网络，但只有合约开发者能够改变应用底层执行效率。

结语

Gas 优化是一种工程实践，用于减少加密货币智能合约和交易消耗的资源。

它降低的是 Gas 使用量，而不是直接改变每个 Gas 单位的市场价格。

最有效的优化通常来自更简单的架构、更少的存储操作、高效的数据位置、有界循环和更少的外部调用。

编译器优化、常量、不可变值、自定义错误、变量打包、瞬态存储和适当的批处理也可以进一步节省成本。

开发者应使用当前版本的编译器、查看已知编译器漏洞，并针对正确的 EVM 版本。

每项优化都必须针对成功交易、失败交易、大型输入和异常执行路径进行测试。

绝不能仅为减少 Gas 报告中的数值而移除安全控制。

经过良好优化的合约只执行提供安全、透明且可靠的加密货币功能所必需的链上工作。