¿Qué deberías evaluar en un proveedor de nodos RPC de Ethereum?

Elegir un proveedor de nodos RPC de Ethereum es realmente una cuestión de cómo tu aplicación lee y escribe el estado de la cadena bajo carga. La mainnet de Ethereum produce un bloque aproximadamente cada 12 segundos, y cada consulta de saldo de wallet, consulta de logs y transmisión de transacción pasa por un endpoint JSON-RPC. Si ese endpoint es lento, tiene límites de velocidad o le faltan los métodos que necesitas, tus usuarios lo notan antes que tus paneles.

Esta página es para desarrolladores y compradores de infraestructura que comparan opciones de RPC de Ethereum. Cubre qué hace realmente un proveedor de nodos, qué capacidades separan un endpoint compartido de un nodo dedicado y cómo probar un proveedor antes de comprometer tráfico de producción.

Comienza con tu carga de trabajo, no con la lista de proveedores

Antes de comparar proveedores, anota lo que tu aplicación realmente envía. La mayor parte del tráfico RPC de Ethereum cae en unos pocos patrones, y cada uno estresa una parte diferente del nodo.

Si solo envías eth_call y eth_getBalance, un endpoint compartido bien gestionado suele ser suficiente. Si ejecutas eth_getLogs en rangos amplios de bloques, reproduces historial o necesitas métodos trace_* y debug_*, estás en territorio de archivo y nodo dedicado. Esa distinción impulsa el costo mucho más que el conteo bruto de solicitudes.

Qué ejecuta realmente un proveedor de nodos RPC de Ethereum

Un proveedor opera clientes de ejecución y consenso de Ethereum, los mantiene sincronizados con la red y los expone a través de una capa JSON-RPC con balanceo de carga. Los buenos proveedores también gestionan actualizaciones de clientes, manejo de reorgs, gestión de pares y monitoreo para que tú no tengas que hacerlo.

Hay tres modelos de entrega comunes:

• Endpoints públicos. Gratuitos, compartidos y con límites de velocidad. Sirven para prototipos y lecturas de bajo volumen, pero no para apuntar una wallet de producción.
• API RPC gestionada. Un endpoint compartido de pago con límites más altos, claves API y, normalmente, acceso a archivo. Es la opción por defecto para la mayoría de las dapps en producción.
• Nodos dedicados. Capacidad de nodo aislada para un equipo. Obtienes rendimiento predecible, tu propia configuración de archivo o trace y sin vecinos ruidosos.

OnFinality ofrece Ethereum a través de un servicio de API RPC gestionado y mediante nodos dedicados cuando necesitas capacidad aislada. Puedes comenzar en el endpoint compartido y subir de nivel sin cambiar el código de tu aplicación, porque la interfaz JSON-RPC sigue siendo la misma.

Configuración de la cadena Ethereum de un vistazo

Si estás integrando Ethereum en una wallet, una configuración de Hardhat o un servicio backend, necesitas los parámetros canónicos de la red. Usa estos valores para que tus herramientas se conecten a mainnet en lugar de a una testnet.

Una forma rápida de confirmar que un endpoint está activo y en la cadena correcta es preguntarle por el chain ID y el último bloque:

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

# {"jsonrpc":"2.0","id":1,"result":"0x1"}

Si eso devuelve 0x1, estás en la mainnet de Ethereum. Si devuelve cualquier otra cosa, estás apuntando a una cadena diferente o a una testnet. Para trabajo en testnet, usa la página de la red Ethereum Sepolia en su lugar.

Matriz de evaluación de proveedores

Una vez que conoces tu carga de trabajo, compara proveedores según las capacidades que importan para ella. La siguiente tabla es una lista de verificación práctica más que una clasificación.

OnFinality aparece primero aquí porque es el proveedor que opera este sitio: ofrece Ethereum sobre HTTP y WebSocket, soporta cargas de archivo y trace en los planes adecuados y permite a los equipos pasar de RPC compartido a nodos dedicados. Compara cada proveedor con los mismos criterios antes de decidir.

Probar un proveedor antes de comprometerte

No migres tráfico de producción basándote en la página de marketing de un proveedor. Ejecuta una evaluación corta contra tus métodos reales. Un script simple que mida latencia y corrección en unos pocos endpoints te dirá más que cualquier tabla de benchmarks.

// probe.mjs — compare Ethereum RPC endpoints on the methods you actually use
const endpoints = [
  "https://eth.api.onfinality.io/public",
  // add other provider endpoints you are evaluating
];

async function probe(url) {
  const body = (method, params = []) =>
    JSON.stringify({ jsonrpc: "2.0", id: 1, method, params });

  const call = async (method, params) => {
    const start = performance.now();
    const res = await fetch(url, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: body(method, params),
    });
    const json = await res.json();
    return { ms: Math.round(performance.now() - start), ok: !json.error };
  };

  const block = await call("eth_blockNumber");
  const logs = await call("eth_getLogs", [
    { fromBlock: "latest", toBlock: "latest" },
  ]);
  console.log(url, { block, logs });
}

for (const url of endpoints) await probe(url);

Ejecuta esto en diferentes momentos del día. Presta atención a los endpoints que son rápidos en eth_blockNumber pero lentos o con errores en eth_getLogs, ya que las consultas de logs son donde la capacidad compartida suele mostrar sus límites.

