Введение

В этой статье мы познакомимся с MEV налогами, механизмом, который произвольные приложения могут использовать для сбора собственных MEV.

Этот механизм может быть использован сегодня на OP стеках L2, таких как OP Основная сеть, Base и Blast, потому что инициаторы блоков в этих цепочках следуют набору правил, которые мы называем конкурентным приоритетным упорядочиванием.

Чтобы реализовать налог MEV в одной из этих цепочек, смарт-контракт взимает комиссию, которая является функцией приоритетной комиссии транзакции. Мы показываем, что если приложение взимает с пользователей MEV налог в размере (скажем) 99 долларов США за каждый 1 доллар США приоритетной платы, оно может получить 99% конкурентного MEV для этой транзакции.

Налоги MEV — это простой метод, который открывает обширное пространство для дизайна. Вы можете думать о них как о том, что любое приложение в цепочке может запускать свой собственный аукцион MEV, не нуждаясь в какой-либо собственной инфраструктуре вне сети, просто подключившись к одному общему аукциону, проводимому инициатором блока.

Мы показываем, как налоги MEV могут быть использованы для решения трех основных проблем в исследованиях MEV:

• Децентрализованные биржи (DEX) маршрутизаторы, оптимизирующие цену, получаемую своппером
• Автоматизированные маркет-мейкеры (AMM), которые минимизируют потери по сравнению с ребалансировкой (LVR), с которыми сталкиваются поставщики ликвидности
• . Кошельки, которые позволяют своим пользователям фиксировать любые «обратные» MEV, созданные их транзакциями

Но есть одна загвоздка. Налоги MEV работают только в том случае, если инициаторы блоков строго следуют правилам конкурентного приоритетного упорядочивания, которые включают сортировку транзакций по приоритетной плате без цензуры, подглядывания или задержки. Если те, кто предлагает блокировку, отклоняются от этих правил, они могут уклоняться от налогов MEV, чтобы получить ценность для себя. Таким образом, сегодня MEV налоги зависят от доверия к секвенсорам L2 и, скорее всего, вообще не будут работать на Ethereum L1, где в построении блоков доминирует конкурентный аукцион строителей, который максимизирует доход для того, кто предлагает.

Тем не менее, сила и гибкость налогов MEV предполагает, что приоритетный заказ может быть правильным выбором для платформ, которые могут предоставить его сегодня. А относительная простота упорядочения конкурентных приоритетов предполагает, что может существовать жизнеспособный способ обеспечить его децентрализованным способом, без необходимости доверять одному секвенсору. Мы надеемся, что этот пост мотивирует к дальнейшей работе над этой проблемой.

Приоритетный порядок

Когда кто-то отправляет транзакцию на Ethereum L1 или L2, он указывает комиссию за приоритет, которую он платит инициатору блока.1 Вы можете себе представить, что это указано как priorityFeePerGas, число, которое умножается на газ, используемый в транзакции, чтобы получить builderPriorityFee — общий платеж в ETH. 2

В Ethereum Протокол нет правила, согласно которому транзакции в блоке должны упорядочиваться жадно по убыванию priorityFeePerGas. Тем не менее, это популярный способ построения блоков — например, это алгоритм по умолчанию, используемый секвенсорами OP Stack chains, а также geth и reth. Упорядочение приоритетов не только позволяет участникам транзакций эффективно выражать срочность своих транзакций, но и естественным образом направляет определенные виды MEV к инициатору блока.

Это происходит потому, что приоритетный порядок превращает конкуренцию за MEV в аукцион priority Газ. Когда есть возможность получить прибыль от взаимодействия с цепочкой, например, путем арбитража AMM против централизованной биржи, поисковики соревнуются, чтобы первыми воспользоваться этой возможностью. Если цепочка использует приоритетный порядок для определения включения и упорядочения транзакций, поисковики соревнуются, устанавливая комиссию с высоким приоритетом для своих транзакций.

