¿En qué se diferencian los proveedores de RPC de Solana en cuanto a limitación de velocidad y rendimiento?

El alto rendimiento de Solana hace que la capacidad de RPC sea una restricción de ingeniería real. A diferencia de las cadenas EVM, donde una simple eth_call es barata, las solicitudes RPC de Solana varían enormemente en costo: una llamada getBalance es trivial, mientras que getProgramAccounts o una suscripción WebSocket ocupada pueden consumir una gran parte de los recursos de un nodo. Por eso, la "limitación de velocidad" en Solana no es un único número que puedas comparar entre proveedores. Es una combinación de límites de solicitudes por segundo, restricciones a nivel de método, contabilidad de unidades de cómputo y límites de conexión.

Este artículo explica los modelos de limitación de velocidad que encontrarás, qué verificar antes de comprometerte con un proveedor y cómo decidir entre capacidad compartida y dedicada para tu carga de trabajo.

Recomendación rápida: ¿nivel compartido o nodo dedicado?

Antes de comparar proveedores línea por línea, decide qué modelo de capacidad se adapta a tu aplicación.

• Prototipado, dApps de bajo volumen o paneles de solo lectura: un nivel de RPC compartido suele ser suficiente. Obtienes un endpoint gestionado con un límite de velocidad publicado o flexible, y no gestionas infraestructura.
• Bots de trading, indexadores, backends de billeteras o cualquier cosa con carga en ráfagas o sostenida: los niveles compartidos eventualmente te limitarán. Un nodo dedicado te da un techo predecible y elimina la contención del grupo compartido que causa picos de latencia.
• getProgramAccounts pesados, escaneos de getSignaturesForAddress o gran fan-out de WebSocket: estas son las llamadas con mayor probabilidad de ser restringidas en niveles compartidos. Si tu aplicación depende de ellas, planifica capacidad dedicada o una capa de indexación.

Si no estás seguro, comienza con un endpoint compartido, instrumenta tus patrones de solicitud y pasa a capacidad dedicada cuando veas limitación o variación de latencia. OnFinality ofrece ambos modelos, para que puedas escalar sin cambiar de proveedor. Consulta Precios de RPC para ver cómo los niveles se asignan al uso.

Los cuatro modelos de limitación de velocidad que realmente encontrarás

Los proveedores rara vez publican una única cifra de "solicitudes por segundo". La mayoría combina varios mecanismos:

1. Solicitudes por segundo (RPS) o por minuto (RPM). El límite más simple. Se aplica por clave de API o por IP. Bien para tráfico constante, castiga las ráfagas.
2. Contabilidad de unidades de cómputo (CU). A cada método se le asigna un costo. Un getBalance podría costar 1 CU mientras que getProgramAccounts cuesta cientos o miles. Tu plan es un presupuesto de CU, no un conteo de solicitudes. Este es el modelo más alineado con cómo los nodos de Solana consumen recursos realmente.
3. Restricciones a nivel de método. Algunos proveedores bloquean o limitan fuertemente métodos costosos en niveles compartidos, independientemente de tu presupuesto de CU. getProgramAccounts y los escaneos tipo getProgramAccounts son los sospechosos habituales.
4. Límites de conexión y suscripción. Las conexiones WebSocket, las suscripciones concurrentes y los conteos de accountSubscribe / logsSubscribe a menudo se limitan por separado del HTTP.

Cuando compares proveedores, pregunta cuáles de estos cuatro aplican y cómo interactúan. Un proveedor con un límite generoso de RPS pero una contabilidad estricta de CU puede limitarte antes de lo esperado.

Matriz de evaluación de proveedores

Usa esta tabla para estructurar tu comparación. Completa los detalles de la documentación actual de cada proveedor, ya que los límites cambian con el tiempo.

OnFinality proporciona acceso compartido a la API RPC y nodos dedicados de Solana, para que puedas adaptar el modelo a tu carga de trabajo. Compara los dos en la página de la red Solana.

Límites específicos de Solana que complican las comparaciones

Las comparaciones genéricas de RPC a menudo ignoran la economía de métodos de Solana. Tres áreas merecen especial atención.

getProgramAccounts y escaneos de cuentas

getProgramAccounts puede devolver conjuntos de resultados enormes. Muchos proveedores lo deshabilitan en niveles compartidos, requieren un dataSlice o filtros, o cobran un alto costo de CU. Si tu aplicación depende de él, confirma la política antes de comprometerte. Un proveedor que "admite Solana" pero limita silenciosamente este método romperá tu indexador.

Suscripciones WebSocket

Las aplicaciones de Solana usan con frecuencia accountSubscribe, logsSubscribe y slotSubscribe. Estas mantienen recursos del servidor durante la vida de la conexión. Los proveedores limitan las suscripciones concurrentes por clave, y una suscripción ocupada puede ser limitada independientemente de tu tráfico HTTP. Prueba los límites de suscripción bajo carga realista, no solo con una única conexión.

Envío de transacciones y tarifas de prioridad

El comportamiento de sendTransaction varía. Algunos proveedores reenvían transacciones a los líderes con diferentes estrategias, y algunos aplican límites separados a las llamadas de ruta de escritura. Si envías transacciones en volumen, pregunta cómo maneja el proveedor el envío y si afecta tu presupuesto de velocidad.

Probar los límites de un proveedor antes de comprometerte

