Ottimizzazione della latenza

I suggerimenti riportati di seguito hanno finalità puramente informative e costituiscono un punto di partenza non esaustivo. Non costituiscono consigli di trading e non garantiscono alcuna latenza o risultato di trading.

Ottimizzazione della latenza di lettura (ricezione dei dati di mercato)

1. Eseguire un nodo non validante collegato a un peer affidabile, come il non-validator della Hyper Foundation.
2. Eseguire il nodo con --disable-output-file-buffering per ottenere gli output non appena i blocchi vengono eseguiti
3. Eseguire il nodo con specifiche hardware adeguate, almeno 32 core logici, 128 GB di RAM e 500 MB/s di throughput del disco. L'aumento dei core può ridurre la latenza perché i blocchi vengono eseguiti più rapidamente.
4. Costruire il book e altro stato dell'exchange localmente utilizzando gli output del nodo, che contengono dati più rapidi e granulari rispetto all'API. Vedere https://github.com/hyperliquid-dex/order_book_server per un esempio di come creare un book degli ordini sulla stessa macchina che esegue un nodo. Questo repository non è mantenuto attivamente. Si consiglia di creare un fork del repository o di scrivere un'implementazione da zero per integrare dettagli come le commissioni prioritarie ALO o altri casi limite.
5. --batch-by-block sul nodo attende la fine del blocco per scrivere i dati. Il server di esempio per il book degli ordini menzionato sopra utilizza questa opzione per semplificare la logica, ma un'ulteriore ottimizzazione potrebbe consistere nel disattivare il flag e nel dedurre altrimenti i confini dei blocchi.
6. Gli utenti sensibili alla latenza possono trovare utile split_client_blocks: true, poiché trasmette in streaming le transazioni da confermare prima che vengano incluse nei client blocks. Questo può comportare un miglioramento della latenza di 70-150ms nella lettura degli input. Come documentato nel repository del nodo, questi sono gli input delle transazioni più rapidi verso l'esecuzione, trasmessi addirittura prima che vengano eseguiti dall'L1. Il compromesso associato ai dati di input più rapidi è che i risultati dell'esecuzione non sono ancora disponibili. Tuttavia, con azioni semplici come gli ordini, il consumer può trasmettere in streaming i valori stimati degli account per tutti gli utenti al fine di prevedere i risultati dell'esecuzione con ragionevole accuratezza.
7. Il non-validator della foundation è uno dei peer non validanti con il più alto uptime e la latenza più bassa. Vedere qui per i dettagli sull'accesso per gli utenti sensibili alla latenza.
8. Le commissioni prioritarie di lettura sono il modo più rapido per leggere i dati grezzi dalla rete. Vedere qui per maggiori dettagli.

Ottimizzazione della latenza di scrittura (invio di ordini e annullamenti)

1. Gli annullamenti devono essere inviati con il flag fast. Non vi è alcuno svantaggio nell'usare il flag fast, salvo che gli annullamenti fast non possono essere utilizzati per annullare gli ordini trigger.
2. Le commissioni prioritarie di scrittura sono il modo più rapido per inviare ordini alla rete. Vedere qui per maggiori dettagli.
3. La logica di esecuzione di Hyperliquid è progettata per proteggere i maker dal flusso tossico, affinché gli utenti finali vedano spread ridotti e liquidità profonda anche durante la volatilità. Il fattore principale di questo effetto è che gli annullamenti e gli ordini ALO inviati al tempo t vengono quasi sempre eseguiti prima degli ordini IOC e GTC inviati al tempo t. Questa prioritizzazione si estende su più blocchi. L'effetto secondario è che ciascun blocco L1 contiene solo pochi bundle di consenso. All'interno di ogni bundle, ALO e annullamenti vengono eseguiti prima delle altre transazioni.
4. La latenza end-to-end su Hyperliquid non è direttamente confrontabile con i motori di matching centralizzati, perché il book degli ordini è completamente onchain. La latenza end-to-end include il tempo verso il server API, il tempo di inclusione nella mempool e il tempo di commit (in genere 2 blocchi nel consenso HyperBFT in pipeline). La sequenziazione delle transazioni è soggetta a molta meno variabilità rispetto a quanto la latenza end-to-end lasci intendere. Sebbene un annullamento o un ordine ALO possa mostrare una latenza end-to-end di \~380ms, gli utenti dovrebbero essere in grado di eseguire esperimenti con una variazione <10ms tra i tempi di invio e osservare un ordinamento prevedibile sull'L1.
5. Gli utenti che intendono ridurre la latenza di scrittura end-to-end (ad esempio per prevedere la sequenza delle transazioni che verranno confermate) possono leggerle dai split client blocks nel nodo non validante (vedere la sezione sulla latenza di lettura sopra). Questo approccio non include il risultato dell'esecuzione della transazione.