В конкурентном сценарии, где безрисковая прибыль конкурируется до нуля, победивший поисковик должен в конечном итоге заплатить полную сумму MEV в качестве приоритетных сборов. 3 Таким образом, если от взаимодействия с контрактом можно получить 100 ETH прибыли, то первая транзакция, претендующая на него, установит приоритетную комиссию в размере 100 ETH. (Мы обсудим некоторые предостережения по этому поводу в разделе Ограничения).

MEV taxes

Предположим, что смарт-контракт хочет захватить MEV из любой транзакции, которая с ним взаимодействует. Существует обширная библиотека исследований о различных способах, с помощью которых смарт-контракты могут попытаться захватить свой собственный MEV.

Но на самом деле нам не обязательно что-либо знать о приложении. Если мы знаем, что блок строится с помощью конкурентного приоритетного упорядочивания, то у нас есть один универсальный сигнал для количества MEV в транзакции: комиссия за приоритет.

Мы предполагаем, что смарт-контракт может рассматривать комиссию за приоритет транзакции и взимать свою собственную комиссию как некоторую возрастающую ее функцию. Например, контракт может потребовать, чтобы тот, кто его вызывает, передал applicationPriorityFee = 99 * proposerPriorityFee в ETH в контракт. 4

Эта новая комиссия оплачивается пользователем, отправляющим транзакцию, поэтому она влияет на поведение этого пользователя. Если в возможной сделке есть 100 MEV, выигрышная транзакция теперь установит только приоритетную комиссию в размере 1 ETH, поскольку это приведет к общей выплате 100 ETH (1 ETH инициатору блока и 99 ETH смарт-контракту). Любая комиссия с более высоким приоритетом сделает транзакцию невыгодной; Любая плата с более низким приоритетом приведет к потере возможности в пользу конкурента, который установил более высокую плату. Это означает, что смарт-контракт захватил 99% MEV в транзакции.

Мы называем эту дополнительную плату, взимаемую смарт-контрактом, налогом MEV. Налоги MEV позволяют приложению перехватывать приоритетный заказ в своих интересах, позволяя ему возвращать MEV для своих пользователей, а не передавать его инициатору блока.

Если эта плата увеличивается достаточно быстро в зависимости от priorityFeePerGas, то инициатору будет начислено лишь незначительное количество MEV. Поскольку priorityFeePerGas деноминирован в wei (одна миллиардная миллиардная часть одного ETH), у нас есть большая точность для работы. Например, лонг поскольку налог на MEV является достаточно чувствительным, чтобы приоритет FeePerGas в размере 50 000 привел к непомерно высокому налогу, то общая сумма платежа предложителю будет меньше 0,01 доллара США. 5

Однако есть важный нюанс. Как обсуждалось в разделе «Ограничения», MEV налоги работают только в том случае, если инициаторы блоков следуют определенным правилам — тому, что мы называем «заказом конкурентного приоритета», — а не отклоняются от этих правил в ордерах, чтобы максимизировать свой собственный доход. Обеспечение соблюдения этих правил без доверия является открытой проблемой.

Single application MEV capture

Здесь мы рассмотрим, как в цепочке, которая гарантированно использует конкурентный приоритетный порядок для создания блоков, MEV налоги могут быть использованы для смягчения трех важных проблем в MEV: позволить интерфейсам DEX улучшить исполнение сделок для свопперов, позволить AMM снизить потери для арбитража для своих провайдеров ликвидности и позволить кошелькам уменьшить утечку MEV для своих пользователей, продавая право на обратный ход пользователя.

DEX маршрутизаторы В протоколах

маршрутизации DEX на основе намерений, таких как UniswapX и 1inch Fusion, пользователь (Алиса) подписывает намерение поменяться, а поисковики соревнуются в маршрутизации или выполнении этого намерения по наиболее выгодной цене для Алисы.

Текущие версии UniswapX используют два механизма для проведения этого конкурса: голландский аукцион, где лимитная цена Алисы изменяется со временем, пока ее не заполнит пользователь, и первоначальный аукцион с запросом котировок (RFQ) для установки стартовой цены этого голландского аукциона.

На платформе, которая гарантирует приоритетные заказы на конкурентной основе, UniswapX может заменить их единым механизмом: налогом MEV. Это можно реализовать, заставив пользователя подписать ордер, который может быть немедленно исполнен кем угодно, но с ценой исполнения, которая устанавливается в зависимости от приоритета транзакции.

