Base 公共 RPC 端点和独立性能指标：你应该评估什么？

Base 公共 RPC 端点是将钱包、脚本或原型连接到 Base 网络的最快方式。它们也是 Base 基础设施中最容易被误解的部分：公共端点是共享的、尽力而为的，并且通常没有关于速率限制或方法覆盖范围的文档。独立性能指标可以帮助你比较端点，但前提是你知道正在测量什么以及它如何映射到你的工作负载。

本页面是为搜索 Base 公共 RPC 端点和独立性能指标的开发者和基础设施购买者提供的实用参考。它涵盖了链设置、如何阅读性能数据、何时公共端点足够，以及何时迁移到托管 RPC API 或专用 Base 节点。

快速建议：公共端点、托管 RPC 还是专用节点？

在将端点复制到生产环境之前，请使用此决策指南。

如果你仍在提供商之间做决定，如何选择 RPC 提供商 中的更广泛标准直接适用于 Base。有关当前的 Base 端点选项和传输支持，请参阅 Base RPC 网络页面。

测试任何端点之前需要的 Base 链设置

在基准测试任何内容之前，请确认你指向正确的网络。Base 主网和 Base Sepolia 共享工具，但不共享链 ID。

一个常见的失败模式是混淆这些：为链 ID 8453 配置的脚本将拒绝 Base Sepolia 端点，而指向错误链 ID 的钱包将显示令人困惑的余额或 nonce 错误。始终在启动时断言链 ID。

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

预期结果：0x2105，即十进制的 8453。如果你得到 0x14a34，则你在 Base Sepolia（84532）上。

如何阅读独立性能指标而不被误导

独立性能仪表板很有用，但它们测量的是特定时间、特定位置的特定探针。将它们视为起始信号，而非最终结论。

• 延迟取决于位置。 从一个区域看起来最快的提供商，从你的用户所在区域可能更慢。检查方法论是否列出了探针位置。
• 方法组合很重要。 仅调用 eth_blockNumber 的仪表板无法预测针对大型合约的 eth_getLogs、debug_traceTransaction 或 eth_call 的性能。
• 速率限制通常不可见。 公共端点经常按 IP 或按方法进行限制。仪表板可能显示低延迟，因为它发送的请求非常少。
• 正常运行时间窗口隐藏了事故。 30 天平均值可能看起来健康，而 10 分钟的中断会破坏你的应用。查看事故历史，而不仅仅是平均值。
• 测试网和主网是分开的。 Base Sepolia 的指标不能描述 Base 主网的行为。

最终唯一重要的指标是你针对自己工作负载测量的指标。使用公共仪表板建立候选列表，然后运行你自己的探针。

你可以自行运行的最小 Base RPC 探针

这个 Node.js 示例测量几个常见方法的往返时间。从与你的应用服务器相同的区域运行它，以获得真实的信号。

const ENDPOINT = "https://base.api.onfinality.io/public";

const calls = [
  { method: "eth_chainId", params: [] },
  { method: "eth_blockNumber", params: [] },
  { method: "eth_getBlockByNumber", params: ["latest", false] },
];

async function probe(call) {
  const start = performance.now();
  const res = await fetch(ENDPOINT, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: call.method, params: call.params }),
  });
  const body = await res.json();
  const ms = performance.now() - start;
  return { method: call.method, status: res.status, ms: Math.round(ms), ok: !body.error };
}

(async () => {
  for (const call of calls) {
    console.log(await probe(call));
  }
})();

在几个小时内重复运行此操作，如果可能的话从多个区域运行，并记录结果。该数据集比任何单一的公共基准更有用，因为它反映了你实际的调用模式。

Base 上公共端点 vs 托管 RPC vs 专用节点

一旦你有了自己的数据，将它们映射到你实际运行的工作负载。

OnFinality 提供托管 Base RPC API 和专用 Base 节点选项。你可以查看 RPC 定价 了解计划形态，以及 支持的 RPC 网络 获取完整列表，包括 Base 和 Base Sepolia。

何时公共 Base 端点确实是正确选择

公共端点不是你应该感到糟糕的妥协。它们在以下情况下是合适的：

• 你正在构建原型并希望避免账户设置。
• 你正在编写每天运行几次的脚本。
• 你正在教学、编写文档或演示概念。
• 你需要一个用于非关键路径的备用端点。

当你依赖它们处理面向用户的流量、需要历史状态或需要保证响应时间时，它们就会成为问题。此时，托管端点的成本通常小于在生产环境中调试间歇性故障的成本。

迁移检查点：从公共 Base 端点迁移

如果你决定迁移，请将其视为带有检查清单的配置更改，而不是重写。

1. 清点你的方法。 列出你的应用调用的每个 JSON-RPC 方法，包括任何归档或 trace 调用。这决定了你需要哪种计划或节点类型。
2. 测量基线行为。 记录当前延迟、错误率以及你在公共端点上观察到的任何限制。
3. 在配置标志后添加新端点。 不要在应用程序代码中硬编码端点；从环境变量中读取它们。
4. 运行影子流量。 将只读请求的副本发送到新端点，并在切换写入或面向用户的流量之前比较响应。
5. 验证链 ID 和区块高度。 确认新端点报告链 ID 8453 和与之前来源一致的区块高度。
6. 设置监控。 跟踪错误率、p95 延迟和区块滞后。对持续偏差发出警报，而不是单个峰值。
7. 保留备用。 保留辅助端点和文档化的故障转移路径。

常见的 Base RPC 陷阱及如何诊断

对于大多数这些问题，修复方法是缩小请求范围或迁移到具有你的工作负载所需容量和方法支持的端点。

关键要点

• Base 公共 RPC 端点最适合原型、钱包和低容量脚本，不适合具有严格延迟需求的生产流量。
• 独立性能指标是有用的候选列表工具，但它们测量的是特定探针，而不是你的工作负载。始终从你的应用程序所在区域运行自己的探针。
• 首先确认链设置：Base 主网是链 ID 8453，Base Sepolia 是 84532。
• 当你需要可预测的访问和可观测性时，迁移到托管 RPC API；当你需要隔离容量、归档访问或 WebSocket 支持时，迁移到专用节点。
• 将迁移视为检查清单：清点方法、影子流量、验证链 ID、监控并保留备用。

常见问题

Base 公共 RPC 端点可以免费使用吗？

它们通常无需账户即可用于低容量使用，但它们是共享的，可能会受到速率限制或按方法限制。对于生产流量，托管 RPC API 或专用节点可提供更清晰的容量预期。

我可以信任独立的 RPC 性能指标吗？

使用它们来建立候选列表，而不是做出最终决定。检查方法论、探针位置以及测试了哪些方法，然后根据你的实际调用模式用自己的测量结果进行验证。

Base 应该使用什么链 ID？

Base 主网使用链 ID 8453。Base Sepolia 使用链 ID 84532。始终在启动时断言链 ID，以避免将请求发送到错误的网络。

何时应从公共端点切换到专用 Base 节点？

当你需要隔离容量、归档或 trace 方法、WebSocket 订阅或负载下的一致延迟时。如果你的应用是面向用户的并且依赖 RPC 可用性，托管或专用选项通常是更安全的选择。

OnFinality 支持 Base 和 Base Sepolia 吗？

是的。OnFinality 为 Base 和 Base Sepolia 提供 RPC API 访问，以及专用节点选项。有关详细信息，请参阅 RPC 定价 和 支持的 RPC 网络。