Límites de tasa de RPC de Ethereum y errores 429: Costos de métodos, unidades de cómputo y mitigación

Respuesta directa: Por qué recibe errores 429 en RPC de Ethereum

Si está viendo HTTP 429 Too Many Requests desde un endpoint de RPC de Ethereum, significa que su aplicación ha excedido el límite de tasa del proveedor. A diferencia de un timeout (que indica que el servidor no respondió a tiempo) o un error JSON-RPC (que es una respuesta válida con un código de error), un 429 es una respuesta a nivel HTTP que le indica que debe reducir la velocidad. Los proveedores miden el uso asignando un costo de unidad de cómputo a cada método JSON-RPC, y aplican límites tanto en solicitudes por segundo como en solicitudes concurrentes. Métodos pesados como eth_getLogs en un rango grande de bloques o eth_call en nodos de archivo pueden consumir cientos de unidades de cómputo, agotando rápidamente su cuota.

La clave para resolver los 429 es comprender el modelo de costos y ajustar el comportamiento de su cliente. Este artículo explica el mecanismo, proporciona una demostración reproducible con curl y describe estrategias de mitigación estandarizadas. Para una visión general más amplia sobre el manejo de 429, consulte nuestra guía manejo genérico de RPC 429.

Cómo miden el uso los proveedores de RPC de Ethereum: Unidades de cómputo y ventanas

Los proveedores de RPC de Ethereum, incluido OnFinality, suelen utilizar un sistema de unidades de cómputo (CU) para fijar el precio del acceso a la API. Cada método tiene un peso basado en los recursos computacionales que requiere. Por ejemplo, un simple eth_blockNumber podría costar 1 CU, mientras que eth_getLogs en un rango amplio puede costar cientos o miles de CUs. Los proveedores también aplican dos tipos de ventanas: un límite de solicitudes por segundo (por ejemplo, 100 solicitudes por segundo) y un límite de concurrencia (por ejemplo, 10 solicitudes simultáneas). Cuando excede cualquiera de ellos, recibe un 429.

Los valores exactos de CU no están estandarizados entre proveedores; cada proveedor los documenta. Por ejemplo, Alchemy e Infura publican sus propias tablas de CU. La página de precios de OnFinality describe nuestro enfoque. La tabla a continuación muestra rangos representativos basados en el comportamiento documentado de los principales proveedores; trátelos como estimaciones, no como constantes universales.

• eth_blockNumber: 1 CU (bajo)
• eth_getBalance: 2-10 CU (bajo a medio)
• eth_call: 10-50 CU (medio, depende de la complejidad)
• eth_getLogs (bloque único): 10-50 CU (medio)
• eth_getLogs (rango amplio, por ejemplo, 1000 bloques): 500-2000+ CU (alto)
• debug_traceTransaction: 100-500 CU (alto, solo archivo)
• eth_getStorageAt (archivo): 20-100 CU (medio a alto)

Por qué eth_getLogs y los métodos de archivo dominan

eth_getLogs es conocido por consumir altas unidades de cómputo porque escanea un rango de bloques y filtra registros. Un rango amplio (por ejemplo, 10,000 bloques) puede hacer que el nodo procese una gran cantidad de datos, lo que lleva a un alto uso de CPU y E/S. De manera similar, los métodos de archivo como eth_getBalance en bloques históricos o debug_traceTransaction requieren que el nodo reproduzca el estado, lo cual es computacionalmente costoso. Estos métodos suelen ser la causa principal de los 429 en aplicaciones de producción.

Para mitigar, debe estrechar los rangos de bloques, usar filtros indexados y almacenar en caché los resultados. Por ejemplo, en lugar de consultar registros de los últimos 10,000 bloques cada minuto, puede consultar solo el último bloque y almacenar los resultados en una base de datos local. Para datos de archivo, considere usar un endpoint de archivo dedicado o un proveedor que ofrezca acceso de archivo rentable, como la página de red Ethereum de OnFinality.

429 vs Timeout vs Códigos de error JSON-RPC

Es importante distinguir entre un 429, un timeout y un error JSON-RPC. Un 429 es un código de estado HTTP devuelto por la puerta de enlace del proveedor, que indica que ha excedido el límite de tasa. Un timeout ocurre cuando el servidor no responde dentro de un tiempo especificado (por ejemplo, 30 segundos), a menudo debido a una solicitud pesada. Un error JSON-RPC es una respuesta HTTP 200 válida con un objeto de error en el cuerpo, como 'execution reverted' o 'method not found'. Estos son modos de fallo diferentes y requieren un manejo diferente.

Por ejemplo, un 429 debería desencadenar backoff y reintento, mientras que un timeout podría requerir reducir la complejidad de la solicitud. Un error JSON-RPC podría indicar un error en su llamada de contrato. Comprender estas diferencias le ayuda a implementar un manejo de errores robusto.

Demostración reproducible: 200 vs 429 con curl

Los siguientes comandos curl demuestran una solicitud exitosa y una solicitud limitada por tasa. Reemplace YOUR_API_KEY con su clave de API de OnFinality. El primer comando envía una solicitud simple eth_blockNumber, que debería devolver un 200 con un resultado JSON. El segundo comando envía una ráfaga de solicitudes en un bucle para provocar un 429; ajuste el número de iteraciones para exceder el límite de su plan.

Nota: El límite de tasa exacto depende de su plan. El nivel gratuito de OnFinality permite un cierto número de solicitudes por segundo; consulte sus precios para más detalles. Para ver un 429, es posible que necesite ejecutar el bucle muchas veces o usar un método pesado como eth_getLogs.