Например, если у Алисы есть ордер UniswapX на продажу 1 ETH, она может определить цену исполнения ордера как minimumPrice + ($0.01 * priorityFeePerGas). minimumPrice может быть неким фиксированным значением, которое, как она ожидает, будет значительно ниже текущей цены.

Поисковики будут соревноваться за выполнение ордера Алисы, отправляя транзакции. Любая транзакция, имеющая наивысший приоритет и не отменяющаяся, будет выполнять ордер, что должно гарантировать, что своппер получит лучшую цену, которую могут найти поисковики. (Некоторые исключения из этого правила обсуждаются в разделе Ограничения.)

Если минимальная цена Алисы составляет 3,000 долларов, а текущая цена ETH составляет 3,500 долларов, priorityFeePerGas в выигрышной транзакции составит около 50,000. (Обратите внимание, что в транзакции, которая стоит 200 000 газов, это приведет к выплате всего около 10 миллиардов wei (около 0,000035 доллара) инициатору блока.)

Это имеет некоторые потенциальные преимущества по сравнению с существующими механизмами, используемыми в UniswapX.

Заказы, использующие налоги MEV, могут быть выполнены быстрее и по более выгодной цене, чем заказы, использующие голландские аукционы. Как обсуждалось в этой статье, голландские аукционы в сети теряют некоторую ценность для MEV из-за движения цен между блоками, и для их завершения может потребоваться много блоков. Напротив, заказы, в которых используются налоги MEV, обычно могут быть завершены в следующем блоке, захватывая при этом подавляющее большинство их MEV.

В отличие от оффчейн-запроса предложения, аукцион по заполнению ордера, использующего налоги MEV, будет происходить атомарно с выполнением транзакции в блокчейне. Это означает, что победителю торгов может быть гарантировано, что он обязуется выполнить ордер только в том случае, если его транзакция в сети будет успешной. Это может облегчить конкуренцию ликвидности в сети, такой как AMM, с ликвидностью вне сети, а это означает, что UniswapX может служить еще более эффективным маршрутизатором для систем с несколькими пулами, таких как Uniswap v4.

AMMs

Как правило, AMM передают ценность арбитражерам, которые торгуют против устаревших цен в верхней части блока, как описано в убыток против ребалансировки документы. Мы можем использовать налоги MEV, чтобы AMM захватывали этот MEV. Чтобы не усложнять задачу, мы обсудим, как это может работать на AMM без концентрированной ликвидности. (Если вас интересует, как можно решить такую проблему с помощью концентрированной ликвидности, Sorella скоро опубликует одно решение.)

AMM может захватывать MEV, взимая дополнительную комиссию в зависимости от приоритетной комиссии за транзакцию, что позволяет ему продавать на аукционе право торговать первым в блоке. Есть много способов рассчитать и номинировать эту плату. Мы обсудим один, возможно, нейтральный вариант — деноминировать его в единицах ликвидности пула, sqrt(xy). Выигрышной будет та сделка, которая больше всего увеличит ликвидность пула.

При выполнении первой транзакции в пуле в блоке, вместо того, чтобы применять условие x_end y_end > x_start y_start, пул может применить условие (с a в качестве некоторой константы):

x_end y_end > (sqrt(x_start y_start) + a*priorityFeePerGas)^2

Эта формула будет стимулировать арбитражного трейдера торговать по истинной цене, и после этой сделки средняя цена на пуле должна быть истинной ценой. 6

После этой первой транзакции сделки могут работать так же, как и на Uniswap v2, с фиксированной комиссией за своп. Неинформированные транзакции, которые хотят торговать на пуле без уплаты дополнительного налога MEV, будут устанавливать комиссию с низким приоритетом.

Есть много других способов внедрения налогов MEV на AMM, которые будут иметь другие последствия. Например, налоги MEV могут быть номинированы во входном или выходном токене свопа, могут влиять на процент комиссии за своп, применяемый пулом, или могут определять минимальную цену сделки пользователя. Мы считаем, что это интересное пространство для дизайна.

