Endpoint RPC público de Optimism: cómo conectarse y cuándo cambiar

Un endpoint RPC público de Optimism es la forma más rápida de empezar a leer el estado de OP Mainnet y enviar transacciones. Apuntas tu billetera o script a una URL HTTP o WebSocket, configuras el chain ID y ya estás en la red. La contrapartida es que los endpoints públicos son compartidos, por lo que no controlas el rendimiento, los límites de velocidad ni la rapidez con la que se actualiza el nodo. Esta página cubre la configuración exacta de la cadena, un ejemplo de solicitud funcional, los errores que encontrarás y el punto en el que un endpoint gestionado o dedicado se convierte en la mejor opción.

Configuración de la cadena de un vistazo

Antes de enviar una sola solicitud, asegúrate de tener estos valores correctos. Un chain ID incorrecto o una URL RPC que no coincide es la razón más común por la que una billetera muestra un saldo incorrecto o una transacción no se transmite.

Optimism es una Layer 2 equivalente a EVM, por lo que la superficie JSON-RPC se asemeja mucho a Ethereum. Esto significa que las mismas bibliotecas, los mismos nombres de métodos y las mismas herramientas ABI funcionan sin cambios. Lo que difiere es el chain ID, el comportamiento del secuenciador y el hecho de que estás leyendo el estado de L2 en lugar del estado de L1.

Si estás probando antes de tocar mainnet, Optimism Sepolia usa el chain ID 11155420 y el endpoint https://optimism-sepolia.api.onfinality.io/public. Mantén las dos configuraciones separadas en tu base de código para que nunca transmitas por accidente una transacción de testnet a mainnet.

Decide cómo te conectarás

No hay una única respuesta correcta aquí. La elección correcta depende de lo que hace tu aplicación y de cuánto control necesitas sobre el nodo detrás del endpoint.

Usa un endpoint público cuando estés prototipando, ejecutando un script, consultando saldos o construyendo algo con tráfico bajo y en ráfagas. Los endpoints públicos son gratuitos de probar y no requieren cuenta. Son una buena opción para desarrollo local, proyectos de hackathon y paneles de solo lectura.

Pasa a una API RPC gestionada cuando estés lanzando a usuarios reales. Un endpoint gestionado te da una URL estable, un manejo predecible de las solicitudes y una vía de soporte cuando algo falla. Este es el siguiente paso habitual una vez que tu aplicación tiene tráfico de producción.

Elige un nodo dedicado cuando necesites rendimiento constante, datos de archivo, métodos de trace o consultas pesadas de eth_getLogs. La infraestructura dedicada elimina el problema del vecino ruidoso porque el nodo sirve únicamente a tu carga de trabajo.

Una forma rápida de decidir: si una solicitud fallida te haría recibir una alerta a las 2 de la mañana, has superado el endpoint público. Si una solicitud fallida solo significa que reintentas en tu terminal, el endpoint público está bien.

Conéctate con curl

Puedes verificar que un endpoint está activo y devuelve la cadena esperada antes de integrarlo en una aplicación. Esta solicitud pide el chain ID, que debería devolver 0xa (10 en hexadecimal).

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

Una respuesta saludable se ve así:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0xa"
}

Si obtienes 0xa, el endpoint está en OP Mainnet. Si obtienes un valor diferente, estás apuntando a la red incorrecta. Si obtienes un objeto de error en su lugar, lee el campo message antes de cambiar cualquier otra cosa.

Conéctate desde JavaScript

La mayoría de las aplicaciones usan una biblioteca en lugar de HTTP sin procesar. Con ethers, la configuración del proveedor es una línea una vez que tienes la URL.

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider(
  "https://optimism.api.onfinality.io/public",
  { chainId: 10, name: "optimism" }
);

const block = await provider.getBlockNumber();
console.log("Latest OP Mainnet block:", block);

Pasar el chain ID explícitamente vale la pena los caracteres extra. Permite que ethers detecte una discrepancia en lugar de leer silenciosamente de la cadena incorrecta, lo cual es un error difícil de detectar después.

Para casos de uso en tiempo real, como observar transacciones pendientes o rastrear una dirección específica, usa el transporte WebSocket en lugar de hacer polling sobre HTTP. Optimism admite ws, por lo que puedes suscribirte a nuevos encabezados de bloque y reaccionar a medida que llegan en lugar de preguntar cada pocos segundos.

Agrega Optimism a una billetera

Si estás configurando una billetera manualmente, usa los valores de la tabla de configuración de la cadena. En MetaMask, abre el selector de red, elige Agregar red e introduce el nombre de la red, la URL RPC, el chain ID, el símbolo y el explorador. El chain ID es lo que evita que la billetera confunda OP Mainnet con Ethereum mainnet o una testnet.

Un error común es pegar una URL RPC de una publicación de blog que desde entonces ha quedado fuera de línea. Confirma siempre que el endpoint responde antes de guardarlo, y ten una segunda URL a mano para poder cambiar rápidamente si la primera se degrada.

Modos de fallo comunes

Los endpoints públicos fallan de maneras predecibles. Conocer el síntoma te evita depurar la capa equivocada.

