EVM Nonce 管理：在并发场景下正确使用 eth_getTransactionCount

直接答案：Nonce 是应用程序状态，而非每次请求的 RPC 调用

在并发场景下正确使用 eth_getTransactionCount 的方法是不要为每笔要发送的交易都调用它。相反，应将 nonce 视为应用程序状态：通过 eth_getTransactionCount(ADDRESS, 'pending') 初始化一次，然后维护一个本地单调递增的计数器，每广播一笔交易就递增一次。仅在重连、重组或丢失在途交易跟踪后，才从节点重新同步。这样可以避免经典的竞争条件：多个并发发送者各自读取相同的 'pending' nonce，然后发生冲突，产生 'nonce too low' 错误或交易卡住。

本文解释了 nonce 背后的机制，为什么 'pending' 标签既强大又危险，并提供了一个可复现的 Node.js 项目来观察失败和修复。还包括常见 JSON-RPC 错误字符串及其补救措施的决策表。

EVM Nonce 的工作原理：每个账户的标量

在以太坊协议中，来自外部拥有账户（EOA）的每笔交易都携带一个 nonce 字段：一个顺序的、每账户的标量，第一笔交易从 0 开始。以太坊黄皮书将账户状态定义为包含 nonce，而 eth_getTransactionCount 的执行 API 规范指出，它返回从某个地址发送的交易数量——这正是你应该使用的下一个 nonce。

节点维护该计数的两个视图：已提交状态（规范区块中的内容）和 pending 状态（已提交加上节点内存池中的内容）。eth_getTransactionCount 方法接受一个区块参数：'latest'（默认）返回已提交的计数，'pending' 包含内存池中的交易，十六进制区块号返回特定历史区块的计数。

关键洞察是，'pending' 并非全局真相——它是你所查询的特定节点的内存池视图。不同节点（和不同提供商）可能具有不同的内存池，尤其是在传播延迟或重组之后。如果你依赖 'pending' 进行每次发送，可能会得到一个已被其他发送者使用的过期值，或者可能错过另一个节点已经看到的交易。

并发发送失败的原因：竞争条件

考虑一个简单的脚本，它生成 N 个并行发送者，每个都调用 eth_getTransactionCount(ADDRESS, 'pending')，然后使用该 nonce 广播交易。由于调用是并发的，它们很可能收到相同的 nonce 值。第一笔交易被挖矿，但其他交易因 'nonce too low' 被拒绝，因为该 nonce 已被使用。

即使你串行化读取，节点的 pending 视图也可能因传播延迟而尚未包含你刚刚广播的交易。这就是为什么每次发送都读取 'pending' 从根本上存在竞争。

安全模式是让一个单一的写入者（或分布式锁）拥有 nonce 计数器。初始化一次，本地递增，并且仅在怀疑本地计数器不同步时（例如，在重组或交易被丢弃后）重新同步。

故障模式及如何恢复

当你发送具有错误 nonce 的交易时，节点会返回 JSON-RPC 错误。以下是常见的错误及处理方法：

'nonce too low' – 你使用的 nonce 已在规范链或内存池中。这通常意味着你重复计数了。恢复：从 eth_getTransactionCount(ADDRESS, 'pending') 重新同步本地计数器，并使用正确的 nonce 重新广播。

'nonce too high' – 你跳过了 nonce，造成间隙。节点将排队你的交易，但在所有较低 nonce 被填充之前不会挖矿。恢复：先发送缺失的较低 nonce 交易，或通过发送具有缺失 nonce 的交易（例如，向自己发送 0 值转账）来取消间隙。

'replacement transaction underpriced' – 你尝试用相同的 nonce 替换待处理交易，但 gas 价格不够高。以太坊替换规则要求至少约 10% 的价格提升（确切百分比不在协议规范中，但由 Geth 等节点强制执行）。恢复：以更高的 gas 价格（例如，增加 10-20%）重新广播。

重组和交易被丢弃 – 重组后，节点的 'pending' 视图可能回退，内存池中的交易可能被丢弃。如果你的本地计数器领先于节点，你将收到 'nonce too high'。恢复：从 'pending' 重新同步，并准备重新发送任何丢失的交易。

可复现的 Node.js 项目：查看 Bug 和修复

以下 Node.js 脚本使用 ethers v6（或通过 fetch 的原始 JSON-RPC）来演示这些概念。它需要用户提供的端点（例如，OnFinality 以太坊端点）和具有一些资金的 EOA 的私钥。

该脚本有三种模式：check 打印地址的 'latest' 和 'pending' nonce；bug 运行并发发送以演示竞争；safe 运行带有本地计数器和重试逻辑的安全模式。

将脚本保存为 nonce-demo.js，并使用 node nonce-demo.js <endpoint> <privateKey> <mode> 运行。

const { ethers } = require('ethers');

