Optimierung der Latenz

Die folgenden Empfehlungen dienen ausschließlich der Information und stellen einen nicht vollständigen Ausgangspunkt dar. Sie sind keine Handelsberatung und garantieren weder eine bestimmte Latenz noch ein bestimmtes Handelsergebnis.

Optimierung der Leselatenz (Empfang von Marktdaten)

1. Betreiben Sie einen nicht-validierenden Node gegenüber einem zuverlässigen Peer, etwa dem Hyper Foundation Non-Validator.
2. Betreiben Sie den Node mit --disable-output-file-buffering, um Ausgaben unmittelbar nach Ausführung der Blöcke zu erhalten
3. Betreiben Sie den Node mit ausreichender Hardwareausstattung, mindestens 32 logischen Kernen, 128 GB RAM und einem Festplattendurchsatz von 500 MB/s. Mehr Kerne können die Latenz verringern, da Blöcke schneller ausgeführt werden.
4. Erstellen Sie das Orderbuch und den übrigen Börsenzustand lokal aus den Ausgaben des Nodes, die schnellere und detailliertere Daten als die API liefern. Ein Beispiel dafür, wie Sie ein Orderbuch auf demselben Rechner aufbauen, auf dem ein Node läuft, finden Sie unter https://github.com/hyperliquid-dex/order_book_server. Dieses Repository wird nicht aktiv gepflegt. Es wird empfohlen, das Repository zu forken oder eine eigene Implementierung von Grund auf zu schreiben, um Details wie ALO-Prioritätsgebühren oder andere Randfälle zu berücksichtigen.
5. --batch-by-block auf dem Node wartet bis zum Ende des Blocks, um die Daten zu schreiben. Der oben genannte Beispiel-Orderbuchserver nutzt dies zur Vereinfachung der Logik; eine weitere Optimierung könnte darin bestehen, das Flag zu deaktivieren und Blockgrenzen auf anderem Weg zu ermitteln.
6. Für latenzempfindliche Nutzer kann split_client_blocks: true nützlich sein, da damit Transaktionen gestreamt werden, die committet werden sollen, bevor sie in Client-Blöcke aufgenommen werden. Dies kann beim Lesen von Eingaben zu einer Latenzverbesserung von 70-150ms führen. Wie im Node-Repository dokumentiert, sind dies die schnellsten Transaktionseingaben bis zur Ausführung, die sogar gesendet werden, bevor sie von der L1 ausgeführt werden. Der Nachteil der schnelleren Eingangsdaten besteht darin, dass die Ergebnisse der Ausführung noch nicht verfügbar sind. Bei einfachen Aktionen wie Orders kann der Consumer jedoch geschätzte Kontowerte für alle Nutzer streamen, um Ausführungsergebnisse mit hinreichender Genauigkeit vorherzusagen.
7. Der Foundation Non-Validator gehört zu den Non-Validator-Peers mit der höchsten Verfügbarkeit und der geringsten Latenz. Details zum Zugang für latenzempfindliche Nutzer finden Sie hier.
8. Lese-Prioritätsgebühren sind der schnellste Weg, Rohdaten aus dem Netzwerk zu lesen. Weitere Details finden Sie hier.

Optimierung der Schreiblatenz (Senden von Orders und Stornierungen)

1. Stornierungen sollten mit dem fast-Flag gesendet werden. Das fast-Flag hat keinen Nachteil, außer dass fast-Stornierungen nicht zum Stornieren von Trigger-Orders verwendet werden können.
2. Schreib-Prioritätsgebühren sind der schnellste Weg, Orders an das Netzwerk zu senden. Weitere Details finden Sie hier.
3. Die Ausführungslogik von Hyperliquid ist darauf ausgelegt, Maker vor toxischem Orderfluss zu schützen, sodass Endnutzer auch bei Volatilität enge Spreads und tiefe Liquidität sehen. Der Hauptgrund für diesen Effekt ist, dass Stornierungen und ALO-Orders, die zum Zeitpunkt t gesendet werden, fast immer vor IOC- und GTC-Orders ausgeführt werden, die zum Zeitpunkt t gesendet werden. Diese Priorisierung erstreckt sich über mehrere Blöcke. Der sekundäre Effekt besteht darin, dass jeder L1-Block nur wenige Konsens-Bündel enthält. Innerhalb jedes Bündels werden ALO-Orders und Stornierungen vor anderen Transaktionen ausgeführt.
4. Die Ende-zu-Ende-Latenz auf Hyperliquid ist nicht direkt mit zentralisierten Matching-Engines vergleichbar, da das Orderbuch vollständig onchain ist. Die Ende-zu-Ende-Latenz umfasst die Zeit bis zum API-Server, die Zeit bis zur Aufnahme in den Mempool und die Zeit bis zum Commit (üblicherweise 2 Blöcke im HyperBFT-Konsens mit Pipelining). Die Reihenfolge der Transaktionen ist deutlich weniger streuungsbehaftet, als die Ende-zu-Ende-Latenz vermuten lässt. Während eine Stornierung oder ALO-Order eine Ende-zu-Ende-Latenz von \~380ms aufweisen kann, sollten Nutzer Experimente mit <10ms Abweichung zwischen den Sendezeiten durchführen und eine vorhersehbare Reihenfolge auf der L1 beobachten können.
5. Nutzer, die ihre Ende-zu-Ende-Schreiblatenz verringern möchten (beispielsweise um die Reihenfolge der Transaktionen vorherzusagen, die committet werden), können diese aus den Split-Client-Blöcken im nicht-validierenden Node lesen (siehe Abschnitt zur Leselatenz oben). Dieses Verfahren enthält nicht das Ausführungsergebnis der Transaktion.