Cuándo los endpoints compartidos dejan de ser suficientes

Un endpoint compartido gestionado es la opción por defecto correcta para la mayoría de los equipos. Deja de ser suficiente cuando se cumple una de estas condiciones:

• Alcanzas regularmente los límites de velocidad durante el tráfico pico y no puedes suavizar la carga.
• Necesitas eth_getLogs en rangos amplios de bloques de forma programada.
• Dependes de métodos trace_* o debug_* que los niveles compartidos restringen.
• Necesitas una conexión WebSocket que permanezca abierta para suscripciones sin reconexiones.
• Necesitas rendimiento predecible para un lanzamiento, un mint o una ventana de trading.

En ese punto, un nodo dedicado de Ethereum te da CPU, memoria y disco aislados, además de tu propia configuración de archivo y trace. También elimina el problema del vecino ruidoso, donde el pico de tráfico de otro inquilino se convierte en tu pico de latencia. Consulta nodos dedicados para saber cómo funciona ese modelo, y precios de RPC para comparar niveles.

Estrategia de failover y múltiples proveedores

Incluso un proveedor bien gestionado puede tener una mala hora. Las aplicaciones en producción deben asumir que cualquier endpoint individual fallará ocasionalmente y diseñar para ello.

Un patrón común es un endpoint primario con uno o dos de respaldo, seleccionados por comprobaciones de estado en lugar de un orden codificado:

// rpc-router.mjs — simple health-checked failover across endpoints
const pool = [
  "https://eth.api.onfinality.io/public",
  // fallback endpoints
];

async function healthy(url) {
  try {
    const res = await fetch(url, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_blockNumber", params: [] }),
      signal: AbortSignal.timeout(2000),
    });
    const json = await res.json();
    return !json.error;
  } catch {
    return false;
  }
}

export async function send(payload) {
  for (const url of pool) {
    if (!(await healthy(url))) continue;
    const res = await fetch(url, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(payload),
    });
    if (res.ok) return res.json();
  }
  throw new Error("all Ethereum RPC endpoints failed");
}

Mantén la lista de respaldo corta y probada. Un respaldo no probado es peor que ninguno, porque falla exactamente cuando lo necesitas.

Modos de fallo comunes y qué suelen significar

Cuando una llamada RPC de Ethereum se comporta mal, el error a menudo apunta a la configuración más que al proveedor.

Si estás depurando problemas a nivel de transacción como errores de nonce, el explicador de nonce repasa la mecánica.

Puntos clave

• Un proveedor de nodos RPC de Ethereum ejecuta los nodos; tú consumes JSON-RPC sobre HTTP o WebSocket. El modelo de entrega (público, gestionado, dedicado) importa más que la marca.
• Adapta el proveedor a tu carga de trabajo. Las lecturas, consultas de logs, transmisiones de transacciones y llamadas trace estresan diferentes partes de un nodo.
• La mainnet de Ethereum usa chain ID 1, ETH como moneda nativa y soporta transportes HTTP y WebSocket.
• Prueba los proveedores con tus métodos reales, especialmente eth_getLogs y cualquier llamada trace_*, antes de migrar tráfico de producción.
• Planifica el failover. Un endpoint primario más respaldos probados es una práctica estándar para aplicaciones en producción.
• Pasa a un nodo dedicado cuando alcances límites de velocidad, necesites acceso a archivo o trace, o requieras rendimiento predecible. Consulta redes RPC soportadas y precios de RPC para ver opciones.

Preguntas frecuentes

¿Cuál es la diferencia entre un proveedor de RPC de Ethereum y un proveedor de nodos?

En la práctica se superponen. Un proveedor de nodos ejecuta los clientes de Ethereum; un proveedor de RPC los expone sobre JSON-RPC. La mayoría de los servicios gestionados hacen ambas cosas, por lo que los términos suelen usarse indistintamente.

¿Necesito un nodo de archivo para Ethereum?

Solo si consultas estado histórico o logs más allá de la ventana reciente. Las wallets y las dapps simples normalmente no lo necesitan. Los indexadores, herramientas de analítica y puentes a menudo sí.

¿Puedo usar un endpoint RPC público de Ethereum en producción?

Los endpoints públicos son compartidos y tienen límites de velocidad, por lo que son mejores para pruebas. Las aplicaciones en producción generalmente usan una API RPC gestionada o un nodo dedicado para un comportamiento predecible.

¿OnFinality soporta suscripciones WebSocket de Ethereum?

Ethereum en OnFinality soporta transportes HTTP y WebSocket. Consulta la página de la red Ethereum para detalles actuales del endpoint y opciones de plan.

¿Cómo cambio de proveedor sin reescribir mi aplicación?

Como JSON-RPC de Ethereum está estandarizado, normalmente solo cambias la URL del endpoint y la clave API. Mantén tu URL RPC en configuración, no codificada, para que la migración sea un cambio de configuración en lugar de un cambio de código.

¿Cuándo debería pasar de RPC compartido a un nodo dedicado?

Cuando alcanzas consistentemente límites de velocidad, necesitas métodos de archivo o trace, o requieres rendimiento estable para lanzamientos y ventanas de trading. Los nodos dedicados aíslan tu capacidad de otros inquilinos.