Backrunning auctions

В приведенных выше описаниях показано, как можно спроектировать определенные приложения, чтобы избежать утечки MEV. Однако, что, если кошелек хочет попытаться помочь своим пользователям получить MEV, который они создают из произвольных транзакций, взаимодействующих с любым приложением, даже с теми, которые не включают налоги MEV?

Например, когда Алиса совершает крупную сделку на AMM, она иногда создает арбитражную возможность для «бэкраннеров», чтобы сдвинуть цену назад. Обычно это происходит в MEV, а не в Алисе.

MEV-Share и MEVBlocker — это два протокола, которые позволяют пользователям получать MEV от своих транзакций, но они полагаются на сложную систему оффчейн-аукционов. В Orderflow Auction Design Space описаны некоторые другие решения.

Налоги MEV в сочетании с кошельком смарт-контрактов на основе намерений могут позволить нам создать альтернативную систему для сбора MEV для Алисы. Предположим, что вместо того, чтобы создавать транзакцию, которая торгуется на AMM, Алиса подписывает намерение, которое любой может отправить в кошелек смарт-контракта Алисы, чтобы заставить его выполнить это действие. Кошелек смарт-контракта Алисы взимает с любого, кто отправляет эту транзакцию, налог MEV, который выплачивается Алисе.

Пользователь, отправивший намерение Алисы, будет иметь исключительное право на обратный обход Алисы, поскольку они могут сделать это атомарно в одной и той же транзакции. В результате, если поиск является конкурентным, вся прибыль от обратного обхода Алисы должна поступать к Алисе через ее налог MEV.

Обратите внимание, что эта система не обязательно защищает пользователей от атак, связанных с опережающими пользовательскими транзакциями, поскольку транзакция, которая опережает пользователя, может избежать уплаты налога MEV этому пользователю. Эта проблема (и некоторые возможные способы ее устранения) более подробно обсуждается в разделе Ограничения ниже. Тем не менее, это может быть, по крайней мере, улучшением по сравнению с системами, использующими публичные мемпулы без каких-либо смягчений.

Другие варианты использования

В дополнение к этим примерам, другие потенциальные варианты использования MEV налогов могут включать почти все, что в настоящее время использует оффчейн или голландский аукцион, например:

• Протоколы для оракулов для сбора извлекаемой ими ценности оракулов, такие как Oval
• Refinancing auctions in NFT Insurance Protocols, такие как Blend
• Lending Протокол ликвидации, которые меньше утечек по стоимости, чем на голландских аукционах

Захват MEV между приложениями

Вышеуказанные решения предназначены для захвата MEV от взаимодействия с одним приложением. Но иногда поисковик может получить еще больше выгоды, взаимодействуя с несколькими приложениями в одной транзакции.

Если только одно из этих приложений имеет налог MEV, то все MEV из транзакции должны поступать в приложение с налогом MEV, независимо от того, насколько высок или низок этот налог MEV.

Но что, если транзакция пользователя взаимодействует с двумя приложениями, использующими налоги MEV? Например, что делать, если есть какой-то MEV, который можно получить, только выполнив один из описанных выше ордеров UniswapX, облагаемых налогом на MEV, против AMM, облагаемого MEV?

В этом случае относительная сумма избыточного MEV, захваченного каждым приложением, определяется тем, как эти приложения устанавливают свои налоги на MEV. Если значение, которое app_i взимает в качестве налога на MEV, задано функцией tax_i(priority), то приоритет выигрышной транзакции можно определить, решив для приоритета в следующем уравнении:

tax_1(приоритетПерГаз) + tax_2(приоритетПерГаз) = общее MEV

(Технически мы могли бы добавить третий член для priorityPerGas * gasUsed для выставления счета за плату за приоритет, уплаченную инициатору блока, но мы проигнорируем это, поскольку, как обсуждалось в Приложении A, в нормальных условиях он, скорее всего, будет пренебрежимо мал.)

В простом случае MEV налогов, которые являются линейными по приоритетуPerGas (т.е. tax_1(priorityPerGas) = a_1 * priorityPerGas), можно решить вопрос о доле MEV, получаемой каждой заявкой:

a_1 priorityPerGas + a_2 priorityPerGas = MEV

priorityPerGas = MEV/(a_1 + a_2)

tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV

tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

При установлении собственного налога MEV приложение сталкивается с компромиссом — более высокие налоги позволяют ему захватывать большую долю MEV между приложениями, когда это происходит, но означают, что оно может упустить некоторый MEV между приложениями, если есть конкурирующие способы его извлечения. Например, если существует AMM, который взимает налог MEV с каждой сделки, то ордер UniswapX с налогом MEV может быть с большей вероятностью исполнен другим AMM или наполнителем вне сети.

Во многих случаях может существовать равновесие, при котором два приложения разрабатывают свои налоги MEV в ордерах на совместное использование MEV таким образом, чтобы максимизировать их благосостояние. Например, AMM с налогом на MEV, скорее всего, захочет получить выгоду от одного информированного трейдера в верхней части блока, но затем захочет предоставить ликвидность другим трейдерам и приложениям (в том числе тем, которые используют налоги MEV) с низкой фиксированной комиссией. В этом случае AMM, скорее всего, установит относительно низкий налог MEV (скажем, 0,00001 доллара США priorityFeePerGas), чтобы арбитражная транзакция (если таковая имеется) произошла в начале блока, а затем не взимал налог MEV с последующих транзакций в блоке. Такие приложения, как UniswapX, которые хотят взаимодействовать с AMM, могут установить гораздо более высокий налог на MEV (скажем, 0,01 доллара США priorityFeePerGas), чтобы гарантировать, что их транзакции будут включены после того, как пул уже будет арбитражным. С этими относительными налогами AMM в конечном итоге окажется в первую очередь, даже если на нем будет только 1 доллар MEV и 50 000 долларов MEV в ордере UniswapX.

Мы считаем, что это широкое пространство для дизайна, достойное дальнейшего изучения.

Ограничения

MEV налоги имеют некоторые сложности и недостатки. Мы считаем, что каждый из них представляет собой интересную область для будущих исследований.

Несовместимость поощрений

MEV налоги не совместимы со стимулами для монополистического инициатора блока. Они работают только в том случае, если существует честная конкуренция за включение транзакций, что может произойти только в том случае, если инициатор блока следует правилам, которые мы называем «конкурентным приоритетным упорядочиванием», а не максимизирует свой собственный доход. Неформально и неисчерпывающе мы предлагаем, чтобы эти правила включали:

• Приоритетный заказ. Транзакции в блоке должны быть упорядочены по убывающему ордеру priorityFeePerGas.
• Цензура-сопротивление. Если инициатор блока получает транзакцию t1 во время блока, и блок либо не полон, либо включает в себя какую-либо транзакцию t2 такую, что t2.priorityFeePerGas < t1.priorityFeePerGas, то блок должен включать транзакцию t1.
• Конфиденциальность перед сделкой. Инициатор блока должен принимать транзакции через частную конечную точку и не должен делиться такими транзакциями с кем-либо еще перед фиксацией в блоке или использовать содержимое этих транзакций в качестве входных данных при создании собственных транзакций.
• Никакого последнего взгляда. Инициатор блока должен установить определенное время blockTime, до которого он принимает транзакции от кого бы то ни было, и после которого он не принимает транзакции ни от кого.

Если одно или несколько из этих свойств нарушаются, это может ослабить эффективность налогов MEV. Инициатор блока, который нарушает сопротивление цензуре, может избежать большинства налогов MEV, исключив конкурирующие транзакции и отправив транзакцию с нулевым приоритетом, которая использует эту возможность для себя. Инициатор блока, который нарушает конфиденциальность перед транзакцией, может украсть MEV из других транзакций или заглянуть в их приоритетные сборы, чтобы точно знать, насколько высокую ему нужно установить, в то время как тот, кто может отправлять транзакции позже, чем кто-либо другой, будет иметь свободный «последний взгляд» на то, стоит ли перебивать других за возможность. И то, и другое может создать проблемы неблагоприятного отбора, которые в конечном итоге препятствуют конкуренции.

