Chainstack vs QuickNode: Un método reproducible para elegir un proveedor de RPC

Qué prueba realmente una decisión Chainstack vs QuickNode

Ambos proveedores exponen JSON-RPC sobre HTTPS y WebSocket en un amplio conjunto de redes EVM y no EVM, y ambos ofrecen niveles de nodos compartidos y dedicados. Esa superposición significa que una lista de verificación de características generalmente terminará en un empate. La decisión se plantea mejor como una pregunta de ajuste a la carga de trabajo: ¿qué modelo de medición, huella regional y límites de plan del proveedor coinciden con el tráfico que realmente genera tu aplicación?

Este artículo es una metodología de medición, no un veredicto. Asume que ya tienes una red candidata, un conjunto representativo de métodos RPC y al menos un entorno de pruebas donde puedes apuntar un cliente a dos endpoints. Si solo necesitas una recomendación concreta de endpoint para una cadena específica, las guías de endpoints del Asistente RPC son el camino más rápido; vuelve aquí cuando necesites justificar la elección de un proveedor ante un equipo.

• Alcance: JSON-RPC de EVM más suscripciones WebSocket, con notas sobre métodos de archivo y traza.
• Fuera de alcance: contratos empresariales negociados, términos legales e historial de incidentes del proveedor.
• Suposición: puedes ejecutar scripts desde la misma máquina y región desde la que despliegas.

Requisitos previos y un entorno de pruebas limpio

Antes de comparar cualquier cosa, fija las variables. Usa una máquina cliente por región, la misma biblioteca HTTP, el mismo tiempo de espera y las mismas cargas útiles para ambos proveedores. Registra el nivel de plan para cada endpoint, porque un nivel gratuito y uno de pago no son comparables y producirán resultados engañosos de latencia y límite de velocidad.

Crea dos variables de entorno, una por proveedor, y nunca codifiques las claves en los scripts. Mantén una tercera variable para un endpoint de respaldo para que puedas probar la conmutación por error más adelante. Guarda los resultados sin procesar como JSON para que puedas recalcular los percentiles sin volver a ejecutar la prueba.

• Fija la versión del cliente y el sistema operativo para que las diferencias de latencia no sean artefactos de la biblioteca.
• Ejecuta cada sonda a la misma hora del día en al menos tres ventanas separadas.
• Registra el código de estado HTTP junto con la latencia; un 429 rápido no es un éxito rápido.

export CHAINSTACK_RPC_URL="https://your-chainstack-endpoint"
export QUICKNODE_RPC_URL="https://your-quicknode-endpoint"
export FALLBACK_RPC_URL="https://your-secondary-endpoint"
export TEST_ADDRESS="0x0000000000000000000000000000000000000000"

El modelo mental de medición: créditos, unidades de solicitud y peso del método

La mayor fuente de sorpresas en la factura en cualquier comparación de RPC es la ponderación de métodos. Los proveedores que miden con créditos o unidades de solicitud a menudo asignan diferentes pesos a diferentes métodos JSON-RPC: una simple consulta de número de bloque puede costar una unidad, mientras que eth_getLogs en un rango amplio o un debug_traceCall puede costar muchas. Un plan que parece más barato con una cuota nominal puede invertirse una vez que se aplica tu combinación real de métodos.

El enfoque práctico es construir una tabla de combinación de métodos a partir de tus propios registros. Para cada método que llames, registra el número de llamadas durante un período representativo y el peso publicado por el proveedor para ese método. Multiplica y suma para obtener unidades ponderadas por período, luego compara esa cifra con la cuota incluida y la tarifa de exceso de cada plan. Haz esto antes de ejecutar cualquier prueba de latencia, porque el endpoint más barato con poco volumen puede ser el incorrecto con volumen de producción.

El comportamiento documentado varía según el plan y puede cambiar, así que trata cualquier peso que leas como una instantánea con fecha. Vuelve a verificar los pesos cada vez que cambies el patrón de llamadas de tu aplicación, especialmente si agregas indexación, trazado o análisis con muchos registros.

