Введение в смягчение MEV

Продвинутый12/17/2024, 7:06:29 AM
Этот пост относится к техникам смягчения внутри и вне протокола. Под техниками смягчения MEV внутри протокола мы подразумеваем механизмы, которые либо являются частью правил протокола Ethereum, либо требуют изменения правил протокола Ethereum. Техники смягчения вне протокола - это все механизмы, которые не являются внутри протокола.

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

Этот пост организован следующим образом:

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

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

В-третьих, мы исследуем, что делает протокол Ethereum, чтобы предотвратить негативные внешние эффекты MEV.

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

Начало этого поста является частичной систематизацией знаний о смягчении MEV. Однако четвертый раздел представляет относительно новый аргумент, что внепротокольное смягчение MEV не решает проблемы внутрипротокольного MEV. Этот аргумент основан на бумагапоДавиде Краписи я.

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

Минимизация внепротокольного MEV

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

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

Поставщики ликвидности (LP) предоставляют несколько разных токенов AMM и позволяют AMM устанавливать цены, по которым пользователи могут торговать токенами LP.

AMM корректирует свои цены только в ответ на транзакции, включенные в новые блоки. Такая дискретная корректировка контрастирует с непрерывными колебаниями цен базовых токенов на внешних рынках.

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

Эта форма MEV, известная как Loss-Versus-Rebalancing (LVR), является издержками для поставщиков ликвидности. При сохранении постоянных комиссий, начисляемых поставщикам ликвидности, объем предоставляемой ликвидности уменьшается вместе с объемом LVR, извлекаемым из AMM. Меньшая ликвидность означает, что пользовательские сделки оказывают большее влияние на цену, а это означает, что пользователям дороже торговать на AMM. Целью проектирования AMM является снижение стоимости, которую LVR налагает на AMM. Аналогичным образом, целью разработки приложений, как правило, является снижение затрат MEV для пользователей.

Существует много способов снизить стоимость MEV. Грубо говоря, методы смягчения MEV вне протокола делятся на две оси:

  • Техники смягчения MEV для прикладной или общей инфраструктуры.
  • Предотвращение MEV или возврат MEV.

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

Рисунок 1: 2-мерная категоризация методов смягчения MEV вне протокола с примерами для каждой категории.

Приложение-специфика и предотвращение MEV: функция, максимизирующая AMM.

Техника смягчения MEV, которая обычно концептуально наиболее интуитивна для тех, кто впервые слышит о MEV, это приложение, которое предотвращает экспозицию MEV. Захватывающий пример - функция максимизации AMMпредложенныйАндреа Канидио и Робин Фрич. Он пакетирует сделки, собранные за определенный период времени и исполняет все по равной цене очистки. Авторы показывают, что это устраняет LVR и другую форму MEV - сендвичинг. Интуиция заключается в том, что все участники торгуют по предельной цене пула после пакетирования, и арбитражеры получают стимул торговать до тех пор, пока эта цена не станет равной внешней рыночной цене. Эта система похожа на частые пакетные аукционы, предложенные gate.io.Budish, Cramton и Shim (2015)в традиционной финансовой литературе. Кстати, это отличный пример синергии между децентрализованной и традиционной финансовой сферами. Идеи традиционной финансовой сферы могут быть реализованы в децентрализованной финансовой сфере; опыт из реализации Затем может быть использован для информирования о традиционных финансах.

Приложение-Specific и Rebating MEV: Захват MEV AMM.

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

Инфраструктура и возмещение MEV: MEV-Share.

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

Инфраструктура и предотвращение MEV: защищенный поток заказов в мире, стремящемся к прибыли.

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

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

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

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

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

Отсутствие встроенного смягчения MEV

Эти методы снижения MEV могут показаться недостаточно удовлетворительными для некоторых. Почему Ethereum не может быть протоколом инфраструктуры, который целостно решает MEV? Может быть, некоторые читатели предложили бы использовать конкретное правило упорядочения. Предложения о принудительном применении определенного правила упорядочения в Ethereum, такие как В порядке живой очереди, не получили широкой поддержки. Я считаю, что есть две основные причины, по которым протокол не смог всесторонне решить проблему, которую МЭВ представляет для конечных пользователей и приложений - обе связаны с доверительным ограничением Эфириума.

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

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

Рисунок 2: Слайд, показывающий правила упорядочения первым пришел, первым обслужил, может застрять в циклах Кондорсе. Слайд взят из презентации о Темис от Махимны Келкар.

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

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

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