async function main() {
  const endpoint = process.argv[2];
  const privateKey = process.argv[3];
  const mode = process.argv[4] || 'check';
  const provider = new ethers.JsonRpcProvider(endpoint);
  const wallet = new ethers.Wallet(privateKey, provider);
  const address = wallet.address;

  if (mode === 'check') {
    const latest = await provider.getTransactionCount(address, 'latest');
    const pending = await provider.getTransactionCount(address, 'pending');
    console.log(`Latest nonce: ${latest}`);
    console.log(`Pending nonce: ${pending}`);
    return;
  }

  if (mode === 'bug') {
    // Concurrent sends: each reads pending nonce and sends
    const senders = [];
    for (let i = 0; i < 5; i++) {
      senders.push((async () => {
        const nonce = await provider.getTransactionCount(address, 'pending');
        try {
          const tx = await wallet.sendTransaction({
            to: address, // send to self
            value: 0,
            nonce,
            gasLimit: 21000,
            maxFeePerGas: ethers.parseUnits('1', 'gwei'),
            maxPriorityFeePerGas: ethers.parseUnits('1', 'gwei')
          });
          console.log(`Sent with nonce ${nonce}: ${tx.hash}`);
        } catch (e) {
          console.log(`Failed with nonce ${nonce}: ${e.shortMessage || e.message}`);
        }
      })());
    }
    await Promise.all(senders);
    return;
  }

  if (mode === 'safe') {
    // Seed once
    let nextNonce = await provider.getTransactionCount(address, 'pending');
    console.log(`Starting nonce: ${nextNonce}`);

    // Serialize sends with a simple queue
    const sendQueue = [];
    for (let i = 0; i < 5; i++) {
      sendQueue.push((async () => {
        const nonce = nextNonce++;
        let attempt = 0;
        while (attempt < 3) {
          try {
            const tx = await wallet.sendTransaction({
              to: address,
              value: 0,
              nonce,
              gasLimit: 21000,
              maxFeePerGas: ethers.parseUnits('1', 'gwei'),
              maxPriorityFeePerGas: ethers.parseUnits('1', 'gwei')
            });
            console.log(`Sent with nonce ${nonce}: ${tx.hash}`);
            return;
          } catch (e) {
            const msg = e.shortMessage || e.message;
            if (msg.includes('replacement transaction underpriced')) {
              // Bump gas price by 20%
              attempt++;
              const newGas = ethers.parseUnits((1 + attempt * 0.2).toFixed(2), 'gwei');
              console.log(`Underpriced, retrying with gas ${newGas}`);
              // Re-send with higher gas (simplified: need to recreate tx)
              // In practice, you'd use a higher fee and same nonce
            } else if (msg.includes('nonce too low')) {
              // Re-sync
              nextNonce = await provider.getTransactionCount(address, 'pending');
              console.log(`Nonce too low, re-synced to ${nextNonce}`);
              return;
            } else {
              console.log(`Failed: ${msg}`);
              return;
            }
          }
        }
      })();
    }
    await Promise.all(sendQueue);
  }
}

main().catch(console.error);

预期输出和结果表

当你运行 check 模式时，你会看到两个数字。它们之间的差异表示该地址当前在内存池中的交易数量。例如：

这意味着有两笔交易待处理（nonce 5 和 6）。

bug 模式可能会产生多个 'nonce too low' 错误，因为所有发送者都读取了相同的 pending nonce。safe 模式应该能够使用顺序 nonce 成功发送所有交易。

用你自己的结果填写下表以验证行为：

• 模式 | 观察到的输出 | 解释
• check | Latest: X, Pending: Y | Y - X = 在途交易数量
• bug | 多个 'nonce too low' | 竞争条件：所有发送者读取相同 nonce
• safe | 所有交易均以顺序 nonce 发送 | 本地计数器防止冲突

Latest nonce: 5
Pending nonce: 7

错误字符串决策表

下表将常见的 JSON-RPC 错误消息映射到其原因和推荐的修复方法。在调试 nonce 问题时，可将其用作快速参考。

• 错误 | 原因 | 修复
• nonce too low | Nonce 已被使用（已挖矿或在内存池中） | 从 'pending' 重新同步，并使用正确的 nonce 重新广播
• nonce too high | Nonce 序列中存在间隙 | 先发送缺失的较低 nonce，或取消间隙
• replacement transaction underpriced | 替换待处理交易时 gas 价格提升不足 | 以至少约 10% 更高的 gas 价格重新广播
• transaction underpriced | Gas 价格低于节点最低要求 | 提高 gas 价格以满足节点最低要求
• already known | 交易已在内存池中 | 等待确认或使用更高 gas 替换
• nonce too low after reorg | 节点视图回退 | 从 'pending' 重新同步 nonce 并重新发送丢失的交易

局限性与权衡

内存池可见性因提供商和节点客户端而异。一笔交易可能在一个节点上可见，但在另一个节点上不可见，因此 'pending' 并非全局真相。始终使用可靠的端点，并考虑使用专门的 RPC 提供商，如 OnFinality 的以太坊 API 以获得一致的行为。

替换策略是为价格提升而设计的，而不是为相同的重新发送。如果你使用相同的 nonce 和相同的 gas 价格发送，节点将拒绝它，提示 'replacement transaction underpriced'。替换时始终将 gas 价格提高至少 10%。

切勿假设重组后 'pending' 会立即一致。节点可能需要时间来重建其内存池。如果你处于高风险环境中，请考虑在重组后等待几秒钟再重新同步。

对于高吞吐量应用，请考虑使用本地 nonce 管理器或像 ethers 的 NonceManager 这样的库（尽管它有其自身的局限性）。关键是集中化 nonce 分配。

后续步骤与进一步阅读

既然你了解了 nonce 管理，就可以将这些模式应用到自己的应用程序中。有关更多 RPC 故障排查，请浏览 OnFinality Learn 中心，获取有关 以太坊 RPC 超时和重试、JSON-RPC 批处理最佳实践 和 监控 RPC 端点 的指南。

如果你正在以太坊上构建，还可以查看 选择以太坊 RPC 端点 和 解码以太坊 revert 原因。对于生产环境，请考虑使用专门的 API 服务 和满足你需求的 RPC 定价。

请记住：nonce 是一个简单的标量，但在并发下正确管理它是一个经典的分布式系统问题。将其视为状态，而不是每次请求的查询，你将避免大多数陷阱。