Resumen
Esta página explica qué es un endpoint de Arbitrum, cómo conectarse a Arbitrum One y Arbitrum Sepolia, y cómo elegir entre RPC público, nodos dedicados y servicios API. Cubre la configuración de la cadena, ejemplos de solicitudes y modos de fallo comunes para que puedas configurar tu dApp o backend con confianza.
Guía rápida de decisión: ¿qué endpoint de Arbitrum deberías usar?
Si estás construyendo una dApp, un indexador o un servicio backend que se comunica con Arbitrum, la primera decisión es si usar un endpoint público, un nodo dedicado o un servicio API. Aquí tienes una forma rápida de decidir:
- Prototipado o pruebas de bajo volumen: Usa el endpoint RPC público de Arbitrum. Es gratuito y adecuado para desarrollo, pero es compartido y puede estar sujeto a límites de tasa bajo carga pesada.
- dApp de producción o servicio con tráfico constante: Usa un servicio API RPC gestionado como OnFinality. Obtienes mayor rendimiento, soporte WebSocket y acceso a métodos de depuración/trazado sin ejecutar tu propia infraestructura.
- Cargas de trabajo pesadas de archivo o indexación personalizada: Considera un nodo dedicado. Esto te da acceso exclusivo a un nodo, control total sobre la disponibilidad de métodos y rendimiento predecible.
Para la mayoría de los equipos, un servicio API gestionado es el equilibrio adecuado entre costo y confiabilidad. Puedes comenzar con el endpoint público y luego pasar a un nodo dedicado o plan API a medida que tu tráfico crezca. Consulta la página de precios de RPC para comparar opciones.
¿Qué es un endpoint de Arbitrum?
Un endpoint de Arbitrum es una URL que tu aplicación usa para enviar solicitudes JSON-RPC a la red Arbitrum. Es el punto de entrada para leer datos de blockchain, enviar transacciones y suscribirse a eventos. Los endpoints son típicamente proporcionados por operadores de nodos, ya sea como servicios públicos o a través de proveedores RPC comerciales.
Arbitrum es una capa 2 de Ethereum que utiliza rollups optimistas. Hereda la seguridad de Ethereum mientras ofrece tarifas más bajas y mayor rendimiento. Para interactuar con Arbitrum, necesitas un endpoint que apunte a Arbitrum One (mainnet) o Arbitrum Sepolia (testnet).
Configuración de la cadena Arbitrum de un vistazo
Aquí están los ajustes clave de la cadena que necesitas para configurar tu billetera o dApp:
| Configuración | Arbitrum One | Arbitrum Sepolia |
|---|---|---|
| ID de cadena | 42161 | 421614 |
| Nombre de la red | Arbitrum One | Arbitrum Sepolia |
| Moneda nativa | ETH | Sepolia ETH |
| Explorador de bloques | arbiscan.io | sepolia.arbiscan.io |
| URL RPC pública | https://arbitrum.api.onfinality.io/public | https://arbitrum-sepolia.api.onfinality.io/public |
Estos ajustes se usan al agregar Arbitrum a MetaMask u otras billeteras. Las URLs RPC públicas son proporcionadas por OnFinality y son adecuadas para desarrollo y uso ligero.
Cómo conectarse a Arbitrum con ethers.js
Aquí tienes un ejemplo simple usando ethers.js para conectarse a Arbitrum One y leer el número de bloque más reciente:
const { ethers } = require("ethers");
const provider = new ethers.JsonRpcProvider("https://arbitrum.api.onfinality.io/public");
async function getBlockNumber() {
const blockNumber = await provider.getBlockNumber();
console.log("Número de bloque actual:", blockNumber);
}
getBlockNumber();
Para suscripciones WebSocket, puedes usar el endpoint WebSocket (si está disponible) para escuchar nuevas transacciones pendientes o encabezados de bloque. OnFinality soporta WebSocket en Arbitrum One; consulta la página de la red Arbitrum para la URL exacta.
Usando curl para una llamada JSON-RPC rápida
Puedes probar un endpoint con un simple comando curl. Por ejemplo, para obtener el número de bloque más reciente en Arbitrum One:
curl -X POST https://arbitrum.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
Esto devuelve un número de bloque hexadecimal. Puedes usar llamadas similares para eth_getBalance, eth_call o eth_getLogs.
Modos de fallo comunes y cómo depurarlos
Incluso con un endpoint confiable, puedes encontrar problemas. Aquí hay modos de fallo comunes y cómo diagnosticarlos:
| Síntoma | Causa probable | Paso de depuración |
|---|---|---|
ECONNREFUSED o tiempo de espera | El endpoint está caído o es inalcanzable | Verifica la URL del endpoint y la conectividad de red. Prueba con otro proveedor. |
429 Too Many Requests | Límite de tasa excedido | Reduce la frecuencia de solicitudes o actualiza a un plan con límites más altos. |
Error -32000 o -32005 | Método no soportado o parámetros inválidos | Verifica el nombre del método y los parámetros. Algunos métodos como eth_getLogs pueden tener límites de rango de bloques. |
| Desconexiones de WebSocket | Tiempo de espera por inactividad o problema de red | Implementa lógica de reconexión y mensajes de heartbeat. |
| ID de cadena incorrecto | Usar endpoint de mainnet para testnet o viceversa | Verifica el ID de cadena en tu configuración. |
Cómo elegir entre RPC público, servicio API y nodo dedicado
Tu elección depende de tu carga de trabajo. Aquí hay una comparación para ayudarte a decidir:
| Opción | Mejor para | Consideraciones |
|---|---|---|
| RPC público (OnFinality) | Desarrollo, pruebas, aplicaciones de bajo volumen | Gratis, pero compartido y con límites de tasa. Sin SLA. |
| Servicio API gestionado (OnFinality) | dApps de producción, tráfico moderado a alto | Mayor rendimiento, soporte WebSocket, acceso a métodos de depuración/trazado. Precio de pago por uso. |
| Nodo dedicado (OnFinality) | Indexación de archivo pesada, métodos RPC personalizados, alta consistencia | Nodo exclusivo, control total, rendimiento predecible. Mayor costo. |
OnFinality ofrece las tres opciones. Puedes comenzar con el endpoint público y actualizar según sea necesario. Consulta la página de redes RPC compatibles para una lista completa de redes y características disponibles.
Lista de verificación para preparación de producción
Antes de implementar en producción, revisa esta lista:
- Usa un endpoint dedicado o gestionado – evita endpoints públicos para tráfico de producción.
- Implementa reintentos y backoff – maneja fallos transitorios con elegancia.
- Monitorea los límites de tasa – rastrea tu uso y actualiza antes de alcanzar los límites.
- Usa WebSocket para datos en tiempo real – si tu aplicación necesita actualizaciones en vivo, usa WebSocket en lugar de polling.
- Prueba primero en testnet – implementa en Arbitrum Sepolia para validar tu integración.
- Protege tus claves API – si usas un endpoint privado, mantén las claves fuera del código del lado del cliente.
Conclusiones clave
- Un endpoint de Arbitrum es la URL que usas para interactuar con la red Arbitrum a través de JSON-RPC.
- Arbitrum One usa el ID de cadena 42161, y Arbitrum Sepolia usa 421614.
- OnFinality proporciona endpoints públicos para ambas redes, además de opciones de API gestionada y nodo dedicado.
- Elige tu endpoint según la carga de trabajo: público para desarrollo, API para producción, dedicado para indexación pesada.
- Depura problemas comunes verificando límites de tasa, soporte de métodos e ID de cadena.
Preguntas frecuentes
¿Cuál es el endpoint RPC de Arbitrum?
OnFinality proporciona endpoints públicos: https://arbitrum.api.onfinality.io/public para Arbitrum One y https://arbitrum-sepolia.api.onfinality.io/public para Arbitrum Sepolia.
¿Cuál es el ID de cadena de Arbitrum?
Arbitrum One usa el ID de cadena 42161, y Arbitrum Sepolia usa 421614.
¿Puedo usar WebSocket con Arbitrum?
Sí, OnFinality soporta WebSocket en Arbitrum One. Consulta la página de la red Arbitrum para la URL de WebSocket.
¿Cómo obtengo ETH de prueba en Arbitrum Sepolia?
Puedes usar un faucet de Sepolia para obtener ETH de prueba, que luego es usable en Arbitrum Sepolia.
¿Cuál es la diferencia entre un endpoint público y un nodo dedicado?
Un endpoint público es compartido y tiene límites de tasa, mientras que un nodo dedicado es exclusivo para ti, ofreciendo mayor rendimiento y personalización.
Para más detalles sobre precios y soporte de red, visita las páginas de precios de RPC y redes compatibles.