優化延遲
以下建議僅供參考，是一個非全面性的起點。它們不構成交易建議，也不保證任何延遲或交易結果。
優化讀取延遲（接收市場數據）
- 對可靠的對等節點（例如 Hyper Foundation 非驗證節點）運行一個非驗證節點。
- 運行節點時加上
--disable-output-file-buffering，以便在區塊執行完成後立即獲得輸出 - 使用足夠規格的機器運行節點，至少 32 個邏輯核心、128 GB 記憶體和 500 MB/s 的磁盤吞吐量。增加核心數可以降低延遲，因爲區塊的執行會更快。
- 利用節點輸出在本地建構訂單簿及其他交易所狀態，節點數據比 API 更快、更細粒度。參見 https://github.com/hyperliquid-dex/order_book_server，其中示例了如何在運行節點的同一臺機器上建構訂單簿。該倉庫不再積極維護。建議 fork 該倉庫或從頭實現，以納入 ALO 優先費等細節或其他邊界情況。
- 節點上的
--batch-by-block會等到區塊結束才寫入數據。上面的訂單簿伺服器示例利用這一點來簡化邏輯，但進一步的優化可以包括關閉該標誌並以其他方式推斷區塊邊界。 - 對延遲敏感的用戶可能會發現
split_client_blocks: true很有用，它會在交易被納入 client block 之前先流式傳輸待提交的交易。這可以在讀取輸入時帶來 70-150ms 的延遲改善。如節點倉庫文件所述，這是到執行的最快交易輸入，甚至在 L1 執行之前就已廣播。更快的輸入數據的代價是執行結果尚不可用。不過，對於下單這類簡單操作，消費方可以流式地爲所有用戶估算帳戶價值，從而以合理的準確度預測執行結果。 - Foundation 非驗證節點是正常運行時間和延遲方面最優的非驗證節點之一。延遲敏感用戶的接入詳情見這裡。
- 讀取優先費是從網路讀取原始數據的最快方式。更多細節見這裡。
優化寫入延遲（發送訂單和撤單）
- 撤單應使用 fast 標誌發送。fast 標誌沒有任何缺點，只是 fast 撤單不能用於撤銷觸發訂單。
- 寫入優先費是向網路發送訂單的最快方式。更多細節見這裡。
- Hyperliquid 的執行邏輯旨在保護 Maker 免受毒性訂單流的影響，從而讓終端用戶即使在劇烈波動中也能看到緊密的價差和充足的流動性。這一效應的主要驅動因素是：在時刻
t發送的撤單和 ALO 訂單幾乎總是在時刻t發送的 IOC 和 GTC 訂單之前執行。這種優先排序跨越多個區塊。次要效應是每個 L1 區塊只包含少數幾個共識捆綁（bundle）。在每個捆綁內，ALO 和撤單先於其他交易執行。 - Hyperliquid 上的端到端延遲與中心化撮合引擎不可直接類比，因爲訂單簿完全在鏈上。端到端延遲包括到達 API 伺服器的時間、記憶體池（mempool）打包時間和提交時間（在流水線化的 HyperBFT 共識中通常爲 2 個區塊）。交易的先後順序的噪聲遠小於端到端延遲所顯示的程度。雖然撤單或 ALO 訂單可能顯示約 380ms 的端到端延遲，但用戶應該能夠以發送時間之間 <10ms 的偏差運行實驗，並在 L1 上看到可預測的排序。
- 希望降低端到端寫入延遲的用戶（例如爲了預測將被提交的交易順序），可以從非驗證節點的 split client block 中讀取這些交易（參見上面的讀取延遲部分）。這種方式不包含交易的執行結果。