Ejecutar un nodo de archivo de Hyperliquid: historial, almacenamiento y acceso a consultas

Superficies de datos y roles de nodo en Hyperliquid

Hyperliquid es una L1 creada específicamente y compuesta por HyperCore y HyperEVM, y sus superficies de datos públicas incluyen una API JSON-RPC/REST para el estado en vivo, un WebSocket para transmisión y exportaciones tipo archivo/archivos planos para historial masivo. La documentación de Hyperliquid describe nodos, superficies de API y acceso a datos, y es el punto de partida autorizado para entender qué superficie sirve cada tipo de dato.

Un nodo completo mantiene el estado reciente y está optimizado para validar y servir la punta actual de la cadena. Un nodo de archivo conserva el historial completo del libro mayor, las transacciones y, cuando corresponde, el estado necesario para backtests profundos y lecturas en un punto concreto. La distinción importa porque un nodo podado devolverá un error o un resultado vacío para una consulta de estado histórico que un nodo de archivo responde con un valor no nulo.

Antes de elegir un modelo operativo, asigna tu carga de trabajo a la superficie correcta. El trading en vivo y la monitorización pertenecen a las superficies JSON-RPC/REST y WebSocket, mientras que el análisis masivo sin conexión y los backtests pertenecen a las exportaciones de archivo/archivos planos o a un nodo de archivo. La página Endpoints RPC de Hyperliquid (RPC Assistant) enumera opciones de endpoint, y el artículo API de datos históricos de mercado de Hyperliquid cubre la superficie de la API de datos para historial específico de mercado.

• API JSON-RPC/REST: estado en vivo, envío de transacciones y consultas de bloques recientes.
• WebSocket: actualizaciones en streaming para aplicaciones en tiempo real.
• Exportaciones de archivo/archivos planos: historial masivo para procesamiento sin conexión, no consultas en vivo.
• Nodo de archivo: historial completo del libro mayor y del estado servido a través de JSON-RPC para lecturas en un punto concreto.

Tres formas de obtener historial profundo de Hyperliquid

La primera opción es ejecutar tú mismo un nodo de archivo para tener control total y los datos más recientes. Esto te proporciona un endpoint privado que puede servir consultas de estado histórico y te mantiene independiente de los límites de tasa de terceros, pero requiere un almacenamiento, RAM, CPU y ancho de banda significativos, y es más lento de sincronizar que un nodo completo.

La segunda opción es consumir una exportación de archivo/archivos planos desde almacenamiento de objetos para procesamiento masivo sin conexión. Esto es eficiente para backtests grandes porque lees archivos directamente sin ejecutar un nodo, pero las exportaciones solo están tan actualizadas como la última exportación y no pueden servir la punta de la cadena ni responder consultas en vivo.

La tercera opción es consultar a un proveedor que exponga el estado histórico a través de JSON-RPC para lecturas en un punto concreto. Esto evita operar infraestructura con gran consumo de almacenamiento, pero el rango de archivo exacto y la superficie de consulta dependen del proveedor. Compara estos modelos con las ventajas y desventajas en Nodo de archivo vs nodo completo y los métodos en Acceder a datos históricos de blockchain.

• Nodo de archivo autoalojado: control total, datos más recientes, mayor coste operativo.
• Exportación de archivo/archivos planos: procesamiento masivo sin conexión, sin consultas en vivo, actualidad limitada por la cadencia de exportación.
• JSON-RPC histórico alojado por proveedor: lecturas en un punto concreto sin operaciones de almacenamiento, el rango varía según el proveedor.

Dimensiones de recursos para un nodo de archivo

El almacenamiento crece con la retención, así que planifica a partir del crecimiento observado del libro mayor multiplicado por tu ventana objetivo. Mide la tasa de crecimiento en un nodo completo o a partir de metadatos de exportación, y luego proyecta el almacenamiento necesario para el rango de archivo que necesitas. No asumas un tamaño fijo; el requisito depende de la actividad de la cadena y de tu política de retención.

La RAM la consumen el estado y los índices, y la CPU la consumen la ejecución y el servicio de consultas. El ancho de banda lo consumen la ingesta y las consultas de los clientes. Como estas dimensiones interactúan, un nodo adecuado para el estado reciente puede quedarse corto para servir archivos, especialmente cuando se ejecutan muchas consultas históricas de forma concurrente.

Un método práctico de planificación es registrar el almacenamiento usado en dos momentos, calcular la diferencia y extrapolar. La tabla de resultados que aparece más adelante en este artículo proporciona columnas para el almacenamiento usado y la ventana de retención, de modo que puedas hacer seguimiento con tu propio endpoint.

• Almacenamiento: ventana de retención x tasa de crecimiento observada del libro mayor.
• RAM: huella del estado y los índices, que crece con el historial.
• CPU: ejecución y servicio de consultas bajo carga concurrente.
• Ancho de banda: ingesta más tráfico de consultas de clientes.