• Cuenta llamadas por método, no llamadas totales; los promedios ocultan valores atípicos costosos.
• Separa los métodos de lectura intensiva (eth_call, eth_getLogs) de los métodos de traza y depuración.
• Modela un escenario de crecimiento de 2x y 5x para ver dónde las tarifas de exceso comienzan a dominar.

Construyendo un perfil de carga de trabajo a partir de tu propio tráfico

Si ya estás en producción, exporta una semana de recuentos de métodos RPC desde tu puerta de enlace o registros de cliente. Si estás antes del lanzamiento, estima a partir de las rutas de lectura de tu aplicación: con qué frecuencia cada página o trabajo llama a balance, logs, recibos y trazas. El objetivo es una tabla pequeña que puedas reutilizar para ambos proveedores.

El siguiente script resume un archivo JSON de recuentos de métodos en un total ponderado dado un mapa de pesos por método. Reemplaza el mapa de pesos con los valores publicados para cada plan de proveedor que estés evaluando y mantén las dos salidas una al lado de la otra.

• Ejecuta los mismos recuentos a través de los mapas de pesos de ambos proveedores.
• Marca cualquier método cuyo peso no hayas podido confirmar en la documentación.
• Mantén el archivo de recuentos sin procesar bajo control de versiones para que las comparaciones sean auditables.

import json, sys

# method_counts.json: {"eth_call": 120000, "eth_getLogs": 4000, ...}
with open("method_counts.json") as f:
    counts = json.load(f)

# Replace with weights published for the plan you are evaluating.
weights = {
    "eth_call": 1,
    "eth_getLogs": 10,
    "eth_getBlockByNumber": 1,
    "debug_traceCall": 50,
}

total = 0
for method, n in counts.items():
    w = weights.get(method, 1)
    total += n * w
    print(f"{method:28s} calls={n:>10d} weight={w:>3d} units={n*w:>12d}")
print(f"TOTAL WEIGHTED UNITS: {total}")

Sondas de latencia y confiabilidad que puedes repetir

Las comparaciones de latencia solo son significativas cuando la carga útil, la región y la concurrencia coinciden. Comienza con una sonda secuencial para establecer una línea base, luego agrega concurrencia para ver cómo se comporta cada endpoint bajo carga. Mide p50, p95 y p99 en lugar de la media, porque la latencia de cola es lo que sienten los usuarios durante la congestión.

El siguiente script de Python emite la misma llamada eth_blockNumber repetidamente contra ambos endpoints, registra códigos de estado y duraciones, e imprime percentiles. Ejecútalo desde la región donde están tus usuarios y repítelo para un método más pesado como eth_getLogs con un rango de bloques realista.

• Ejecuta al menos tres ventanas por proveedor y compara distribuciones, no ejecuciones individuales.
• Registra los fallos por separado; un 429 durante una ráfaga es una señal de capacidad.
• Repite desde una segunda región si tus usuarios están distribuidos geográficamente.

import os, time, json, statistics, urllib.request

def probe(url, method="eth_blockNumber", params=None, n=200):
    payload = json.dumps({"jsonrpc":"2.0","id":1,"method":method,"params":params or []}).encode()
    results = []
    for _ in range(n):
        req = urllib.request.Request(url, data=payload, headers={"Content-Type":"application/json"})
        start = time.perf_counter()
        try:
            with urllib.request.urlopen(req, timeout=10) as r:
                r.read()
                status = r.status
        except Exception as e:
            status = getattr(e, "code", "error")
        results.append((status, (time.perf_counter() - start) * 1000))
    ok = [ms for s, ms in results if s == 200]
    ok.sort()
    def pct(p):
        return ok[min(len(ok)-1, int(len(ok)*p))] if ok else None
    return {"success": len(ok), "total": n, "p50": pct(0.50), "p95": pct(0.95), "p99": pct(0.99)}

