Descripción general de la API de Arbitrum: endpoints RPC, configuración de la cadena y configuración para producción

¿A qué endpoint de Arbitrum deberías conectarte primero?

Si estás construyendo sobre Arbitrum, la primera decisión no es qué método llamar, sino contra qué endpoint llamarlo. Arbitrum tiene dos redes que tocarás: Arbitrum One (mainnet, ID de cadena 42161) y Arbitrum Sepolia (testnet, ID de cadena 421614). Ambas exponen una API JSON-RPC compatible con Ethereum, por lo que las mismas bibliotecas cliente, configuraciones de billetera y herramientas de contratos funcionan en cualquiera de las dos.

Usa esta tabla de enrutamiento rápida antes de escribir cualquier código:

OnFinality expone endpoints de Arbitrum a través de su servicio de API RPC y opciones de nodo dedicado. Puedes revisar los detalles de la red en la página de la red Arbitrum.

Configuración de la cadena Arbitrum de un vistazo

Las billeteras y frameworks como Hardhat, Foundry, ethers y viem necesitan los mismos pocos parámetros. Mantenlos consistentes entre entornos para no apuntar accidentalmente una compilación de staging a mainnet.

Una configuración de red de billetera se ve así:

await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0xa4b1", // 42161 in hex
    chainName: "Arbitrum One",
    nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
    rpcUrls: ["https://arbitrum.api.onfinality.io/public"],
    blockExplorerUrls: ["https://arbiscan.io"]
  }]
});

Para Sepolia, cambia chainId a 0xa4ba (421614), el nombre de la cadena, la URL RPC y la URL del explorador. Los endpoints públicos son convenientes para desarrollo, pero el tráfico de producción debe pasar por un endpoint gestionado o dedicado para que controles el rendimiento y la disponibilidad.

Haciendo tu primera solicitud JSON-RPC

Arbitrum habla JSON-RPC estándar de Ethereum. Una verificación de estado mínima es eth_blockNumber, que confirma que el endpoint es accesible y está sincronizado lo suficiente para responder:

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

Una respuesta devuelve la altura del último bloque en hexadecimal. A partir de ahí, los métodos que más usarás son eth_getBalance, eth_getTransactionCount, eth_call, eth_estimateGas, eth_getLogs y eth_sendRawTransaction. Debido a que Arbitrum es equivalente a EVM, los ABI de contratos y las herramientas de Solidity se trasladan desde Ethereum con pocos cambios.

En JavaScript, usando viem contra un endpoint de Arbitrum se ve así:

import { createPublicClient, http } from "viem";
import { arbitrum } from "viem/chains";

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

const block = await client.getBlockNumber();
console.log("Latest Arbitrum block:", block);

Si necesitas actualizaciones basadas en push en lugar de polling, conéctate por WebSocket a un proveedor que lo admita y suscríbete a newHeads o logs. Arbitrum One admite transporte WebSocket en OnFinality; Sepolia es solo HTTP en la configuración de red actual.

Soporte de métodos y comportamiento específico de Arbitrum

La mayoría de los métodos JSON-RPC de Ethereum funcionan como se espera, pero algunas áreas merecen atención cuando pasas de una testnet a producción:

• Logs y filtros. eth_getLogs es la columna vertebral de los indexadores y backends basados en eventos. Los rangos de bloques amplios y las consultas sin filtrar son la causa más común de timeouts. Reduce tu rango y filtra por dirección y tema.
• Estimación de gas. Arbitrum tiene su propio modelo de tarifas superpuesto al de Ethereum. eth_estimateGas sigue funcionando, pero no codifiques precios de gas copiados de la mainnet de Ethereum.
• Datos de archivo. Las consultas de estado histórico, como saldos en un bloque antiguo, requieren un nodo con capacidad de archivo. Confirma el acceso a archivo con tu proveedor antes de construir funciones de analítica o contabilidad.
• Métodos de trace y debug. Las API de debug y trace son útiles para simulación de transacciones y análisis de incidentes, pero el soporte varía según el proveedor y el tipo de nodo. Pregunta explícitamente en lugar de asumir.
• Solicitudes por lotes. El procesamiento por lotes JSON-RPC reduce los viajes de ida y vuelta para paneles y billeteras. Verifica si tu plan de endpoint lo admite.

Una regla práctica: enumera cada método no estándar que llama tu aplicación, luego confirma cada uno con la documentación de tu proveedor antes del lanzamiento. Los métodos estándar suelen ser seguros; las consultas de debug, trace y archivo son donde aparecen las sorpresas.

Público, compartido o dedicado: eligiendo la infraestructura de nodos de Arbitrum

Una vez que tu prototipo funciona, la siguiente decisión es operativa. Hay tres formas amplias de obtener un endpoint de Arbitrum, y equilibran el control contra el esfuerzo.

OnFinality ofrece RPC gestionado a través de su servicio de API y nodos dedicados de Arbitrum a través de la infraestructura de nodo dedicado. El precio escala con la opción que elijas; consulta precios de RPC para los planes actuales. Para un marco más amplio sobre la evaluación de proveedores, la guía de selección de proveedores de RPC cubre el dimensionamiento de la carga de trabajo, la conmutación por error y las expectativas de soporte.

Lista de verificación de preparación para producción de las API de Arbitrum

Antes de dirigir usuarios reales a través de un endpoint de Arbitrum, revisa estos puntos de control. Capturan la mayoría de los problemas que surgen después del lanzamiento.

