レイテンシの最適化

以下の提案は情報提供のみを目的とした、網羅的ではない出発点です。これらはトレーディングに関する助言ではなく、いかなるレイテンシやトレーディングの結果も保証するものではありません。

読み取りレイテンシの最適化（マーケットデータの受信）

Hyper Foundation のノンバリデーターなど、信頼できるピアに接続してノンバリデーターノードを実行します。
ブロックが実行された直後に出力を得るために、--disable-output-file-buffering を付けてノードを実行します
十分なマシンスペック（少なくとも32論理コア、128 GB RAM、500 MB/sのディスクスループット）でノードを実行します。コア数を増やすとブロックの実行が速くなるため、レイテンシを削減できます。
ノードの出力を使用して、オーダーブックやその他の取引所ステートをローカルで構築します。ノードの出力は、API よりも速く、より細かいデータを提供します。ノードを実行しているのと同じマシン上でオーダーブックを構築する方法の例については、https://github.com/hyperliquid-dex/order_book_server を参照してください。このリポジトリは積極的に保守されていません。ALO 優先手数料やその他のエッジケースなどの詳細を組み込むために、リポジトリをフォークするか、ゼロから実装を書くことをお勧めします。
ノードの --batch-by-block は、ブロックの終了まで待ってからデータを書き込みます。上記のサンプルオーダーブックサーバーはこれを利用してロジックを単純化していますが、さらなる最適化として、このフラグをオフにして他の方法でブロック境界を推測することが考えられます。
レイテンシに敏感なユーザーには split_client_blocks: true が役立つ場合があります。これは、クライアントブロックに含まれる前に、コミットされるトランザクションをストリーミングします。これにより、入力の読み取り時に70〜150msのレイテンシ改善が得られる可能性があります。ノードリポジトリに記載されているように、これらは実行までの最速のトランザクション入力であり、L1 で実行される前でさえブロードキャストされます。より速い入力データのトレードオフは、実行結果がまだ利用できないことです。ただし、注文のような単純なアクションでは、コンシューマーは全ユーザーの推定アカウント価値をストリーミングして、実行結果を合理的な精度で予測できます。
Foundation のノンバリデーターは、最も稼働率が高く低レイテンシなノンバリデーターピアの1つです。レイテンシに敏感なユーザー向けのアクセスの詳細については、こちらを参照してください。
読み取り優先手数料は、ネットワークから生データを読み取る最速の方法です。詳細については、こちらを参照してください。

書き込みレイテンシの最適化（注文とキャンセルの送信）

キャンセルは fast フラグを付けて送信すべきです。fast キャンセルでトリガー注文をキャンセルできないことを除き、fast フラグにデメリットはありません。
書き込み優先手数料は、ネットワークに注文を送信する最速の方法です。詳細については、こちらを参照してください。
Hyperliquid の実行ロジックは、有害なフローからメイカーを保護するように設計されており、エンドユーザーはボラティリティが高いときでもタイトなスプレッドと深い流動性を享受できます。この効果の主要な要因は、時刻 t に送信されたキャンセルと ALO 注文が、時刻 t に送信された IOC 注文および GTC 注文よりもほとんど常に先に実行されることです。この優先順位付けは複数のブロックにまたがります。副次的な効果として、各 L1 ブロックには少数のコンセンサスバンドルのみが含まれ、各バンドル内では ALO とキャンセルが他のトランザクションよりも先に実行されます。
Hyperliquid のエンドツーエンドのレイテンシは、オーダーブックが完全にオンチェーンであるため、中央集権的なマッチングエンジンとは単純に比較できません。エンドツーエンドのレイテンシには、APIサーバーへの到達時間、メモリプールへの取り込み時間、コミットまでの時間（パイプライン化された HyperBFT コンセンサスでは通常2ブロック）が含まれます。トランザクションのシーケンシングは、エンドツーエンドのレイテンシが示唆するよりもはるかにノイズが少ないです。キャンセルや ALO 注文は \~380msのエンドツーエンドレイテンシを示すことがありますが、ユーザーは送信時刻の変動が10ms未満の実験を実行し、L1 上で予測可能な順序を観察できるはずです。
エンドツーエンドの書き込みレイテンシを削減したいユーザー（例えば、コミットされるトランザクションのシーケンスを予測するため）は、ノンバリデーターノードの split クライアントブロックからそれらを読み取ることができます（上記の読み取りレイテンシのセクションを参照）。このアプローチにはトランザクションの実行結果は含まれません。