Arbitrum RPC API：端点设置、方法与故障模式

Arbitrum One 是一个乐观 rollup，结算到以太坊，但它暴露了与以太坊兼容的 JSON-RPC 接口。这种兼容性很方便，也是一个陷阱：大多数以太坊工具都能工作，但少数方法、gas 规则和时序假设的行为有所不同。本页提供了连接所需的设置、发布前值得检查的方法，以及生产环境中出现的故障模式。

链设置一览

首先确认你的客户端、钱包或框架所需的值。Arbitrum One 是主网 rollup；Arbitrum Sepolia 是用于暂存的测试网。

Arbitrum One 的钱包网络配置如下所示：

{
  "chainId": "0x66eee",
  "chainName": "Arbitrum One",
  "nativeCurrency": { "name": "Ether", "symbol": "ETH", "decimals": 18 },
  "rpcUrls": ["https://arbitrum.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://arbiscan.io"]
}

注意 0x66eee 是 42161 的十六进制形式。钱包会拒绝你在文档中引用的十进制链 ID 与在 wallet_addEthereumChain 中发送的十六进制值不匹配的情况。

在编写代码之前决定如何连接

连接决策通常归结为三个问题：你的应用是否需要推送更新，是否需要历史状态，以及你的流量突发性如何？

• 只读仪表盘和钱包通常可以在共享 HTTP 端点上运行。请求短小、无状态且可缓存。
• 对新块或待处理活动做出反应的应用受益于 WebSocket 订阅，这样你就不必在循环中轮询 eth_getBlockByNumber。
• 索引器、分析和回填需要归档访问，并且通常需要更重的 eth_getLogs 查询，这正是共享公共端点开始吃紧的地方。
• 高流量或延迟敏感的工作负载更适合专用节点，你的流量不会与其他租户共享容量。

如果你不确定自己属于哪一类，RPC 提供商选择指南 会介绍评估标准。具体到 Arbitrum，你可以在 Arbitrum 网络页面 上比较共享和专用选项。

调用 Arbitrum RPC API

基本的读取请求与以太坊相同。这个 curl 调用获取最新的区块号：

curl -s https://arbitrum.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

在 JavaScript 中使用 viem，配置好链后，同样的调用只需一行：

import { createPublicClient, http } from 'viem';
import { arbitrum } from 'viem/chains';

const client = createPublicClient({
  chain: arbitrum,
  transport: http('https://arbitrum.api.onfinality.io/public'),
});

const blockNumber = await client.getBlockNumber();
console.log(blockNumber);

要订阅新块头的 WebSocket：

import WebSocket from 'ws';

const ws = new WebSocket('wss://arbitrum.api.onfinality.io/public/ws');
ws.on('open', () => {
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_subscribe',
    params: ['newHeads'],
  }));
});
ws.on('message', (data) => console.log(data.toString()));

在硬编码之前，请根据 Arbitrum 网络页面 确认确切的 WebSocket 路径，因为主网和测试网之间的传输支持可能不同。

在 Arbitrum 上行为不同的方法

由于 Arbitrum 是 rollup，一些方法返回的值与以太坊 L1 的思维模型不匹配。

gas 差异是最让团队惊讶的地方。Arbitrum 上的交易支付 L2 执行 gas 和单独的 L1 数据可用性成本，因此在以太坊上看起来合适的 gas 价格可能低估了 Arbitrum 交易。始终估算而不是假设。

故障模式及如何调试

大多数 Arbitrum RPC API 问题都属于少数几类。在更换提供商之前，将症状与可能的原因匹配。

一个实用的调试顺序：用 curl 重现失败的调用，从而将你的框架排除在外，确认你查询的区块号，然后检查同样的调用在第二个端点上是否成功。如果只在一个端点上失败，则存在基础设施问题。如果在所有地方都失败，则问题出在请求本身。

生产就绪检查清单

在将真实流量指向 Arbitrum 端点之前，请确认以下每一项：

• 故障转移：你的客户端可以在不重新部署的情况下切换到第二个端点。
• 重试：瞬态 5xx 和超时响应使用指数退避重试，而不是立即重试。
• 超时：设置请求超时，以免慢调用阻塞整个请求路径。
• 日志查询：eth_getLogs 范围有界并分页。
• 订阅：WebSocket 客户端自动重连并重新订阅。
• 可观测性：你按方法跟踪错误率和延迟，而不仅仅是整体正常运行时间。
• 容量：你知道峰值每秒请求数以及共享端点是否能吸收。

如果你的峰值负载稳定且高，或者你需要归档和 trace 访问，专用节点 消除了噪声邻居变量。如果你的负载适中且突发，托管共享端点通常是更简单的选择。两种模式的定价在 RPC 定价页面 上。

测试网工作流程

使用 Arbitrum Sepolia 进行暂存，这样你就不会在集成测试中消耗主网 ETH。链 ID 是 421614，浏览器是 https://sepolia.arbiscan.io。Arbitrum Sepolia 的水龙头由生态系统提供商运营；为一个一次性密钥提供资金，并将其排除在生产配置之外。由于测试网状态不是永久的，不要构建依赖于特定历史区块永久存在的断言。

值得跟踪的监控信号

一旦上线，有用的信号是方法级别的。将 eth_sendRawTransaction 的错误率与读取方法分开跟踪，因为写入失败通常表示 nonce 或 gas 问题，而不是基础设施问题。单独跟踪 eth_getLogs 延迟，因为它对查询形状最敏感。并跟踪 WebSocket 重连频率，因为重连次数上升是订阅处理需要关注的早期预警。

关键要点

• Arbitrum One 使用链 ID 42161，Arbitrum Sepolia 使用 421614；两者都使用 ETH 作为原生货币。
• JSON-RPC 接口与以太坊兼容，但由于 Arbitrum 是 rollup，gas 估算和日志查询行为不同。
• 始终估算 gas 而不是硬编码，并始终限制 eth_getLogs 区块范围。
• 将连接类型与工作负载匹配：HTTP 用于无状态读取，WebSocket 用于推送更新，专用节点用于持续或归档密集型流量。
• 在扩展流量之前构建故障转移、重试和重连逻辑，而不是在事件之后。

常见问题

Arbitrum RPC API 与以太坊的相同吗？ 很接近。方法名称和请求格式相同，但 gas 定价、日志查询成本和出块时间不同，因为 Arbitrum 是乐观 rollup。

Arbitrum 使用什么链 ID？ Arbitrum One 使用 42161，Arbitrum Sepolia 使用 421614。在钱包配置中，发送十六进制形式。

我需要 WebSocket 端点吗？ 只有当你的应用需要推送更新（如新块头或事件订阅）时才需要。只读应用可以仅使用 HTTP。

为什么我的 eth_getLogs 调用超时？ 区块范围通常太宽。将其拆分为更小的窗口并分页。

什么时候应该从共享端点迁移到专用节点？ 当你的持续请求量、归档需求或延迟要求超过共享端点舒适服务的范围时。在 Arbitrum 网络页面 上比较选项，并查看 RPC 定价 了解两种模式。

在哪里可以看到 OnFinality 支持哪些网络？ 完整列表在 支持的 RPC 网络 页面上。