Интересным примером, который приближается к технике возврата MEV в протоколе, являетсяналоги MEV, предложенный Дэн РобинсониДэйв Уайт. Он позволяет любому приложению перегрузить приоритетную комиссию в протоколе, установив параметр, скажем, $k$. Любой пользователь, взаимодействующий с приложением, должен будет заплатить приоритетную комиссию в $k$ раз больше, чем он заплатил консенсусному валидатору, приложению. Вы можете видеть, как этот система может обеспечить возврат средств MEV приложениям обобщенным способом. Например, если из приложения можно извлечь 10 ETH MEV, с $k = 9$, будучи первым, кто с ним взаимодействует, пользователь может заплатить приоритетную комиссию в 1 ETH валидатору и 9 ETH приложению, предполагая, что транзакции упорядочены по приоритетной комиссии.

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

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

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

Зашифрованные mempool-ы работают в реальном времени на Gnosis Chain, блокчейне, который имеет архитектуру, аналогичную Ethereum. Участники экосистемы, в частности, gateСеть Shutter, стремится привнести зашифрованные пулы памяти в основную сеть Ethereum. Некоторые текущие ограничивающие факторы - это доверительные предположения, которые необходимы при использовании криптографических техник на основе порогового шифрования,состояние функций проверяемой задержки, и проблемы свободного доступа к даннымсвязанных с зашифрованными пулами транзакций.

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

Что делает протокол?

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

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

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

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

  • [ ] Подтверждение информации, необходимой для достижения согласия и создания блоков согласия, является наиболее важной ролью в системе согласия Proof-of-Stake Ethereum. Примеры включают подтверждение головы цепочки, подтверждение своевременностьсообщений и создание блоков консенсуса при необходимости. Вознаграждения за эти роли довольно однородны для всех участников.
  • [ ] Предложение выполнения блока. Эта роль обеспечивает живучесть слоя выполнения. Она может состоять в своевременной представлении выполнения полезной нагрузки и эффективном распределении прав на создание выполнения полезной нагрузки. Вознаграждения за эту роль зависят от уровня риска и скорости участника.
  • [ ] Построение блока выполнения. Эта роль определяет порядок транзакций в исполняемой нагрузке. Она имеет наибольший потенциал для извлечения MEV из системы, а также связана с ясной экономикой масштаба, высокими барьерами входа и сложностью. Вознаграждения для участников этой роли очень разнообразны.

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

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

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

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

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

Рисунок 3: Разделение труда по отделению аттестанта-предложителя (APS) и отделению предложителя-строителя (PBS) с использованием списков включения и продажей прав на строительство в качестве односторонних клапанов между ролями.

Нет единого решения для двух разных проблем

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

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

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

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

В качестве примера этого аргумента рассмотрим случай Потери по сравнению с балансировкой (LVR), ранее введенные как потери арбитража задержки ликвидности, с которыми поставщики ликвидности в AMM сталкиваются из-за того, что их он-чейн котировки остаются устаревшими между блоками по сравнению с непрерывно обновляемым внешним рынком. В своей работе Милионис и др. обнаружили, что накопленный LVR за слот пропорционален времени слота в степени 3/2.

На первый взгляд, это может указывать на то, что уменьшение времени слота также уменьшает MEV. LVR, однако, является потерями при арбитраже на единицу ликвидности. Более того, Джоэл Хасбрук, Томас Ривера и Фахад Салех.показалИндивидуальные позиции ликвидности можно рассматривать как объекты для инвестирования. Ожидаемая доходность активов обычно основана на их риске. Неясно, как изменится риск позиции ликвидности при уменьшении времени слота, но для аргумента предположим, что он остается постоянным. Тогда доходность позиции ликвидности должна оставаться постоянной независимо от времени слота; следовательно, если затраты на единицу ликвидности уменьшаются, то и доходы на единицу ликвидности также должны уменьшиться. В AMM доходы будут уменьшаться из-за увеличения ликвидности, поступающей в AMM. Большая ликвидность означает, что больше единиц ликвидности сталкиваются с LVR. Таким образом, агрегированный эффект неоднозначен. Таким образом, неясно, как изменится общее количество MEV, исходящее из LVR, если изменится время слота, даже если MEV на единицу стоимости может уменьшиться.

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

Таблица 1: Влияние времени слота на LVR, объем ликвидности и общий объем MEV. В этой таблице показано, как время слота влияет на LVR на каждый слот и на коэффициент, на который умножается ликвидность. Предполагается, что доход от комиссий остается постоянным, а возможные потери на каждый слот равны нулю. Результаты нормализованы с учетом значений, соответствующих базовому 12-секундному времени слота.

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

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

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

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

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

