Prioritätsgebühren

Erweiterte Funktion für latenzempfindliche Nutzer

Gossip-Priorität (Lesen)

Es gibt 3 unabhängige niederländische Auktionen, die auf denselben 3-Minuten-Zeitplan synchronisiert sind. Die Auktionsindizes werden von den Nodes optional als Reihenfolge für ihre Peers beim Senden von Daten interpretiert. Die Prioritätsreihenfolge betrifft sowohl geteilte Client-Blöcke als auch normale Client-Blöcke, die Antworten enthalten. Der Foundation-Non-Validator wird die Prioritätsreihenfolge der Gossip-Auktion freiwillig berücksichtigen.

Die unabhängigen Slot-Auktionen sind nicht additiv, daher wird eine IP, die auf mehrere Slots bietet, gemäß ihrem niedrigsten Slot priorisiert. Damit die Auktion die Latenz beeinflusst, muss die On-Chain-IP exakt mit der IP übereinstimmen, die der datensendende Peer sieht. Die Ergebnisse jeder Auktion wirken sich nur auf die Dauer der folgenden Auktion aus. Für Nodes, die über eine Kette von Nodes mit dem Validierungsnetzwerk verbunden sind, ist zu beachten, dass jeder Netzwerk-Hop die Prioritätsauktion je nach Konfiguration des übergeordneten Nodes berücksichtigen kann oder nicht.

Niedrigere Auktionsindizes werden strikt gegenüber höheren Indizes priorisiert. Die Priorisierung gilt gleichermaßen für alle Daten im Mempool-Transaktionsstrom. Die Reihenfolge sollte erwartungsgemäß relativ konsistent sein, unterliegt jedoch Schwankungen durch das p2p-Konsensnetzwerk. Die Gossip-Priorität gilt nur für das Lesen von Daten. Zur Priorisierung des Sendens von Daten siehe den Abschnitt unten zur Order-Priorität. Nodes, die die Gossip-Priorität berücksichtigen, verwenden die Gewinner der vorherigen Auktion relativ zum aktuellen Ausführungszustand dieses Nodes. Ähnlich wie bei den Token-, Spot- und Perpetual-Deployment-Auktionen werden die Gebühren aus dem Spot-Guthaben entnommen und verbrannt.

Die Gewinner der vorherigen Auktion (d. h. die aktuelle Gossip-Prioritätsreihenfolge) und die aktuellen Auktionsstatus können über die Info-Anfrage { "type": "gossipPriorityAuctionStatus"} abgefragt werden.

Die Gossip-Priorität verringert die Notwendigkeit für Market Maker, ihre Infrastruktur zu überoptimieren, um wettbewerbsfähig zu bleiben. Um an der Auktion teilzunehmen, senden Nutzer die Aktion {"type": "gossipPriorityBid", "slotId": 0, "ip": "1.2.3.4", "maxGas": 100000000}, wobei Gas in Wei (d. h. Einheiten von 0.00000001 HYPE) in HYPE dem Spot-Guthaben belastet wird. Jede Auktion wird auf das 10-fache des vorherigen Gewinnerpreises dieses Slots zurückgesetzt und hat einen Mindestpreis von 0.1 HYPE. Jede Adresse kann im Namen jeder IP-Adresse bieten.

Die aktuelle empirische Wirkung der Gossip-Priorität im Mainnet ist eine Verringerung der Latenz um etwa 25 ms pro Auktionsslot.

Order-Priorität (Schreiben)

Die Order-Priorität verringert die Notwendigkeit für Market Maker, ihre Order-Eingabe und Konnektivität zu überoptimieren, und erlaubt es ihnen stattdessen, sich auf die Strategie selbst zu konzentrieren. Sie schützt Maker zusätzlich und ermöglicht eine Reaktion auf Preisbewegungen, die von anderen Venues ausgehen.

Die Prioritätsgruppierung wird nur für Order-Aktionen unterstützt, bei denen beides zutrifft

1. jede Order bezieht sich auf ein Nicht-Outcome-Asset
2. jede Order ist IOC oder jede Order ist ein nicht-reduce-only ALO

Orders können mit einer Gruppierung der Form {"p": 12345} gesendet werden, wobei die Rate als Bruch p / 100000000.0 interpretiert wird. Die Rate wird dem nicht delegierten Staking-Guthaben als Anteil des ausgeführten Nominalwerts bei IOC bzw. des ruhenden Nominalwerts bei ALO belastet. Die berechnete Prioritäts-Gas wird anhand des Spot-Markpreises in HYPE umgerechnet.

IOC-Priorität

Die Prioritätsrate hat einen linearen Effekt auf die Ende-zu-Ende-Latenz von 0-8bps, d. h. p = 80000. Die aktuelle empirische Wirkung der Order-Prioritätsgebühren im Mainnet ist eine Verringerung der Ende-zu-Ende-Latenz um etwa 45 ms pro 1 bp gezahlter Prioritätsgebühr. Auch mit Order-Priorität werden alle Stornierungen vor allen sofort ausführbaren Orders priorisiert. Höher priorisierte Orders werden jedoch vor niedriger priorisierten Orders als lineare Funktion der Prioritätsrate priorisiert.

