Приоритетные комиссии
Продвинутая функция для чувствительных к задержке пользователей
Gossip-приоритет (чтение)
Существует 3 независимых голландских аукциона, синхронизированных с одним и тем же 3-минутным расписанием. Индексы аукциона опционально интерпретируются нодами как порядок их пиров при отправке данных. Приоритетный порядок влияет как на split client blocks, так и на обычные клиентские блоки, содержащие ответы. Невалидатор фонда будет учитывать порядок аукциона gossip-приоритета.
Независимые аукционы слотов не суммируются, поэтому IP, делающий ставки на несколько слотов, приоритизируется по своему низшему слоту. Чтобы аукцион влиял на задержку, ончейн-IP должен точно совпадать с IP, который видит пир, отправляющий данные. Результаты каждого аукциона влияют только на длительность следующего аукциона. Для нод, подключённых к валидирующей сети через цепочку нод, учтите, что каждый сетевой переход (хоп) может как учитывать, так и не учитывать аукцион приоритета — в зависимости от конфигурации родительской ноды.
Аукционы с более низкими индексами строго приоритетнее аукционов с более высокими индексами. Приоритизация одинаково применяется ко всем данным в потоке транзакций мемпула. Порядок должен быть относительно стабильным в ожидании, но подвержен дисперсии со стороны p2p-консенсусной сети. Gossip-приоритет применяется только к чтению данных. О приоритизации отправки данных см. раздел ниже о приоритете ордеров. Ноды, учитывающие gossip-приоритет, используют победителей предыдущего аукциона относительно текущего состояния исполнения этой ноды. Как и в случае аукционов деплоя токенов, спота и перпов, комиссии списываются со спот-баланса и сжигаются.
Победителей предыдущего аукциона (т.е. текущий порядок gossip-приоритета) и статусы текущего аукциона можно запросить с помощью info-запроса { "type": "gossipPriorityAuctionStatus"}.
Gossip-приоритет снижает потребность маркет-мейкеров в гипер-оптимизации инфраструктуры для сохранения конкурентоспособности. Для участия в аукционе пользователи отправляют действие {"type": "gossipPriorityBid", "slotId": 0, "ip": "1.2.3.4", "maxGas": 100000000}, где gas — это вэй (т.е. единицы 0.00000001 HYPE) HYPE, списываемые со спот-баланса. Каждый аукцион сбрасывается до 10-кратной предыдущей выигрышной цены соответствующего слота и имеет минимальную цену 0.1 HYPE. Любой адрес может делать ставки от имени любого IP-адреса.
Текущий эмпирический эффект gossip-приоритета в mainnet — сокращение задержки примерно на 25 мс за каждый слот аукциона.
Приоритет ордеров (запись)
Приоритет ордеров снижает потребность маркет-мейкеров в гипер-оптимизации ввода ордеров и связности, позволяя сосредоточиться на самой стратегии. Он дополнительно защищает маркет-мейкеров и позволяет реагировать на движения цен, вызванные другими площадками.
Приоритетная группировка поддерживается только для действий order, в которых одновременно
- каждый ордер относится к активу, не являющемуся outcome-активом
- каждый ордер является IOC, или каждый ордер является не-reduce-only ALO
Ордера можно отправлять с группировкой вида {"p": 12345}, где ставка интерпретируется как доля p / 100000000.0. Ставка списывается с неделегированного стейкинг-баланса как доля от исполненного ноционала в случае IOC и от стоящего в стакане ноционала в случае ALO. Списываемый приоритетный газ конвертируется в HYPE по спот-марк-цене.
IOC-приоритет
Приоритетная ставка оказывает линейное влияние на сквозную задержку в диапазоне 0-8 bps, т.е. p = 80000. Текущий эмпирический эффект приоритетных комиссий ордеров в mainnet — сокращение сквозной задержки примерно на 45 мс за каждые 1 bps уплаченной приоритетной комиссии. Даже с приоритетом ордеров все отмены приоритетнее всех немедленно исполнимых ордеров. Однако ордера с более высоким приоритетом приоритетнее ордеров с более низким приоритетом как линейная функция приоритетной ставки.
Максимальная приоритетная ставка — 100%. Любой приоритет между 8bps и 100% обрабатывается в мемпуле с одинаковым временным предпочтением. Однако IOC-ордера с приоритетной комиссией не менее 8bps, которые были бы исполнены предлагающим блок в каждом 70-мс интервале unix-времени (обычно соответствующем 1 блоку), сортируются в порядке убывания приоритетной комиссии. Другими словами, диапазон 0-8bps влияет на временную приоритизацию, а диапазон 8bps-100% разрешает ничьи среди ордеров из этого диапазона, полученных примерно в одно время. Конкретный пример: если граница unix-миллисекунд — (T, T + 70ms), ордера с (mempool_receive_time, priority), равными (T, 8bps), (T + 30ms, 9bps), (T + 69ms, 10bps), будут отсортированы в обратном порядке времени получения.
Хотя блоки дискретны, приоритизация ордеров непрерывна относительно приоритетной комиссии за запись ордера. Транзакции мемпула фактически сортируются по 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-приоритетные комиссии не влияют на приоритизацию в мемпуле. ALO-ордера как транзакции всегда обрабатываются в порядке FIFO, со сквозной задержкой, аналогичной отменам. Реализация приоритетной комиссии влияет на место в очереди между транзакциями. Другими словами, ALO-ордера приоритизируются в мемпуле одинаково независимо от их приоритета, но позиция в очереди может меняться на шкале времени 400 мс после исполнения транзакций ордеров на L1.
Конкретный пример: открывается новый уровень L, пустой в момент времени t. Первый ордер A на уровне L применяется ончейн (как указано выше, это означает исполнение на L1) в момент t' > t с нулевой приоритетной комиссией. Следующий ордер 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 поддерживает корректный порядок уровней, используя поле insertBefore в RawBookDiff::New из файлов raw_book_diff.