eth_estimateGas：为什么 Gas 估算会出错，以及如何安全设置 Gas 上限

eth_estimateGas 实际返回什么

以太坊 JSON-RPC 规范将 eth_estimateGas 定义为生成并返回一笔交易完成所需 Gas 估算值的方法。关键词是“估算”：节点针对特定状态执行该调用，并返回执行所消耗的 Gas，这是对一次模拟的测量，而不是对未来某个区块的承诺。规范还记录了一个可选的区块参数，因此同一个调用可以在 latest、指定的历史区块或 pending 状态下求值。

当你传入完整的交易对象时，返回的数量包含交易的固有成本，以太坊黄皮书将其固定为普通转账 21000 Gas，再加上 calldata 和合约创建成本。当你只传入一个没有 from 或 nonce 的调用对象时，某些客户端会将其视为调用，可能不会加上完整的固有成本。这种歧义是上限过低的最常见来源之一，也正是为什么你发送的参数对象与你拿到的数字同样重要。

由于结果是模拟，它反映的是你所请求区块的状态。如果该状态在你的交易被打包之前发生变化，即使节点回答正确，估算也可能出错。请把这个数字当作上限计算的输入，而不是上限本身。

本文贯穿使用的方法契约由以太坊 JSON-RPC 规范中关于 eth_estimateGas 和 eth_call 的定义确定，Gas 上限与费用参数的划分来自 EIP-1559，固有 Gas 下限（21000 加上 calldata 成本）定义于以太坊黄皮书。请以这些为事实来源，本文只是建立在其之上的操作流程。

• 返回在给定状态下模拟执行所消耗的 Gas 数量。
• 在提供完整交易对象时包含 21000 固有 Gas。
• 遵循可选的区块参数，因此 latest 与指定区块的结果可能不同。
• 不保证链上成功；它只是对一次模拟的测量。

Gas 估算出错的四个原因

状态漂移是第一个原因。估算是在区块 N 取得的，但你的交易可能在区块 N+3 才被打包，此时其他交易已经改变了余额、授权额度或合约存储。一笔在区块 N 估算为 150000 Gas 的兑换，如果在区块 N+3 时池子比例发生变化并执行了不同分支，就可能需要更多 Gas。这是有文档记录的协议行为：估算的准确性只取决于取得它时的状态。

第二个原因是在模拟中成功、但在状态已经变化的区块中回滚的调用。一笔依赖另一笔待处理交易的交易，例如尚未被挖出的授权，会针对授权不存在的状态进行估算。如果合约能容忍缺失的授权额度，模拟可能仍然成功，但当依赖以不同方式落地时，真实交易可能回滚。

第三个原因是服务商差异。以太坊 JSON-RPC 规范记录了可选的区块参数和状态覆盖集，但某个服务商是否遵循它们、以及如何处理缺失的 from 字段，因服务商而异。有些端点会忽略指定区块，始终在 latest 上估算；另一些则拒绝状态覆盖。请始终确认你所使用端点的行为，而不要假设规范已被完整实现。

第四个原因是回滚时的提前终止。当模拟调用回滚时，节点报告的是到回滚点为止消耗的 Gas，而不是成功路径所需的 Gas。如果你把这个数字当作上限，你就是在为失败做预算，而不是为成功。这就是为什么回滚原因通常只能通过使用相同参数的 eth_call 才能看到。

• 估算与打包之间的状态漂移会改变执行的分支。
• 依赖待处理交易的调用会针对一个不会存在的状态进行估算。
• 服务商对区块参数和状态覆盖的处理各不相同。
• 回滚会提前终止模拟，只报告到失败点为止消耗的 Gas。

eth_call 与 eth_estimateGas：选择正确的探测方式

以太坊 JSON-RPC 规范将 eth_call 描述为立即执行一个新的消息调用而不创建交易、并返回该调用返回数据的方法。如果调用回滚，eth_call 会返回错误，许多客户端会在该错误中包含回滚原因。eth_estimateGas 返回一个数量，当调用回滚时它也会返回错误，但该错误针对的是估算值而不是返回值。

当你需要返回数据、想要暴露回滚原因，或检查某条路径在给定状态下是否成功时，请使用 eth_call。当你需要用于构建交易的 Gas 数量时，请使用 eth_estimateGas。实践中你会同时使用两者：先估算得到起始数字，再用相同参数调用以确认路径成功并捕获任何回滚原因。解码以太坊回滚原因与自定义错误一文介绍了如何将这些错误转换为可读的消息。

一个有用的模式是先用你打算发送的确切参数运行 eth_call。如果它回滚，先修复调用，再花时间做 Gas 估算。如果它成功，就在同一区块运行 eth_estimateGas 并比较。两者之间差距很大，说明估算是在不同状态或不同默认值下取得的。

• eth_call 返回返回数据，并在回滚时报错，从而暴露回滚原因。
• eth_estimateGas 返回 Gas 数量，并在调用回滚时报错。
• 先运行 eth_call 验证路径，再用 eth_estimateGas 确定上限大小。
• 在同一区块比较两者，以发现状态或默认值不匹配。