К сожалению, в то время как первое свойство было бы легко применить на уровне протокола, принудительное применение других свойств является открытой проблемой.

При отсутствии правоприменения на уровень протокола, единственному секвенсору, который придерживается этих правил, нужно доверять, что он не будет отклоняться от них, и если инициаторы передают создание блоков на аутсорсинг конкурентному аукциону, максимизирующему доход (например, Ethereum L1 MEV-Boost), блоки, скорее всего, не будут им следовать.

Эти проблемы могут быть «решены» с помощью одного доверенного секвенсора, который обязуется использовать конкурентный порядок приоритетов для построения блоков. Они также могут быть решены с помощью децентрализованного механизма, использующего некоторую комбинацию консенсуса, криптографии и/или доверенных сред выполнения, таких как Angstrom от Sorella, SUAVE от Flashbots, Leaderless Auctions или Multiplicity.

Полные блоки

Одно из исключений из нормальной работы MEV налогов происходит, когда блоки полностью заполнены. В этом случае инициаторам блока, возможно, придется пропустить транзакции с более низким приоритетом, а не просто включить их в конце блока. Поскольку транзакции, которые взаимодействуют с приложениями, облагаемыми налогом на MEV, скорее всего, будут иметь чрезвычайно низкий приоритет, эти приложения, скорее всего, будут вытеснены приложениями, которые не используют налоги MEV, или теми, которые имеют чрезвычайно низкие налоги MEV. Однако в цепочке, которая использует механизм, подобный EIP-1559, для установки отдельной базовой комиссии, блоки должны быть относительно редкими, чтобы они были полностью заполнены. Кроме того, учитывая, что некоторые транзакции необходимо отложить, когда блоки заполнены, задержка транзакций, которые выражают меньшую срочность, путем установки более высоких налогов MEV может быть разумным результатом.

Отмененные транзакции

MEV налоги фактически полагаются на аукционы с одним блоком, в которых каждая "ставка" является транзакцией. Одним из недостатков этих аукционов является то, что проигрышные ставки, как правило, приводят к тому, что отмененные транзакции включаются в блокчейн, уплачивая некоторую базовую комиссию и перегружая цепочку.

Если секвенсор может полностью исключить неудачные транзакции, это устранит эту проблему, хотя это может быть трудно реализовать даже с помощью централизованного секвенсора. (Он также не будет строго подчиняться свойству цензуры-сопротивления, описанному выше, хотя это определение может быть скорректировано.) Более сложный секвенсор может оптимизировать этот процесс, позволив транзакциям указывать, в каких спорных аукционах они участвуют, предоставляя секвенсору достаточно информации, чтобы пропустить последующие транзакции, которые, как он знает, не увенчаются успехом.

Утечка намерений пользователей

MEV налогов работает только в том случае, если существует конкуренция среди пользователей, а это означает, что возможность должна быть в какой-то степени широко известна. Для таких приложений, как AMM, где возможность видна в блокчейне, это должно произойти естественным образом. Но для таких приложений, как маршрутизация на основе намерений или обратные аукционы, это означает, что приложению может потребоваться поделиться намерением пользователя с пользователями, выполняющими поиск.

В некоторых случаях временная конфиденциальность, утраченная в результате трансляции намерения пользователя до его выполнения, может привести к утечке ценности таким образом, что она не может быть восстановлена налогом MEV.

Например, предположим, что Алиса хочет приобрести токен с низкой ликвидностью, используя описанный выше протокол обратного аукциона. Она публикует подписанное намерение для своего кошелька смарт-контракта приобрести этот токен на AMM, установив некоторый допуск к проскальзыванию. Пользователи могут наперегонки подтолкнуть цену этого токена к ее допустимому проскальзыванию в высокоприоритетной транзакции, не выполняя ордера пользователя. Победитель, Боб, мог затем неконкурентно удовлетворить намерение Алисы, включив и опередив его в транзакции с низким приоритетом, тем самым зажав сделку Алисы и дав ей худшую цену, уклонившись от ее налога на MEV. Аналогичная проблема может возникнуть и с покупкой NFT.

