Paradigm изобрела новый механизм, налог MEV, который может изменить существующий ландшафт DeFi

Эта статья взята из Priority Is All You Need

Автор оригинала: Дэн Робинсон, Дэйв Уайт

Составил: Odaily Planet Daily Husband

4 июня издание Paradigm опубликовало статью Priority Is All You Need, в которой подробно описан новый механизм налога на электроэнергию (MEV).

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

Появление налогового механизма MEV может оказать влияние на существующую экосистему DeFi:

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

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

• Решить некоторые проблемы в DeFi:M, такие как оптимизация маршрутизации DEX, сокращение потерь AMM на арбитраж, сокращение утечки MEV пользователей кошельков и т. д. Вводя налог MEV, приложения могут улучшить свои продукты и услуги, тем самым повышая эффективность и устойчивость экосистемы DeFi.

Цитаты

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

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

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

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

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

Маршрутизатор децентрализованной биржи (DEX), который оптимизирует цены, получаемые обменниками

Автоматизированный маркет-мейкер (AMM), который минимизирует потери поставщика ликвидности (LVR) из-за ребалансировки

Кошелек, который позволяет пользователям захватить любые «резервные» MEV, сгенерированные их транзакциями.

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

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

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

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

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

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

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

Налог на МЭВ

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

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

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

Эта новая комиссия оплачивается искателем, отправляющим транзакцию, поэтому она влияет на поведение этого искателя. Если в возможности есть 100 ETH 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 .

Однако есть важное предостережение. Как обсуждалось в разделе «Ограничения», налог 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 gas это приведет к тому, что предлагающему блок лицу будет выплачено всего около 10 миллиардов wei (около $0.000035).)

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

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

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

Автоматизированный маркет-мейкер (AMM)

Обычно утечка стоимости 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 Эта формула будет стимулировать арбитражных трейдеров торговать по истинной цене, после чего срединная цена пула должна стать истинной ценой.

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

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

Аукционы с обратной ставкой

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

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

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

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

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

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

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

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

• Такие протоколы, как Oval, работают, фиксируя извлекаемую ценность оракула (OEV), которую они создают.

• Аукционы рефинансирования в протоколах кредитования с обеспечением NFT, таких как Blend.

• Ликвидация кредитных протоколов приводит к меньшим потерям стоимости, чем голландские аукционы.

Кросс-приложение захвата MEV

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

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

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

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

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

В простом случае налога MEV, который линейен по priorityPerGas (то есть tax_ 1(priorityPerGas) = a_ 1 * priorityPerGas), можно вычислить долю MEV, которую получает каждое приложение:

a_1 * приоритетНаГаз + a_2 * приоритетНаГаз = МЭВ

приоритетНаГаз = МЭВ/(a_ 1 + a_ 2)

налог_1(приоритетЗаГаз) =(a_1/(a_1+a_2))*MEV

