运行 Hyperliquid 归档节点：历史数据、存储与查询访问

Hyperliquid 数据接口与节点角色

Hyperliquid 是一个由 HyperCore 和 HyperEVM 组成的专用 L1，其公共数据接口包括用于实时状态的 JSON-RPC/REST API、用于流式传输的 WebSocket，以及用于批量历史的归档/平面文件式导出。Hyperliquid 文档描述了节点、API 接口和数据访问方式，是了解哪个接口提供哪种数据的权威起点。

全节点保留近期状态，并针对验证和提供当前链头进行优化。归档节点保留完整的账本、交易以及（在适用情况下）状态历史，用于深度回测和特定时间点读取。这一区别很重要，因为对于历史状态查询，修剪节点会返回错误或空结果，而归档节点会返回非空值。

在选择运营模式之前，请将你的工作负载映射到正确的接口。实时交易和监控属于 JSON-RPC/REST 和 WebSocket 接口，而批量离线分析和回测属于归档/平面文件导出或归档节点。Hyperliquid RPC 端点（RPC Assistant）页面列出了端点选项，Hyperliquid 历史市场数据 API文章介绍了面向市场特定历史的数据 API 接口。

• JSON-RPC/REST API：实时状态、交易提交和近期区块查询。
• WebSocket：面向实时应用的流式更新。
• 归档/平面文件导出：用于离线处理的批量历史，不支持实时查询。
• 归档节点：通过 JSON-RPC 提供完整账本和状态历史，用于特定时间点读取。

获取 Hyperliquid 深度历史的三种方式

第一种方式是自行运行归档节点，以获得完全控制权和最新数据。这为你提供一个可服务历史状态查询的私有端点，并让你不受第三方速率限制的影响，但需要大量存储、内存、CPU 和带宽，且同步速度比全节点慢。

第二种方式是从对象存储消费归档/平面文件导出，用于批量离线处理。这对于大型回测很高效，因为你可以直接读取文件而无需运行节点，但导出的新鲜度仅取决于最后一次导出，且无法服务链头或回答实时查询。

第三种方式是查询通过 JSON-RPC 暴露历史状态的提供商，以进行特定时间点读取。这避免了运营存储密集型基础设施，但确切的归档范围和查询接口取决于提供商。请将这些模式与归档节点与全节点对比中的权衡以及访问历史区块链数据中的方法进行比较。

• 自托管归档节点：完全控制、最新数据、运营成本最高。
• 归档/平面文件导出：批量离线处理、无实时查询、新鲜度受导出频率限制。
• 提供商托管的历史 JSON-RPC：无需存储运维即可进行特定时间点读取，范围因提供商而异。

归档节点的资源维度

存储随保留量增长，因此请根据观察到的账本增长乘以目标窗口来规划。在全节点上或从导出元数据中测量增长率，然后推算所需归档范围所需的存储。不要假设固定大小；需求取决于链上活动和你的保留策略。

内存由状态和索引消耗，CPU 由执行和查询服务消耗。带宽由数据摄入和客户端查询消耗。由于这些维度相互影响，一个足以处理近期状态的节点在归档服务方面可能规模不足，尤其是在许多历史查询并发运行时。

一种实用的规划方法是记录两个时间点的已用存储，计算差值并进行外推。本文后面的结果表提供了已用存储和保留窗口列，以便你对照自己的端点进行跟踪。

• 存储：保留窗口 × 观察到的账本增长率。
• 内存：状态和索引占用，随历史增长。
• CPU：并发负载下的执行和查询服务。
• 带宽：数据摄入加上客户端查询流量。

验证归档节点是否提供历史数据

要验证归档可用性，请针对已知旧区块或哈希发起历史状态查询，并确认结果非空。ethereum.org上的以太坊 JSON-RPC 规范记录了归档节点所服务的归档状态查询模式，而jsonrpc.org上的 JSON-RPC 2.0 规范定义了用于探测归档可用性的请求结构。

将归档响应与修剪节点进行对比，后者对同一查询返回错误或空结果。非空的历史结果是节点保留该区块状态的证据，而诸如缺失 trie 节点之类的错误或空结果则表明状态不可用。

由于提供商特定行为各不相同，请将探测视为可重复的测试而非保证。针对你自己的端点运行它，并将结果记录在结果表中。

• 归档节点：历史状态查询返回非空结果。
• 修剪节点：同一查询返回错误或空结果。
• 提供商行为：有文档说明 / 因提供商而异，因此需按端点验证。

使用 curl 探测历史可用性