La limitación de velocidad es la que los desarrolladores subestiman. Un endpoint público es compartido por muchos llamadores, por lo que tu rendimiento efectivo depende de lo que estén haciendo todos los demás en ese momento. El código que funciona en pruebas puede ralentizarse durante un período de mucha actividad. Construye lógica de reintento con retroceso exponencial desde el principio, y agrupa lecturas independientes donde la biblioteca lo admita.

Qué verificar antes de depender de un endpoint

Si estás comparando endpoints o proveedores, prueba con tu carga de trabajo real en lugar de un benchmark genérico. Algunas comprobaciones separan un endpoint utilizable de uno que causará incidentes.

• Cobertura de métodos. Confirma que el endpoint admite los métodos que llamas, incluidas consultas de archivo y métodos de trace si necesitas estado histórico.
• Soporte de transporte. Si necesitas suscripciones, verifica que WebSocket esté disponible, no solo HTTP.
• Comportamiento bajo carga. Envía una ráfaga realista y observa si hay limitación o aumento de latencia.
• Conmutación por error. Ten un segundo endpoint configurado para que una única interrupción no derribe tu aplicación.
• Observabilidad. Rastrea tasas de error y latencia por endpoint para que notes la degradación antes que los usuarios.

OnFinality proporciona RPC de Optimism a través de una API gestionada y opciones de nodos dedicados. Puedes revisar los detalles de la red en la página de API RPC de Optimism, comparar costos en precios de RPC y ver el conjunto completo de cadenas en redes RPC compatibles. Si necesitas rendimiento constante o acceso a archivo, los nodos dedicados te permiten ejecutar infraestructura dimensionada para tu carga de trabajo. Para un marco más amplio, consulta cómo elegir un proveedor de RPC.

Migrar desde un endpoint público

Salir de un endpoint público no debería requerir reescribir tu aplicación. Si has mantenido la URL en un solo lugar, el cambio es una actualización de configuración.

1. Coloca la URL RPC en una variable de entorno en lugar de codificarla directamente.
2. Agrega un segundo endpoint como respaldo y enruta las solicitudes hacia él cuando falle el primero.
3. Ejecuta ambos endpoints en staging y compara latencia y tasas de error con tu tráfico real.
4. Cambia el tráfico de producción una vez que el nuevo endpoint iguale o supere al anterior en tus métodos clave.
5. Mantén el endpoint público como respaldo de último recurso, no como tu ruta principal.

Este enfoque también te protege durante incidentes del proveedor. Un único endpoint, público o privado, es un punto único de fallo. Dos endpoints con un orden de prioridad claro es el mínimo para cualquier cosa orientada al usuario.

Puntos clave

• OP Mainnet usa el chain ID 10, ETH como moneda nativa y admite RPC tanto HTTP como WebSocket.
• Un endpoint público está bien para prototipado y lecturas de bajo tráfico, pero es compartido, por lo que el rendimiento no está garantizado.
• Configura siempre el chain ID explícitamente en la configuración de tu proveedor para detectar discrepancias de red a tiempo.
• La limitación de velocidad y las consultas grandes de eth_getLogs son las dos fuentes más comunes de errores en endpoints públicos.
• Pasa a una API RPC gestionada o a un nodo dedicado cuando necesites rendimiento predecible, datos de archivo o una vía de soporte.
• Mantén tu URL RPC en la configuración y agrega un endpoint de respaldo antes de pasar a producción.

Preguntas frecuentes

¿Qué es el endpoint RPC público de Optimism?

OnFinality expone un endpoint público de OP Mainnet en https://optimism.api.onfinality.io/public. Admite HTTP y WebSocket y es adecuado para desarrollo y uso ligero en producción. Para cargas de trabajo más pesadas, un endpoint gestionado o dedicado es una mejor opción.

¿Cuál es el chain ID de Optimism?

OP Mainnet usa el chain ID 10. Optimism Sepolia, la testnet, usa el chain ID 11155420. Confirma siempre que el chain ID coincida con la red que pretendes usar.

¿Es seguro un endpoint RPC público para producción?

Puede funcionar para aplicaciones de bajo tráfico, pero los endpoints públicos son compartidos y pueden limitar solicitudes durante períodos de mucha actividad. Para aplicaciones orientadas al usuario, un endpoint gestionado con un respaldo es la opción predeterminada más segura.

¿Por qué mi solicitud a Optimism devuelve un error de límite de velocidad?

Probablemente estás enviando solicitudes más rápido de lo que permite el endpoint compartido. Agrega retroceso exponencial, agrupa lecturas independientes o pasa a un endpoint gestionado con límites más altos.

¿Optimism admite RPC por WebSocket?

Sí. OP Mainnet admite transportes HTTP y WebSocket, por lo que puedes suscribirte a nuevos bloques y eventos en lugar de hacer polling.

¿Cuándo debería usar un nodo dedicado de Optimism?

Cuando necesites rendimiento constante, datos de archivo, métodos de trace o consultas pesadas de logs, un nodo dedicado elimina el efecto del vecino ruidoso y te da infraestructura dimensionada para tu carga de trabajo.