¿Cómo manejan los proveedores de RPC de Solana la limitación de velocidad y los niveles de uso?

Solana RPC no es un solo producto con un solo conjunto de límites. Cada proveedor envuelve la misma superficie JSON-RPC en su propio modelo de limitación y luego vende el acceso en niveles. Si estás comparando proveedores, la pregunta útil no es "quién tiene el número más alto" sino "qué modelo de limitación se ajusta a cómo mi aplicación realmente envía tráfico".

Esta página explica cómo suele funcionar la limitación de velocidad en Solana RPC, qué controla normalmente un nivel de uso y cómo elegir entre un endpoint compartido y una infraestructura de nodo dedicado. Está escrita para desarrolladores y compradores de infraestructura que necesitan dimensionar un endpoint antes de lanzarlo.

Cómo decidir antes de comparar niveles

Antes de leer la tabla de niveles de cualquier proveedor, anota tres cosas sobre tu carga de trabajo: tus solicitudes máximas por segundo, la combinación de métodos que llamas y si necesitas suscripciones WebSocket. Esas tres respuestas eliminan la mayoría de los niveles de inmediato.

• Tráfico bajo y constante (una billetera, un panel, unos pocos miles de llamadas al día): un nivel compartido público o de entrada suele ser suficiente. Te importa más la disponibilidad de métodos que el rendimiento bruto.
• Tráfico en ráfagas (un mint, una ventana de reclamo, un bot que se activa con eventos): te importa la asignación de ráfagas y la rapidez con la que el proveedor te limita una vez que la superas.
• Tráfico pesado o continuo (indexadores, sistemas de trading, escaneos de getProgramAccounts, streaming de logs): los niveles compartidos tienden a convertirse en el cuello de botella. Aquí es donde los nodos dedicados o un endpoint privado suelen tener más sentido.

Si tu aplicación cae en el tercer grupo, la tabla de niveles es el documento equivocado para optimizar. Empieza por la capacidad y trata los niveles compartidos como una vía de respaldo.

Qué significa realmente "limitación de velocidad" en Solana RPC

Los proveedores rara vez aplican un solo número. En la práctica te encontrarás con varios tipos de límites a la vez, y el primero que alcances es el que define tu experiencia.

RPS es el número que más proveedores anuncian, pero en Solana el presupuesto estilo unidades de cómputo suele ser lo que realmente te detiene. Una sola llamada a getProgramAccounts con un filtro amplio puede costar más que cientos de llamadas a getSlot. Si solo comparas cifras de RPS, puedes elegir un nivel que parezca generoso y aun así verte limitado en tu primer escaneo de cuentas.

Leer un nivel de uso sin llevarte sorpresas

Un nivel de uso es un paquete de cuatro cosas: una asignación de velocidad, un conjunto de métodos, un conjunto de transportes y una capa de soporte o SLA. Los proveedores los presentan de forma diferente, pero las preguntas subyacentes son las mismas.

1. ¿La velocidad es un límite duro o uno blando? Los límites duros devuelven errores de inmediato. Los límites blandos pueden encolar o degradar la latencia primero.
2. ¿Qué métodos están excluidos? Las consultas de archivo, las llamadas estilo trace y los escaneos pesados de cuentas con frecuencia están restringidos a niveles superiores.
3. ¿Se incluye WebSocket? Las suscripciones se comportan de manera diferente a HTTP y a veces se miden por separado.
4. ¿Qué sucede en el límite? Un código de error claro es más fácil de manejar que un crecimiento silencioso de la latencia.

Cuando evalúes un nivel, pregunta por el comportamiento ante fallos, no solo por el techo. Un nivel que devuelve un 429 limpio del que puedes retroceder es más manejable que uno que ralentiza silenciosamente cada solicitud.

Endpoints compartidos vs nodos dedicados en Solana

Esta es la verdadera decisión detrás de la consulta. La limitación de velocidad existe porque la capacidad compartida es finita. La infraestructura dedicada cambia la forma del problema.

OnFinality ofrece ambos modelos para Solana: un endpoint RPC de Solana compartido para cargas de trabajo estándar, e infraestructura de nodo dedicado cuando necesitas capacidad reservada y control sobre tus propios límites. La elección correcta depende de si tu techo lo establece el grupo de otra persona o tu propio tráfico.

Probar un nivel con tu tráfico real

No dimensiones un nivel a partir de una tabla. Envía tráfico representativo y observa qué sucede en los bordes. Una sonda de carga breve contra el endpoint público te muestra la forma de la respuesta antes de comprometerte con un plan.

# Sonda simple de RPS contra el endpoint público de Solana de OnFinality
ENDPOINT="https://solana.api.onfinality.io/public"

for i in $(seq 1 50); do
  curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
    -X POST "$ENDPOINT" \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[]}'
done

Vigila tres señales: respuestas que no sean 200, aumento de time_total y cualquier objeto de error JSON-RPC en el cuerpo. Una ejecución limpia en tu pico esperado te dice que el nivel encaja. Los errores o el crecimiento de la latencia te indican que subas de nivel o pases a capacidad dedicada.