1. Claves separadas por entorno. Usa claves API o endpoints distintos para staging y producción para que un script de prueba descontrolado no pueda agotar el rendimiento de producción.
2. Agrega un endpoint de respaldo. Configura una URL RPC secundaria en tu cliente para que un incidente de un solo proveedor no derribe tu aplicación.
3. Establece tiempos de espera y reintentos. Las llamadas JSON-RPC pueden ser lentas bajo carga; envuélvelas con tiempos de espera y reintentos acotados con retroceso exponencial.
4. Monitorea el retraso de bloques. Consulta eth_blockNumber periódicamente y alerta si tu endpoint se queda atrás de la red.
5. Limita los rangos de eth_getLogs. Divide los escaneos históricos grandes en ventanas acotadas y persiste el progreso.
6. Confirma las necesidades de archivo y trace. Si consultas estado antiguo o simulas transacciones, verifica que esos métodos estén habilitados en tu plan.
7. Prueba las reconexiones de WebSocket. Si te suscribes a eventos, maneja las desconexiones y vuelve a suscribirte limpiamente.

Una sonda de monitoreo simple que puedes ejecutar periódicamente:

#!/usr/bin/env bash
RPC="https://arbitrum.api.onfinality.io/public"
HEIGHT=$(curl -s "$RPC" -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  | sed -E 's/.*"result":"(0x[0-9a-f]+)".*/\1/')
echo "Arbitrum block height: $((HEIGHT))"

Registra el resultado y alerta sobre brechas inesperadas. Esta es una señal ligera, no una pila de observabilidad completa, pero detecta el modo de falla más común: un endpoint que es accesible pero está desactualizado.

Modos de falla comunes y cómo depurarlos

Cuando falla una llamada a la API de Arbitrum, el mensaje de error a menudo apunta al síntoma en lugar de la causa. Usa este mapa para pasar del síntoma al siguiente paso.

Comienza con la verificación más simple: ¿responde eth_blockNumber? Si es así, el endpoint está activo y el problema probablemente sea específico del método, de los parámetros o de la cuota. Si no, trátalo como un incidente de conectividad o del proveedor y conmuta por error.

Migrando desde otro proveedor de Arbitrum

Cambiar de proveedor de RPC de Arbitrum suele ser un cambio de configuración, no una reescritura, porque la API es compatible con Ethereum. Una migración segura sigue cuatro pasos:

1. Inventaria tus métodos. Enumera cada método JSON-RPC que llama tu aplicación, incluidos debug, trace y consultas de archivo.
2. Ejecuta ambos endpoints en paralelo. Apunta un entorno de staging al nuevo endpoint y compara las respuestas para los mismos bloques y llamadas.
3. Verifica las necesidades de transporte. Confirma que el soporte de HTTP y WebSocket coincida con lo que espera tu cliente.
4. Cambia con un respaldo. Mantén el endpoint antiguo como URL secundaria hasta que el nuevo haya funcionado limpiamente durante un ciclo de lanzamiento completo.

Debido a que los ID de cadena y los nombres de cadena son idénticos entre proveedores, no necesitas cambiar las configuraciones de billetera ni las direcciones de contratos. Los principales riesgos son las brechas en el soporte de métodos y los límites de rendimiento, y el paso de ejecución en paralelo los expone temprano.

Puntos clave

• Arbitrum expone una API JSON-RPC compatible con Ethereum en Arbitrum One (ID de cadena 42161) y Arbitrum Sepolia (ID de cadena 421614).
• Métodos estándar como eth_call, eth_getLogs y eth_sendRawTransaction funcionan como se espera; los métodos de debug, trace y archivo necesitan confirmación explícita.
• Los endpoints públicos están bien para prototipos pero no para tráfico de producción; el RPC gestionado compartido y los nodos dedicados cubren cargas de trabajo de producción.
• OnFinality proporciona RPC de Arbitrum a través de su servicio de API y nodos dedicados; consulta precios de RPC y redes RPC compatibles para más detalles.
• Una lista de verificación de producción —claves separadas, endpoints de respaldo, monitoreo de retraso de bloques y consultas de logs acotadas— previene la mayoría de los incidentes posteriores al lanzamiento.

Preguntas frecuentes

¿Cuál es el ID de cadena de Arbitrum? Arbitrum One usa el ID de cadena 42161; Arbitrum Sepolia usa 421614. Ambas usan ETH como moneda nativa.

¿La API de Arbitrum es la misma que la de Ethereum? Es JSON-RPC compatible con Ethereum, por lo que la mayoría de los métodos, bibliotecas cliente y herramientas funcionan sin cambios. Algunos detalles del modelo de tarifas y del soporte de métodos difieren, así que verifica los métodos no estándar con tu proveedor.

¿Puedo usar un endpoint RPC público de Arbitrum en producción? Los endpoints públicos son mejores para desarrollo y pruebas. Para producción, usa un endpoint gestionado o dedicado para que controles el rendimiento, la disponibilidad y el soporte de métodos.

¿Arbitrum admite suscripciones WebSocket? Arbitrum One admite transporte WebSocket en OnFinality; Arbitrum Sepolia es solo HTTP en la configuración de red actual. Confirma con tu proveedor antes de depender de suscripciones.

¿Cómo obtengo ETH de testnet para Arbitrum Sepolia? Usa un faucet de Sepolia para obtener ETH de prueba, luego puentealo o úsalo directamente en Arbitrum Sepolia. La disponibilidad de los faucets cambia, así que verifica las fuentes actuales antes de depender de uno.

¿Dónde puedo encontrar los detalles del endpoint de Arbitrum de OnFinality? Consulta la página de la red Arbitrum para la configuración del endpoint y la cadena, y precios de RPC para las opciones de planes.