API RPC de Arbitrum: Configuración de Endpoints, Métodos y Modos de Fallo

Arbitrum One es un rollup optimista que se liquida en Ethereum, pero expone una superficie JSON-RPC compatible con Ethereum. Esa compatibilidad es conveniente y también una trampa: la mayoría de las herramientas de Ethereum funcionan, pero un puñado de métodos, reglas de gas y suposiciones de temporización se comportan de manera diferente. Esta página te proporciona la configuración para conectarte, los métodos que vale la pena verificar antes de lanzar y los modos de fallo que aparecen en producción.

Configuración de la cadena de un vistazo

Comienza confirmando los valores que tu cliente, billetera o framework necesita. Arbitrum One es el rollup de mainnet; Arbitrum Sepolia es la testnet que usas para staging.

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

{
  "chainId": "0x66eee",
  "chainName": "Arbitrum One",
  "nativeCurrency": { "name": "Ether", "symbol": "ETH", "decimals": 18 },
  "rpcUrls": ["https://arbitrum.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://arbiscan.io"]
}

Ten en cuenta que 0x66eee es la forma hexadecimal de 42161. Las billeteras rechazan una discrepancia entre el chain ID decimal que citas en la documentación y el valor hexadecimal que envías en wallet_addEthereumChain.

Decide cómo te conectarás antes de escribir código

La decisión de conexión generalmente se reduce a tres preguntas: ¿tu aplicación necesita actualizaciones push?, ¿necesita estado histórico?, y ¿qué tan variable es tu tráfico?

• Paneles de solo lectura y billeteras generalmente pueden funcionar en un endpoint HTTP compartido. Las solicitudes son cortas, sin estado y almacenables en caché.
• Aplicaciones que reaccionan a nuevos bloques o actividad pendiente se benefician de una suscripción WebSocket para no estar sondeando eth_getBlockByNumber en un bucle.
• Indexadores, análisis y rellenos necesitan acceso a archivo y a menudo consultas más pesadas de eth_getLogs, que es donde los endpoints públicos compartidos comienzan a sobrecargarse.
• Cargas de trabajo de alto volumen o sensibles a la latencia se sirven mejor con un nodo dedicado donde tu tráfico no comparte capacidad con otros inquilinos.

Si no estás seguro de en qué categoría encajas, la guía de selección de proveedor de RPC repasa los criterios de evaluación. Para Arbitrum específicamente, puedes comparar opciones compartidas y dedicadas en la página de la red Arbitrum.

Llamar a la API RPC de Arbitrum

Una solicitud de lectura básica es idéntica a Ethereum. Esta llamada curl obtiene el último número de bloque:

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

En JavaScript con viem, la misma llamada es una línea una vez configurada la cadena:

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

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

const blockNumber = await client.getBlockNumber();
console.log(blockNumber);

Para una suscripción WebSocket a nuevos encabezados de bloque:

import WebSocket from 'ws';

const ws = new WebSocket('wss://arbitrum.api.onfinality.io/public/ws');
ws.on('open', () => {
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_subscribe',
    params: ['newHeads'],
  }));
});
ws.on('message', (data) => console.log(data.toString()));

Confirma la ruta exacta del WebSocket en la página de la red Arbitrum antes de codificarla, ya que el soporte de transporte puede diferir entre mainnet y testnet.

Métodos que se comportan de manera diferente en Arbitrum

Debido a que Arbitrum es un rollup, algunos métodos devuelven valores que no coinciden con un modelo mental de Ethereum L1.

La diferencia de gas es la que más sorprende a los equipos. Una transacción en Arbitrum paga gas de ejecución de L2 y un costo separado de disponibilidad de datos de L1, por lo que un precio de gas que parece bien en Ethereum puede subestimar una transacción de Arbitrum. Siempre estima en lugar de asumir.

Modos de fallo y cómo depurarlos

La mayoría de los problemas de la API RPC de Arbitrum caen en un pequeño conjunto de categorías. Relaciona el síntoma con la causa probable antes de cambiar de proveedor.

Una secuencia de depuración práctica: reproduce la llamada fallida con curl para eliminar tu framework de la ecuación, confirma el número de bloque contra el que estás consultando, luego verifica si la misma llamada tiene éxito en un segundo endpoint. Si solo falla en un endpoint, tienes un problema de infraestructura. Si falla en todas partes, el problema está en la solicitud misma.

