Latencia de RPC de Hyperliquid: Medición, HyperEVM vs API Nativa y Ajuste de Baja Latencia

Respuesta directa: la latencia de RPC de Hyperliquid depende de la API que uses

Si te preguntas sobre la latencia de RPC de Hyperliquid, lo primero que debes saber es que Hyperliquid expone dos APIs muy diferentes: la API nativa de L1 (REST y WebSocket) para datos de mercado y trading, y el JSON-RPC de HyperEVM para el lado EVM. La API nativa está diseñada para trading de baja latencia y puede lograr tiempos de ida y vuelta inferiores a 10 ms desde un nodo geográficamente cercano, mientras que el RPC de HyperEVM es un endpoint estándar compatible con Ethereum con mayor latencia y límites de tasa más estrictos. Esta guía te muestra cómo medir ambos, comprender los factores que dominan la latencia y ajustar tu configuración para la menor latencia posible.

Para trading de baja latencia, los feeds de WebSocket nativos (allMids, l2Book) son la opción principal, ya que envían actualizaciones en tiempo real sin la sobrecarga del sondeo. En contraste, el RPC de HyperEVM es mejor para lecturas de estado ocasionales o interacciones con contratos, donde la latencia es menos crítica. El RPC público de HyperEVM tiene un límite de tasa de aproximadamente 100 solicitudes por minuto por IP (documentado por los proveedores), lo que puede causar solicitudes caídas o estancadas si lo excedes, afectando directamente la latencia percibida.

• API nativa de L1: REST y WebSocket de baja latencia para datos de mercado y trading.
• RPC de HyperEVM: JSON-RPC estándar para estado y transacciones EVM, mayor latencia.
• Límites de tasa: RPC público de HyperEVM ~100 req/min por IP (documentado por el proveedor).
• La proximidad geográfica es el factor dominante para la latencia de la API nativa.
• La documentación de Hyperliquid define la API nativa info/exchange y los métodos RPC de HyperEVM que respaldan estas características de latencia; consulta docs de Hyperliquid para la referencia autorizada de endpoints y métodos.

Arquitectura: por qué dos pilas tienen diferentes perfiles de latencia

El núcleo de Hyperliquid es una cadena de bloques L1 personalizada optimizada para el trading de libros de órdenes. La API nativa (endpoints de información e intercambio) está estrechamente integrada con el consenso y el motor de coincidencia, lo que permite lecturas y escrituras de latencia extremadamente baja. Los feeds de WebSocket envían actualizaciones tan pronto como se procesan, a menudo en milisegundos. En contraste, HyperEVM es un entorno de ejecución separado que se ejecuta junto a L1, proporcionando compatibilidad con Ethereum. Las llamadas JSON-RPC de EVM implican capas adicionales de abstracción y generalmente son atendidas por nodos que pueden estar menos optimizados para la velocidad.

La ruta de red también difiere. Para la API nativa, las conexiones más rápidas provienen de nodos geográficamente cercanos al conjunto de validadores de Hyperliquid, que se concentra en regiones específicas. Para HyperEVM, la latencia depende más de la infraestructura del proveedor y la distancia a sus nodos. Además, el RPC de HyperEVM se usa a menudo para consultas de archivo, que requieren leer el estado histórico y pueden ser significativamente más lentas que las lecturas de estado actual.

El comportamiento de tasa también difiere. La API nativa tiene límites de tasa más altos (documentados en la guía de límites de tasa de API de Hyperliquid), mientras que el RPC público de HyperEVM es más restrictivo. Esto significa que en el lado EVM, puedes experimentar picos de latencia debido a la limitación de tasa, que no es un problema de latencia de red sino de limitación de solicitudes.

• API nativa: optimizada para baja latencia, push de WebSocket.
• HyperEVM: JSON-RPC estándar, mayor sobrecarga, lecturas de archivo más lentas.
• Límites de tasa: API nativa más alta, HyperEVM ~100 req/min por IP.
• La proximidad geográfica importa más para la API nativa.

Medición de latencia: un script reproducible

Para medir la latencia tú mismo, puedes usar el siguiente script de Node.js. Mide el tiempo de ida y vuelta (RTT) para una llamada REST nativa (endpoint de información), una llamada JSON-RPC de HyperEVM (eth_blockNumber) y una sonda de latencia de suscripción WebSocket. El script usa los endpoints públicos, pero puedes reemplazarlos con los endpoints de tu proveedor. Ten en cuenta que este es un método de medición, no un benchmark de proveedor; los resultados variarán según tu ubicación, red y proveedor.

El script envía múltiples solicitudes y calcula la latencia promedio, mínima y máxima. Para la sonda WebSocket, mide el tiempo entre enviar una suscripción y recibir el primer mensaje. Ejecútalo desde una ubicación cercana a la infraestructura de Hyperliquid para obtener los mejores resultados.

• Usa el script para medir RTT para REST, JSON-RPC y WebSocket.
• Reemplaza los endpoints con los de tu proveedor.
• Ejecuta varias veces para obtener un promedio estable.
• Registra los resultados en la tabla a continuación.

const https = require('https');
const WebSocket = require('ws');