Введение в смягчение MEV

Продвинутый12/17/2024, 7:06:29 AM
Этот пост относится к техникам смягчения внутри и вне протокола. Под техниками смягчения MEV внутри протокола мы подразумеваем механизмы, которые либо являются частью правил протокола Ethereum, либо требуют изменения правил протокола Ethereum. Техники смягчения вне протокола - это все механизмы, которые не являются внутри протокола.

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

Этот пост организован следующим образом:

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

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

В-третьих, мы исследуем, что делает протокол Ethereum, чтобы предотвратить негативные внешние эффекты MEV.

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

Начало этого поста является частичной систематизацией знаний о смягчении MEV. Однако четвертый раздел представляет относительно новый аргумент, что внепротокольное смягчение MEV не решает проблемы внутрипротокольного MEV. Этот аргумент основан на бумагапоДавиде Краписи я.

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

Минимизация внепротокольного MEV

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

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

Поставщики ликвидности (LP) предоставляют несколько разных токенов AMM и позволяют AMM устанавливать цены, по которым пользователи могут торговать токенами LP.

AMM корректирует свои цены только в ответ на транзакции, включенные в новые блоки. Такая дискретная корректировка контрастирует с непрерывными колебаниями цен базовых токенов на внешних рынках.

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

Эта форма MEV, известная как Loss-Versus-Rebalancing (LVR), является издержками для поставщиков ликвидности. При сохранении постоянных комиссий, начисляемых поставщикам ликвидности, объем предоставляемой ликвидности уменьшается вместе с объемом LVR, извлекаемым из AMM. Меньшая ликвидность означает, что пользовательские сделки оказывают большее влияние на цену, а это означает, что пользователям дороже торговать на AMM. Целью проектирования AMM является снижение стоимости, которую LVR налагает на AMM. Аналогичным образом, целью разработки приложений, как правило, является снижение затрат MEV для пользователей.

Существует много способов снизить стоимость MEV. Грубо говоря, методы смягчения MEV вне протокола делятся на две оси:

  • Техники смягчения MEV для прикладной или общей инфраструктуры.
  • Предотвращение MEV или возврат MEV.

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

Рисунок 1: 2-мерная категоризация методов смягчения MEV вне протокола с примерами для каждой категории.

Приложение-специфика и предотвращение MEV: функция, максимизирующая AMM.

Техника смягчения MEV, которая обычно концептуально наиболее интуитивна для тех, кто впервые слышит о MEV, это приложение, которое предотвращает экспозицию MEV. Захватывающий пример - функция максимизации AMMпредложенныйАндреа Канидио и Робин Фрич. Он пакетирует сделки, собранные за определенный период времени и исполняет все по равной цене очистки. Авторы показывают, что это устраняет LVR и другую форму MEV - сендвичинг. Интуиция заключается в том, что все участники торгуют по предельной цене пула после пакетирования, и арбитражеры получают стимул торговать до тех пор, пока эта цена не станет равной внешней рыночной цене. Эта система похожа на частые пакетные аукционы, предложенные gate.io.Budish, Cramton и Shim (2015)в традиционной финансовой литературе. Кстати, это отличный пример синергии между децентрализованной и традиционной финансовой сферами. Идеи традиционной финансовой сферы могут быть реализованы в децентрализованной финансовой сфере; опыт из реализации Затем может быть использован для информирования о традиционных финансах.

Приложение-Specific и Rebating MEV: Захват MEV AMM.

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

Инфраструктура и возмещение MEV: MEV-Share.

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

Инфраструктура и предотвращение MEV: защищенный поток заказов в мире, стремящемся к прибыли.

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

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

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

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

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

Отсутствие встроенного смягчения MEV

Эти методы снижения MEV могут показаться недостаточно удовлетворительными для некоторых. Почему Ethereum не может быть протоколом инфраструктуры, который целостно решает MEV? Может быть, некоторые читатели предложили бы использовать конкретное правило упорядочения. Предложения о принудительном применении определенного правила упорядочения в Ethereum, такие как В порядке живой очереди, не получили широкой поддержки. Я считаю, что есть две основные причины, по которым протокол не смог всесторонне решить проблему, которую МЭВ представляет для конечных пользователей и приложений - обе связаны с доверительным ограничением Эфириума.

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

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

Рисунок 2: Слайд, показывающий правила упорядочения первым пришел, первым обслужил, может застрять в циклах Кондорсе. Слайд взят из презентации о Темис от Махимны Келкар.

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

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

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

