Hyperliquid RPC 延迟：测量、HyperEVM 与原生 API 对比及低延迟调优

直接回答：Hyperliquid RPC 延迟取决于你使用的 API

如果你询问 Hyperliquid RPC 延迟，首先需要知道 Hyperliquid 暴露了两种截然不同的 API：用于市场数据和交易的原生 L1 API（REST 和 WebSocket），以及用于 EVM 侧的 HyperEVM JSON-RPC。原生 API 专为低延迟交易设计，从地理位置接近的节点可以实现亚 10 毫秒的往返时间，而 HyperEVM RPC 是标准的以太坊兼容端点，延迟更高，速率限制更严格。本指南将展示如何测量两者，理解影响延迟的主要因素，并调整你的设置以获得尽可能低的延迟。

对于低延迟交易，原生 WebSocket 订阅（allMids、l2Book）是首选，因为它们实时推送更新，无需轮询。相比之下，HyperEVM RPC 最适合偶尔的状态读取或合约交互，此时延迟不太关键。公共 HyperEVM RPC 的速率限制约为每个 IP 每分钟 100 个请求（由提供商记录），如果超过此限制，可能会导致请求被丢弃或停滞，直接影响感知延迟。

• 原生 L1 API：用于市场数据和交易的低延迟 REST 和 WebSocket。
• HyperEVM RPC：用于 EVM 状态和交易的标准 JSON-RPC，延迟较高。
• 速率限制：HyperEVM 公共 RPC 约 100 请求/分钟/IP（提供商记录）。
• 地理邻近性是原生 API 延迟的主要因素。
• Hyperliquid 文档定义了原生 info/exchange API 和 HyperEVM RPC 方法，这些构成了上述延迟特性；权威的端点和接口参考请参见 Hyperliquid 文档。

架构：为什么两个技术栈具有不同的延迟特征

Hyperliquid 的核心是专为订单簿交易优化的自定义 L1 区块链。原生 API（info 和 exchange 端点）与共识和撮合引擎紧密集成，允许极低延迟的读写。WebSocket 订阅在处理后立即推送更新，通常在毫秒内。相比之下，HyperEVM 是一个独立的执行环境，与 L1 并行运行，提供以太坊兼容性。EVM JSON-RPC 调用涉及额外的抽象层，通常由可能未针对速度进行优化的节点提供服务。

网络路径也不同。对于原生 API，最快的连接来自地理上靠近 Hyperliquid 验证者集的节点，这些节点集中在特定区域。对于 HyperEVM，延迟更依赖于提供商的基础设施以及到其节点的距离。此外，HyperEVM RPC 通常用于归档查询，这需要读取历史状态，可能比当前状态读取慢得多。

速率行为也不同。原生 API 具有更高的速率限制（记录在 Hyperliquid API 速率限制指南 中），而 HyperEVM 公共 RPC 限制更严格。这意味着在 EVM 侧，你可能会遇到由于速率限制导致的延迟峰值，这不是网络延迟问题，而是请求节流问题。

• 原生 API：针对低延迟优化，WebSocket 推送。
• HyperEVM：标准 JSON-RPC，开销更高，归档读取更慢。
• 速率限制：原生 API 更高，HyperEVM 约 100 请求/分钟/IP。
• 地理邻近性对原生 API 更重要。

测量延迟：可复现的脚本

要自行测量延迟，可以使用以下 Node.js 脚本。它测量原生 REST 调用（info 端点）、HyperEVM JSON-RPC 调用（eth_blockNumber）以及 WebSocket 订阅延迟探测的往返时间（RTT）。脚本使用公共端点，但你可以将其替换为你自己的提供商端点。请注意，这是一种测量方法，不是供应商基准测试；结果将根据你的位置、网络和提供商而有所不同。

脚本发送多个请求并计算平均、最小和最大延迟。对于 WebSocket 探测，它测量发送订阅和接收第一条消息之间的时间。在靠近 Hyperliquid 基础设施的位置运行以获得最佳结果。

• 使用脚本测量 REST、JSON-RPC 和 WebSocket 的 RTT。
• 将端点替换为你的提供商的端点。
• 多次运行以获得稳定的平均值。
• 将结果记录在下表中。

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

预期输出和结果表

脚本将输出类似以下内容（数值仅为示例，并非基准测试）：

在下方表格中填写你自己的结果。这是一种测量方法，不是供应商基准测试。对于特定提供商的数据，请参考独立来源，如 Dwellir 的指南或 hyperpc 的比较，它们有自己的方法论。

• 原生 REST（info）延迟（毫秒）：平均：12.34，最小：10.11，最大：15.67
• HyperEVM eth_blockNumber 延迟（毫秒）：平均：45.67，最小：40.23，最大：52.10
• WebSocket allMids 首条消息延迟（毫秒）：平均：8.90，最小：7.12，最大：11.45

| 端点 | 平均（毫秒） | 最小（毫秒） | 最大（毫秒） |
|----------|----------|----------|----------|
| 原生 REST（info） | | | |
| HyperEVM eth_blockNumber | | | |
| WebSocket allMids | | | |

常见故障及修复