No confíes solo en los números publicados. Ejecuta una prueba de carga corta contra tus endpoints candidatos y observa la forma de la limitación.

Una sonda mínima usando curl contra el endpoint público de Solana de OnFinality:

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

Para una verificación rápida de rendimiento en JavaScript, lanza un lote de llamadas baratas y mide cómo responde el proveedor a medida que aumentas la concurrencia:

const endpoint = "https://solana.api.onfinality.io/public";

async function probe(concurrency) {
  const calls = Array.from({ length: concurrency }, (_, i) =>
    fetch(endpoint, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        jsonrpc: "2.0",
        id: i,
        method: "getSlot",
        params: [],
      }),
    }).then((r) => r.status)
  );
  const results = await Promise.all(calls);
  const throttled = results.filter((s) => s === 429).length;
  console.log(`concurrency=${concurrency} throttled=${throttled}`);
}

probe(10);
probe(50);
probe(100);

Observa las respuestas HTTP 429, los códigos de error JSON-RPC y el aumento de latencia. El nivel de concurrencia donde comienza la limitación es tu techo práctico en ese nivel. Repite contra un endpoint dedicado para ver la diferencia.

Leer correctamente las señales de limitación

Cuando alcanzas un límite, el síntoma te dice qué mecanismo se activó:

Distinguir estos casos evita el error común de actualizar un plan cuando la solución real es agrupar o filtrar tus llamadas.

Reducir tu huella de limitación de velocidad

Antes de pagar por más capacidad, reduce la carga innecesaria:

• Agrupa solicitudes JSON-RPC donde el proveedor lo admita, para que muchas llamadas baratas compartan un único viaje HTTP.
• Usa dataSlice y filtros en getProgramAccounts para reducir los conjuntos de resultados.
• Cachea agresivamente. Las alturas de slot, los metadatos de tokens y los datos de cuentas cambian con menos frecuencia de lo que podrías consultar.
• Prefiere suscripciones WebSocket en lugar de sondeo para estados que cambian con frecuencia, pero limita el número de suscripciones.
• Separa las rutas de lectura y escritura para que una ráfaga de envíos de transacciones no ahogue tu tráfico de lectura.

Estos cambios a menudo retrasan la necesidad de un nivel superior y hacen que tu uso sea más predecible.

Cuándo la capacidad dedicada es la respuesta correcta

Los niveles compartidos son económicos y adecuados para muchas aplicaciones. Los nodos dedicados tienen sentido cuando:

• Necesitas un techo de rendimiento predecible que no varíe con otros inquilinos.
• Dependes de métodos pesados o un gran fan-out de WebSocket que los niveles compartidos restringen.
• Quieres ejecutar consultas tipo archivo o indexar datos históricos.
• Necesitas latencia consistente para trading o UX en tiempo real.

La opción de nodo dedicado de OnFinality te brinda un nodo Solana privado mientras mantiene el modelo operativo gestionado. Puedes revisar las redes admitidas en la página de redes y comparar costos en Precios de RPC.

Puntos clave

• La limitación de velocidad de Solana no es un solo número; combina límites de RPS/RPM, contabilidad de unidades de cómputo, restricciones de métodos y límites de WebSocket.
• getProgramAccounts, los escaneos de firmas y las suscripciones son las llamadas con mayor probabilidad de ser limitadas en niveles compartidos.
• Siempre prueba la carga de los endpoints candidatos y lee las señales de limitación antes de comprometerte.
• Reduce tu huella con agrupación, filtros, caché y suscripciones antes de actualizar.
• Pasa a un nodo dedicado cuando necesites rendimiento predecible, soporte para métodos pesados o latencia consistente.

Preguntas frecuentes

¿Puedo comparar proveedores de RPC de Solana solo por solicitudes por segundo? No. El RPS es solo un mecanismo. La contabilidad de unidades de cómputo y las restricciones a nivel de método a menudo importan más, especialmente para llamadas pesadas como getProgramAccounts.

¿Por qué recibo errores 429 solo en algunos métodos? Eso generalmente indica una restricción a nivel de método en lugar de un límite global de RPS. Agrega filtros o dataSlice, o mueve esas llamadas a un nodo dedicado.

¿Las suscripciones WebSocket cuentan contra mi límite de velocidad? A menudo sí, pero por separado del HTTP. Los proveedores suelen limitar las conexiones concurrentes y las suscripciones por clave.

¿Cómo sé cuándo cambiar de compartido a dedicado? Cuando veas limitación sostenida, variación de latencia por contención del grupo compartido, o dependas de métodos restringidos en niveles compartidos.

¿OnFinality ofrece acceso compartido y dedicado a Solana? Sí. OnFinality proporciona endpoints de API RPC compartidos y nodos dedicados de Solana, para que puedas comenzar compartido y escalar a dedicado sin cambiar de proveedor. Consulta Precios de RPC y la página de la red Solana.

Próximos pasos

Comienza mapeando tus patrones de solicitud reales: qué métodos, con qué frecuencia y qué tan en ráfagas. Luego prueba un endpoint compartido contra tu carga máxima. Si aguanta, ya está. Si se limita, ahora sabes si la solución es agrupar, filtrar o capacidad dedicada. OnFinality admite ambos modelos, y puedes revisar las redes RPC admitidas para planificar tu implementación.