curl -X POST https://ethereum-rpc.publicnode.com \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# Esperado: HTTP/1.1 200 OK con un resultado JSON como {"jsonrpc":"2.0","result":"0x...","id":1}

# Para provocar un 429, ejecute un bucle (ajuste el número para exceder su límite):
for i in $(seq 1 100); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST https://ethereum-rpc.publicnode.com \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
done
# Esperado: algunas respuestas serán 429 si excede el límite de tasa.

Resultados esperados y cómo verificar

Cuando ejecute el primer curl, debería ver un estado 200 y una respuesta JSON con el número de bloque actual. Cuando ejecute el bucle, puede ver una mezcla de respuestas 200 y 429. El cuerpo de la respuesta 429 típicamente incluye un mensaje como 'Too Many Requests' y puede incluir un encabezado Retry-After. Para verificar su límite de tasa, consulte el panel de control o la documentación de su proveedor. Para OnFinality, puede monitorear el uso en la consola de servicio de API.

Si no ve un 429, aumente el número de iteraciones del bucle o use un método más pesado como eth_getLogs con un rango amplio. Recuerde que los límites de tasa son por clave de API, por lo que usar un endpoint público puede tener límites diferentes.

Estrategias de mitigación estandarizadas

Para evitar los 429, implemente las siguientes estrategias:

Batching: Combine múltiples solicitudes en un solo lote JSON-RPC. Esto reduce el número de solicitudes HTTP y puede reducir el consumo de CU si el proveedor ofrece descuentos por lote. Consulte nuestro artículo hermano sobre mejores prácticas de batching para más detalles.

Caché: Almacene en caché saldos, registros y otros datos localmente. Por ejemplo, almacene en caché los resultados de eth_getBalance con un TTL corto (por ejemplo, 15 segundos) para evitar llamadas repetidas.

Estrechar rangos de bloques: Para eth_getLogs, consulte rangos más pequeños (por ejemplo, 100 bloques) y pagine si es necesario.

Use suscripciones WebSocket: En lugar de sondear eth_getBalance o eth_blockNumber, use eth_subscribe para recibir actualizaciones push. Esto reduce el número de solicitudes.

Backoff exponencial con Retry-After: Cuando reciba un 429, espere el encabezado Retry-After (si está presente) o use backoff exponencial (por ejemplo, 1s, 2s, 4s) antes de reintentar.

Mueva la carga sostenida a un endpoint dedicado: Si tiene tráfico de producción de alto volumen, considere un endpoint dedicado con límites más altos. OnFinality ofrece endpoints dedicados para este propósito.

// Ejemplo: Backoff exponencial con Retry-After en Node.js
const axios = require('axios');

async function rpcCall(method, params) {
  const url = 'https://ethereum-rpc.publicnode.com';
  const data = { jsonrpc: '2.0', method, params, id: 1 };
  let retries = 0;
  while (true) {
    try {
      const response = await axios.post(url, data);
      return response.data;
    } catch (error) {
      if (error.response && error.response.status === 429) {
        const retryAfter = parseInt(error.response.headers['retry-after'] || '0');
        const delay = retryAfter > 0 ? retryAfter * 1000 : Math.min(1000 * 2 ** retries, 10000);
        await new Promise(resolve => setTimeout(resolve, delay));
        retries++;
      } else {
        throw error;
      }
    }
  }
}

// Uso: rpcCall('eth_blockNumber', [])

Fallos comunes y soluciones

Un fallo común es no manejar los 429 en el código, lo que lleva a bloqueos o pérdida de datos. Otro es usar una sola clave de API tanto para desarrollo como para producción, lo que hace que producción alcance los límites. Un tercero es sondear con demasiada frecuencia; por ejemplo, sondear eth_blockNumber cada segundo cuando el tiempo de bloque es de 12 segundos.

Las soluciones incluyen: implementar lógica de reintento con backoff, usar claves de API separadas para diferentes entornos y reducir la frecuencia de sondeo. Además, considere usar suscripciones WebSocket para datos en tiempo real. Para solución de problemas más avanzada, consulte nuestra herramienta RPC Assistant.

Compensaciones y limitaciones

Si bien el batching reduce la sobrecarga HTTP, puede aumentar la complejidad del manejo de errores porque un lote puede devolver errores parciales. El almacenamiento en caché introduce desactualización, lo que puede ser inaceptable para algunas aplicaciones. Estrechar los rangos de bloques puede perder registros si no maneja la paginación correctamente. Las suscripciones WebSocket requieren mantener una conexión persistente, lo que puede no ser adecuado para entornos serverless.

Además, los costos de unidades de cómputo no están estandarizados; varían según el proveedor y pueden cambiar. Consulte siempre la documentación de su proveedor para conocer los valores más recientes. Para OnFinality, consulte nuestra página de precios.

Próximos pasos y lecturas adicionales

Ahora que comprende los límites de tasa de RPC de Ethereum, puede implementar las estrategias de mitigación para reducir los errores 429. Comience auditando su uso actual de RPC para identificar métodos pesados. Luego, aplique batching, caché y backoff. Para carga sostenida, considere un endpoint dedicado.

Explore más recursos: página de red Ethereum para detalles de endpoints, RPC Assistant para comparar proveedores, servicio de API para monitoreo, y nuestro centro de aprendizaje para más tutoriales. También lea la guía manejo genérico de RPC 429 para una perspectiva más amplia.