¿Cómo elijo un proveedor de RPC de Celo para una aplicación en producción?

Celo es una Layer 1 compatible con EVM con un historial de diseño mobile-first y un sólido ecosistema de stablecoins y pagos. Si estás construyendo sobre Celo, el endpoint de RPC es la capa entre tu aplicación y la cadena, y el proveedor que elijas determina cómo se comporta tu aplicación bajo carga, durante reorganizaciones y cuando necesitas estado histórico. Esta página está escrita para desarrolladores y compradores de infraestructura que ya saben que necesitan un endpoint y están tratando de decidir qué ejecutar contra él.

Recomendación rápida: ¿endpoint compartido o nodo dedicado?

Empieza por la carga de trabajo, no por el logo del proveedor. La configuración correcta de RPC de Celo depende de tres cosas: cuántas solicitudes por segundo envías, si necesitas estado histórico y si puedes tolerar un endpoint compartido durante picos de tráfico.

• Prototipos, scripts y dApps de bajo tráfico: una API de RPC compartida suele ser suficiente. Obtienes un endpoint HTTPS, métodos JSON-RPC estándar y ninguna operación de nodo. La API de RPC de Celo de OnFinality es una opción gestionada en esta categoría.
• Aplicaciones en producción con tráfico constante y SLAs: busca un proveedor que ofrezca tanto niveles compartidos como dedicados, para que puedas empezar compartido y pasar a un nodo dedicado cuando tu perfil de solicitudes crezca. Consulta Precios de RPC para ver cómo se estructuran los niveles.
• Indexadores, analítica y cualquier cosa que lea bloques antiguos: necesitas acceso de archivo. Confirma el soporte de archivo antes de comprometerte, porque no todos los endpoints compartidos conservan el historial completo.
• Bots de trading, keepers de liquidación y paneles en tiempo real: necesitas lecturas de baja latencia más soporte de WebSocket o streaming, y un endpoint de failover configurado en tu cliente.

Si no estás seguro, empieza con un endpoint compartido, instrumenta tu volumen de solicitudes y tasa de errores durante una semana, y luego decide si un nodo dedicado está justificado.

Configuración de la cadena Celo de un vistazo

Usa estos valores al añadir Celo a una billetera, una configuración de hardhat o una librería cliente. Coinciden con la configuración de Celo mainnet.

Una configuración de billetera o cliente se ve así:

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

El chain ID 42220 es la forma decimal; 0x1a4 es el mismo valor en hexadecimal, que es lo que espera wallet_addEthereumChain. Equivocarse en esto es una de las causas más comunes de que una billetera se niegue a cambiar de red.

Qué estresa realmente tu carga de trabajo en Celo

Diferentes aplicaciones de Celo impactan la capa de RPC de distintas maneras. Antes de comparar proveedores, asigna tu tráfico a uno de estos perfiles.

Si tu perfil está en las tres últimas filas, un endpoint compartido aún puede funcionar, pero deberías verificar el soporte de archivo, los límites de consulta de logs y la disponibilidad de WebSocket antes de construir sobre él.

Matriz de evaluación de proveedores

Cuando compares proveedores de RPC de Celo, puntúalos según los criterios que coincidan con tu carga de trabajo. La tabla a continuación enumera las dimensiones que más importan, con OnFinality como una opción a evaluar junto a otras.

Dos comprobaciones prácticas que separan proveedores rápidamente:

1. Profundidad de archivo. Pregunta hasta dónde atrás funcionan eth_getLogs y eth_getBalance. Si la respuesta es vaga, pruébalo tú mismo contra un bloque de varios meses atrás.
2. Comportamiento bajo carga. Envía una ráfaga de solicitudes eth_getLogs o eth_call y observa si hay respuestas de límite de tasa, tiempos de espera o resultados truncados.

Conectar y probar tu endpoint

Una vez que tengas un endpoint, verifícalo antes de conectarlo a tu aplicación. Una sola llamada eth_chainId confirma que estás hablando con Celo mainnet y no con una testnet o un proxy mal configurado.

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

Una respuesta correcta devuelve 0x1a4, que es 42220 en decimal. A partir de ahí, verifica el último bloque y una llamada histórica:

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

En JavaScript, la misma comprobación con una librería cliente es sencilla:

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 });

Si planeas usar suscripciones WebSocket, confirma que el proveedor expone un endpoint wss:// para Celo y prueba una suscripción antes de depender de ella en producción.