Verificar que un nodo de archivo sirve el historial

Para verificar la disponibilidad del archivo, emite una consulta de estado histórico para un bloque o hash antiguo conocido y confirma un resultado no nulo. La especificación JSON-RPC de Ethereum en ethereum.org documenta el patrón de consulta de estado archivado que sirve un nodo de archivo, y la especificación JSON-RPC 2.0 en jsonrpc.org define la forma de la solicitud utilizada para sondear la disponibilidad del archivo.

Contrasta la respuesta del archivo con un nodo podado, que devuelve un error o un resultado vacío para la misma consulta. Un resultado histórico no nulo es evidencia de que el nodo conserva el estado para ese bloque, mientras que un error como un nodo trie faltante o un resultado vacío indica que el estado no está disponible.

Como el comportamiento específico del proveedor varía, trata la sonda como una prueba reproducible en lugar de una garantía. Ejecútala contra tu propio endpoint y registra el resultado en la tabla de resultados.

• Nodo de archivo: la consulta de estado histórico devuelve un resultado no nulo.
• Nodo podado: la misma consulta devuelve un error o un resultado vacío.
• Comportamiento del proveedor: documentado / varía según el proveedor, así que verifica por endpoint.

Sondear la disponibilidad histórica con curl

El siguiente ejemplo de curl envía un POST JSON-RPC para un bloque antiguo y una lectura de estado en un punto concreto, e imprime PASS si se sirve el rango de archivo. Reemplaza el endpoint y el número de bloque con valores para tu cadena y nodo objetivo.

Ejecútalo contra un endpoint de archivo conocido y un endpoint podado conocido para observar la diferencia. El script comprueba si hay un resultado no nulo y sale con un estado claro.

#!/usr/bin/env bash
set -euo pipefail

ENDPOINT="${1:-http://127.0.0.1:8545}"
BLOCK="${2:-1000000}"

block_resp=$(curl -s -X POST "$ENDPOINT" \
  -H 'Content-Type: application/json' \
  -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_getBlockByNumber\",\"params\":[\"0x$(printf '%x' "$BLOCK")\", false]}")

echo "Block response: $block_resp"

if echo "$block_resp" | grep -q '"result":null'; then
  echo "FAIL: block $BLOCK not available (pruned or out of range)"
  exit 1
fi

state_resp=$(curl -s -X POST "$ENDPOINT" \
  -H 'Content-Type: application/json' \
  -d "{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"eth_getBalance\",\"params\":[\"0x0000000000000000000000000000000000000000\",\"0x$(printf '%x' "$BLOCK")\"]}")

echo "State response: $state_resp"

if echo "$state_resp" | grep -q '"result":null'; then
  echo "FAIL: historical state at block $BLOCK not available"
  exit 1
fi

echo "PASS: archive range served for block $BLOCK"

Sondear la disponibilidad histórica con Node.js

Este ejemplo de Node.js realiza la misma sonda usando fetch, que está disponible en los runtimes modernos de Node.js. Comprueba un bloque antiguo y una lectura de estado en un punto concreto, y luego imprime PASS o FAIL.

Úsalo como una comprobación repetible en tu monitorización o canal de CI. Ajusta el número de bloque a la altura más antigua que esperas que sirva tu archivo.

const endpoint = process.env.ENDPOINT || 'http://127.0.0.1:8545';
const blockNumber = Number(process.env.BLOCK || 1000000);
const blockHex = '0x' + blockNumber.toString(16);

async function rpc(method, params) {
  const res = await fetch(endpoint, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
  });
  return res.json();
}

(async () => {
  const block = await rpc('eth_getBlockByNumber', [blockHex, false]);
  console.log('Block response:', JSON.stringify(block));
  if (!block.result) {
    console.error(`FAIL: block ${blockNumber} not available`);
    process.exit(1);
  }

  const state = await rpc('eth_getBalance', ['0x0000000000000000000000000000000000000000', blockHex]);
  console.log('State response:', JSON.stringify(state));
  if (!state.result) {
    console.error(`FAIL: historical state at block ${blockNumber} not available`);
    process.exit(1);
  }

  console.log(`PASS: archive range served for block ${blockNumber}`);
})();

Tabla de resultados reproducible para tu endpoint

Usa la tabla a continuación para registrar mediciones contra tu propio endpoint. Rellénala ejecutando las sondas anteriores y anotando los resultados. Esto mantiene tu evaluación reproducible y comparable entre proveedores o configuraciones de nodo.

Las columnas capturan el bloque o altura objetivo, el endpoint, el método utilizado, si hubo un resultado, el bloque más antiguo disponible, el almacenamiento usado y la ventana de retención. Como el comportamiento específico del proveedor varía, tu tabla rellenada es el registro autorizado para tu entorno.