在测量或使用 Hyperliquid RPC 时，你可能会遇到几个常见问题。以下是最常见的问题及解决方法。

HyperEVM RPC 速率限制：公共端点允许每个 IP 每分钟约 100 个请求。如果超过此限制，你将收到 HTTP 429 响应或连接被丢弃。修复：实现客户端速率限制，使用提供商的专用端点，或批量请求。有关详细信息，请参阅 Hyperliquid API 速率限制指南。

WebSocket 断开连接：如果未在特定时间间隔内发送 ping，原生 WebSocket 可能会断开连接。修复：实现心跳机制。Hyperliquid WebSocket 订阅指南 涵盖了这一点。

地理距离导致的高延迟：如果你远离 Hyperliquid 基础设施，延迟会更高。修复：使用地理分布式提供商或在靠近验证者的区域运行自己的节点。对于低延迟交易，请考虑使用专用端点，如 HypeRPC，它针对速度进行了优化。

HyperEVM 上的归档节点读取：读取历史状态可能很慢。修复：使用提供归档节点的提供商，或缓存频繁访问的数据。

• 速率限制：实现退避和重试，或使用专用端点。
• WebSocket 超时：定期发送 ping。
• 地理距离：选择在 Hyperliquid 验证者附近有节点的提供商。
• 归档读取：使用提供归档节点的提供商或缓存。

低延迟调优：最佳实践

要实现 Hyperliquid 交易的最低延迟，请遵循以下最佳实践：

首先，优先使用原生 WebSocket 订阅获取实时市场数据。allMids 和 l2Book 订阅在可用时立即推送更新，无需轮询。轮询 REST API 至少增加一次往返时间，并且可能错过轮询之间的更新。

其次，在 HyperEVM 侧，批量处理 JSON-RPC 请求以减少往返次数。例如，不要为多个地址调用 eth_getBalance，而是使用 eth_getProof 或自定义批量。此外，缓存不频繁更改的状态读取，如代币小数位或合约元数据。

第三，在所有 HTTP 和 WebSocket 连接上设置显式超时。这可以防止请求挂起，并允许快速失败和重试。使用带有超时选项的库（如 axios），或在 WebSocket 客户端中设置超时。

第四，使用地理分布式或专用端点。对于低延迟交易，请考虑使用像 HypeRPC 这样的提供商，它专为低延迟访问 Hyperliquid 而设计。或者，在靠近 Hyperliquid 验证者的区域运行自己的节点。Hyperliquid RPC 端点（RPC 助手） 页面列出了可用的端点。

最后，持续监控你的延迟。使用上述测量脚本作为基线，并跟踪随时间的变化。这有助于你及早发现问题并调整设置。

• 使用原生 WebSocket 订阅获取实时数据。
• 在 EVM 侧批量处理 JSON-RPC。
• 缓存状态读取。
• 设置显式超时。
• 使用地理分布式或专用端点。
• 定期监控延迟。

权衡与限制

虽然原生 API 提供更低的延迟，但它也有局限性。WebSocket 订阅未经过身份验证，在高负载期间可能具有更高的延迟。REST API 有速率限制，尽管限制高于 EVM RPC。对于 HyperEVM，主要限制是速率限制和缺乏低延迟保证。

另一个权衡是运行自己的节点的复杂性。虽然它提供最低延迟，但需要大量的基础设施和维护。使用像 Dwellir 或 hyperpc 这样的第三方提供商更容易，但会引入网络开销。

此外，请注意，公共 HyperEVM RPC 的速率限制约为每个 IP 每分钟 100 个请求，这是提供商记录的。对于需要频繁状态读取的应用程序，这可能成为瓶颈。在这种情况下，请考虑使用专用端点或提供更高限制的提供商。

最后，延迟测量高度依赖于你的网络路径和提供商的基础设施。你从脚本获得的数字特定于你的环境，不应直接与供应商基准测试进行比较。始终参考独立来源进行提供商比较。

• 原生 API：延迟较低，但有速率限制和潜在的负载问题。
• HyperEVM：延迟较高，速率限制严格。
• 运行自己的节点：延迟最低，但维护成本高。
• 第三方提供商：更容易，但增加网络开销。
• 测量结果特定于环境。

后续步骤

既然你了解了如何测量和调优 Hyperliquid RPC 延迟，你可以将这些技术应用到自己的应用程序中。有关更多详细信息，请探索以下资源：

查看 Hyperliquid 网络概述 获取一般信息。要深入了解速率限制，请参阅 Hyperliquid API 速率限制指南。如果你使用 WebSocket，Hyperliquid WebSocket 订阅指南 是必不可少的。你还可以浏览 OnFinality 学习中心 获取更多指南。有关专用端点的定价，请参阅 RPC 定价 和 API 服务。最后，Hyperliquid RPC 端点（RPC 助手） 页面列出了所有可用的端点。

• Hyperliquid 网络概述
• Hyperliquid API 速率限制指南
• Hyperliquid WebSocket 订阅指南
• OnFinality 学习中心
• RPC 定价
• API 服务
• Hyperliquid RPC 端点（RPC 助手）