Интересным примером, который приближается к технике возврата MEV в протоколе, являетсяналоги MEV, предложенный Дэн РобинсониДэйв Уайт. Он позволяет любому приложению перегрузить приоритетную комиссию в протоколе, установив параметр, скажем, $k$. Любой пользователь, взаимодействующий с приложением, должен будет заплатить приоритетную комиссию в $k$ раз больше, чем он заплатил консенсусному валидатору, приложению. Вы можете видеть, как этот система может обеспечить возврат средств MEV приложениям обобщенным способом. Например, если из приложения можно извлечь 10 ETH MEV, с $k = 9$, будучи первым, кто с ним взаимодействует, пользователь может заплатить приоритетную комиссию в 1 ETH валидатору и 9 ETH приложению, предполагая, что транзакции упорядочены по приоритетной комиссии.

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

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

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

Зашифрованные mempool-ы работают в реальном времени на Gnosis Chain, блокчейне, который имеет архитектуру, аналогичную Ethereum. Участники экосистемы, в частности, gateСеть Shutter, стремится привнести зашифрованные пулы памяти в основную сеть Ethereum. Некоторые текущие ограничивающие факторы - это доверительные предположения, которые необходимы при использовании криптографических техник на основе порогового шифрования,состояние функций проверяемой задержки, и проблемы свободного доступа к даннымсвязанных с зашифрованными пулами транзакций.

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

Что делает протокол?

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

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

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

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

  • [ ] Подтверждение информации, необходимой для достижения согласия и создания блоков согласия, является наиболее важной ролью в системе согласия Proof-of-Stake Ethereum. Примеры включают подтверждение головы цепочки, подтверждение своевременностьсообщений и создание блоков консенсуса при необходимости. Вознаграждения за эти роли довольно однородны для всех участников.
  • [ ] Предложение выполнения блока. Эта роль обеспечивает живучесть слоя выполнения. Она может состоять в своевременной представлении выполнения полезной нагрузки и эффективном распределении прав на создание выполнения полезной нагрузки. Вознаграждения за эту роль зависят от уровня риска и скорости участника.
  • [ ] Построение блока выполнения. Эта роль определяет порядок транзакций в исполняемой нагрузке. Она имеет наибольший потенциал для извлечения MEV из системы, а также связана с ясной экономикой масштаба, высокими барьерами входа и сложностью. Вознаграждения для участников этой роли очень разнообразны.

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

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

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

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

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

Рисунок 3: Разделение труда по отделению аттестанта-предложителя (APS) и отделению предложителя-строителя (PBS) с использованием списков включения и продажей прав на строительство в качестве односторонних клапанов между ролями.

Нет единого решения для двух разных проблем

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

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

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

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

В качестве примера этого аргумента рассмотрим случай Потери по сравнению с балансировкой (LVR), ранее введенные как потери арбитража задержки ликвидности, с которыми поставщики ликвидности в AMM сталкиваются из-за того, что их он-чейн котировки остаются устаревшими между блоками по сравнению с непрерывно обновляемым внешним рынком. В своей работе Милионис и др. обнаружили, что накопленный LVR за слот пропорционален времени слота в степени 3/2.

На первый взгляд, это может указывать на то, что уменьшение времени слота также уменьшает MEV. LVR, однако, является потерями при арбитраже на единицу ликвидности. Более того, Джоэл Хасбрук, Томас Ривера и Фахад Салех.показалИндивидуальные позиции ликвидности можно рассматривать как объекты для инвестирования. Ожидаемая доходность активов обычно основана на их риске. Неясно, как изменится риск позиции ликвидности при уменьшении времени слота, но для аргумента предположим, что он остается постоянным. Тогда доходность позиции ликвидности должна оставаться постоянной независимо от времени слота; следовательно, если затраты на единицу ликвидности уменьшаются, то и доходы на единицу ликвидности также должны уменьшиться. В AMM доходы будут уменьшаться из-за увеличения ликвидности, поступающей в AMM. Большая ликвидность означает, что больше единиц ликвидности сталкиваются с LVR. Таким образом, агрегированный эффект неоднозначен. Таким образом, неясно, как изменится общее количество MEV, исходящее из LVR, если изменится время слота, даже если MEV на единицу стоимости может уменьшиться.

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

Таблица 1: Влияние времени слота на LVR, объем ликвидности и общий объем MEV. В этой таблице показано, как время слота влияет на LVR на каждый слот и на коэффициент, на который умножается ликвидность. Предполагается, что доход от комиссий остается постоянным, а возможные потери на каждый слот равны нулю. Результаты нормализованы с учетом значений, соответствующих базовому 12-секундному времени слота.

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

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

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

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

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