• Bloque/altura objetivo: el punto histórico que consultaste.
• Endpoint: la URL JSON-RPC que probaste.
• Método: el método JSON-RPC utilizado, como eth_getBlockByNumber o eth_getBalance.
• ¿Resultado presente?: sí o no, según un resultado no nulo.
• Bloque más antiguo disponible: el bloque más antiguo que sirve el endpoint.
• Almacenamiento usado: disco consumido por tu nodo o conjunto de datos.
• Ventana de retención: el rango de tiempo o de bloques retenido.

Limitaciones y compensaciones de la infraestructura de archivo

El rango de archivo exacto y la superficie de consulta dependen del proveedor o de la configuración de tu nodo, por lo que una sonda que pasa para un bloque no garantiza que todo el historial esté disponible. Los nodos de archivo consumen mucho almacenamiento y son más lentos de sincronizar que los nodos completos, lo que afecta al tiempo y al coste de despliegue.

Las exportaciones de archivos planos solo están tan actualizadas como la última exportación y no pueden servir la punta de la cadena, por lo que no son adecuadas para consultas en vivo. Los datos específicos de Hyperliquid, como el historial de financiación y del libro de órdenes, pueden residir en la API de datos de mercado en lugar del propio nodo, lo que significa que un nodo de archivo por sí solo puede no cubrir todas las necesidades analíticas.

Planifica estas restricciones combinando superficies: usa un nodo de archivo o un proveedor para lecturas de estado en un punto concreto, exportaciones de archivos planos para procesamiento masivo sin conexión y la API de datos de mercado para historial específico de mercado. El artículo API de datos históricos de mercado de Hyperliquid detalla esa última superficie.

• Rango de archivo y superficie de consulta: documentado / varía según el proveedor.
• Nodos de archivo: consumen mucho almacenamiento y son más lentos de sincronizar.
• Exportaciones de archivos planos: actualidad limitada por la cadencia de exportación, sin punta de cadena.
• Historial específico de mercado: puede requerir la API de datos de mercado, no el nodo.

Solución de problemas de fallos en consultas de archivo

Cuando falla una consulta histórica, primero confirma que el número de bloque está dentro del rango de archivo. Un resultado null o un error como un nodo trie faltante normalmente significa que el nodo está podado o que el bloque es anterior al rango retenido. Vuelve a ejecutar la sonda contra un endpoint de archivo conocido para aislar si el problema es el endpoint o la consulta.

Si el endpoint es correcto pero las consultas son lentas, comprueba la presión de recursos. El almacenamiento, la RAM, la CPU y el ancho de banda interactúan, y las consultas históricas concurrentes pueden saturar un nodo que maneja cómodamente el estado reciente. Reduce la concurrencia o escala los recursos, y luego vuelve a medir.

Para endpoints alojados por proveedores, revisa el rango de archivo documentado y los posibles límites de tasa. Como el comportamiento específico del proveedor varía, verifica con la sonda en lugar de asumir cobertura. El artículo Latencia RPC de Hyperliquid cubre consideraciones de latencia que afectan al rendimiento de las consultas.

• Null o nodo trie faltante: bloque fuera del rango retenido o nodo podado.
• Consultas lentas: presión de recursos o saturación por concurrencia.
• Endpoints de proveedor: comprueba el rango de archivo documentado y los límites de tasa.
• Aislamiento: prueba la misma consulta contra un endpoint de archivo conocido.

Próximos pasos para operar infraestructura de archivo

Empieza definiendo tu ventana de retención y las consultas históricas que necesitas, y luego elige entre un nodo de archivo autoalojado, exportaciones de archivos planos o un endpoint JSON-RPC histórico alojado por un proveedor. Usa las sondas de este artículo para verificar la disponibilidad y rellenar la tabla de resultados para tu entorno.

Si prefieres no operar infraestructura con gran consumo de almacenamiento, revisa Precios de RPC y el Servicio de API para opciones gestionadas, y explora la página de la red Hyperliquid para detalles específicos de la red. El centro de aprendizaje de OnFinality recopila guías relacionadas, incluidas Nodo de archivo vs nodo completo y Acceder a datos históricos de blockchain.

Por último, mantén tu verificación reproducible. Vuelve a ejecutar las sondas después de cambios de configuración, migraciones de proveedor o ajustes de retención, y actualiza la tabla de resultados para que tu cobertura de archivo siga documentada y sea comprobable.

• Define la ventana de retención y las consultas históricas requeridas.
• Elige historial autoalojado, basado en exportaciones o alojado por proveedor.
• Verifica con sondas y registra los resultados en la tabla.
• Vuelve a verificar tras cambios de configuración o de proveedor.