налог_2(приоритетЗаГаз) = (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 в конечном итоге будет арбитражироваться в первую очередь, даже если в книге заказов UniswapX будет только $1 MEV и $50,000 MEV.

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

ограничение

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

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

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

• Сортировка по приоритету: Транзакции в блоке должны быть отсортированы в порядке убывания priorityFeePerGas.

• Устойчивость к цензуре: Если инициатор блока получает транзакцию t 1 при построении блока, а блок не заполнен или содержит транзакцию t 2 , и t 2.priorityFeePerGas

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

• Нет никакой окончательности. Заявители блоков должны установить определенное время (blockTime), до которого они принимают транзакции от кого угодно и после которого они не принимают транзакции от кого угодно.

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

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

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

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

Полный блок

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

Откат транзакции

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

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

Раскрытие намерений пользователя

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

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

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

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

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

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

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

Обсуждение и предварительная работа

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

Первый пришел, первый обслужен. С помощью правил последовательности транзакций (таких как Фемида или Текущий секвенсор Arbitrum Ones Некоторые попытки смягчить MEV были сосредоточены на применении другого правила упорядочения — «первым пришел, первым обслужен» (иногда называемого «справедливым упорядочением»), при котором лица, предлагающие блоки, должны упорядочивать транзакции в том порядке, в котором они их видят.

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

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

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

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

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

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

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

Существуют и другие исследования по созданию механизмов построения блоков с минимальным доверием, включая SUAVE от Flashbots, Angstrom от Sorella, Leaderless Auctions, децентрализованный Timeboost от Espresso и Offchain Labs, а также принудительное публичное пакетирование транзакций от Петера Силаги.

в заключение

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

Мы также надеемся, что это вдохновит на дальнейшие исследования протоколов приоритизации конфликтов, минимизирующих доверие на уровнях L1 и L2.

сноска

1. В этой статье мы используем термин «предлагающий» для обозначения участника или процесса, который определяет, какие транзакции включены в конкретный блок. В Ethereum L2 эта роль обычно выполняется «секвенсором». В Ethereum L1 ее выполняет определенный валидатор Ethereum, называемый предлагающим, хотя предлагающие обычно передают задачу построения блоков на аутсорсинг конкурентному аукциону с участием «реле» и «строителей». Подробности того, как распределяются эти обязанности, выходят за рамки этой статьи.

2. Плата за приоритет за Gas на самом деле явно не указана в транзакции, но ее можно рассчитать в транзакции. Транзакция указывает цену Gas, но Ethereum также взимает базовую плату, которая берется из цены Gas и уничтожается. Для целей налога MEV базовую плату следует игнорировать, поскольку она не контролируется трейдером. Плата за приоритет за Gas (т. е. цена части платы за транзакцию, которая идет предлагающему блок) может быть рассчитана в Solidity как priorityGasPrice = tx.gasprice – block.basefee.

3. Мы можем просто определить «MEV», чтобы исключить любую прибыль поисковика и ссылаться только на стоимость, которая поступит к валидаторам.

4. Обратите внимание, что suggesterPriorityFee на самом деле не может быть рассчитан как кратное от суммы priorityFeePerGas (равной общему количеству Gas, использованному в транзакции) во время контракта, поскольку нет способа узнать, сколько Gas в конечном итоге будет использовано транзакцией. Однако это обычно не имеет значения, так как нам нужна только верхняя граница. Для надежности вы можете умножить priorityFeePerGas на 30 миллионов — текущий максимальный Gas в блоке Ethereum. Переоценка этого значения будет означать только то, что налог MEV составляет большую долю MEV.

5. Если предположить, что транзакция не может превышать 30 миллионов Gas, priorityFeePerGas в размере 50 000 приведет к выплате Gas в размере 1500 gwei — около $0.006 по цене ETH $4,000.

6. Если priorityFeePerGas установлен таким образом, что прибыль арбитражера равна нулю, то арбитражная сделка, максимизирующая прибыль, должна соответствовать той же сделке на AMM, максимизирующей функцию.

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

Эта статья взята из интернета: Paradigm изобрела новый механизм, налог MEV, который может изменить существующий ландшафт DeFi

По теме: Исследовательский институт Bitget: сектор мемов резко упал за выходные, ожидается, что LayerZero и zkSync выпустят токены

За последние 24 часа на рынке появилось много новых горячих валют и тем, и весьма вероятно, что они станут следующей возможностью заработать деньги. Необходимо обратить внимание на следующие секторы: Сектор мемов, сектор токенов фанатов Горячие токены поиска и темы пользователями: Scroll, Manta Network, BONK Потенциальные возможности для airdrop включают: Scroll, Orbiter Finance Время статистики данных: 20 мая 2024 г. 4:00 (UTC + 0) 1. Рыночная среда На прошлой неделе спотовый ETF BTC имел чистый приток в течение 5 дней подряд. Приток средств за последние две недели компенсировал все оттоки в апреле. BTC вырос на 9% за неделю, а цена колебалась около 67 000. Данные наблюдения за Федеральным резервом CME показывают, что вероятность Федерального…