Оптимизация задержки

Приведённые ниже рекомендации носят исключительно информационный характер и являются неполным отправным пунктом. Они не являются торговой рекомендацией и не гарантируют каких-либо результатов по задержке или торговле.

Оптимизация задержки чтения (получение рыночных данных)

1. Запустите невалидирующую ноду с надёжным пиром, например невалидатором Hyper Foundation.
2. Запустите ноду с --disable-output-file-buffering, чтобы получать вывод сразу после исполнения блоков
3. Запустите ноду на машинах с достаточными характеристиками: минимум 32 логических ядра, 128 ГБ RAM и пропускная способность диска 500 МБ/с. Увеличение числа ядер может снизить задержку, так как блоки будут исполняться быстрее.
4. Стройте стакан заявок и другое состояние биржи локально, используя вывод ноды, которая предоставляет более быстрые и гранулярные данные, чем API. См. https://github.com/hyperliquid-dex/order_book_server — пример того, как построить стакан заявок на той же машине, на которой работает нода. Этот репозиторий активно не поддерживается. Рекомендуется сделать форк репозитория или написать реализацию с нуля, чтобы учесть такие детали, как ALO priority fees и другие краевые случаи.
5. Флаг --batch-by-block на ноде ожидает конца блока перед записью данных. Приведённый выше пример сервера стакана заявок использует это для упрощения логики, но дальнейшей оптимизацией может быть отключение этого флага и определение границ блоков другим способом.
6. Чувствительные к задержке пользователи могут найти опцию split_client_blocks: true полезной, так как она передаёт поток транзакций для коммита ещё до их включения в клиентские блоки. Это может дать улучшение задержки на 70-150 мс при чтении входных данных. Как документировано в репозитории ноды, это самые быстрые входные данные транзакций для исполнения, транслируемые даже до их исполнения на L1. Компромисс при использовании более быстрых входных данных состоит в том, что результаты исполнения пока недоступны. Однако при простых действиях, таких как ордера, потребитель может передавать потоком оценочные стоимости счетов всех пользователей, чтобы предсказывать результаты исполнения с разумной точностью.
7. Невалидатор фонда — один из невалидирующих пиров с самым высоким аптаймом и низкой задержкой. Подробности доступа для чувствительных к задержке пользователей см. здесь.
8. Read priority fees — самый быстрый способ чтения сырых данных из сети. Подробнее см. здесь.

Оптимизация задержки записи (отправка ордеров и отмен)

1. Отмены следует отправлять с флагом fast. У флага fast нет недостатков, кроме того, что быстрые отмены нельзя использовать для отмены триггерных ордеров.
2. Write priority fees — самый быстрый способ отправки ордеров в сеть. Подробнее см. здесь.
3. Логика исполнения Hyperliquid спроектирована так, чтобы защищать маркет-мейкеров от токсичного потока, благодаря чему конечные пользователи видят узкие спреды и глубокую ликвидность даже в периоды волатильности. Основной источник этого эффекта в том, что отмены и ALO-ордера, отправленные в момент времени t, почти всегда исполняются раньше IOC- и GTC-ордеров, отправленных в момент времени t. Эта приоритизация охватывает несколько блоков. Вторичный эффект состоит в том, что каждый блок L1 содержит лишь несколько консенсусных бандлов. Внутри каждого бандла ALO и отмены исполняются раньше других транзакций.
4. Сквозная задержка в Hyperliquid не сопоставима напрямую с централизованными матчинговыми движками, поскольку стакан заявок полностью ончейн. Сквозная задержка включает время до сервера API, время включения в мемпул и время коммита (обычно 2 блока в конвейерном консенсусе HyperBFT). Последовательность транзакций содержит гораздо меньше шума, чем предполагает сквозная задержка. Хотя отмена или ALO-ордер может показывать сквозную задержку \~380 мс, пользователи могут проводить эксперименты с вариацией менее 10 мс между временами отправки и наблюдать предсказуемый порядок на L1.
5. Пользователи, желающие снизить сквозную задержку записи (например, чтобы предсказывать последовательность транзакций, которые будут закоммичены), могут читать их из split client blocks в невалидирующей ноде (см. выше раздел о задержке чтения). Этот подход не включает результат исполнения транзакции.