Обратите внимание, что такая атака была бы рискованной для Боба, так как он не смог бы гарантировать атомарность между покупкой токена и продажей его Алисе. Наивный Боб может падение жертвой ловушка «разрывания бутербродов», в котором Алиса публикует намерение купить у себя бесполезный жетон, заставляя Боба купить его в ожидании сэндвича, но Алиса отзывает свое намерение до того, как Боб успевает закончить бутерброд.

Приложения также могут смягчить это, ограничивая набор пользователей, с которыми они обмениваются намерениями, и отслеживая их поведение, как это делают многие существующие аукционы потока заказов.

Также можно комбинировать MEV налоги с функциями конструктора, учитывающими конфиденциальность, как это предусмотрено в дизайне Flashbots для SUAVE.

Наконец, в тех случаях, когда Алиса решает, что затраты на раскрытие ее намерения перевешивают выгоду от конкурентного поиска, она может сама создать транзакцию и отправить ее непосредственно в блок. Как обсуждалось выше, идеальная реализация конкурентного приоритетного упорядочения должна обеспечить конфиденциальность до транзакции со стороны инициатора блока.

Обсуждение и предыдущая работа

Приоритетные Газ аукционы. Динамика упорядочения приоритетов в децентрализованных блокчейнах была изучена в статье Flash Boys 2.0, в которой был введен термин «извлекаемая ценность майнера». В этом документе отмечалось, что майнеры Ethereum (когда эта сеть использовала доказательство работы) уже заказывали транзакции по приоритету, и что арбитражеры полагались на это поведение для участия в «приоритетных аукционах газа», в которых они делали ставки на право быть первыми в блоке, что привело к тому, что большая часть MEV от децентрализованного арбитража на бирже досталась майнерам.

В порядке живой очереди. Некоторые попытки смягчить MEV с помощью правил упорядочения транзакций, таких как Themis или текущий секвенсор Arbitrum One,7 были сосредоточены на применении другого правила упорядочения, первым пришел, первым обслужен (иногда называемого "справедливым упорядочиванием"), где инициаторы блока должны ордер транзакции в том ордере, в котором они их видят.

При упорядочении приоритетов используется другой подход: транзакции, поступающие в течение определенного периода, обрабатываются одинаково, а вместо этого упорядочиваются по объявленному приоритету.

Принцип «первым пришел, первым обслужен» трудно реализовать или даже определить в реальной сетевой среде с более чем одним валидатором. Это также может привести к расточительным гонкам с задержкой и спаму даже с одним доверенным секвенсором. Наконец, налоги MEV могут устранить определенные виды MEV, которые не могут быть устранены при заказе в порядке живой очереди, такие как арбитражная прибыль от прерывистых «скачков» цен на активы. Потенциальные преимущества приоритетного упорядочения по сравнению с заказом в порядке живой очереди в некоторой степени связаны с преимуществами дискретного времени по сравнению с непрерывным обменом, рассмотренными в Budish, Cramton, Shim (2015).

Между тем, несмотря на то, что порядок приоритетов, похоже, по умолчанию приводит к утечке значения в MEV, в этом посте показано, как приложения могут быть спроектированы для его повторного захвата.

Разделение комиссий. Blast, Ethereum L2, делит часть как приоритетных, так и базовых сборов с смарт-контракты, к которому осуществляется доступ в транзакции.

Налоги MEV допускают нечто подобное (по крайней мере, для приоритетных сборов), но могут быть реализованы на прикладном уровне в любой цепочке, использующей конкурентный приоритетный заказ, без специальной поддержке для разделения комиссий. Они также позволяют приложениям определять свои собственные налоги как пользовательские функции приоритетного сбора, обеспечивая большую гибкость и потенциально приводя к большей компоновке приложений, поддерживающих MEV.

Ненадежные решения. В этом посте основное внимание уделяется мотивации платформ использовать конкурентный приоритетный порядок и способам использования преимуществ платформ, которые это делают, а не обсуждению того, как обеспечить его соблюдение без доверия.

