Введение

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

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

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

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

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

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

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

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

Приоритетный заказ

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

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

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

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

налоги MEV

Предположим, что смарт-контракт хочет захватить 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 достаточно чувствителен, чтобы priorityFeePerGas в 50 000 привел к запретно высокому налогу, общий платеж предлагающему будет менее $0.01.5

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

Захват MEV в одно-приложении

Здесь мы набросаем, как на цепочке, гарантированно использующей конкурентоспособный приоритетный порядок для построения блоков, MEV-налоги могут быть использованы для смягчения трех важных проблем в MEV: позволяя интерфейсам DEX улучшать исполнение сделок для обменников, позволяя AMM снижать потери от арбитража для их LP, и позволяя кошелькам снизить утечку 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.

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

AMMs

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

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

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

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

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

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

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

Аукционы с заездом

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

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

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

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

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

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

Другие применения

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

• Протоколы для оракулов, чтобы захватить создаваемое ими оракульное извлекаемое значение, наподобиеОвал
• Аукционы рефинансирования в протоколах кредитования с залогом NFT, таких как Смешать
• Ликвидации протокола займа, которыепротечка меньшего значениячем голландские аукционы

Захват MEV межприложений

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

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

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

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

tax_1(priorityPerGas) + tax_2(priorityPerGas) = общий MEV

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

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

a_1 priorityPerGas + a_2priorityPerGas = 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 за каждую сделку, то MEV-налоговый ордер UniswapX может быть заполнен другой AMM или офчейн-заполнителем.

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

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

Ограничения

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

Несовместимость стимулов

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

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

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

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

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

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

Полные блоки

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

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

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

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

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

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

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

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

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

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

Возможно, также можно объединить налоги MEV с функциями конструктора, обеспечивающими конфиденциальность, как это предусмотрено в дизайнах Flashbots для СУАВЕ.

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

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

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

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

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

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

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

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

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

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

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

Были исследования по созданию механизмов для построения блоков с минимальным доверием, включая Flashbots’sСУАВЕ, SorellaАнгстрем, Аукционы без лидера, Эспрессо и Offchain Labs’@espressosys /espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">децентрализованный Timeboost, и обязательное включение публичных транзакций от Петера Силажи.

Заключение

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

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

Сноски

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

Disclaimer：

1. Эта статья перепечатана с [парадигма], Все авторские права принадлежат оригинальному автору [Дэн Робинсон, Dave White]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно разберутся с этим.
2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.