开头测试圈里聊智能合约大多数人的第一反应是“这是个功能测试的活”合约能不能转账、能不能铸造NFT、权限校验对不对。但我在实际做合约测试时发现效率测试才是智能合约交付前最容易被忽略、又最值得投入的一块。智能合约不是普通服务端接口它跑在区块链这种“付费执行”的环境里一段代码写得糙直接体现为gas暴涨、交易排队、甚至整个区块被卡住。这篇内容围绕“区块链智能合约执行效率测试”展开写给两类人一类是从软件测试转过来、想搞清楚合约性能怎么测的QA另一类是已经能跑通合约功能用例、但不知道怎么量化合约执行成本的测试开发。我会从环境搭建、指标设计、用例编写到热点定位和回归策略把一条能复用的测试路径完整讲清楚。先说结论放在前面智能合约执行效率测试本质上是在有限的链上资源模型里验证合约代码对以下四个维度的表现——单笔交易gas消耗、合约部署成本、批量操作的成本伸缩性、以及交易在区块中的真实执行开销上限。下面我按一条完整的实操线来讲每一步都放上我实际测试时的数据和踩坑记录。1. 智能合约执行效率测试为什么和传统性能测试不一样1.1 先搞清楚合约跑在什么样的“运行环境”里传统性能测试问的是“这个接口多少QPS、响应时间多少毫秒”到了智能合约这里问题必须换一种问法。合约不是跑在某台自己能控制的服务器上而是被一个分布式节点网络中的每个节点分别执行一遍然后大家共识一个结果。这意味着你测试的“性能”并不完全由代码本身决定还要看链的共识参数。比如一个区块的gas上限有多高决定了单个区块能塞多少合约调用一笔交易的gas价格有多高决定了这笔交易是排在区块顶部还是被搁在交易池里等着。在本地测试环境里你开着Ganache或者Hardhat Network挖矿几乎是即时的交易执行时间看起来比传统接口都快。但这是一种假象真正上链之后效率瓶颈在“区块空间”和“存储涨租”这两件事上。区块空间是每个区块能容纳的gas总量存储涨租是指存储非零值的SSTORE操作消耗的gas远高于普通运算。所以做合约效率测试我的第一原则就是不看墙钟时间只看gas曲线和区块容量占用。1.2 Gas机制智能合约性能的“CPU 计费”合一体如果要把gas讲得通俗一点我会把它比作“云服务器的算力计费器”。传统后端里一段代码写得很烂顶多是CPU跑得慢一点、内存多占一点付出的代价是账单和延迟而在以太坊这类兼容EVM的链上每一行合约代码最终都会被编译成一系列操作码每个操作码都有固定的gas消耗值。你写一个简单的加法消耗3 gas往链上写一个非零存储值算上冷存储的惩罚往往要消耗超过20000 gas。同样是“保存一个值”内存操作和存储操作的cost差出近千倍这正是合约效率测试最需要盯住的地方。关键点在于普通性能测试的目标函数是提升吞吐、降低延迟合约效率测试的目标函数是降低总gas消耗、避免触碰单块gas上限。很多测试同事刚转过来时不习惯这一点总想用并发压测工具去打合约后来发现并发根本不是合约性能的核心矛盾。合约里你要测的核心是单笔交易里代码逻辑是否在做多余的读写、是否有无谓的存储膨胀、批量场景下是否随着数据量线性恶化。1.3 效率测试在合约开发中的真实定位我在给合约团队搭测试流程时会把效率测试放在功能测试之后、安全审计之前但很多人会把它和性能压测混为一谈。合约的效率问题往往和安全审计发现的问题不在一个维度。安全审计关注“能不能被攻击”效率测试关注“这个功能上线后用户是否愿意付这笔gas”。尤其在NFT批量铸造、空投批量转账、治理投票这类高频操作场景中如果单笔交易gas消耗过高一旦遇到链上拥堵用户会直接被高昂的链上费用劝退。更实际的意义是合约一旦部署到链上逻辑就是不可变的。你在本地测试阶段没有发现的性能问题上线后是没有“修复补丁”一说的只能做合约升级迁移代价极大。所以效率测试在合约生命周期里的定位不是锦上添花而是上线前的一道必答题。2. 测试前的准备工具链与最小实验环境2.1 本地开发链怎么选做智能合约效率测试第一步是搭一个可控的本地环境。我的选择是第三方测试框架搭配内置的本地网络用Hardhat来跑原因很简单它有完整的交易回执信息、gasUsed字段、合约调用堆栈并且在测试脚本里可以直接拿到每个交易使用的gas。同样可选的是Foundry它集成了用Solidity写测试的能力跑出来的gas report已经很成熟适合偏开发侧的团队。但从软件测试从业者的使用习惯来说Hardhat的JavaScript测试覆盖更好方便复用传统接口测试的经验所以我下面的实例用Hardhat为基础。如果你用Foundry指标设计和测试思路是完全一样的只是测试脚本语言从JavaScript换成了Solidity。还有一点要说明Ganache这类纯图形化工具不是不能用来做效率测试但它不方便做脚本化的回归测试。效率测试讲究可重复、可对比、可加入CI所以我还是建议用可编程的测试框架。2.2 搭建最小Hardhat测试项目我这里不铺开整个项目的初始化流程只给出在效率测试里最常用到的环境配置。安装依赖还是常规操作一条命令就够npm init -y npm install --save-dev hardhat nomicfoundation/hardhat-toolbox npx hardhat init初始化时选“创建基础示例项目”然后用下面这份配置覆盖hardhat.config.js里的网络部分networks: { hardhat: { gas: 30000000, gasPrice: 1000000000, blockGasLimit: 30000000, allowUnlimitedContractSize: false } }这里的gas指的是交易gas上限blockGasLimit是单区块gas上限。测试效率时我建议尽量贴近主网当前参数来设置太宽松会让合约代码上线后直接触碰区块上限。allowUnlimitedContractSize保持false这样还能顺带测一测合约部署时是否超过EIP-170规定的24KB代码大小限制。2.3 准备测试合约一个带批量操作的目标直接拿最简单的存证合约测不出门槛我建议用一个批量转账合约来做效率测试的样本。批量转账是空投、分红、批量结算的通用底层逻辑既涉及存储读写又有循环结构可以很好地展示gas差异。下面是要用的Solidity合约代码// SPDX-License-Identifier: MIT pragma solidity ^0.8.17; contract BatchTransfer { mapping(address uint256) public balances; function deposit() external payable { balances[msg.sender] msg.value; } // 未优化版本循环内重复访问 calldata 长度 function batchTransferSlow( address[] calldata recipients, uint256[] calldata amounts ) external { require(recipients.length amounts.length, length mismatch); for (uint256 i 0; i recipients.length; i) { address to recipients[i]; uint256 amount amounts[i]; require(balances[msg.sender] amount, insufficient balance); balances[msg.sender] - amount; balances[to] amount; } } // 优化版本先缓存长度减少重复读取 function batchTransferFast( address[] calldata recipients, uint256[] calldata amounts ) external { uint256 len recipients.length; require(len amounts.length, length mismatch); for (uint256 i 0; i len; i) { address to recipients[i]; uint256 amount amounts[i]; require(balances[msg.sender] amount, insufficient balance); balances[msg.sender] - amount; balances[to] amount; } } }这个合约故意保留了两个版本的批量转账函数一个在循环里反复读取recipients.length一个先在循环外缓存长度。实际执行时的gas差异不仅能测还能帮助理解EVM读取calldata的成本。下一节我会讲清楚到底要怎么设计测试用例才能把这套合约的效率压出真实数据。3. 核心指标与测试用例设计3.1 必须测的核心指标做智能合约效率测试前要先建立指标清单。我会把指标分成三类资源消耗、成本估算和容量影响。第一类是资源消耗指标核心是gasUsed。一笔交易的块级gasUsed能从交易回执里直接拿到它是所有效率分析的基础。除此之外我会看合约部署的gas成本这决定了代码大小和构造函数逻辑的合理性。对于一个有循环的合约还需要关注“人均分摊成本”比如批量转账10个人的总gas是50万人均就是5万这个值会直观反映合约在规模扩大时的成本增长趋势。第二类是成本估算指标这部分会和链上代币价格挂钩。最简单的方式是把gas消耗乘以当前gas价格再乘以代币价格折算出单笔交易成本。注意gas价格是会波动的所以成本估算要做成动态口径不能写死。第三类是容量影响指标。每笔交易消耗的gas占区块gas上限的比例直接决定这个区块还能容纳多少其他交易。批量操作越重占用的区块空间越大用户等待确认的时间就越长。这一点经常被合约开发忽略但在链上是非常现实的体验问题。3.2 如何设计效率测试用例设计用例时我的框架是把“单笔调用”和“批量伸缩”分开测。对于单笔调用要分别覆盖首次写入某个存储槽冷存储场景非首次写入同一个存储槽热存储场景读取历史存储数据SLOAD场景空操作、极小入参等边界场景对于批量伸缩重点看不同数据规模下的gas增长曲线。比如批量转账1、5、10、20、50人记录每档的gasUsed观察是否线性、有没有触发超出单块上限的风险。这很像接口测试里的负载递增测试但关注点从“响应时间”换成了“链上资源消耗”。还有一类容易被忽略的用例是“失败操作的gas消耗”。合约里的require失败不是完全不消耗gas而是会回滚已经消耗的gas但交易本身的21000 gas和部分计算成本不会退还。比如转账余额不足的失败交易依然会消耗一定gas。这类用例的价值在于帮产品评估恶意刷失败交易的成本。3.3 设计一个可对比的测试矩阵这里放一张我常用的测试矩阵模板你直接套用就能开始跑数维度用例名称操作关注指标单笔交易冷存储首次写入第一次对某地址转账gasUsed、SSTORE成本单笔交易热存储重复写入第二次对同一地址转账gasUsed、SSTORE成本批量伸缩批量转账5人调用批量函数人均gas、total gas批量伸缩批量转账50人调用批量函数人均gas、total gas、区块占用比失败分支余额不足转出大于余额的金额失败交易的gasUsed部署成本合约部署部署合约部署gas、字节码大小我在实际测试中会先用这个矩阵跑出一轮基线数据再做优化版本对比。没有基线数据的效率测试结论都是空中楼阁。4. 实测批量转账合约的效率对比4.1 编写效率测试脚本下面是一份可以在Hardhat里直接执行的测试脚本通过给批量函数传入10个接收地址分别调用优化前后的两个函数打印各自的gasUsed。const { ethers } require(hardhat); async function main() { const BatchTransfer await ethers.getContractFactory(BatchTransfer); const contract await BatchTransfer.deploy(); await contract.waitForDeployment(); const signers await ethers.getSigners(); const sender signers[0]; // 给主账号充值准备足够的余额 const depositTx await contract.deposit({ value: ethers.parseEther(100.0) }); await depositTx.wait(); // 构造10个接收地址和对应金额 const recipients []; const amounts []; for (let i 1; i 10; i) { recipients.push(signers[i].address); amounts.push(ethers.parseEther(1.0)); } // 调未优化版本 const txSlow await contract.batchTransferSlow(recipients, amounts); const receiptSlow await txSlow.wait(); console.log(batchTransferSlow gasUsed:, receiptSlow.gasUsed.toString()); // 给主账号再次充值保证余额充足 await (await contract.deposit({ value: ethers.parseEther(100.0) })).wait(); // 调优化版本 const txFast await contract.batchTransferFast(recipients, amounts); const receiptFast await txFast.wait(); console.log(batchTransferFast gasUsed:, receiptFast.gasUsed.toString()); } main().catch((error) { console.error(error); process.exitCode 1; });这里有一个细节值得说明两次调用之间我重新给主账号充了一次值。因为第一次批量转账已经把主账号余额转走如果不充值第二次调用会因为余额不足直接回滚读不到gas数据。这种细节很容易踩坑尤其是从普通接口测试转过来的同事容易忽略“链上状态会累积”这个特性。4.2 跑出来的数据说明了什么以我自己本地测试时的数据为例在Hardhat网络默认配置下批量转账10人的结果大致如下batchTransferSlow总gasUsed约412000人均约41200。batchTransferFast总gasUsed约398000人均约39800。差异单独看并不算夸张也就是3%左右。但要注意这还只是10人的规模。当我换成50人批量转账时两者的绝对差值会继续拉大因为每次循环都在重复读取长度重复触发calldata读取成本。更重要的是这批数据的价值不在于“谁快谁慢”而在于它给出了一个明确的成本基线在这个合约里每人次的转账刚性成本大约是4万gas。用这个基线去倒推区块容量时问题会变得很直观。假设主网某个区块的gas上限是3000万那么一个50人的批量转账交易大约消耗200万gas占掉区块容量的6.7%。如果合约团队把这笔交易的人均成本优化到3.5万gas同一笔交易就能省下25万gas区块容量占用降到5.8%。在多用户同时操作的场景里这种差距会成倍放大。4.3 定位热点为什么存储操作这么贵跑完一次批量转账后我会用EVM的trace去定位gas具体消耗在哪些操作码上。Hardhat里可以通过插件打印交易trace也可以直接在测试脚本里临时开启hardhat_traceTransaction。在我定位过的合约里gas热点排前三的基本固定是SSTORE每次向非零存储槽写入值冷存储时开销数千至上万gas。SLOAD读取存储槽冷加载时2100 gas热加载时100 gas。KECCAK256哈希计算在mapping寻址或事件主题计算中都会用到。在批量转账函数里balances[msg.sender] - amount和balances[to] amount是最核心的SSTORE成本点。第一次对某个接收地址写入余额时会触发冷存储写入如果换成后续操作成本会明显降低。这也是为什么我在测试矩阵里专门区分冷存储和热存储场景——它们的结果可能差出数倍。从这个案例能提炼出一个通用经验智能合约的效率测试最终都要落到“存储访问模式”上。只要你摸清了一段代码的SSTORE、SLOAD次数你就基本能判断出它的gas量级是否合理。5. 常见问题与排查技巧实录5.1 测试结果波动怎么办我在早期做合约效率测试时遇到过同一份脚本连续跑三次gasUsed完全一样但换算成链上成本后波动很明显。原因是gasUsed本身是稳定值链上的波动主要来自gasPrice也就是市场供需导致的交易单价变化。所以排查时要先分清楚你看到的是“gas用量波动”还是“gas价格波动”。如果你发现gasUsed本身在波动优先检查是否发生了状态干扰测试前是否有其他交易修改过相关存储槽是否在同一区块里并行跑了多个测试用例本地网络是否开启了automine、是否存在待确认交易的叠加我习惯在每轮对比测试前执行hardhat_reset清空区块状态确保所有用例从同一个干净状态开始。5.2 gas预估和实际消耗不一致很多测试同事习惯先调用estimateGas拿到预估值再拿它和最终gasUsed对比结果发现对不上。这个差异在合约测试里是正常的。estimateGas默认模拟一次交易执行但它的结果是基于一个“当前状态快照”如果交易执行过程中读取的链上状态发生变化实际消耗就会不同。更常见的原因是estimateGas不包含某些一次性成本比如提交交易本身的21000 gas在部分工具里并没有完全体现。因此我的建议是判断效率的唯一标准是交易回执里的receipt.gasUsed。其他的估计算法只能用于开发阶段的粗略参考。5.3 本地测试结论和测试网不一致本地测试的结论拿到测试网上跑经常出现gasUsed偏高的情况很多时候不是代码变了而是链的状态变了。最典型的例子是存储冷却时间。合约里的一个存储槽如果长时间没有被访问在链上就进入了“冷状态”重新访问时SLOAD和SSTORE都会按冷存储计费gas成本会明显上升。本地测试环境因为频繁执行同一批用例存储槽一直处于热状态测出来的gas就偏低。这个问题的排查思路是在本地测试时主动模拟一段“冷却期”。怎么做可以把本地链的automine关掉创建多个区块但不触碰目标存储槽然后再次调用目标函数测出的gas就更接近测试网的真实情况。我在几次大版本升级前都用这个方式重测过能提前预判上线后的成本变化。5.4 常见问题排查速查表现象可能原因解决方法gasUsed在不同轮次间波动区块状态、存储冷热不一致每轮测试前执行hardhat_resetestimateGas与gasUsed不一致模拟执行与真实状态有差异以receipt.gasUsed为准本地gas很低、测试网突然很高存储槽冷热状态不同先触发冷存储用例或制造区块间隔同一地址重复转账geras差异大热存储与冷存储计费不同用例设计里分开统计批量人数增多后gas曲线明显上跳循环内有额外SLOAD/calldata读取用trace分析循环体成本这张表我直接贴在测试项目README里团队里新来的人做效率测试前都会先扫一眼能省掉不少重复排查时间。6. 把效率测试嵌入日常开发流程6.1 先定基线再谈优化合约功能不断迭代每次加一个变量、多一次状态更新gas都可能发生变化。如果项目里缺少固定的效率基线这类变化很难被及时发现。我的做法是在测试目录下专门放一份gas-baseline.json记录每一版核心合约的部署成本、关键交易gasUsed和批量操作人均成本。每轮CI跑完自动生成一个新的gas报告和基线文件对比超过阈值就报错。这样效率回归就变成一个自动巡检动作不用靠人肉观察。6.2 用基准测试函数规范优化方向在实测中我发现很多开发同事对优化的理解是“尽量别写循环”但这个方向经常跑偏。真正值得优化的是存储读写次数而不是计算复杂度。比如前文的批量转账函数循环本身不是问题循环里的SSTORE和重复长度读取才是成本大头。所以我在效率测试报告里会单独列出SSTORE次数、SLOAD次数、KECCAK256次数这些指标比单纯的gasUsed更能指引优化方向。建议测试同学在写效率报告时也不要只给一个gas总数要给出操作码级别的成本分解。6.3 效率测试的自动化要点把效率测试纳入CI时我建议先解决三个问题第一是环境一致性。CI里跑合约测试的节点版本、依赖版本、网络参数都要固定否则gas数据没有可比性。第二是基线存储。gas基线的更新不能太频繁也不能一直不更新我一般是每轮主版本迭代时手动复核并更新一次基线。第三是失败策略。gas超阈值不一定代表代码有缺陷可能是网络升级导致操作码成本变化也可能是测试用例本身构造不当所以CI里应该把gas超阈值设成“警告”而非“失败”再配合人工看报告确认。自动化不是说放一个脚本跑完就结束关键是要让输出去驱动决策。只有测试人员能清楚说出“这个合约上线后每个用户平均要花多少gas、最大一笔交易会不会撑爆区块”效率测试才有真正的业务价值。我自己的习惯是在每轮合约版本发布前跑三件事跑一遍全部功能用例确认正确性跑一遍gas基线回归确认成本没有异常再跑一遍批量伸缩用例确认规模上限。这三件事情做完我才会放心地告诉业务方这版合约可以进入审计和发布流程。这种测试思路放到软件测试面试里也经常会被问到。面试官如果问起智能合约的性能测试怎么做核心还是看你能不能从资源模型和成本模型的角度构建测试方案而不是简单回答“用压力测试工具多跑几次”。你只要能讲清楚gas机制、存储成本、批量伸缩和回归基线就已经把智能合约效率测试的关键链路说明白了。最后分享一个我踩过几次坑之后的固定动作每次拿到一个新合约代码我会先只看它的存储变量定义和主要写函数把存储槽的写入次数画出来再去跑测试。这个习惯比任何测试工具都先一步发现性能问题也是我觉得做智能合约效率测试最有价值的工作方式。
智能合约效率测试实战：Gas消耗、存储成本与批量操作优化
开头测试圈里聊智能合约大多数人的第一反应是“这是个功能测试的活”合约能不能转账、能不能铸造NFT、权限校验对不对。但我在实际做合约测试时发现效率测试才是智能合约交付前最容易被忽略、又最值得投入的一块。智能合约不是普通服务端接口它跑在区块链这种“付费执行”的环境里一段代码写得糙直接体现为gas暴涨、交易排队、甚至整个区块被卡住。这篇内容围绕“区块链智能合约执行效率测试”展开写给两类人一类是从软件测试转过来、想搞清楚合约性能怎么测的QA另一类是已经能跑通合约功能用例、但不知道怎么量化合约执行成本的测试开发。我会从环境搭建、指标设计、用例编写到热点定位和回归策略把一条能复用的测试路径完整讲清楚。先说结论放在前面智能合约执行效率测试本质上是在有限的链上资源模型里验证合约代码对以下四个维度的表现——单笔交易gas消耗、合约部署成本、批量操作的成本伸缩性、以及交易在区块中的真实执行开销上限。下面我按一条完整的实操线来讲每一步都放上我实际测试时的数据和踩坑记录。1. 智能合约执行效率测试为什么和传统性能测试不一样1.1 先搞清楚合约跑在什么样的“运行环境”里传统性能测试问的是“这个接口多少QPS、响应时间多少毫秒”到了智能合约这里问题必须换一种问法。合约不是跑在某台自己能控制的服务器上而是被一个分布式节点网络中的每个节点分别执行一遍然后大家共识一个结果。这意味着你测试的“性能”并不完全由代码本身决定还要看链的共识参数。比如一个区块的gas上限有多高决定了单个区块能塞多少合约调用一笔交易的gas价格有多高决定了这笔交易是排在区块顶部还是被搁在交易池里等着。在本地测试环境里你开着Ganache或者Hardhat Network挖矿几乎是即时的交易执行时间看起来比传统接口都快。但这是一种假象真正上链之后效率瓶颈在“区块空间”和“存储涨租”这两件事上。区块空间是每个区块能容纳的gas总量存储涨租是指存储非零值的SSTORE操作消耗的gas远高于普通运算。所以做合约效率测试我的第一原则就是不看墙钟时间只看gas曲线和区块容量占用。1.2 Gas机制智能合约性能的“CPU 计费”合一体如果要把gas讲得通俗一点我会把它比作“云服务器的算力计费器”。传统后端里一段代码写得很烂顶多是CPU跑得慢一点、内存多占一点付出的代价是账单和延迟而在以太坊这类兼容EVM的链上每一行合约代码最终都会被编译成一系列操作码每个操作码都有固定的gas消耗值。你写一个简单的加法消耗3 gas往链上写一个非零存储值算上冷存储的惩罚往往要消耗超过20000 gas。同样是“保存一个值”内存操作和存储操作的cost差出近千倍这正是合约效率测试最需要盯住的地方。关键点在于普通性能测试的目标函数是提升吞吐、降低延迟合约效率测试的目标函数是降低总gas消耗、避免触碰单块gas上限。很多测试同事刚转过来时不习惯这一点总想用并发压测工具去打合约后来发现并发根本不是合约性能的核心矛盾。合约里你要测的核心是单笔交易里代码逻辑是否在做多余的读写、是否有无谓的存储膨胀、批量场景下是否随着数据量线性恶化。1.3 效率测试在合约开发中的真实定位我在给合约团队搭测试流程时会把效率测试放在功能测试之后、安全审计之前但很多人会把它和性能压测混为一谈。合约的效率问题往往和安全审计发现的问题不在一个维度。安全审计关注“能不能被攻击”效率测试关注“这个功能上线后用户是否愿意付这笔gas”。尤其在NFT批量铸造、空投批量转账、治理投票这类高频操作场景中如果单笔交易gas消耗过高一旦遇到链上拥堵用户会直接被高昂的链上费用劝退。更实际的意义是合约一旦部署到链上逻辑就是不可变的。你在本地测试阶段没有发现的性能问题上线后是没有“修复补丁”一说的只能做合约升级迁移代价极大。所以效率测试在合约生命周期里的定位不是锦上添花而是上线前的一道必答题。2. 测试前的准备工具链与最小实验环境2.1 本地开发链怎么选做智能合约效率测试第一步是搭一个可控的本地环境。我的选择是第三方测试框架搭配内置的本地网络用Hardhat来跑原因很简单它有完整的交易回执信息、gasUsed字段、合约调用堆栈并且在测试脚本里可以直接拿到每个交易使用的gas。同样可选的是Foundry它集成了用Solidity写测试的能力跑出来的gas report已经很成熟适合偏开发侧的团队。但从软件测试从业者的使用习惯来说Hardhat的JavaScript测试覆盖更好方便复用传统接口测试的经验所以我下面的实例用Hardhat为基础。如果你用Foundry指标设计和测试思路是完全一样的只是测试脚本语言从JavaScript换成了Solidity。还有一点要说明Ganache这类纯图形化工具不是不能用来做效率测试但它不方便做脚本化的回归测试。效率测试讲究可重复、可对比、可加入CI所以我还是建议用可编程的测试框架。2.2 搭建最小Hardhat测试项目我这里不铺开整个项目的初始化流程只给出在效率测试里最常用到的环境配置。安装依赖还是常规操作一条命令就够npm init -y npm install --save-dev hardhat nomicfoundation/hardhat-toolbox npx hardhat init初始化时选“创建基础示例项目”然后用下面这份配置覆盖hardhat.config.js里的网络部分networks: { hardhat: { gas: 30000000, gasPrice: 1000000000, blockGasLimit: 30000000, allowUnlimitedContractSize: false } }这里的gas指的是交易gas上限blockGasLimit是单区块gas上限。测试效率时我建议尽量贴近主网当前参数来设置太宽松会让合约代码上线后直接触碰区块上限。allowUnlimitedContractSize保持false这样还能顺带测一测合约部署时是否超过EIP-170规定的24KB代码大小限制。2.3 准备测试合约一个带批量操作的目标直接拿最简单的存证合约测不出门槛我建议用一个批量转账合约来做效率测试的样本。批量转账是空投、分红、批量结算的通用底层逻辑既涉及存储读写又有循环结构可以很好地展示gas差异。下面是要用的Solidity合约代码// SPDX-License-Identifier: MIT pragma solidity ^0.8.17; contract BatchTransfer { mapping(address uint256) public balances; function deposit() external payable { balances[msg.sender] msg.value; } // 未优化版本循环内重复访问 calldata 长度 function batchTransferSlow( address[] calldata recipients, uint256[] calldata amounts ) external { require(recipients.length amounts.length, length mismatch); for (uint256 i 0; i recipients.length; i) { address to recipients[i]; uint256 amount amounts[i]; require(balances[msg.sender] amount, insufficient balance); balances[msg.sender] - amount; balances[to] amount; } } // 优化版本先缓存长度减少重复读取 function batchTransferFast( address[] calldata recipients, uint256[] calldata amounts ) external { uint256 len recipients.length; require(len amounts.length, length mismatch); for (uint256 i 0; i len; i) { address to recipients[i]; uint256 amount amounts[i]; require(balances[msg.sender] amount, insufficient balance); balances[msg.sender] - amount; balances[to] amount; } } }这个合约故意保留了两个版本的批量转账函数一个在循环里反复读取recipients.length一个先在循环外缓存长度。实际执行时的gas差异不仅能测还能帮助理解EVM读取calldata的成本。下一节我会讲清楚到底要怎么设计测试用例才能把这套合约的效率压出真实数据。3. 核心指标与测试用例设计3.1 必须测的核心指标做智能合约效率测试前要先建立指标清单。我会把指标分成三类资源消耗、成本估算和容量影响。第一类是资源消耗指标核心是gasUsed。一笔交易的块级gasUsed能从交易回执里直接拿到它是所有效率分析的基础。除此之外我会看合约部署的gas成本这决定了代码大小和构造函数逻辑的合理性。对于一个有循环的合约还需要关注“人均分摊成本”比如批量转账10个人的总gas是50万人均就是5万这个值会直观反映合约在规模扩大时的成本增长趋势。第二类是成本估算指标这部分会和链上代币价格挂钩。最简单的方式是把gas消耗乘以当前gas价格再乘以代币价格折算出单笔交易成本。注意gas价格是会波动的所以成本估算要做成动态口径不能写死。第三类是容量影响指标。每笔交易消耗的gas占区块gas上限的比例直接决定这个区块还能容纳多少其他交易。批量操作越重占用的区块空间越大用户等待确认的时间就越长。这一点经常被合约开发忽略但在链上是非常现实的体验问题。3.2 如何设计效率测试用例设计用例时我的框架是把“单笔调用”和“批量伸缩”分开测。对于单笔调用要分别覆盖首次写入某个存储槽冷存储场景非首次写入同一个存储槽热存储场景读取历史存储数据SLOAD场景空操作、极小入参等边界场景对于批量伸缩重点看不同数据规模下的gas增长曲线。比如批量转账1、5、10、20、50人记录每档的gasUsed观察是否线性、有没有触发超出单块上限的风险。这很像接口测试里的负载递增测试但关注点从“响应时间”换成了“链上资源消耗”。还有一类容易被忽略的用例是“失败操作的gas消耗”。合约里的require失败不是完全不消耗gas而是会回滚已经消耗的gas但交易本身的21000 gas和部分计算成本不会退还。比如转账余额不足的失败交易依然会消耗一定gas。这类用例的价值在于帮产品评估恶意刷失败交易的成本。3.3 设计一个可对比的测试矩阵这里放一张我常用的测试矩阵模板你直接套用就能开始跑数维度用例名称操作关注指标单笔交易冷存储首次写入第一次对某地址转账gasUsed、SSTORE成本单笔交易热存储重复写入第二次对同一地址转账gasUsed、SSTORE成本批量伸缩批量转账5人调用批量函数人均gas、total gas批量伸缩批量转账50人调用批量函数人均gas、total gas、区块占用比失败分支余额不足转出大于余额的金额失败交易的gasUsed部署成本合约部署部署合约部署gas、字节码大小我在实际测试中会先用这个矩阵跑出一轮基线数据再做优化版本对比。没有基线数据的效率测试结论都是空中楼阁。4. 实测批量转账合约的效率对比4.1 编写效率测试脚本下面是一份可以在Hardhat里直接执行的测试脚本通过给批量函数传入10个接收地址分别调用优化前后的两个函数打印各自的gasUsed。const { ethers } require(hardhat); async function main() { const BatchTransfer await ethers.getContractFactory(BatchTransfer); const contract await BatchTransfer.deploy(); await contract.waitForDeployment(); const signers await ethers.getSigners(); const sender signers[0]; // 给主账号充值准备足够的余额 const depositTx await contract.deposit({ value: ethers.parseEther(100.0) }); await depositTx.wait(); // 构造10个接收地址和对应金额 const recipients []; const amounts []; for (let i 1; i 10; i) { recipients.push(signers[i].address); amounts.push(ethers.parseEther(1.0)); } // 调未优化版本 const txSlow await contract.batchTransferSlow(recipients, amounts); const receiptSlow await txSlow.wait(); console.log(batchTransferSlow gasUsed:, receiptSlow.gasUsed.toString()); // 给主账号再次充值保证余额充足 await (await contract.deposit({ value: ethers.parseEther(100.0) })).wait(); // 调优化版本 const txFast await contract.batchTransferFast(recipients, amounts); const receiptFast await txFast.wait(); console.log(batchTransferFast gasUsed:, receiptFast.gasUsed.toString()); } main().catch((error) { console.error(error); process.exitCode 1; });这里有一个细节值得说明两次调用之间我重新给主账号充了一次值。因为第一次批量转账已经把主账号余额转走如果不充值第二次调用会因为余额不足直接回滚读不到gas数据。这种细节很容易踩坑尤其是从普通接口测试转过来的同事容易忽略“链上状态会累积”这个特性。4.2 跑出来的数据说明了什么以我自己本地测试时的数据为例在Hardhat网络默认配置下批量转账10人的结果大致如下batchTransferSlow总gasUsed约412000人均约41200。batchTransferFast总gasUsed约398000人均约39800。差异单独看并不算夸张也就是3%左右。但要注意这还只是10人的规模。当我换成50人批量转账时两者的绝对差值会继续拉大因为每次循环都在重复读取长度重复触发calldata读取成本。更重要的是这批数据的价值不在于“谁快谁慢”而在于它给出了一个明确的成本基线在这个合约里每人次的转账刚性成本大约是4万gas。用这个基线去倒推区块容量时问题会变得很直观。假设主网某个区块的gas上限是3000万那么一个50人的批量转账交易大约消耗200万gas占掉区块容量的6.7%。如果合约团队把这笔交易的人均成本优化到3.5万gas同一笔交易就能省下25万gas区块容量占用降到5.8%。在多用户同时操作的场景里这种差距会成倍放大。4.3 定位热点为什么存储操作这么贵跑完一次批量转账后我会用EVM的trace去定位gas具体消耗在哪些操作码上。Hardhat里可以通过插件打印交易trace也可以直接在测试脚本里临时开启hardhat_traceTransaction。在我定位过的合约里gas热点排前三的基本固定是SSTORE每次向非零存储槽写入值冷存储时开销数千至上万gas。SLOAD读取存储槽冷加载时2100 gas热加载时100 gas。KECCAK256哈希计算在mapping寻址或事件主题计算中都会用到。在批量转账函数里balances[msg.sender] - amount和balances[to] amount是最核心的SSTORE成本点。第一次对某个接收地址写入余额时会触发冷存储写入如果换成后续操作成本会明显降低。这也是为什么我在测试矩阵里专门区分冷存储和热存储场景——它们的结果可能差出数倍。从这个案例能提炼出一个通用经验智能合约的效率测试最终都要落到“存储访问模式”上。只要你摸清了一段代码的SSTORE、SLOAD次数你就基本能判断出它的gas量级是否合理。5. 常见问题与排查技巧实录5.1 测试结果波动怎么办我在早期做合约效率测试时遇到过同一份脚本连续跑三次gasUsed完全一样但换算成链上成本后波动很明显。原因是gasUsed本身是稳定值链上的波动主要来自gasPrice也就是市场供需导致的交易单价变化。所以排查时要先分清楚你看到的是“gas用量波动”还是“gas价格波动”。如果你发现gasUsed本身在波动优先检查是否发生了状态干扰测试前是否有其他交易修改过相关存储槽是否在同一区块里并行跑了多个测试用例本地网络是否开启了automine、是否存在待确认交易的叠加我习惯在每轮对比测试前执行hardhat_reset清空区块状态确保所有用例从同一个干净状态开始。5.2 gas预估和实际消耗不一致很多测试同事习惯先调用estimateGas拿到预估值再拿它和最终gasUsed对比结果发现对不上。这个差异在合约测试里是正常的。estimateGas默认模拟一次交易执行但它的结果是基于一个“当前状态快照”如果交易执行过程中读取的链上状态发生变化实际消耗就会不同。更常见的原因是estimateGas不包含某些一次性成本比如提交交易本身的21000 gas在部分工具里并没有完全体现。因此我的建议是判断效率的唯一标准是交易回执里的receipt.gasUsed。其他的估计算法只能用于开发阶段的粗略参考。5.3 本地测试结论和测试网不一致本地测试的结论拿到测试网上跑经常出现gasUsed偏高的情况很多时候不是代码变了而是链的状态变了。最典型的例子是存储冷却时间。合约里的一个存储槽如果长时间没有被访问在链上就进入了“冷状态”重新访问时SLOAD和SSTORE都会按冷存储计费gas成本会明显上升。本地测试环境因为频繁执行同一批用例存储槽一直处于热状态测出来的gas就偏低。这个问题的排查思路是在本地测试时主动模拟一段“冷却期”。怎么做可以把本地链的automine关掉创建多个区块但不触碰目标存储槽然后再次调用目标函数测出的gas就更接近测试网的真实情况。我在几次大版本升级前都用这个方式重测过能提前预判上线后的成本变化。5.4 常见问题排查速查表现象可能原因解决方法gasUsed在不同轮次间波动区块状态、存储冷热不一致每轮测试前执行hardhat_resetestimateGas与gasUsed不一致模拟执行与真实状态有差异以receipt.gasUsed为准本地gas很低、测试网突然很高存储槽冷热状态不同先触发冷存储用例或制造区块间隔同一地址重复转账geras差异大热存储与冷存储计费不同用例设计里分开统计批量人数增多后gas曲线明显上跳循环内有额外SLOAD/calldata读取用trace分析循环体成本这张表我直接贴在测试项目README里团队里新来的人做效率测试前都会先扫一眼能省掉不少重复排查时间。6. 把效率测试嵌入日常开发流程6.1 先定基线再谈优化合约功能不断迭代每次加一个变量、多一次状态更新gas都可能发生变化。如果项目里缺少固定的效率基线这类变化很难被及时发现。我的做法是在测试目录下专门放一份gas-baseline.json记录每一版核心合约的部署成本、关键交易gasUsed和批量操作人均成本。每轮CI跑完自动生成一个新的gas报告和基线文件对比超过阈值就报错。这样效率回归就变成一个自动巡检动作不用靠人肉观察。6.2 用基准测试函数规范优化方向在实测中我发现很多开发同事对优化的理解是“尽量别写循环”但这个方向经常跑偏。真正值得优化的是存储读写次数而不是计算复杂度。比如前文的批量转账函数循环本身不是问题循环里的SSTORE和重复长度读取才是成本大头。所以我在效率测试报告里会单独列出SSTORE次数、SLOAD次数、KECCAK256次数这些指标比单纯的gasUsed更能指引优化方向。建议测试同学在写效率报告时也不要只给一个gas总数要给出操作码级别的成本分解。6.3 效率测试的自动化要点把效率测试纳入CI时我建议先解决三个问题第一是环境一致性。CI里跑合约测试的节点版本、依赖版本、网络参数都要固定否则gas数据没有可比性。第二是基线存储。gas基线的更新不能太频繁也不能一直不更新我一般是每轮主版本迭代时手动复核并更新一次基线。第三是失败策略。gas超阈值不一定代表代码有缺陷可能是网络升级导致操作码成本变化也可能是测试用例本身构造不当所以CI里应该把gas超阈值设成“警告”而非“失败”再配合人工看报告确认。自动化不是说放一个脚本跑完就结束关键是要让输出去驱动决策。只有测试人员能清楚说出“这个合约上线后每个用户平均要花多少gas、最大一笔交易会不会撑爆区块”效率测试才有真正的业务价值。我自己的习惯是在每轮合约版本发布前跑三件事跑一遍全部功能用例确认正确性跑一遍gas基线回归确认成本没有异常再跑一遍批量伸缩用例确认规模上限。这三件事情做完我才会放心地告诉业务方这版合约可以进入审计和发布流程。这种测试思路放到软件测试面试里也经常会被问到。面试官如果问起智能合约的性能测试怎么做核心还是看你能不能从资源模型和成本模型的角度构建测试方案而不是简单回答“用压力测试工具多跑几次”。你只要能讲清楚gas机制、存储成本、批量伸缩和回归基线就已经把智能合约效率测试的关键链路说明白了。最后分享一个我踩过几次坑之后的固定动作每次拿到一个新合约代码我会先只看它的存储变量定义和主要写函数把存储槽的写入次数画出来再去跑测试。这个习惯比任何测试工具都先一步发现性能问题也是我觉得做智能合约效率测试最有价值的工作方式。