Para pruebas a nivel de método, sondea las llamadas de las que realmente dependes en lugar de solo getSlot:

// Comprueba si un método pesado está disponible en tu nivel
const endpoint = "https://solana.api.onfinality.io/public";

async function probe(method, params) {
  const res = await fetch(endpoint, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  const body = await res.json();
  console.log(method, res.status, body.error ?? "ok");
}

await probe("getSlot", []);
await probe("getVersion", []);

Si un método devuelve un error de método no encontrado o de límite de velocidad en tu nivel, eso es una frontera de nivel, no un error. Regístralo y tenlo en cuenta en tu plan.

Señales de fallo y qué significan

Cuando un endpoint RPC de Solana empieza a rechazar trabajo, el síntoma te dice qué límite alcanzaste.

Trata estas señales como entradas de diseño. Si tu aplicación activa regularmente el mismo límite, el nivel tiene la forma equivocada para la carga de trabajo, y ninguna cantidad de lógica de reintento arreglará el desajuste subyacente.

Diseñar en torno a los límites en lugar de luchar contra ellos

Los buenos clientes de Solana asumen que existen límites. Algunos hábitos reducen la frecuencia con la que los alcanzas:

• Agrupa donde la API lo permita. Las solicitudes por lotes JSON-RPC reducen los viajes de ida y vuelta y la presión sobre RPS.
• Cachea lo que no cambia. La altura del slot, la información de época y los datos estáticos de cuentas no necesitan una llamada por solicitud.
• Usa suscripciones WebSocket para cambios de estado en lugar de sondear en un bucle.
• Separa cargas de trabajo por clave. Mantén el tráfico del indexador alejado del tráfico orientado al usuario para que uno no deje sin recursos al otro.
• Añade un endpoint de respaldo. Un segundo proveedor o un nodo dedicado te da una vía cuando el primario limita.

Estos patrones son independientes del proveedor. También facilitan las comparaciones de niveles, porque comparas tu tráfico optimizado con cada nivel en lugar de tu ráfaga en el peor caso.

Conclusiones clave

• La limitación de velocidad de Solana RPC suele ser una mezcla de límites de RPS, presupuestos de unidades de cómputo, límites por método y límites de conexión, no un solo número.
• Un nivel de uso agrupa una asignación de velocidad, un conjunto de métodos, un conjunto de transportes y una capa de soporte; el comportamiento ante fallos importa tanto como el techo.
• Los métodos pesados como los escaneos de cuentas suelen ser la verdadera restricción, así que compara el soporte de métodos, no solo RPS.
• Los endpoints compartidos sirven para billeteras, paneles y aplicaciones moderadas; los nodos dedicados sirven para indexadores, sistemas de trading y backends continuos de alto volumen.
• Prueba un nivel con tráfico representativo y vigila los 429, el crecimiento de la latencia y los errores de método antes de comprometerte.
• OnFinality ofrece tanto un endpoint RPC de Solana compartido como opciones de nodo dedicado, con detalles sobre precios de RPC y redes RPC compatibles.

Preguntas frecuentes

¿Todos los proveedores de RPC de Solana limitan la velocidad de la misma manera? No. La mayoría combina límites de RPS con costos ponderados por método y límites de conexión, pero el modelo exacto y el punto en el que te limitan difieren. Compara el comportamiento ante fallos, no solo las cifras destacadas.

¿Un nivel de uso más alto es siempre la solución correcta? Solo si tu carga de trabajo encaja en un modelo compartido. Si ejecutas tráfico pesado continuo o escaneos de cuentas frecuentes, la capacidad dedicada suele encajar mejor que subir de nivel.

¿Cómo sé qué límite alcancé? Mira el síntoma. Los errores inmediatos en todas las llamadas suelen significar un límite de RPS. Los errores solo en métodos pesados apuntan a un presupuesto de cómputo o un límite por método. El crecimiento de la latencia sin errores sugiere una limitación blanda o contención compartida.

¿Puedo evitar por completo los límites de velocidad? Ningún endpoint es ilimitado. Puedes reducir la frecuencia con la que alcanzas los límites agrupando, cacheando, usando suscripciones WebSocket y separando cargas de trabajo, y puedes elevar tu techo con infraestructura dedicada.

¿OnFinality admite WebSocket de Solana? Sí. El endpoint de Solana admite transportes HTTP y WebSocket. Consulta la página de la red Solana para los detalles actuales del endpoint y precios de RPC para las opciones de plan.

Próximos pasos

Si todavía estás comparando proveedores, empieza con las preguntas sobre la carga de trabajo al principio de esta página y asigna tus respuestas a un nivel. Si tu tráfico es continuo o pesado en métodos, evalúa la capacidad de nodo dedicado en lugar de perseguir un nivel compartido más alto. Para detalles del endpoint, opciones de plan y la lista completa de redes, consulta Solana RPC, precios de RPC y redes RPC compatibles.