const NATIVE_REST_URL = 'https://api.hyperliquid.xyz/info';
const EVM_RPC_URL = 'https://api.hyperliquid.xyz/evm';
const WS_URL = 'wss://api.hyperliquid.xyz/ws';

function measureRest() {
  return new Promise((resolve) => {
    const start = process.hrtime.bigint();
    const data = JSON.stringify({ type: 'meta' });
    const req = https.request(NATIVE_REST_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' }
    }, (res) => {
      res.on('data', () => {});
      res.on('end', () => {
        const end = process.hrtime.bigint();
        resolve(Number(end - start) / 1e6); // ms
      });
    });
    req.on('error', () => resolve(-1));
    req.write(data);
    req.end();
  });
}

function measureEvm() {
  return new Promise((resolve) => {
    const start = process.hrtime.bigint();
    const body = JSON.stringify({ jsonrpc: '2.0', method: 'eth_blockNumber', params: [], id: 1 });
    const req = https.request(EVM_RPC_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' }
    }, (res) => {
      res.on('data', () => {});
      res.on('end', () => {
        const end = process.hrtime.bigint();
        resolve(Number(end - start) / 1e6);
      });
    });
    req.on('error', () => resolve(-1));
    req.write(body);
    req.end();
  });
}

function measureWs() {
  return new Promise((resolve) => {
    const start = process.hrtime.bigint();
    const ws = new WebSocket(WS_URL);
    ws.on('open', () => {
      ws.send(JSON.stringify({ method: 'subscribe', subscription: { type: 'allMids' } }));
    });
    ws.on('message', () => {
      const end = process.hrtime.bigint();
      ws.close();
      resolve(Number(end - start) / 1e6);
    });
    ws.on('error', () => resolve(-1));
  });
}

async function main() {
  const restTimes = [];
  const evmTimes = [];
  const wsTimes = [];
  for (let i = 0; i < 5; i++) {
    restTimes.push(await measureRest());
    evmTimes.push(await measureEvm());
    wsTimes.push(await measureWs());
  }
  const avg = (arr) => arr.reduce((a, b) => a + b, 0) / arr.length;
  console.log('Native REST (info) latency (ms):');
  console.log('  avg:', avg(restTimes).toFixed(2), 'min:', Math.min(...restTimes).toFixed(2), 'max:', Math.max(...restTimes).toFixed(2));
  console.log('HyperEVM eth_blockNumber latency (ms):');
  console.log('  avg:', avg(evmTimes).toFixed(2), 'min:', Math.min(...evmTimes).toFixed(2), 'max:', Math.max(...evmTimes).toFixed(2));
  console.log('WebSocket allMids first message latency (ms):');
  console.log('  avg:', avg(wsTimes).toFixed(2), 'min:', Math.min(...wsTimes).toFixed(2), 'max:', Math.max(...wsTimes).toFixed(2));
}

main();

Salida esperada y tabla de resultados

El script generará algo como lo siguiente (los valores son ejemplos, no benchmarks):

Completa la tabla a continuación con tus propios resultados. Este es un método de medición, no un benchmark de proveedor. Para números específicos de proveedores, consulta fuentes independientes como la guía de Dwellir o la comparación de hyperpc, que tienen sus propias metodologías.

• Latencia de REST nativo (info) (ms): promedio: 12.34, mín: 10.11, máx: 15.67
• Latencia de HyperEVM eth_blockNumber (ms): promedio: 45.67, mín: 40.23, máx: 52.10
• Latencia del primer mensaje de WebSocket allMids (ms): promedio: 8.90, mín: 7.12, máx: 11.45

| Endpoint | Promedio (ms) | Mín (ms) | Máx (ms) |
|----------|----------|----------|----------|
| REST nativo (info) | | | |
| HyperEVM eth_blockNumber | | | |
| WebSocket allMids | | | |

Fallos comunes y soluciones

Al medir o usar RPC de Hyperliquid, puedes encontrar varios problemas comunes. Aquí están los más frecuentes y cómo solucionarlos.

Limitación de tasa en el RPC de HyperEVM: El endpoint público permite alrededor de 100 solicitudes por minuto por IP. Si excedes esto, obtendrás respuestas HTTP 429 o conexiones caídas. Solución: implementa limitación de tasa en el cliente, usa un endpoint dedicado de un proveedor o agrupa solicitudes. Consulta la guía de límites de tasa de API de Hyperliquid para más detalles.

Desconexiones de WebSocket: El WebSocket nativo puede desconectarse si no envías un ping dentro de un cierto intervalo. Solución: implementa un mecanismo de heartbeat. La guía de suscripciones WebSocket de Hyperliquid cubre esto.

Alta latencia debido a la distancia geográfica: Si estás lejos de la infraestructura de Hyperliquid, la latencia será mayor. Solución: usa un proveedor geo-distribuido o ejecuta tu propio nodo en una región cercana a los validadores. Para trading de baja latencia, considera un endpoint dedicado como HypeRPC, que está optimizado para velocidad.

Lecturas de nodo de archivo en HyperEVM: Leer el estado histórico puede ser lento. Solución: usa un proveedor que ofrezca nodos de archivo o almacena en caché los datos de acceso frecuente.