Die maximale Prioritätsrate beträgt 100%. Jede Priorität zwischen 8bps und 100% wird im Mempool mit identischer Zeitpräferenz behandelt. IOC-Orders mit mindestens 8bps Prioritätsgebühr jedoch, die vom Block-Proposer in jedem 70ms-Unix-Zeitfenster (üblicherweise entsprechend 1 Block) ausgeführt würden, werden in absteigender Reihenfolge der Prioritätsgebühr sortiert. Mit anderen Worten bewirkt der Bereich 0-8bps eine zeitliche Priorisierung, und der Bereich 8bps-100% löst Gleichstände unter Orders in diesem Bereich auf, die zu ähnlicher Zeit empfangen wurden. Als konkretes Beispiel: Wenn die Grenze der Unix-Millisekunden (T, T + 70ms) beträgt, würden die Orders mit (mempool_receive_time, priority) gleich (T, 8bps), (T + 30ms, 9bps), (T + 69ms, 10bps) in umgekehrter Reihenfolge der Empfangszeit sortiert.

Obwohl Blöcke diskret sind, ist die Order-Priorisierung hinsichtlich der Order-Write-Prioritätsgebühr kontinuierlich. Die Mempool-Transaktionen werden effektiv nach effective_time = arrival_time + f(action, priority_fee) sortiert, wobei f eine streng monoton fallende Funktion der Prioritätsgebühr ist und für priorisierte Aktionen wie Stornierungen null ist. Für einen gegebenen Aktionstyp sind die Grenzen zwischen Blöcken für die relative Priorisierung nicht relevant, da die Transaktionen innerhalb eines Blocks weiterhin nach effective_time sortiert werden .

Die Order-Priorität gilt nur für das Senden von Daten. Zur Priorisierung des Lesens von Daten siehe den vorherigen Abschnitt zur Gossip-Priorität. Ähnlich wie bei den Gossip-Prioritätsauktionen werden Order-Prioritätsgebühren verbrannt.

Die gezahlte IOC-Prioritätsgebühr kann aus der von den Nodes geschriebenen Datei user_fills als Feld priorityGas ausgelesen werden .

ALO-Priorität

Auf der Zeitskala von T = 400ms werden ALO-Orders nach Priorität sortiert. Genauer gesagt wird das Ende der Warteschlange auf jeder Stufe, das aus Orders besteht, die innerhalb der letzten T platziert wurden, in absteigender Reihenfolge der Prioritätsrate sortiert.

Folglich ist jeder Platz in der Warteschlange für ein Fenster der Dauer T für Gebote auf die Prioritätsgebühr berechtigt. Jede neue Order vergleicht zum Zeitpunkt der Platzierung mit dem Ende der Orders, die weniger als T alt sind. Mit anderen Worten ist das T-Fenster kontinuierlich, nicht in Buckets unterteilt. ALO-Prioritätsgebühren werden zum Zeitpunkt der Platzierung der Order abgezogen, unabhängig davon, ob die Order ausgeführt wird.

Anders als bei IOC-Orders bewirken ALO-Prioritätsgebühren keine Mempool-Priorisierung. ALO-Orders werden als Transaktionen stets nach FIFO verarbeitet, mit ähnlicher Ende-zu-Ende-Latenz wie Stornierungen. Die Implementierung der Prioritätsgebühr beeinflusst die Position in der Warteschlange über Transaktionen hinweg. Mit anderen Worten werden ALO-Orders im Mempool unabhängig von ihrer Priorität ähnlich priorisiert, die Position in der Warteschlange kann sich jedoch auf einer 400ms-Zeitskala ändern, nachdem die Orders-Transaktionen auf der L1 ausgeführt wurden.

Ein konkretes Beispiel: Eine neue Stufe L öffnet sich und ist zum Zeitpunkt t leer. Die erste Order A auf Stufe L wird zum Zeitpunkt t' > t mit einer Prioritätsgebühr von null on-chain angewendet (wie oben bedeutet dies die Ausführung auf der L1). Die nächste Order B wird zum Zeitpunkt t' + T - 1ms mit Priorität p > 0 on-chain angewendet. Angenommen, A und B sind die einzigen Orders auf Stufe L, dann steht zum Zeitpunkt t' + T B vor A. Eine dritte Order C wird zum Zeitpunkt t' + T + 1ms mit Priorität p' > p angewendet. Die Reihenfolge zum Zeitpunkt t' + T + 1ms ist B > A > C . Auch wenn C eine höhere Priorität hat, hat B seinen Platz in der Warteschlange bereits gesichert, da A seit T im Orderbuch steht und B vor A liegt.

Gossip-Prioritätsgebühren können aus den von Nodes aufgezeichneten Dateien replica_cmds ausgelesen werden. Der USDC-Wert der Prioritätsgebührenbeträge kann als order_price * order_sz * grouping_priority_rate berechnet werden . Der order_book_server hält die korrekte Stufenreihenfolge aufrecht, indem er das Feld insertBefore auf RawBookDiff::New aus den raw_book_diff-Dateien verwendet.