Límites de tasa de RPC de Polkadot y errores 429: Límites por segundo, banderas y manejo

Respuesta directa: ¿Qué son los límites de tasa de RPC de Polkadot?

Los límites de tasa de RPC de Polkadot son restricciones sobre cuántas solicitudes puedes enviar a un endpoint RPC en un período de tiempo determinado. Los endpoints públicos como rpc.polkadot.io típicamente imponen alrededor de 5 solicitudes por segundo por IP, mientras que los nodos Substrate autoalojados usan la bandera --rpc-rate-limit para establecer un límite por minuto (por defecto 100 llamadas por minuto). Cuando superas estos límites, recibes una respuesta HTTP 429 Demasiadas solicitudes, o en el caso de conexiones WebSocket, el servidor puede desconectarte silenciosamente.

Los límites exactos varían según el proveedor. Por ejemplo, los endpoints RPC de Polkadot de OnFinality tienen límites documentados que difieren de los nodos comunitarios. Siempre consulta la documentación de tu proveedor para conocer los números específicos.

• Endpoints públicos: ~5 req/s (documentado / varía según el proveedor)
• Substrate autoalojado: --rpc-rate-limit por defecto 100 llamadas/min
• 429 es un estado HTTP; las desconexiones de WebSocket son silenciosas

Cómo funciona el límite de tasa de RPC de Substrate

Las cadenas basadas en Substrate como Polkadot tienen límite de tasa de RPC integrado. Las banderas clave son --rpc-rate-limit (para llamadas RPC generales) y --rpc-eth-rate-limit (para métodos RPC compatibles con Ethereum). Estas banderas establecen un límite de llamadas por minuto por IP. Además, --rpc-max-connections-per-ip limita el número de conexiones WebSocket por IP.

El limitador de tasa utiliza un algoritmo de cubo de fichas. Cada IP tiene un cubo que se llena a cierta velocidad y se vacía a medida que se realizan solicitudes. Cuando el cubo está vacío, las solicitudes se rechazan con un 429 o se cae la conexión.

Los endpoints públicos a menudo establecen límites más estrictos que los predeterminados de Substrate para proteger la infraestructura compartida. Por ejemplo, rpc.polkadot.io está fuertemente restringido. Esto está documentado en los docs de infraestructura de nodos de Polkadot.

• --rpc-rate-limit: establece llamadas por minuto (por defecto 100)
• --rpc-eth-rate-limit: para métodos eth_*
• --rpc-max-connections-per-ip: limita conexiones WebSocket
• Algoritmo de cubo de fichas: se rellena con el tiempo

429 vs. Timeout vs. Códigos de error RPC

Un 429 Demasiadas solicitudes es un código de estado HTTP que indica que has superado el límite de tasa. Es diferente de un timeout, que significa que el servidor no respondió dentro de un tiempo especificado. Los códigos de error RPC (como -32000) son errores JSON-RPC devueltos por el nodo para solicitudes inválidas o errores internos.

Cuando recibes un 429, la respuesta puede incluir un encabezado Retry-After que indica cuánto tiempo esperar antes de reintentar. Las conexiones WebSocket no devuelven códigos de estado HTTP; en su lugar, el servidor puede cerrar la conexión o enviar un mensaje de error personalizado.

Entender la diferencia te ayuda a elegir la estrategia de manejo correcta: para 429, usa backoff; para timeouts, aumenta el timeout o reduce la carga; para errores RPC, corrige la solicitud.

• 429: límite de tasa excedido, reintentar después de Retry-After
• Timeout: sin respuesta dentro del límite de tiempo, aumentar timeout o reducir carga
• Error RPC: solicitud inválida, corregir la solicitud

Identificando el alcance del límite

Antes de optimizar, determina si el límite es por conexión o por IP, y si se aplica a HTTP o WebSocket. Para HTTP, el límite suele ser por IP. Para WebSocket, puede ser por conexión o por IP dependiendo del proveedor.

Puedes probar enviando una ráfaga de solicitudes desde una sola conexión y observando cuándo obtienes un 429 o desconexión. También verifica si el límite se aplica a todos los métodos o solo a algunos específicos (por ejemplo, métodos eth_*).

Usa el Asistente de RPC para ver los límites documentados de varios proveedores.

• Consulta los docs del proveedor para límites por IP vs por conexión
• Prueba con una ráfaga de solicitudes para ver el umbral
• Algunos proveedores limitan métodos específicos como eth_*

Reduciendo el volumen de solicitudes

La forma más efectiva de evitar 429 es reducir el número de solicitudes que haces. En lugar de hacer polling de nuevos bloques con chain_getBlock, suscríbete a nuevos bloques usando chain_subscribeFinalizedHeads. Esto empuja actualizaciones hacia ti, reduciendo la sobrecarga del polling.

Usa batching JSON-RPC para combinar múltiples llamadas en una sola solicitud HTTP. Esto es especialmente efectivo para llamadas de solo lectura como chain_getHeader o state_getStorage. La API de polkadot.js soporta batching mediante el método .batch().

Cachea lecturas de almacenamiento que no cambian frecuentemente. Por ejemplo, si necesitas el mismo valor de almacenamiento varias veces, guárdalo localmente y actualízalo solo cuando llegue un nuevo bloque.

