如何为生产应用选择 Celo RPC 提供商？

Celo 是一个兼容 EVM 的 Layer 1，具有移动优先的设计历史和强大的稳定币与支付生态系统。如果你在 Celo 上构建，RPC 端点就是你的应用与链之间的层，你选择的提供商决定了你的应用在负载下、重组期间以及需要历史状态时的行为。本页面面向已经知道自己需要端点并正在决定针对它运行什么的开发人员和基础设施购买者。

快速推荐：共享端点还是专用节点？

从工作负载开始，而不是提供商标志。正确的 Celo RPC 设置取决于三件事：你每秒发送多少请求、是否需要历史状态，以及你是否能容忍流量高峰期间的共享端点。

• 原型、脚本和低流量 dApp： 共享 RPC API 通常就足够了。你获得一个 HTTPS 端点、标准 JSON-RPC 方法，并且无需节点运维。OnFinality 的 Celo RPC API 是此类别中的托管选项。
• 具有稳定流量和 SLA 的生产应用： 寻找同时提供共享和专用层级的提供商，这样你可以从共享开始，并在请求量增长时迁移到专用节点。有关层级结构，请参阅 RPC 定价。
• 索引器、分析和任何读取旧区块的内容： 你需要归档访问权限。在提交之前确认归档支持，因为并非每个共享端点都保留完整历史。
• 交易机器人、清算 keeper 和实时仪表板： 你需要低延迟读取以及 WebSocket 或流式支持，并在客户端中配置故障转移端点。

如果不确定，请从共享端点开始，在一周内监控你的请求量和错误率，然后决定是否值得使用 专用节点。

Celo 链设置一览

在将 Celo 添加到钱包、hardhat 配置或客户端库时，请使用这些值。它们与 Celo 主网配置匹配。

钱包或客户端配置如下所示：

{
  "chainId": "0x1a4",
  "chainName": "Celo Mainnet",
  "nativeCurrency": { "name": "CELO", "symbol": "CELO", "decimals": 18 },
  "rpcUrls": ["https://celo.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://celoscan.io"]
}

链 ID 42220 是十进制形式；0x1a4 是相同的十六进制值，这是 wallet_addEthereumChain 所期望的。弄错这一点是钱包拒绝切换网络的最常见原因之一。

你的 Celo 工作负载实际对什么造成压力

不同的 Celo 应用以不同方式访问 RPC 层。在比较提供商之前，将你的流量映射到以下配置文件之一。

如果你的配置文件位于底部三行，共享端点可能仍然有效，但在围绕它构建之前，你应该验证归档支持、日志查询上限和 WebSocket 可用性。

提供商评估矩阵

当你比较 Celo RPC 提供商时，根据与你的工作负载匹配的标准对它们进行评分。下表列出了最重要的维度，OnFinality 是与其他选项一起评估的一个选项。

两个快速区分提供商的实用检查：

1. 归档深度。 询问 eth_getLogs 和 eth_getBalance 可以回溯多远。如果答案含糊，请自己针对几个月前的区块进行测试。
2. 负载下的行为。 发送一批 eth_getLogs 或 eth_call 请求，观察是否有速率限制响应、超时或结果截断。

连接并测试你的端点

一旦你有了端点，在将其接入应用之前进行验证。一个 eth_chainId 调用即可确认你正在与 Celo 主网通信，而不是测试网或配置错误的代理。

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

正确的响应返回 0x1a4，即十进制的 42220。然后，检查最新区块和历史调用：

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

在 JavaScript 中，使用客户端库进行相同的检查很简单：

import { createPublicClient, http } from "viem";
import { celo } from "viem/chains";

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

const chainId = await client.getChainId();
const block = await client.getBlockNumber();
console.log({ chainId, block });

如果你计划使用 WebSocket 订阅，请确认提供商为 Celo 暴露了 wss:// 端点，并在生产环境中依赖它之前测试订阅。

故障模式及如何调试

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

一个有用的习惯是记录每个失败请求的 id 和 method 以及 HTTP 状态。这样可以清楚地看出失败是集中在一个方法、一个时间窗口还是一个端点上。

在生产环境中运行 Celo：需要落实的事项

在上线之前，覆盖防止大多数事件的基础事项：

• 故障转移。 在客户端中配置主端点和辅助端点。如果主端点返回错误或超时，自动切换。
• 带退避的重试。 重试幂等读取，但不要盲目重试写入。使用相同签名负载重试 eth_sendRawTransaction 通常是安全的；使用新 nonce 重新签名的交易则不安全。
• 关键读取的区块固定。 对于用于决策的余额和合约状态，查询特定区块号而不是 latest。
• 监控。 跟踪请求速率、错误率、p95 延迟和头部滞后。一个简单的探针每几秒调用 eth_blockNumber 并将返回的高度与参考值比较，就足以捕获停滞的端点。
• 归档规划。 如果你查询历史，请在你需要之前确认归档访问是你计划的一部分。

如果你的流量增长超过共享端点舒适处理的范围，专用 Celo 节点可为你提供隔离的容量和可预测的行为。OnFinality 提供托管 RPC 和专用节点基础设施，你可以在 RPC 定价 页面比较层级。有关更广泛的评估框架，请参阅 如何选择 RPC 提供商。

关键要点

• Celo 主网使用链 ID 42220 和原生 CELO 代币；在调试其他任何内容之前确认这两者。
• 将你的工作负载配置文件与提供商功能匹配：索引器需要归档，机器人需要 WebSocket，支付需要写入可靠性。
• 自己测试归档深度和突发行为，而不是依赖营销页面。
• 始终配置故障转移端点并监控头部滞后、错误率和 p95 延迟。
• 共享 RPC 适合原型；当流量或隔离需求增长时，迁移到专用节点。
• OnFinality 提供托管的 Celo RPC API 和专用节点选项，以及 许多其他网络。

常见问题

Celo 主网 RPC 端点是什么？ OnFinality 的公共 Celo 端点是 https://celo.api.onfinality.io/public。对于生产使用，请考虑使用与你的流量匹配的托管或专用端点。

Celo 使用什么链 ID？ Celo 主网使用链 ID 42220，十六进制为 0x1a4。

我需要为 Celo 使用归档节点吗？ 仅当你查询历史状态或日志时才需要。如果你在旧区块范围上调用 eth_getLogs 或读取过去区块的余额，请与你的提供商确认归档访问。

Celo 支持 WebSocket 订阅吗？ Celo 兼容 EVM，因此当提供商暴露 WebSocket 端点时，eth_subscribe 可以工作。在构建实时功能之前，请与你的提供商确认可用性。

如何处理共享 Celo 端点上的速率限制？ 减少突发大小，尽可能批量处理，并添加带退避的重试。如果限制仍然阻碍你的工作负载，请迁移到专用层级。

我可以自己运行 Celo 节点吗？ 可以。自托管提供完全控制，但意味着你需要负责同步、升级、存储和监控。许多团队使用托管提供商进行读取，并保留自托管节点以满足特定需求。

如何在不中断的情况下切换 Celo RPC 提供商？ 将新端点作为辅助端点添加到你的客户端，并行运行两者，比较响应，然后在确信后将新端点提升为主端点。