¿Qué es un RPC público de ETH y cuándo deberías usar uno?

Cuándo un RPC público de ETH es el punto de partida adecuado

Un RPC público es la forma más rápida de hacer que una aplicación de Ethereum se comunique con la cadena. Pegas una URL en tu billetera, script o configuración de framework, y puedes leer saldos, obtener bloques y enviar transacciones sin aprovisionar nada. Para un prototipo de hackathon, un script puntual o una billetera que estás configurando por primera vez, esa es exactamente la compensación correcta.

La decisión de permanecer en un endpoint público es en realidad una pregunta sobre la forma de la carga de trabajo. Si tus solicitudes son ocasionales, tolerantes a reintentos y nunca dependen de suscripciones, un RPC público compartido puede llevarte muy lejos. Si tu aplicación sirve a usuarios reales, indexa historial o escucha eventos, el nivel compartido se convertirá en el cuello de botella.

Usa esta guía rápida para decidir dónde estás hoy:

Si estás en las tres últimas filas, el resto de esta página explica la migración. Si estás en las dos primeras, sigue leyendo para obtener los detalles del endpoint y los pasos de depuración.

Configuración de la cadena Ethereum de un vistazo

Antes de depurar cualquier cosa, confirma que estás apuntando a la red correcta. Ethereum mainnet y Sepolia comparten el mismo conjunto de métodos JSON-RPC pero tienen diferentes chain IDs, y confundirlos es una de las causas más comunes de errores de "red incorrecta".

OnFinality expone endpoints públicos para ambas redes, por lo que puedes desarrollar contra Sepolia y cambiar a mainnet cambiando una sola URL y el chain ID. Para detalles específicos de la red, consulta la página de la red Ethereum Sepolia y la lista completa de redes RPC compatibles.

Conectar una billetera o framework

La mayoría de las billeteras y bibliotecas aceptan una URL de RPC personalizada más un chain ID. Una configuración mínima de red de billetera se ve así:

{
  "chainId": "0x1",
  "chainName": "Ethereum Mainnet",
  "nativeCurrency": { "name": "Ether", "symbol": "ETH", "decimals": 18 },
  "rpcUrls": ["https://eth.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://etherscan.io"]
}

Para Sepolia, cambia chainId a 0xaa36a7 (11155111 en decimal) y cambia la URL de RPC al endpoint de Sepolia. En JavaScript, la misma configuración funciona con ethers o viem:

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

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

const blockNumber = await client.getBlockNumber();
console.log('Latest block:', blockNumber);

Si prefieres JSON-RPC sin procesar, una sola llamada curl confirma que el endpoint es accesible y devuelve la cadena que esperas:

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

La respuesta debería ser {"jsonrpc":"2.0","id":1,"result":"0x1"}. Si obtienes un chain ID diferente, estás en la red incorrecta. Si obtienes un resultado vacío o un error HTTP, el endpoint no es accesible o tiene límite de velocidad.

Ruta de depuración: qué significa realmente cada fallo

Los endpoints públicos fallan de unas pocas formas predecibles. Relaciona el síntoma con la causa antes de cambiar nada.

Un hábito útil es registrar el estado HTTP y el código de error JSON-RPC juntos. Un 429 es una señal de capacidad, mientras que un -32601 (método no encontrado) es una señal de capacidad funcional. Apuntan a soluciones diferentes.

Dónde dejan de escalar los endpoints públicos

Los RPC públicos compartidos están diseñados para acceso amplio y de baja intensidad. Tres patrones de carga de trabajo rompen ese modelo rápidamente:

1. Sondeo de alta frecuencia. Las billeteras y paneles que sondean eth_blockNumber o eth_getBalance cada segundo alcanzarán los límites compartidos rápidamente. En su lugar, agrupa o almacena en caché.
2. Consultas históricas y de archivo. Leer el estado en un bloque antiguo requiere un nodo de archivo. La mayoría de los endpoints públicos solo sirven estado reciente.
3. Aplicaciones basadas en eventos. Las suscripciones WebSocket (eth_subscribe) necesitan una conexión estable y de larga duración. Los endpoints compartidos a menudo limitan los sockets concurrentes o descartan los inactivos.

Si alguno de estos describe tu aplicación, el nivel público es una herramienta de prototipado, no una dependencia de producción. La siguiente sección cubre qué evaluar cuando migres.

Evaluar un RPC de ETH gestionado o dedicado

Cuando superas el endpoint público, estás eligiendo entre un plan de RPC gestionado y un nodo dedicado. Ambos eliminan el problema de capacidad compartida; difieren en control, modelo de costos y carga operativa.