• Usa suscripciones en lugar de polling
• Agrupa múltiples llamadas en una sola solicitud
• Cachea lecturas de almacenamiento e invalida con nuevos bloques

Manejando 429 con backoff y Retry-After

Cuando recibas un 429, implementa backoff exponencial con jitter. Si la respuesta incluye un encabezado Retry-After, espera esa cantidad de segundos antes de reintentar. De lo contrario, comienza con un retraso corto (por ejemplo, 1 segundo) y duplícalo hasta un máximo (por ejemplo, 30 segundos).

Para conexiones WebSocket, si el servidor desconecta, reconecta con un retraso y considera reducir tu tasa de solicitudes.

Aquí hay un ejemplo en Node.js usando polkadot.js que demuestra batching y backoff en 429:

• Backoff exponencial: 1s, 2s, 4s, ... hasta máximo
• Respeta el encabezado Retry-After si está presente
• Para WS, reconecta con retraso

const { ApiPromise, WsProvider } = require('@polkadot/api');

async function main() {
  const provider = new WsProvider('wss://rpc.polkadot.io');
  const api = await ApiPromise.create({ provider });

  // Ejemplo de batching: obtener múltiples cabeceras en una solicitud
  const batch = api.createType('Vec<BlockNumber>', [100, 200, 300]);
  const headers = await api.rpc.chain.getHeader.batch(batch);
  console.log('Headers:', headers.map(h => h.number.toString()));

  // Backoff en 429 (ejemplo HTTP)
  const fetch = require('node-fetch');
  async function rpcCall(method, params) {
    let delay = 1000;
    while (true) {
      const res = await fetch('https://rpc.polkadot.io', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
      });
      if (res.status === 429) {
        const retryAfter = res.headers.get('Retry-After');
        const wait = retryAfter ? parseInt(retryAfter) * 1000 : delay;
        console.log(`429, esperando ${wait}ms`);
        await new Promise(r => setTimeout(r, wait));
        delay = Math.min(delay * 2, 30000);
      } else {
        return res.json();
      }
    }
  }

  const result = await rpcCall('chain_getHeader', []);
  console.log('Header:', result.result.number);

  await api.disconnect();
}

main().catch(console.error);

// Salida esperada: Headers: ['100', '200', '300'] y un número de cabecera

Fallos comunes y soluciones

Incluso con las mejores prácticas, puedes encontrar problemas. Aquí hay fallos comunes y cómo solucionarlos:

1. Desconexiones WebSocket silenciosas: El servidor cierra la conexión sin un 429. Solución: implementa lógica de reconexión con backoff exponencial y reduce la tasa de solicitudes.

2. 429 en HTTP pero no en WS: Algunos proveedores tienen límites diferentes para HTTP y WS. Solución: usa WS para suscripciones y HTTP para lecturas ocasionales.

3. Límite de tasa en métodos específicos: Algunos proveedores limitan los métodos eth_* más estrictamente. Solución: usa métodos nativos de Substrate cuando sea posible.

4. Batching no reduce los 429: Si el proveedor cuenta cada lote como una solicitud, el batching ayuda. Si no, puede que necesites reducir el volumen general.

• Desconexión WS silenciosa: implementa reconexión con backoff
• Límites HTTP vs WS: usa el protocolo apropiado para cada caso
• Límites específicos de método: prefiere métodos nativos de Substrate
• El batching puede no ayudar si el proveedor cuenta cada llamada individualmente

Compensaciones y limitaciones

Los límites de tasa son necesarios para proteger la infraestructura RPC del abuso, pero pueden ser frustrantes para los desarrolladores. La compensación es entre fiabilidad y accesibilidad. Los endpoints públicos son gratuitos pero muy limitados; los endpoints dedicados o nodos autoalojados ofrecen límites más altos pero requieren pago o mantenimiento.

Autoalojar un nodo te da control total sobre los límites de tasa mediante banderas como --rpc-rate-limit. Sin embargo, ejecutar un nodo requiere recursos significativos y mantenimiento. Para cargas de trabajo de producción, considera usar un proveedor como el servicio API de OnFinality con precios de RPC que escalan con tus necesidades.

Recuerda que los límites de tasa no son un sustituto de un buen diseño de cliente. Siempre minimiza las solicitudes, usa suscripciones y maneja los errores con gracia.

• Endpoints públicos: gratuitos pero limitados
• Autoalojado: control total pero alto mantenimiento
• Endpoints de proveedor: escalables pero cuestan dinero
• El buen diseño de cliente es esencial independientemente de los límites

Próximos pasos y lecturas adicionales

Ahora que entiendes los límites de tasa de RPC de Polkadot, puedes optimizar tu aplicación para evitar 429. Comienza identificando tu patrón de uso e implementando batching y suscripciones. Si necesitas límites más altos, considera un endpoint dedicado o tu propio nodo.

Para más ayuda, consulta el hub de aprendizaje de OnFinality para otros tutoriales, y la guía manejo genérico de 429 RPC. También puedes explorar endpoints RPC de Polkadot para comparar proveedores.

Si estás construyendo en Polkadot, también puede interesarte nuestra página de red de Polkadot para detalles de la red.

• Implementa batching y suscripciones en tu cliente
• Considera endpoints dedicados para producción
• Lee más en el hub de aprendizaje de OnFinality
• Consulta manejo genérico de 429 RPC