• Limitación de tasa: implementa backoff y reintentos, o usa un endpoint dedicado.
• Timeouts de WebSocket: envía pings regularmente.
• Distancia geográfica: elige un proveedor con nodos cerca de los validadores de Hyperliquid.
• Lecturas de archivo: usa un proveedor con nodos de archivo o caché.

Ajuste de baja latencia: mejores prácticas

Para lograr la menor latencia posible para el trading de Hyperliquid, sigue estas mejores prácticas:

Primero, prefiere los feeds de WebSocket nativos para datos de mercado en tiempo real. Las suscripciones allMids y l2Book envían actualizaciones tan pronto como están disponibles, eliminando la necesidad de sondeo. El sondeo de la API REST agrega al menos un tiempo de ida y vuelta y puede perder actualizaciones entre sondeos.

Segundo, en el lado de HyperEVM, agrupa las solicitudes JSON-RPC para reducir el número de idas y vueltas. Por ejemplo, en lugar de llamar a eth_getBalance para múltiples direcciones, usa eth_getProof o un lote personalizado. Además, almacena en caché las lecturas de estado que no cambian con frecuencia, como decimales de tokens o metadatos de contratos.

Tercero, establece timeouts explícitos en todas las conexiones HTTP y WebSocket. Esto evita que las solicitudes se cuelguen y te permite fallar rápido y reintentar. Usa una biblioteca como axios con una opción de timeout, o establece el timeout en tu cliente WebSocket.

Cuarto, usa un endpoint geo-distribuido o dedicado. Para trading de baja latencia, considera un proveedor como HypeRPC, que está específicamente diseñado para acceso de baja latencia a Hyperliquid. Alternativamente, ejecuta tu propio nodo en una región cercana a los validadores de Hyperliquid. La página de endpoints RPC de Hyperliquid (Asistente RPC) lista los endpoints disponibles.

Finalmente, monitorea tu latencia continuamente. Usa el script de medición anterior como línea base y rastrea los cambios a lo largo del tiempo. Esto te ayuda a detectar problemas temprano y ajustar tu configuración.

• Usa feeds de WebSocket nativos para datos en tiempo real.
• Agrupa JSON-RPC en el lado EVM.
• Almacena en caché las lecturas de estado.
• Establece timeouts explícitos.
• Usa un endpoint geo-distribuido o dedicado.
• Monitorea la latencia regularmente.

Compensaciones y limitaciones

Si bien la API nativa ofrece menor latencia, tiene limitaciones. Los feeds de WebSocket no están autenticados y pueden tener mayor latencia durante cargas altas. La API REST tiene límites de tasa, aunque son más altos que el RPC de EVM. Para HyperEVM, la limitación principal es el límite de tasa y la falta de garantías de baja latencia.

Otra compensación es la complejidad de ejecutar tu propio nodo. Si bien te da la menor latencia, requiere infraestructura y mantenimiento significativos. Usar un proveedor de terceros como Dwellir o hyperpc es más fácil pero introduce sobrecarga de red.

También ten en cuenta que el límite de tasa del RPC público de HyperEVM es de aproximadamente 100 req/min por IP, documentado por los proveedores. Esto puede ser un cuello de botella para aplicaciones que necesitan lecturas de estado frecuentes. En tales casos, considera usar un endpoint dedicado o un proveedor que ofrezca límites más altos.

Finalmente, las mediciones de latencia dependen en gran medida de tu ruta de red y la infraestructura del proveedor. Los números que obtienes del script son específicos de tu entorno y no deben compararse directamente con benchmarks de proveedores. Siempre consulta fuentes independientes para comparaciones de proveedores.

• API nativa: menor latencia pero límites de tasa y posibles problemas de carga.
• HyperEVM: mayor latencia y límites de tasa estrictos.
• Ejecutar tu propio nodo: menor latencia pero alto mantenimiento.
• Proveedores de terceros: más fáciles pero agregan sobrecarga de red.
• Las mediciones son específicas del entorno.

Próximos pasos

Ahora que entiendes cómo medir y ajustar la latencia de RPC de Hyperliquid, puedes aplicar estas técnicas a tus propias aplicaciones. Para más detalles, explora los siguientes recursos:

Consulta la descripción general de la red Hyperliquid para información general. Para una inmersión más profunda en los límites de tasa, consulta la guía de límites de tasa de API de Hyperliquid. Si usas WebSockets, la guía de suscripciones WebSocket de Hyperliquid es esencial. También puedes explorar el centro de aprendizaje de OnFinality para más guías. Para precios de endpoints dedicados, consulta precios de RPC y el servicio de API. Finalmente, la página de endpoints RPC de Hyperliquid (Asistente RPC) lista todos los endpoints disponibles.

• Descripción general de la red Hyperliquid
• Guía de límites de tasa de API de Hyperliquid
• Guía de suscripciones WebSocket de Hyperliquid
• Centro de aprendizaje de OnFinality
• Precios de RPC
• Servicio de API
• Endpoints RPC de Hyperliquid (Asistente RPC)