OnFinality aparece primero porque es la opción que opera este sitio: endpoints RPC gestionados más infraestructura de nodos dedicados para equipos que necesitan capacidad aislada. Compara planes en la página de precios de RPC, o revisa nodos dedicados si necesitas un nodo privado en lugar de un endpoint compartido.

Cuando evalúes cualquier proveedor, haz cuatro preguntas:

• Modelo de capacidad: ¿El rendimiento es compartido o reservado? ¿Qué sucede durante un pico de tráfico?
• Cobertura de métodos: ¿Están disponibles los métodos debug_ y trace_, y se incluyen los datos de archivo?
• Transporte: ¿Se admite WebSocket para suscripciones, y cómo se manejan las conexiones inactivas?
• Conmutación por error: ¿Puedes configurar un endpoint secundario, y cómo detectas un primario degradado?

Estas preguntas importan más que los números de latencia destacados, porque determinan si tu aplicación se mantiene en pie bajo carga.

Puntos de control de migración

Pasar de un endpoint público a uno gestionado es principalmente un cambio de configuración, pero algunos puntos de control evitan sorpresas:

1. Inventario de tus métodos. Enumera cada método JSON-RPC que llama tu aplicación, incluidos eth_getLogs, eth_call y cualquier uso de debug_ o trace_. Confirma que el nuevo endpoint los admite todos.
2. Separa las rutas de lectura y escritura. Las lecturas a menudo pueden usar un endpoint compartido; las escrituras y suscripciones se benefician de una conexión dedicada.
3. Agrega un respaldo. Configura una URL de RPC secundaria para que el fallo de un solo endpoint no derribe tu aplicación.
4. Vuelve a probar primero en Sepolia. Valida el nuevo endpoint contra Sepolia antes de cambiar el tráfico de mainnet.
5. Monitorea después del cambio. Rastrea tasas de error, conteos de 429 y reconexiones de WebSocket durante los primeros días.

Una sonda de monitoreo simple te mantiene honesto:

async function probe(url) {
  const start = Date.now();
  const res = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'eth_blockNumber', params: [] })
  });
  return { ok: res.ok, status: res.status, ms: Date.now() - start };
}

Ejecuta esto contra tus endpoints primario y de respaldo de forma programada, y alerta cuando cualquiera se degrade.

Puntos clave

• Un RPC público de ETH es un endpoint compartido y sin autenticación — excelente para prototipos, débil para producción.
• Confirma siempre el chain ID: 0x1 para mainnet, 0xaa36a7 para Sepolia.
• Los errores 429 significan capacidad; los resultados de archivo vacíos significan historial faltante; las caídas de WebSocket significan límites de conexión.
• Pasa a un endpoint gestionado o dedicado cuando sondees con frecuencia, necesites datos de archivo o dependas de suscripciones.
• Evalúa a los proveedores por modelo de capacidad, cobertura de métodos, transporte y conmutación por error — no solo por latencia.
• OnFinality ofrece RPC de Ethereum gestionado y nodos dedicados; consulta precios de RPC y redes compatibles.

Preguntas frecuentes

¿Es seguro usar un RPC público de ETH en producción?

Puede funcionar para tráfico de solo lectura y bajo volumen con reintentos y un respaldo. Para aplicaciones orientadas al usuario, sondeo de alta frecuencia, consultas de archivo o suscripciones WebSocket, un endpoint gestionado o dedicado es la opción más confiable.

¿Cuál es el chain ID de Ethereum mainnet y Sepolia?

Ethereum mainnet usa el chain ID 1 (0x1). Sepolia usa el chain ID 11155111 (0xaa36a7). Establecer el incorrecto es una causa común de errores de "red incorrecta".

¿Por qué mi RPC público devuelve resultados vacíos para bloques antiguos?

La mayoría de los endpoints públicos solo sirven estado reciente. Leer estado histórico requiere un nodo de archivo, que normalmente está disponible en planes gestionados o dedicados.

¿Puedo usar suscripciones WebSocket en un RPC público?

Algunos endpoints públicos exponen WebSocket, pero los límites de conexión compartidos y los tiempos de espera inactivos los hacen poco confiables para suscripciones de larga duración. Usa un endpoint gestionado o dedicado para aplicaciones basadas en eventos.

¿Cómo cambio de un RPC público a OnFinality?

Cambia tu URL de RPC y chain ID en la configuración de tu billetera o framework, confirma la cobertura de métodos, agrega un endpoint de respaldo y prueba en Sepolia antes de mover el tráfico de mainnet. Consulta precios de RPC para detalles del plan.