for name in ["CHAINSTACK_RPC_URL", "QUICKNODE_RPC_URL"]:
    print(name, probe(os.environ[name]))

Registrando resultados en una tabla comparativa

Captura cada ejecución en una tabla para que la decisión sea auditable y reproducible. La siguiente tabla es una plantilla; complétala con tus propios valores medidos en lugar de confiar en cualquier punto de referencia publicado. Mantén el nivel de plan y la fecha de prueba en la misma fila, porque ambos cambian con el tiempo.

Trata cualquier fila con una tasa de éxito por debajo de tu umbral como un candidato fallido independientemente de la latencia. Un proveedor que devuelve errores rápidos no es más rápido que uno que devuelve datos correctos un poco más tarde.

Verificando la profundidad de archivo, el soporte de trazas y el comportamiento de WebSocket

El acceso a archivo y depuración son las características con más probabilidades de diferir entre niveles de plan, y son las más fáciles de verificar con una sola llamada. Consulta un bloque histórico muy fuera de la ventana reciente y confirma que la respuesta contiene estado en lugar de un error de datos podados. Luego intenta un método de traza o depuración y registra si tiene éxito, devuelve un error de método no soportado o está limitado por velocidad.

Para WebSocket, suscríbete a nuevos encabezados y mide la brecha entre la marca de tiempo del bloque y el momento en que tu cliente recibe la notificación. Desconéctate y reconéctate deliberadamente para ver cómo cada endpoint maneja la resuscripción. Si tu aplicación depende de datos en tiempo real, esta prueba importa más que la latencia HTTP.

• Un error de estado podado en un bloque histórico significa que el acceso a archivo no está incluido en ese nivel.
• Un error de método no soportado en debug_traceCall es una brecha de capacidad, no un problema de latencia.
• Para WebSocket, registra el tiempo de reconexión y si las suscripciones se reanudan automáticamente.

curl -s -X POST "$CHAINSTACK_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["'"$TEST_ADDRESS"'","0x1"]}'

curl -s -X POST "$QUICKNODE_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"debug_traceCall","params":[{"to":"'"$TEST_ADDRESS"'","data":"0x"},"latest",{}]}'

Comportamiento de conmutación por error y límite de velocidad bajo ráfaga

La confiabilidad en producción depende menos de la latencia en estado estacionario que de lo que sucede cuando superas un límite. Envía una ráfaga corta por encima de tu pico esperado y observa la respuesta: un 429 con un encabezado Retry-After es recuperable, mientras que un tiempo de espera silencioso o un restablecimiento de conexión es más difícil de manejar. Luego prueba la ruta de conmutación por error de tu cliente apuntándolo a un endpoint primario y de respaldo y forzando el fallo del primario.

Un patrón simple es una lista de endpoints en round-robin o por prioridad con una verificación de estado. La siguiente configuración muestra una lista de prioridad con un tiempo de espera y un reintento, que puedes adaptar a tu biblioteca de cliente. Mantén el respaldo en un proveedor diferente para que un incidente de un solo proveedor no derribe ambas rutas.

• Registra qué proveedor atendió cada solicitud para que puedas atribuir incidentes.
• Establece un tiempo de espera más corto que tu presupuesto de SLA de cara al usuario.
• Prueba la conmutación por error durante una ráfaga real, no solo en estado estacionario.

const endpoints = [
  { name: "primary", url: process.env.CHAINSTACK_RPC_URL },
  { name: "secondary", url: process.env.QUICKNODE_RPC_URL },
  { name: "fallback", url: process.env.FALLBACK_RPC_URL },
];

async function rpc(method, params) {
  for (const ep of endpoints) {
    try {
      const res = await fetch(ep.url, {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
        signal: AbortSignal.timeout(3000),
      });
      if (!res.ok) continue;
      const body = await res.json();
      if (body.error) continue;
      return { provider: ep.name, result: body.result };
    } catch (e) {
      // try next endpoint
    }
  }
  throw new Error("all endpoints failed");
}

