Hyperliquid L1 non-validator: текущие требования ноды и границы low-latency tuning

Что подтверждено текущими первичными источниками

• Официальные инструкции ноды указывают для non-validator базовый профиль 16 vCPU / 128 GB / 500 GB SSD, Ubuntu 24.04 и публичные gossip ports 4001/4002.
• Для lowest latency Hyperliquid прямо рекомендует размещать ноду в Tokyo, Japan. Документация при этом не называет конкретный коммерческий facility обязательной точкой размещения.
• Отдельный latency guide рекомендует для latency-sensitive setups как минимум 32 logical cores и около 500 MB/s disk throughput. Это дополнительная optimization guidance, а не замена базового machine contract.
• Флаг --disable-output-file-buffering документирован как способ быстрее получать output lines ценой большего количества disk I/O. Из этого не следует универсальное требование переносить данные на RAM-диск или применять одну фиксированную storage topology.
• Foundation non-validating node публикуется на best-effort basis: без гарантий availability, latency, performance или completeness. Для time-sensitive use данные нужно независимо проверять.

Request capacity не равна priority execution

Текущий Exchange API описывает reserveRequestWeight как резервирование дополнительных действий в рамках address-based request limits. Это rate-limit capacity, а не доказательство приоритетного включения торговой транзакции, более быстрого matching или гарантированного execution priority.

Любая стратегия, зависящая от latency, очередности, nonce handling или block inclusion, должна измерять фактическое поведение отдельно и не подменять rate-limit semantics предположением о приоритете исполнения.

AF_XDP: capability, а не универсальная настройка

Linux AF_XDP поддерживает copy и zero-copy paths. Поддержка zero-copy зависит от device/driver capabilities; принудительный XDP_ZEROCOPY должен завершиться ошибкой, если zero-copy недоступен. Поэтому NIC, queue layout, IRQ affinity, XDP mode и packet-loss behavior нужно сначала обнаружить и измерить на конкретном host.

Low-latency tuning следует проводить как обратимый benchmark loop: baseline → одна гипотеза → latency/jitter/drop telemetry → regression check → rollback criteria. Нельзя переносить чужой kernel/BIOS profile в production только потому, что он выглядит «HFT-оптимизированным».

Что снято с роли текущего deployment authority

• неподтверждённая конкретизация коммерческого Tokyo facility как обязательного места для Hyperliquid;
• жёсткие vendor-specific NIC, interface, BIOS, GRUB, sysctl, IRQ и scheduler настройки как универсальный рецепт;
• фиксированные storage-throughput и RAM-disk размеры, не являющиеся текущими требованиями Hyperliquid;
• локальные service names, CPU pinning maps и real-time priorities как будто это официальный node profile;
• неподтверждённые TPS/latency guarantees и утверждения о полном устранении I/O stalls;
• интерпретация request-weight reservation как priority fee или guaranteed execution mechanism.

Допустимая область использования

Начинайте с текущих официальных node requirements и подписанных binaries, затем отдельно измеряйте peer quality, block-apply lag, disk throughput, output freshness, packet drops и end-to-end strategy latency. Hardware/kernel optimizations должны иметь host-specific evidence и rollback plan.

Эта страница не является торговым разрешением и не запускает ноду, валидатор, exchange API actions, ордера, переводы, firewall changes, kernel tuning, reboot или deployment.