Commissioni di priorità

Funzionalità avanzata per gli utenti sensibili alla latenza

Priorità gossip (lettura)

Sono presenti 3 aste olandesi indipendenti sincronizzate sullo stesso programma di 3 minuti. Gli indici delle aste sono facoltativamente interpretati dai nodi come un ordinamento dei propri peer durante l'invio dei dati. L'ordinamento di priorità interessa sia i blocchi client suddivisi sia i normali blocchi client che includono risposte. Il nodo non validatore della foundation aderirà al rispetto dell'ordinamento dell'asta di priorità gossip.

Le aste degli slot indipendenti non sono additive, pertanto un IP che presenta offerte su più slot sarà prioritizzato in base allo slot più basso. Affinché l'asta influisca sulla latenza, l'IP on-chain deve corrispondere esattamente all'IP visto dal peer che invia i dati. I risultati di ciascuna asta influiscono solo sulla durata dell'asta successiva. Per i nodi collegati alla rete di validazione tramite una catena di nodi, si noti che ogni hop di rete può rispettare o meno l'asta di priorità a seconda della configurazione del nodo padre.

Gli indici d'asta più bassi hanno priorità rigorosa rispetto a quelli più alti. La prioritizzazione si applica equamente a tutti i dati nello stream delle transazioni del mempool. L'ordinamento dovrebbe essere relativamente coerente in termini di aspettativa, ma è soggetto a varianza derivante dalla rete di consenso p2p. La priorità gossip si applica solo alla lettura dei dati. Per la prioritizzazione dell'invio dei dati, si veda la sezione seguente sulla priorità degli ordini. I nodi che rispettano la priorità gossip utilizzeranno i vincitori dell'asta precedente rispetto allo stato di esecuzione corrente del nodo. Analogamente alle aste di deploy di token, spot e perpetual, le commissioni vengono prelevate dal saldo spot e bruciate.

I vincitori dell'asta precedente (ossia l'attuale ordinamento di priorità gossip) e gli stati delle aste correnti possono essere interrogati tramite la richiesta info { "type": "gossipPriorityAuctionStatus"}.

La priorità gossip riduce la necessità per i market maker di ottimizzare in modo estremo la propria infrastruttura per rimanere competitivi. Per partecipare all'asta, gli utenti inviano l'azione {"type": "gossipPriorityBid", "slotId": 0, "ip": "1.2.3.4", "maxGas": 100000000} in cui il gas è espresso in wei (ossia unità di 0.00000001 HYPE) di HYPE addebitati dal saldo spot. Ciascuna asta si azzera a 10 volte il prezzo vincente precedente di quello slot e ha un prezzo minimo di 0.1 HYPE. Qualsiasi indirizzo può presentare un'offerta per conto di un qualsiasi indirizzo IP.

L'effetto empirico attuale della priorità gossip su mainnet è una riduzione della latenza di circa 25 ms per slot d'asta.

Priorità degli ordini (scrittura)

La priorità degli ordini riduce la necessità per i market maker di ottimizzare in modo estremo l'immissione degli ordini e la connettività, consentendo loro di concentrarsi sulla strategia stessa. Protegge inoltre i maker e permette di reagire ai movimenti di prezzo guidati da altri venue.

Il raggruppamento per priorità è supportato solo per le azioni di ordine in cui sussistono entrambe le condizioni

1. ogni ordine riguarda un asset non-outcome
2. ogni ordine è IOC, oppure ogni ordine è un ALO non reduce-only

Gli ordini possono essere inviati con un raggruppamento della forma {"p": 12345} in cui il rate è interpretato come frazione p / 100000000.0. Il rate viene addebitato dal saldo di staking non delegato come frazione del nozionale fillato nel caso di IOC e del nozionale in attesa nel caso di ALO. Il gas di priorità addebitato viene convertito in HYPE utilizzando il mark price spot.

Priorità IOC

Il rate di priorità ha un effetto lineare sulla latenza end-to-end da 0 a 8 bps, ossia p = 80000. L'effetto empirico attuale delle commissioni di priorità degli ordini su mainnet è una riduzione della latenza end-to-end di circa 45 ms per 1 bp di commissione di priorità pagata. Anche con la priorità degli ordini, tutti gli annullamenti hanno la priorità rispetto a tutti gli ordini immediatamente eseguibili. Tuttavia, gli ordini con priorità più alta hanno la precedenza su quelli con priorità più bassa come funzione lineare del rate di priorità.