Lista de verificación de preparación para producción

Antes de dirigir tráfico real a un endpoint de Arbitrum, confirma cada uno de estos:

• Conmutación por error: tu cliente puede cambiar a un segundo endpoint sin un redespliegue.
• Reintentos: las respuestas transitorias 5xx y de tiempo de espera se reintentan con retroceso exponencial, no inmediatamente.
• Tiempos de espera: los tiempos de espera de solicitud están configurados para que una llamada lenta no bloquee toda tu ruta de solicitud.
• Consultas de registros: los rangos de eth_getLogs están limitados y paginados.
• Suscripciones: los clientes WebSocket se reconectan y resuscriben automáticamente.
• Observabilidad: rastreas la tasa de error y la latencia por método, no solo el tiempo de actividad general.
• Capacidad: conoces tus solicitudes máximas por segundo y si un endpoint compartido puede absorberlas.

Si tu carga máxima es constante y alta, o necesitas acceso a archivo y traza, un nodo dedicado elimina la variable del vecino ruidoso. Si tu carga es modesta y en ráfagas, un endpoint compartido gestionado suele ser la opción más simple. Los precios para ambos modelos están en la página de precios de RPC.

Flujo de trabajo en testnet

Usa Arbitrum Sepolia para staging para no quemar ETH de mainnet en pruebas de integración. El chain ID es 421614 y el explorador es https://sepolia.arbiscan.io. Los faucets para Arbitrum Sepolia son operados por proveedores del ecosistema; financia una clave desechable y mantenla fuera de la configuración de producción. Debido a que el estado de testnet no es permanente, no construyas aserciones que dependan de que bloques históricos específicos persistan para siempre.

Señales de monitoreo que vale la pena rastrear

Una vez que estés en vivo, las señales útiles son a nivel de método. Rastrea la tasa de error de eth_sendRawTransaction por separado de los métodos de lectura, porque los fallos de escritura generalmente indican problemas de nonce o gas en lugar de problemas de infraestructura. Rastrea la latencia de eth_getLogs por separado, porque es el método más sensible a la forma de la consulta. Y rastrea la frecuencia de reconexión de WebSocket, porque un recuento de reconexión creciente es una advertencia temprana de que tu manejo de suscripciones necesita atención.

Puntos clave

• Arbitrum One usa el chain ID 42161 y Arbitrum Sepolia usa 421614; ambos usan ETH como moneda nativa.
• La superficie JSON-RPC es compatible con Ethereum, pero la estimación de gas y las consultas de registros se comportan de manera diferente porque Arbitrum es un rollup.
• Siempre estima el gas en lugar de codificarlo, y siempre limita los rangos de bloques de eth_getLogs.
• Relaciona el tipo de conexión con la carga de trabajo: HTTP para lecturas sin estado, WebSocket para actualizaciones push, nodos dedicados para tráfico sostenido o con mucho archivo.
• Construye lógica de conmutación por error, reintentos y reconexión antes de escalar el tráfico, no después de un incidente.

Preguntas frecuentes

¿La API RPC de Arbitrum es la misma que la de Ethereum? Es similar. Los nombres de los métodos y el formato de solicitud son los mismos, pero el precio del gas, el costo de consulta de registros y la temporización de bloques difieren porque Arbitrum es un rollup optimista.

¿Qué chain ID usa Arbitrum? Arbitrum One usa 42161 y Arbitrum Sepolia usa 421614. En las configuraciones de billetera, envía la forma hexadecimal.

¿Necesito un endpoint WebSocket? Solo si tu aplicación necesita actualizaciones push como nuevos encabezados de bloque o suscripciones a eventos. Las aplicaciones de solo lectura pueden usar solo HTTP.

¿Por qué se agota mi llamada a eth_getLogs? El rango de bloques suele ser demasiado amplio. Divídelo en ventanas más pequeñas y pagina.

¿Cuándo debo pasar de un endpoint compartido a un nodo dedicado? Cuando tu volumen de solicitudes sostenido, necesidades de archivo o requisitos de latencia excedan lo que un endpoint compartido puede servir cómodamente. Compara opciones en la página de la red Arbitrum y revisa los precios de RPC para ambos modelos.

¿Dónde puedo ver qué redes soporta OnFinality? La lista completa está en la página de redes RPC compatibles.