Modos de fallo y cómo depurarlos

La mayoría de los problemas de RPC de Celo caen en un pequeño conjunto de categorías. Relaciona el síntoma con la causa probable antes de cambiar de proveedor.

Un hábito útil es registrar el id y el method de cada solicitud fallida junto con el estado HTTP. Eso deja claro si los fallos se agrupan en torno a un método, una ventana de tiempo o un endpoint.

Ejecutar Celo en producción: qué poner en marcha

Antes de salir a producción, cubre lo básico que previene la mayoría de los incidentes:

• Failover. Configura un endpoint primario y uno secundario en tu cliente. Si el primario devuelve errores o se agota el tiempo, cambia automáticamente.
• Reintentos con backoff. Reintenta lecturas idempotentes, pero no reintentes escrituras a ciegas. Un eth_sendRawTransaction reintentado con la misma carga firmada suele ser seguro; una transacción refirmada con un nuevo nonce no lo es.
• Fijación de bloques para lecturas críticas. Para saldos y estado de contratos usados en decisiones, consulta un número de bloque específico en lugar de latest.
• Monitoreo. Rastrea la tasa de solicitudes, la tasa de errores, la latencia p95 y el retraso de cabeza. Una sonda simple que llame a eth_blockNumber cada pocos segundos y compare la altura devuelta con una referencia es suficiente para detectar un endpoint estancado.
• Planificación de archivo. Si consultas historial, confirma que el acceso de archivo forma parte de tu plan antes de necesitarlo.

Si tu tráfico crece más allá de lo que un endpoint compartido maneja cómodamente, un nodo Celo dedicado te da capacidad aislada y comportamiento predecible. OnFinality ofrece tanto RPC gestionado como infraestructura de nodos dedicados, y puedes comparar niveles en la página de Precios de RPC. Para el marco de evaluación más amplio, consulta cómo elegir un proveedor de RPC.

Puntos clave

• Celo mainnet usa el chain ID 42220 y el token nativo CELO; confirma ambos antes de depurar cualquier otra cosa.
• Relaciona tu perfil de carga de trabajo con las características del proveedor: archivo para indexadores, WebSocket para bots, fiabilidad de escritura para pagos.
• Prueba tú mismo la profundidad de archivo y el comportamiento en ráfagas en lugar de confiar en páginas de marketing.
• Configura siempre un endpoint de failover y monitorea el retraso de cabeza, la tasa de errores y la latencia p95.
• El RPC compartido está bien para prototipos; pasa a un nodo dedicado cuando crezcan las necesidades de tráfico o aislamiento.
• OnFinality proporciona una API de RPC de Celo gestionada y opciones de nodos dedicados, junto con muchas otras redes.

Preguntas frecuentes

¿Cuál es el endpoint de RPC de Celo mainnet? El endpoint público de Celo de OnFinality es https://celo.api.onfinality.io/public. Para uso en producción, considera un endpoint gestionado o dedicado con un plan que coincida con tu tráfico.

¿Qué chain ID usa Celo? Celo mainnet usa el chain ID 42220, que es 0x1a4 en hexadecimal.

¿Necesito un nodo de archivo para Celo? Solo si consultas estado o logs históricos. Si llamas a eth_getLogs sobre rangos de bloques antiguos o lees saldos en bloques pasados, confirma el acceso de archivo con tu proveedor.

¿Celo admite suscripciones WebSocket? Celo es compatible con EVM, por lo que eth_subscribe funciona cuando el proveedor expone un endpoint WebSocket. Verifica la disponibilidad con tu proveedor antes de construir características en tiempo real.

¿Cómo manejo los límites de tasa en un endpoint Celo compartido? Reduce los tamaños de ráfaga, agrupa cuando sea posible y añade reintentos con backoff. Si los límites siguen bloqueando tu carga de trabajo, pasa a un nivel dedicado.

¿Puedo ejecutar mi propio nodo Celo en su lugar? Sí. El autoalojamiento da control total, pero significa que tú te encargas de la sincronización, actualizaciones, almacenamiento y monitoreo. Muchos equipos usan un proveedor gestionado para lecturas y mantienen un nodo autoalojado para necesidades específicas.

¿Cómo cambio de proveedor de RPC de Celo sin tiempo de inactividad? Añade el nuevo endpoint como secundario en tu cliente, ejecuta ambos en paralelo, compara respuestas y luego promueve el nuevo endpoint a primario cuando tengas confianza.