以下 curl 示例针对旧区块和特定时间点状态读取发送 JSON-RPC POST，如果归档范围被服务则打印 PASS。请将端点和区块号替换为目标链和节点的值。

针对已知归档端点和已知修剪端点运行它，以观察差异。该脚本检查结果是否非空，并以明确的状态退出。

#!/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"

使用 Node.js 探测历史可用性

此 Node.js 示例使用现代 Node.js 运行时中可用的 fetch 执行相同的探测。它检查旧区块和特定时间点状态读取，然后打印 PASS 或 FAIL。

将其用作监控或 CI 管道中的可重复检查。将区块号调整为你期望归档服务的最早高度。

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}`);
})();

针对你的端点的可复现结果表

使用下表记录针对你自己端点的测量结果。通过运行上述探测并记录结果来填写。这可以保持你的评估可复现，并可在不同提供商或节点配置之间进行比较。

这些列捕获目标区块或高度、端点、使用的方法、是否存在结果、最早可用区块、已用存储和保留窗口。由于提供商特定行为各不相同，你填写的表格是你环境的权威记录。

• 目标区块/高度：你查询的历史时间点。
• 端点：你测试的 JSON-RPC URL。
• 方法：使用的 JSON-RPC 方法，例如 eth_getBlockByNumber 或 eth_getBalance。
• 结果存在？：是或否，基于非空结果。
• 最早可用区块：端点服务的最旧区块。
• 已用存储：你的节点或数据集消耗的磁盘。
• 保留窗口：保留的时间或区块范围。

归档基础设施的局限性与权衡

确切的归档范围和查询接口取决于提供商或你的节点配置，因此一个区块的探测通过并不能保证所有历史都可用。归档节点存储占用大且同步速度比全节点慢，这会影响部署时间和成本。

平面文件导出的新鲜度仅取决于最后一次导出，且无法服务链头，因此不适合实时查询。Hyperliquid 特有的数据（如资金费和订单簿历史）可能位于市场数据 API 而非节点本身，这意味着仅靠归档节点可能无法覆盖所有分析需求。

通过组合接口来应对这些限制：使用归档节点或提供商进行特定时间点状态读取，使用平面文件导出进行批量离线处理，使用市场数据 API 获取市场特定历史。Hyperliquid 历史市场数据 API文章详细介绍了最后一个接口。

• 归档范围和查询接口：有文档说明 / 因提供商而异。
• 归档节点：存储占用大且同步较慢。
• 平面文件导出：新鲜度受导出频率限制，无链头。
• 市场特定历史：可能需要市场数据 API，而非节点。

归档查询失败故障排除

当历史查询失败时，首先确认区块号在归档范围内。结果为 null 或诸如缺失 trie 节点之类的错误通常意味着节点已修剪或区块早于保留范围。针对已知归档端点重新运行探测，以隔离问题是端点还是查询。

如果端点正确但查询缓慢，请检查资源压力。存储、内存、CPU 和带宽相互影响，并发历史查询可能使一个能轻松处理近期状态的节点饱和。降低并发或扩展资源，然后重新测量。

对于提供商托管的端点，请查看文档中说明的归档范围和任何速率限制。由于提供商特定行为各不相同，请使用探测进行验证，而不是假设覆盖范围。Hyperliquid RPC 延迟文章介绍了影响查询性能的延迟考虑因素。

• Null 或缺失 trie 节点：区块超出保留范围或节点已修剪。
• 查询缓慢：资源压力或并发饱和。
• 提供商端点：检查文档中说明的归档范围和速率限制。
• 隔离：针对已知归档端点测试同一查询。

运营归档基础设施的后续步骤

首先定义你的保留窗口和所需的历史查询，然后在自托管归档节点、平面文件导出或提供商托管的历史 JSON-RPC 端点之间进行选择。使用本文中的探测来验证可用性，并为你的环境填写结果表。

如果你不想运营存储密集型基础设施，请查看RPC 定价和API 服务以了解托管选项，并浏览Hyperliquid 网络页面了解网络特定细节。OnFinality Learn 中心汇集了相关指南，包括归档节点与全节点对比和访问历史区块链数据。

最后，保持验证的可复现性。在配置更改、提供商迁移或保留调整后重新运行探测，并更新结果表，以便你的归档覆盖范围保持有记录且可测试。

• 定义保留窗口和所需的历史查询。
• 选择自托管、基于导出或提供商托管的历史。
• 使用探测进行验证并在表中记录结果。
• 在配置或提供商更改后重新验证。