Il rate di priorità massimo è il 100%. Qualsiasi priorità compresa tra 8 bps e il 100% è trattata con identica preferenza temporale nel mempool. Tuttavia, gli ordini IOC con una commissione di priorità di almeno 8 bps che sarebbero eseguiti dal block proposer in ciascun bucket di tempo unix di 70 ms (solitamente corrispondente a 1 blocco) sono ordinati in ordine decrescente di commissione di priorità. In altre parole, l'intervallo 0-8 bps determina la prioritizzazione temporale, mentre l'intervallo 8 bps-100% risolve le parità tra ordini in questo intervallo ricevuti in un momento simile. Come esempio concreto, se il limite in millisecondi unix è (T, T + 70ms) , gli ordini con (mempool_receive_time, priority) pari a (T, 8bps), (T + 30ms, 9bps), (T + 69ms, 10bps) sarebbero ordinati in ordine inverso rispetto al tempo di ricezione.

Sebbene i blocchi siano discreti, la prioritizzazione degli ordini è continua rispetto alla commissione di priorità in scrittura degli ordini. Le transazioni del mempool sono di fatto ordinate secondo effective_time = arrival_time + f(action, priority_fee) dove f è una funzione strettamente decrescente della commissione di priorità e nulla per le azioni prioritarie come gli annullamenti. Per un dato tipo di azione, i confini tra i blocchi non sono rilevanti ai fini della prioritizzazione relativa, poiché le transazioni all'interno di un blocco sono comunque ordinate secondo effective_time .

La priorità degli ordini si applica solo all'invio dei dati. Per la prioritizzazione della lettura dei dati, si veda la sezione precedente sulla priorità gossip. Analogamente alle aste di priorità gossip, le commissioni di priorità degli ordini vengono bruciate.

La commissione di priorità IOC pagata può essere letta dal file user_fills scritto dai nodi nel campo priorityGas .

Priorità ALO

Su una scala temporale di T = 400ms, gli ordini ALO sono ordinati per priorità. Più precisamente, la coda in ciascun livello costituita dagli ordini inseriti negli ultimi T verrà ordinata in ordine decrescente di rate di priorità.

Di conseguenza, qualsiasi slot della coda è idoneo a ricevere offerte di commissione di priorità per una finestra di durata T. Ciascun nuovo ordine viene confrontato con la coda degli ordini inseriti da meno di T al momento dell'inserimento. In altre parole, la finestra T è continua, non suddivisa in bucket. Le commissioni di priorità ALO vengono detratte al momento dell'inserimento dell'ordine indipendentemente dal fatto che l'ordine venga eseguito.

A differenza degli ordini IOC, le commissioni di priorità ALO non influiscono sulla prioritizzazione nel mempool. Gli ordini ALO sono sempre elaborati in FIFO come transazioni, con latenza end-to-end analoga a quella degli annullamenti. L'implementazione della commissione di priorità influisce sulla posizione in coda tra le transazioni. In altre parole, gli ordini ALO sono prioritizzati in modo simile nel mempool indipendentemente dalla loro priorità, ma la posizione in coda può cambiare su una scala temporale di 400 ms dopo che le transazioni degli ordini sono state eseguite sull'L1.

Un esempio concreto: un nuovo livello L si apre ed è vuoto al tempo t. Il primo ordine A al livello L viene applicato on-chain (come sopra, ciò significa eseguito sull'L1) al tempo t' > t con commissione di priorità nulla. L'ordine successivo B viene applicato on-chain al tempo t' + T - 1ms con priorità p > 0. Supponendo che A e B siano gli unici ordini al livello L, l'ordinamento al tempo t' + T vedrà B davanti ad A. Un terzo ordine C viene applicato al tempo t' + T + 1ms con priorità p' > p. L'ordinamento al tempo t' + T + 1ms è B > A > C . Sebbene C abbia priorità più alta, B ha già consolidato la propria posizione in coda poiché A è presente sul book da T e B si trova prima di A.

Le commissioni di priorità gossip possono essere lette dai file replica_cmds registrati dai nodi. Il valore in USDC degli importi delle commissioni di priorità può essere calcolato come order_price * order_sz * grouping_priority_rate . L'order_book_server mantiene il corretto ordinamento dei livelli utilizzando il campo insertBefore su RawBookDiff::New dai file raw_book_diff.