優先費

面向延遲敏感用戶的高級功能

Gossip（讀取）優先級

有 3 個相互獨立的荷蘭式拍賣，同步到同一個 3 分鐘的周期。節點可以選擇將拍賣序號解釋爲向其對等節點發送數據時的排序依據。該優先排序同時影響 split client block 以及包含回應的普通 client block。Foundation 非驗證節點將選擇遵循 gossip 優先拍賣的排序。

各個獨立的槽位拍賣不可疊加，因此競拍多個槽位的 IP 將按其最低的槽位獲得優先級。要讓拍賣影響延遲，鏈上 IP 必須與發送數據的對等節點所看到的 IP 完全一致。每場拍賣的結果只影響下一場拍賣的持續期間。對於通過節點鏈連接到驗證網路的節點，請注意每一跳網路是否遵循優先拍賣取決於父節點的配置方式。

較低的拍賣序號嚴格優先於較高的序號。該優先排序同等地適用於 mempool 交易流中的所有數據。此排序在期望上應當相對一致，但會受到 p2p 共識網路的方差影響。Gossip 優先級僅適用於讀取數據。關於發送數據的優先排序，請參閱下面關於訂單優先級的部分。遵循 gossip 優先級的節點將使用相對於該節點當前執行狀態的前一場拍賣的獲勝者。與代幣、現貨和永續合約部署拍賣類似，從現貨餘額中支付的費用會被銷毀。

前一場拍賣的獲勝者（即當前 gossip 優先排序）以及當前拍賣的狀態可以通過 info 請求 { "type": "gossipPriorityAuctionStatus"} 查詢。

Gossip 優先級降低了做市商爲保持競爭力而過度優化基礎設施的必要性。要參與拍賣，用戶發送操作 {"type": "gossipPriorityBid", "slotId": 0, "ip": "1.2.3.4", "maxGas": 100000000}，其中 gas 是從現貨餘額扣除的 HYPE 的 wei（即 0.00000001 HYPE 爲單位）。每場拍賣重置爲該槽位前一次獲勝價格的 10 倍，且最低價格爲 0.1 HYPE。任何地址都可以代表任何 IP 地址出價。

目前 gossip 優先級在主網上的實測效果約爲每個拍賣槽位降低 25 ms 延遲。

訂單（寫入）優先級

訂單優先級降低了做市商爲保持競爭力而過度優化下單鏈路和連接的必要性，使其可以專注於策略本身。它進一步保護了 Maker，並允許對其他市場驅動的價格變動做出快速回應。

優先分組（grouping）僅支持滿足以下兩個條件的訂單操作：

每筆訂單都是非 outcome 資產
每筆訂單都是 IOC，或每筆訂單都是非只減倉的 ALO

訂單可以以 {"p": 12345} 形式的分組發送，其中費率被解釋爲分數 p / 100000000.0。該費率在 IOC 情形下按成交名義金額的比例、在 ALO 情形下按掛單名義金額的比例，從未質押（undelegated）的質押餘額中扣除。所收取的優先 gas 按現貨標記價格換算爲 HYPE。

IOC 優先級

優先費率在 0-8bps（即 p = 80000）範圍內對端到端延遲有線性影響。目前訂單優先費在主網上的實測效果約爲每支付 1 bp 優先費降低 45 ms 端到端延遲。即使使用訂單優先級，所有撤單仍優先於所有立即可執行的訂單。不過，較高優先級的訂單作爲優先費率的線性函數，排位先於較低優先級的訂單。

最高優先費率爲 100%。8bps 到 100% 之間的任何優先級在 mempool 中被賦予相同的時間優先權。不過，在每個 70ms 的 unix 時間桶（通常對應 1 個區塊）內，將被區塊提議者執行的、優先費至少爲 8bps 的 IOC 訂單，會按優先費從高到低排序。換句話說，0-8bps 範圍影響時間上的優先排序，而 8bps-100% 範圍用於在近似同時收到的該範圍內的訂單之間打破平局。舉一個具體例子，如果 unix 毫秒邊界爲 (T, T + 70ms)，那麼 (mempool_receive_time, priority) 分別爲 (T, 8bps)、(T + 30ms, 9bps)、(T + 69ms, 10bps) 的訂單將按接收時間倒序排序。

儘管區塊是離散的，但訂單優先排序相對於訂單寫入優先費是連續的。Mempool 交易實際上按 effective_time = arrival_time + f(action, priority_fee) 排序，其中 f 是優先費的嚴格遞減函數，對於撤單等被優先處理的操作則爲零。對於給定的操作類型，區塊之間的邊界與相對優先排序無關，因爲區塊內的交易仍按 effective_time 排序。

訂單優先級僅適用於發送數據。關於讀取數據的優先排序，請參閱前面關於 gossip 優先級的部分。與 gossip 優先拍賣類似，訂單優先費會被銷毀。

已支付的 IOC 優先費可以從節點寫入的 user_fills 文件中讀取，欄位爲 priorityGas 。

ALO 優先級

在 T = 400ms 的時間尺度上，ALO 訂單按優先級排序。更準確地說，每個價位上由過去 T 內所下訂單構成的隊尾部分，將按優先費率從高到低排序。

因此，隊列中的任何槽位在持續時間爲 T 的窗口內都有資格進行優先費競價。每筆新訂單在下單時會與放置時距今不足 T 的隊尾訂單進行比較。換句話說，T 窗口是連續的，而非分桶的。ALO 優先費在下單時即被扣除，無論訂單是否成交。

與 IOC 訂單不同，ALO 優先費不影響 mempool 優先排序。ALO 訂單作爲交易始終按 FIFO 處理，端到端延遲與撤單相近。優先費的實現影響的是跨交易的隊列位置。換句話說，無論優先級如何，ALO 訂單在 mempool 中的優先排序是相似的，但在訂單交易於 L1 上執行之後，隊列位置可能在 400ms 的時間尺度上發生變化。

一個具體例子：新的價位 L 在時刻 t 開啓且爲空。第一筆訂單 A 在時刻 t' > t 以零優先費被上鏈應用（如上所述，這意味着在 L1 上執行）。下一筆訂單 B 在時刻 t' + T - 1ms 以優先級 p > 0 被上鏈應用。假設 A 和 B 是價位 L 上僅有的訂單，那麼在時刻 t' + T 的排序中 B 將排在 A 之前。第三筆訂單 C 在時刻 t' + T + 1ms 以優先級 p' > p 被應用。時刻 t' + T + 1ms 的排序爲 B > A > C 。儘管 C 具有更高的優先級，但 B 已經鎖定了其在隊列中的位置，因爲 A 已在訂單簿上停留了 T，而 B 排在 A 之前。

Gossip 優先費可以從節點記錄的 replica_cmds 文件中讀取。優先費金額的 USDC 價值可按 order_price * order_sz * grouping_priority_rate 計算。order_book_server 通過使用 raw_book_diff 文件中 RawBookDiff::New 的 insertBefore 欄位來維護正確的價位排序。