Было проведено значительное предварительное обсуждение каждого из других свойств, необходимых для приоритетного заказа на конкурентной основе. Например, в Fox, Pai, Resnick (2023)) авторы обсуждают уязвимости в ончейн-аукционах при отсутствии С сопротивлением цензуре и описывают дизайн устойчивого к цензуре аукциона с использованием нескольких одновременных предложений. Однако они не предлагают конкретного порядка транзакций.

Были проведены и другие исследования по созданию механизмов для создания блоков с минимальным доверием, в том числе SUAVE, Angstrom Сореллы, Leaderless Auctions, Espresso and Offchain Labs' @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">децентрализованный Timeboost, и обязательным включением публичных транзакций Петером Силаги.

Заключение

Мы надеемся, что этот пост побудит L2 рассмотреть возможность использования приоритетного порядка (который поддерживается по умолчанию в стеке OP) и вдохновит приложения на тестирование MEV налогов там, где они поддерживаются.

Мы также надеемся, что это послужит стимулом для дальнейших исследований протоколов для минимизации доверия к заказу конкурентного приоритета как на L1, так и на L2. Если вы заинтересованы в сотрудничестве над этой проблемой и читаете эту статью до четверга, 6 июня, вы все еще можете подать заявку на стипендию TLDR для работы над MEV-устойчивыми секвенсорами L2 с Дэном. Или не стесняйтесь обращаться к dan@paradigm.xyz и dave@paradigm.xyz с идеями!

Сноски

1. В этом посте мы используем слово "proposer" для обозначения субъекта или процесса, который определяет, какие транзакции включаются в конкретный блок. В Ethereum L2s эту роль обычно выполняет «секвенсор». На Ethereum L1 он заполняется конкретным валидатором Ethereum, называемым proposer, хотя часто автор предложения передает задачу создания блока на аутсорсинг конкурентному аукциону, в котором участвуют «ретрансляторы» и «строители». Подробности о том, как распределяются эти обязанности, выходят за рамки данной статьи. Приоритетная ↩
2. плата за Газ на самом деле не указана явно в транзакции, но может быть рассчитана в ней. В транзакции указывается цена на газ, но Ethereum также взимает базовую плату, которая вычитается из цены на газ и сжигается. Базовая плата не должна учитываться для целей налогообложения MEV, поскольку она не находится под контролем участника операции. Комиссия за приоритет за газ — цена за часть комиссии за транзакцию, которая идет инициатору блока, — может быть рассчитана в Solidity как priorityGasPrice = tx.gasprice - block.basefee. ↩
3. В качестве альтернативы мы могли бы просто определить «MEV», чтобы исключить любую прибыль поисковика и ссылаться только на значение, которое пойдет валидатору. ↩
4. Обратите внимание, что proposerPriorityFee, равный priorityFeePerGas, умноженный на общий объем газа, использованного в транзакции, фактически не может быть рассчитан во время контракта, поскольку нет никакого способа узнать, сколько газа в конечном итоге будет использовано транзакцией. Однако, как правило, это не имеет значения, так как все, что нам нужно, это верхняя граница для этого. Чтобы обезопасить себя, вы можете умножить priorityFeePerGas на 30 миллионов — текущий максимальный газ в блоке Ethereum. Завышение этого значения просто будет означать, что налог MEV захватывает еще больший процент MEV. ↩
5. Предполагая, что транзакция не может превышать 30 миллионов газов, приоритет FeePerGas в 50 000 приведет к платежу за газ в размере 1500 гвеи — около 0,006 доллара США при цене ETH 4000 долларов США. ↩
6. В случае, когда priorityFeePerGas установлен так, что прибыль арбитражер равна нулю, арбитражная сделка, максимизирующая прибыль, должна соответствовать той же сделке на AMM максимизации функции . Доказательство этого оставлено в качестве упражнения для читателя. ↩
7. Arbitrum обсуждал замену этого на форму упорядочения приоритетов под названием Timeboost, но на момент написания этой статьи она не была запущена в производство. ↩

Отказ от ответственности:

1. Эта статья перепечатана из [paradigm]. Все авторские права принадлежат оригинальному автору [Dan Robinson & Dave White]. Если у вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они оперативно рассмотрят их.

2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются какими-либо инвестиционными рекомендациями.

3. Переводом статьи на другие языки занимается команда Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.