固有 Gas 下限与合约创建附加费

以太坊黄皮书将固有 Gas 定义为交易在任何合约代码运行之前支付的基础成本。对于普通价值转账，这是 21000 Gas。calldata 按字节增加成本，零字节成本较低，非零字节成本较高，而合约创建会在基础成本之上增加附加费。安全上限必须包含所有这些，因为低于固有下限的上限会在执行开始前就失败。

eth_estimateGas 是否包含固有成本取决于你传入的参数。当你提供带有 from 地址和 to 地址的完整交易对象时，节点可以计算并包含固有成本。当你提供裸调用对象时，某些客户端只估算执行成本。这是规范参数描述中有记录的行为，但实际效果因服务商而异，因此请用一笔已知的简单转账来验证。

一个快速的合理性检查是估算一笔向外部账户的普通转账。如果结果接近 21000，说明该端点包含了固有 Gas。如果远低于此，你看到的只是执行成本，必须自行加上下限。这一项检查就能避免一大类上限过低的问题。

• 21000 Gas 是普通转账的基础成本。
• calldata 按字节增加成本，零字节与非零字节定价不同。
• 合约创建会在基础成本和 calldata 成本之上增加附加费。
• 通过估算一笔普通转账来验证你的端点是否包含固有 Gas。

从估算值推导安全上限

第一步是将估算值乘以可配置的安全系数。对于简单转账和稳定的合约调用，1.2 到 1.5 是常见的起始范围，而更依赖状态的调用可能需要更高。该系数是策略选择，不是协议常量，应根据你自己的测量结果调整，而不是从博客文章照搬。

第二步是以区块 Gas 上限对结果封顶。高于区块 Gas 上限的上限永远无法被打包，而接近该上限则说明估算有误或该调用异常昂贵。从最新区块读取区块 Gas 上限，并将推导出的上限钳制在其之下。

第三步是对照发送方余额检查可负担性。在 EIP-1559 下，Gas 上限是预算，费用参数是价格，节点会检查发送方能否覆盖上限乘以 maxFeePerGas 再加上 value。慷慨的上限会占用余额，即使只按实际使用的 Gas 收费，因此一个对执行而言安全的上限仍可能让交易变得无法负担。EIP-1559 费用市场文章介绍了价格一侧，本文有意将其与上限分开。

• 将估算值乘以可配置的安全系数，通常为 1.2 到 1.5。
• 将推导出的上限钳制在当前区块 Gas 上限之下。
• 检查余额能否覆盖上限乘以 maxFeePerGas 再加上 value。
• 将上限决策与费用价格决策分开。

一个可运行的 Node.js 估算器：带缓冲与验证

下面的脚本在指定区块上使用完整交易对象调用 eth_estimateGas，应用缓冲，以区块 Gas 上限封顶，然后用 eth_call 验证同一调用。它只使用现代 Node.js 内置的 fetch，因此无需安装任何依赖。请将端点替换为你自己的，可参考以太坊 RPC URL 与端点选择指南。

脚本从同一指定区块的 eth_getBlockByNumber 读取区块 Gas 上限，因此封顶反映的是你估算时所依据的状态。它还会打印原始估算值、缓冲后的上限和封顶后的上限，让你看到每个阶段。如果 eth_call 返回错误，脚本会打印回滚原因，这是区分坏调用与坏估算最快的方法。

const RPC_URL = process.env.RPC_URL || "https://your-endpoint.example";
const PINNED_BLOCK = process.env.BLOCK || "latest";
const SAFETY_FACTOR = Number(process.env.SAFETY_FACTOR || 1.3);

async function rpc(method, params) {
  const res = await fetch(RPC_URL, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params })
  });
  const json = await res.json();
  if (json.error) throw new Error(method + " -> " + JSON.stringify(json.error));
  return json.result;
}

async function main() {
  const tx = {
    from: "0xYourSenderAddress",
    to: "0xRecipientOrContract",
    value: "0x0",
    data: "0x",
    maxFeePerGas: "0x3b9aca00",
    maxPriorityFeePerGas: "0x3b9aca00"
  };

  const block = await rpc("eth_getBlockByNumber", [PINNED_BLOCK, false]);
  const blockGasLimit = BigInt(block.gasLimit);

  const estimateHex = await rpc("eth_estimateGas", [tx, PINNED_BLOCK]);
  const estimate = BigInt(estimateHex);

  const buffered = (estimate * BigInt(Math.round(SAFETY_FACTOR * 100))) / 100n;
  const capped = buffered > blockGasLimit ? blockGasLimit : buffered;

  console.log("raw estimate:", estimate.toString());
  console.log("buffered limit:", buffered.toString());
  console.log("capped limit:", capped.toString());

  try {
    const returnData = await rpc("eth_call", [tx, PINNED_BLOCK]);
    console.log("eth_call ok, return data:", returnData);
  } catch (err) {
    console.log("eth_call reverted:", err.message);
  }
}