Traduciendo las mediciones en una decisión de costo y riesgo

Una vez que tengas unidades ponderadas, percentiles de latencia, resultados de capacidad y comportamiento de conmutación por error, combínalos en una matriz de decisión. Pondera cada dimensión según cuánto importa a tu aplicación: un bot de trading puede ponderar mucho la latencia p99, mientras que un indexador de análisis puede ponderar el costo de consulta de registros y la profundidad de archivo. Multiplica tus unidades ponderadas por la tarifa de exceso de cada plan para estimar el costo mensual con tu volumen actual y proyectado.

No colapses la decisión en una sola puntuación sin registrar las entradas. Cuando un proveedor cambie los precios o tú cambies tu combinación de métodos, querrás volver a ejecutar el modelo en lugar de rehacer la investigación. Para equipos que estandarizan en una plataforma en muchas cadenas, la guía de endpoints multicadena y el directorio de redes ayudan a confirmar la cobertura de cadenas antes de comprometerte.

• Costo = costo de cuota incluida + (unidades ponderadas más allá de la cuota × tarifa de exceso).
• Riesgo = exposición a incidentes × calidad de conmutación por error × brechas de capacidad.
• Vuelve a ejecutar el modelo trimestralmente o cada vez que tu combinación de métodos cambie materialmente.

Solución de errores comunes en comparaciones

La mayoría de las malas comparaciones de proveedores provienen de condiciones no coincidentes en lugar de diferencias reales de rendimiento. La siguiente lista cubre los fallos que vemos con más frecuencia cuando los equipos comparan endpoints RPC.

Si una sonda devuelve errores en un proveedor pero no en el otro, verifica el nivel de plan y el soporte de métodos antes de concluir que hay una brecha de rendimiento. Si la latencia parece increíblemente baja, confirma que la respuesta realmente contenía datos y no fue una respuesta en caché o de error. Si las pruebas de WebSocket son inestables, verifica que tu cliente maneje ping/pong y la resuscripción, ya que algunas bibliotecas eliminan silenciosamente las suscripciones después de una reconexión.

• Comparar un nivel gratuito con un nivel de pago.
• Probar desde un portátil en una red diferente a la de producción.
• Ignorar los pesos de los métodos al comparar cuotas nominales.
• Medir solo la media y perder la latencia de cola.
• Asumir que el acceso a archivo o traza está incluido sin probarlo.
• Conmutar por error a un segundo endpoint en el mismo proveedor.

Limitaciones y próximos pasos

Este método mide lo que puedes observar desde tu propio cliente: latencia, tasa de éxito, capacidad y costo modelado. No puede capturar el historial de incidentes del proveedor, la capacidad de respuesta del soporte ni los términos contractuales, que debes evaluar por separado. Los pesos publicados y los límites de los planes cambian, por lo que cualquier comparación tiene una vida útil; fecha tus resultados y revísalos.

Un siguiente paso práctico es ejecutar los scripts de sonda contra tu carga de trabajo de pruebas durante una semana, completar la tabla comparativa y revisar el resultado con el equipo propietario de la aplicación. Si necesitas capacidad dedicada o rendimiento predecible para una cadena específica, revisa las opciones de nodo dedicado y la estructura de precios de RPC junto con tus unidades medidas. Para equipos que quieren un endpoint gestionado sin realizar la comparación ellos mismos, la descripción general del servicio API describe cómo se aprovisionan y escalan los endpoints.

• Ejecuta el perfil de carga de trabajo y las sondas de latencia durante al menos una semana.
• Completa la tabla comparativa con valores medidos y una fecha de prueba.
• Vuelve a verificar los pesos de los métodos y los límites de los planes antes de firmar un contrato.
• Mantén un respaldo entre proveedores en producción independientemente del ganador.