main().catch((e) => { console.error(e.message); process.exit(1); });

一张针对你自己的端点填写的测量结果表

服务商行为各不相同，因此了解你的端点如何处理 eth_estimateGas 的唯一可靠方式就是实测。在同一指定区块上对多种调用类型运行上面的脚本，然后在 latest 上重复，并记录数字。下表是模板；请用你自己的测量结果填写，而不要依赖任何已发布的数字。

信息量最大的行是普通转账和依赖状态的调用。接近 21000 的普通转账确认了固有 Gas 已被包含。依赖状态的调用在指定区块和 latest 之间出现差异，则确认区块参数被遵循。如果你明知某个调用依赖状态，而两行结果完全相同，那么你的端点可能忽略了区块参数。

• 列：调用类型、区块参数、原始估算值、缓冲上限、封顶上限、eth_call 结果。
• 行：普通转账、ERC-20 转账、依赖状态的兑换、合约创建。
• 在 latest 和指定区块上分别重复每一行，以检测区块参数的处理方式。
• 将区块 Gas 上限与封顶上限一并记录，以便提供上下文。

排查常见的 eth_estimateGas 失败

eth_estimateGas 返回 -32000 execution reverted 错误意味着模拟调用失败。在这种情况下，估算方法返回错误而不是数字，而回滚原因通常只能通过使用相同参数的 eth_call 才能看到。先运行 eth_call，捕获原因，修复调用后再重试估算。JSON-RPC -32603 内部错误调试指南介绍了相邻的一类非回滚的节点侧错误。

gas required exceeds allowance 错误通常意味着发送方余额无法覆盖上限乘以费用参数再加上 value。这是可负担性失败，不是执行失败。如果上限被高估，就降低它，或者为账户充值。请记住，在 EIP-1559 下，即使只按实际使用的 Gas 收费，也会预先检查完整的上限。

对于无限循环路径，估算返回区块 Gas 上限是一个信号，说明模拟触及了上限。不要发送该上限。相反，应检查合约逻辑，确认循环会终止，如果该路径确实无界，应将其视为设计问题而不是 Gas 问题。回滚原因只能通过 eth_call 看到是第四种常见情况：估算报告了失败但没有原因，而 eth_call 会将其暴露出来。

• -32000 execution reverted：用相同参数运行 eth_call 以获取原因。
• gas required exceeds allowance：检查余额能否覆盖上限乘以 maxFeePerGas 再加上 value。
• 估算值等于区块 Gas 上限：怀疑存在无界循环，不要发送。
• 估算中缺少回滚原因：eth_call 是能暴露它的探测方式。

缓冲上限的局限与权衡

慷慨的上限会占用余额。在 EIP-1559 下，节点会检查发送方能否覆盖上限乘以 maxFeePerGas 再加上 value，因此一个所需两倍的上限会在交易期间预留两倍余额。对于批量发送多笔交易的账户，这可能迫使串行化，或要求比实际支出更高的余额。

估算的准确性只取决于取得它时的状态。指定区块提供可复现性，但随着链推进而变得过时；latest 提供新鲜度，但不可复现。两者都无法解决依赖问题，即你的交易结果取决于另一笔待处理交易。对于这些情况，考虑显式安排交易顺序，并在每个依赖落地后重新估算。

最后，安全系数是策略，不是协议保证。对某个合约安全的系数对另一个合约可能太小，今天安全的系数在合约升级后可能太小。请把该系数视为可调参数，用你自己的测量结果定期重新审视，并将上限决策与费用价格决策分开，以便独立推理两者。

• 高上限会预先预留余额，即使只按实际使用的 Gas 收费。
• 指定区块的估算可复现但会过时；latest 新鲜但不可复现。
• 对未打包交易的依赖无法通过任何区块参数解决。
• 安全系数是可调策略，需要定期重新测量。

生产环境 Gas 处理的后续步骤

首先对你的估算器进行埋点，记录原始估算值、缓冲上限、封顶上限以及打包后的实际 Gas 使用量。经过几百笔交易后，你就能看出安全系数是过紧还是过松，并可以基于证据而非猜测来调整。eth_feeHistory 奖励百分位文章介绍了同一流水线的价格一侧。

将上限逻辑与 nonce 管理配合使用，以便依赖交易按正确顺序排列。EVM nonce 管理指南解释了如何读取和排序 nonce，这正是让每个依赖落地后重新估算变得有意义的关键。关于端点选择和故障转移，请查看以太坊网络页面和 API 服务概览，如果你计划进行高频估算，请查看 RPC 定价。OnFinality Learn 中心将相关的费用、nonce 和错误处理文章汇集在一处。

• 记录原始估算值、缓冲上限、封顶上限和实际 Gas 使用量。
• 根据你自己的打包数据调整安全系数。
• 通过正确的 nonce 管理安排依赖交易的顺序。
• 选择遵循你所依赖的区块参数和状态覆盖的端点。