Автор оригинала: АПРИОРИ ⌘
Оригинальная компиляция: Shenchao TechFlow
представлять
В процессе повышения производительности блокчейна для создания крупномасштабных приложений Monad эффективно оптимизирует модель виртуальной машины Ethereum (EVM). Эти улучшения устраняют узкие места выполнения и проблемы неэффективного доступа к состоянию на таких платформах, как Ethereum, не жертвуя при этом децентрализацией.
В этой статье исследуется возможность создания надежной инфраструктуры аукционов с извлекаемой стоимостью майнеров (MEVA) на Monads, опираясь на ценный опыт Flashbots на Ethereum и Jito Network на Solana.
Хотим выделить несколько ключевых моментов:
MEV является неотъемлемым свойством любой сети блокчейнов. Надежная инфраструктура MEVA имеет решающее значение для предотвращения негативных внешних эффектов и несогласованности стимулов в процессе производства блоков.
Конструкция MEVA тесно связана с основным механизмом блокчейна, особенно с этапом выполнения консенсуса. Будущие улучшения будут зависеть от развития этих факторов и того, как сеть будет работать при различных нагрузках.
Исторические тенденции в производстве блоков на Ethereum и Solana могут служить отправной точкой для проектирования MEVA на Monads.
В высокопроизводительном блокчейне с отложенным выполнением, таком как Monad, MEVA может потребоваться вероятностное построение блоков и стратегии поиска, аналогичные высокочастотной торговле, чтобы справиться с ограничениями по времени.
Изучая эти вопросы, мы надеемся получить представление о проектировании инфраструктуры MEVA, которая будет учитывать уникальные архитектурные и производительные потребности Monad.
История MEVA в Ethereum
MEVA на этапе исполнения консенсуса Ethereum
В Эфириуме сначала необходимо достичь консенсуса. Когда узлы согласовывают блок, они согласовывают не только список транзакций в блоке, но и корень Меркла, который суммируется после выполнения блока. Следовательно, предлагающий должен выполнить все транзакции в блоке, прежде чем распространять предложение. В то же время узлам проверки также необходимо выполнить эти транзакции перед голосованием.
Рисунок 1. Рабочий процесс Builder для разделения предлагающего и разработчика (PBS) в MEV-Boost.
На рис. 1 показан типичный рабочий процесс разработчика для разделения предлагающего и разработчика (PBS) в MEV-Boost. После того, как строитель завершает построение блока, он отправляет его ретранслятору, который пересылает блок клиенту уровня исполнения (EL) для моделирования и проверки достоверности.
Поскольку выполнение является обязательным условием для достижения консенсуса, когда разработчик создает блок, ему необходимо переслать блок клиенту уровня выполнения (EL) и смоделировать блок, чтобы проверить его достоверность. Помимо своей необходимой роли на этапе достижения консенсуса, этап моделирования также приносит пользу разработчикам и исследователям.
С точки зрения строителя: моделируя каждую транзакцию, строители могут точно оценить ценность блока для себя и валидаторов. Они также могут попытаться изменить порядок транзакций, чтобы минимизировать откаты и максимизировать комиссию за газ или базовые чаевые, полученные из мемпула и связанных транзакций. Точные оценки позволяют им предлагать более высокие ставки для валидаторов.
С точки зрения поисковика: поскольку строитель отфильтровывает связанные транзакции, которые могут быть отменены, прежде чем транзакция будет помещена в цепочку, поисковик может гарантировать выполнение стратегии, повышая уверенность. Кроме того, поисковики могут получить доступ к последнему статусу блокировки. Когда уровень консенсуса (CL) распространяет новый блок, поисковики могут использовать состояние блока в качестве отправной точки для построения прибыльных связанных транзакций. В то же время есть признаки того, что разработчики теперь предлагают больше внепротокольных транзакций или функций, которые позволяют поисковикам получать информацию о статусе предстоящих блоков, чтобы добавить резервные стратегии к предстоящим блокам.
Однако рост PBS привел к усилению централизации построения блоков, аналогично ситуации в традиционной торговле, где компании конкурируют за выделенные каналы микроволновой сети, чтобы отдать приоритет реализации арбитражных стратегий.
По мере развития сети продукты обновляются.
Теперь мы рассмотрим, как развивалась MEVA по мере развития Ethereum, как показано на рисунке 2.
Рисунок 2. Хронологический взгляд на MEVA по мере развития сети Ethereum.
Эра приоритетного газового аукциона (PGA)
Как показано на рисунке 3, поисковики выявляют выгодные возможности MEV и отправляют транзакции смарт-контрактов в публичный мемпул. Эта публичная видимость приводит к публичным торгам и аукционам по единой цене в сети, где даже неудачные транзакции влекут за собой комиссию за газ.
В этот период наблюдалась высококонкурентная и дорогостоящая неструктурированная деятельность MEV, такая как транзакции с идентичными парами (счета, объявления) и возрастающие ставки, что приводило к перегрузке сети или нестабильности консенсуса.
Рисунок 3: Простая диаграмма приоритетного газового аукциона
Флешботы 和 EIP-1559
Чтобы решить эти проблемы, Flashbots представили ретрансляторы в качестве промежуточных аукционных домов между поисковиками и производителями блоков (майнеры в эпоху PoW). Этот шаг преобразует рынок MEV из аукциона первой цены с открытыми торгами в закрытые торги. Как показано на рисунке 4, ретрансляторы помогают предотвратить эскалацию ставок в общедоступном мемпуле и создать более упорядоченный и безопасный процесс производства блоков.
Здесь также играет роль структура комиссий EIP-1559. Это упрощает торги за счет базовых комиссий, но не решает проблему порядка транзакций внутри блоков, которая по-прежнему стимулирует MEV за счет приоритетных комиссий. Фактически, многие пользователи ранее делали ставки непосредственно майнерам посредством переводов в Coinbase. В итоге у них появилось больше жалоб на комиссии Coinbase, потому что они больше не могли отправлять транзакции, связанные с нулевым газом.
Рисунок 4: MEVA с реле
Разделение предлагающих и строителей (PBS)
После того, как Ethereum завершил слияние и перешел на Proof-of-Stake (PoS), было реализовано разделение предлагающего и создателя (PBS) для дальнейшей оптимизации разделения ролей в конвейере производства блоков. Как упоминалось ранее, ретрансляторы теперь выступают в качестве посредников между создателями блоков и предлагающими, ответственными за обеспечение доступности данных и достоверности блоков. Поскольку предлагающие могут подключать нескольких разработчиков для различных частных транзакций, строителям приходится конкурировать, выплачивая комиссию предлагающим. Эта динамика проиллюстрирована на рисунке 5.
Рисунок 5: MEVA в эпоху PBS
риск концентрации
Несмотря на эти исторические достижения, важно подчеркнуть растущий риск концентрации на строительном рынке. За последний год девять крупнейших застройщиков последовательно захватили более 50% рынка, продемонстрировав высокую степень концентрации рынка, как показано на рисунке 6. Текущее состояние концентрации еще более выражено: три крупнейших застройщика охватывают более 90% блоков.
Рисунок 6: Доля рынка застройщиков. Этот рисунок иллюстрирует высокую степень концентрации, преобладающую на рынке застройщиков (источник изображения).
Хито на Солане
Системная архитектура Jito
Являясь стандартным MEVA на Solana, Jito был создан для решения проблемы большого количества спама в Solana из-за низких транзакционных издержек. Пока комиссия за неудачную транзакцию (приблизительно 0,000005 SOL) не превышает ожидаемую прибыль, спам-рассылка эффективно стимулируется.
Согласно отчету Jito Labs за 2022 год, более 96% попыток арбитража и ликвидации в этом году потерпели неудачу, а блоки содержали более 50% транзакций, связанных с MEV. В отчете также говорится, что ликвидационные боты отправили в сеть миллионы повторяющихся пакетов только для того, чтобы завершить тысячи успешных ликвидаций, в результате чего уровень неудач превышает 99%.
Рисунок 7: MEVA Хито на Солане.
Серьезность проблемы внешних эффектов MEV на Солане побудила Джито разработать слой MEVA, предназначенный для придания порядка и уверенности в процессе производства блоков. Давайте рассмотрим исходную архитектуру MEVA, предложенную Джито и показанную на рисунке 7.
Джито состоит из следующих компонентов:
Релеер — действует как прокси-сервер для получения транзакций и пересылки их в механизм блоков (или цепочку поставок MEVA) и валидаторам.
Block Engine — получает транзакции от ретрансляторов, координирует поисковые системы, принимает пакеты, выполняет моделирование пакетов и пересылает лучшие транзакции и пакеты валидаторам для обработки. Стоит отметить, что Jito проводит аукционы частичных блоков для включения в пакеты, а не аукционы полных блоков, и исторически обрабатывал более 80% пакетов в двух слотах.
Пул псевдопамяти — создает окно времени операции длительностью около 200 миллисекунд через клиента Jito-Solana, запуская дискретный аукцион потока заказов. Джито закрыл этот мемпул 9 марта 2024 года.
Выбор дизайна Джито
Давайте рассмотрим конкретные компоненты конструкции системы Jito и рассмотрим, как этот выбор конструкции связан с процессом производства блоков Solana.
Jito поддерживает только аукционы частичных блоков, а не сборку полных блоков, вероятно, из-за отсутствия глобального планирования в многопоточной модели выполнения Solana. В частности, на рисунке 8 показаны параллельные потоки, выполняющие транзакции, причем каждый поток поддерживает свою собственную очередь транзакций, ожидающих выполнения. Транзакции случайным образом распределяются по потокам и упорядочиваются локально по приоритету комиссии и времени. Без глобального упорядочения на стороне планировщика (до обновления 1.18.x) транзакции Соланы по своей сути были бы недетерминированы из-за сбоев в работе планировщика. Поэтому в MEVA поисковик или верификатор не может достоверно определить текущее состояние.
Рисунок 8: Модель многопоточного выполнения клиента Solana. Обратите внимание, что фаза объединения MEVA присоединяется к многопоточной очереди как отдельный поток.
С инженерной точки зрения параллельная работа блочного движка Jito в качестве дополнительного потока хорошо вписывается в многопоточную архитектуру Solana. Хотя пакетный аукцион обеспечивает приоритетный платный заказ в потоке механизма блоков Jito, нет никакой гарантии, что пакеты всегда будут глобально иметь приоритет над пользовательскими транзакциями.
Чтобы решить эту проблему, Jito предварительно выделяет часть пространства блока для потока объединения, чтобы гарантировать, что для объединения есть место в блоке. Хотя неопределенность остается, такой подход увеличивает вероятность успешной реализации стратегии. Это также стимулирует пользователей участвовать в аукционе, а не рассылать спам в сети транзакциями. Резервируя пространство в блоках для объединения, Jito может найти баланс между продвижением упорядоченных аукционов и смягчением хаотических последствий транзакционного спама.
Удалить пул псевдопамяти
Широкое распространение Jito дало положительные результаты в уменьшении проблем со спамом на Solana. Согласно исследованию p2p и данным, показанным на рисунке 9, относительная производительность блоков значительно увеличивается после внедрения клиента Jito. Это показывает, что обработка транзакций стала более эффективной благодаря оптимизированному механизму блоков, представленному Jito в 2023 году.
Рисунок 9: Доказательства того, что Jito эффективно решает проблему спама на Solana. Эта диаграмма взята из исследования, проведенного командой p2p.
Несмотря на значительный прогресс, остается еще много проблем. Поскольку пакеты Jito лишь частично заполняют блоки, транзакции, вызванные MEV, все равно могут обходить канал аукциона Jito. Часть доказательств можно найти на информационной панели Dune на рисунке 10, где показано, что с 2024 года в сети по-прежнему происходит в среднем более 50% сбоев транзакций из-за спам-транзакций ботов.
Рисунок 10. Панель мониторинга спам-ботов Dune на Solana с мая 2022 года (подробности см. в Dune).
9 марта 2024 года Jito решила приостановить работу своего флагманского пула памяти. Решение было принято из-за роста количества транзакций мемкойнов и, как следствие, всплеска сэндвич-атак (когда поисковики размещают транзакции до и после целевой транзакции), что в конечном итоге повлияло на пользовательский опыт. Подобно каналу потока частных заказов MEVA на Ethereum, закрытие общедоступного мемпула может способствовать росту потока частных заказов за счет сотрудничества с внешними службами, такими как поставщики кошельков и боты Telegram. Поисковики могут вступить в партнерство напрямую с валидатором, чтобы получить права приоритетного исполнения, включения или исключения.
Фактически, на рисунке 11 показана почасовая прибыль сэндвич-бота для крупнейшего частного поисковика в мемпулах после закрытия мемпула.
Крупнейший поисковик приватных мемпулов:
3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81
(Примечание переводчика: сэндвич-робот — это распространенный инструмент для опережающих атак, который в основном используется для получения прибыли от транзакций блокчейна).
Рисунок 11. Прибыль сэндвич-бота в час при использовании частного мемпула для поисковика «3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81».
Решение Джито закрыть мемпул демонстрирует приверженность команды решению фундаментальных проблем в экосистеме Solana. Помимо итерации MEVA или настройки механизма платы за газ Solana, Jito помогает протоколу снизить риск атак за счет выбора дизайна пользовательского интерфейса, такого как ограничение параметров проскальзывания по умолчанию. Будь то корректировка структуры комиссий, которая делает спам-транзакции более дорогими, или модификация протокола связи, инфраструктура Jito продолжит играть решающую роль в поддержании работоспособности и стабильности сети Solana.
Дизайн MEVA на Monad
Задержка исполнения и ее влияние на MEVA
В отличие от Ethereum, где для согласования блока требуется список транзакций (с упорядочиванием) и корень Меркла, обобщающий все состояние после события, монады отделяют предыдущее выполнение от консенсуса. Протокол узла должен решить только официальную проблему заказа. Как показано на рисунке 12, каждый узел независимо выполняет транзакции в блоке N, когда начинает достигать консенсуса в блоке N+1. Такая схема позволяет создать бюджет газа, соответствующий полному времени блока, поскольку исполнение должно идти только в ногу с консенсусом. Поскольку узлу-лидеру не требуется вычислять корень состояния де-факто, выполнение может использовать весь период консенсуса для обработки следующего блока.
Рисунок 12: Сравнение отложенного исполнения Monad и фазы консенсуса исполнения Ethereum. Окна рабочего времени также показаны с точки зрения проектирования MEVA.
Мы определяем операционное временное окно как временной интервал, который позволяет MEVA завершить предложение по построению блоков на Монаде, которое является осуществимым и прибыльным по сравнению с методом построения блоков по умолчанию. Модель отложенного исполнения имеет два прямых последствия:
Когда MEVA создается для N-го блока в пределах временного окна операции, валидаторы одновременно достигают консенсуса по списку транзакций для N-го блока, пытаясь завершить выполнение N-1-го блока. Следовательно, в пределах N-го временного окна возможное доступное состояние все еще находится на уровне N-2. Это означает, что при такой архитектуре отложенного выполнения нет никакой гарантии, что реле или сборщик имеют «последнее состояние». Следовательно, невозможно моделировать последний блок до тех пор, пока не будет сгенерирован следующий блок, что приводит к неопределенности.
Учитывая, что время блока Monad составляет 1 секунду, окно времени работы MEVA чрезвычайно ограничено. Это означает, что у разработчиков может не хватить времени для последовательного моделирования транзакций и объединения полных блоков, как это обычно делается в Ethereum. Многие переменные могут повлиять на время, необходимое для проведения торговой симуляции на EVM. Однако если предположить, что моделирование транзакции занимает от 10^1 до 10^2 микросекунд (приблизительная оценка) и что Монада нацелена на 10^4 транзакций в секунду, моделирование полного блока в пределах окна рабочего времени может занять около 1 секунды. . Учитывая, что время блока Monad составляет 1 секунду, сборщику или ретранслятору будет сложно выполнить несколько полных симуляций блоков для оптимизации строительных блоков.
Вероятностный построитель и стратегии поиска
Учитывая эти ограничения, непрактично выполнять полное блочное моделирование в пределах рабочего временного окна и моделировать с учетом последнего состояния. Поскольку строителям сейчас не хватает ни времени, ни последнего статуса, чтобы знать точную подсказку каждой транзакции, они должны делать выводы о подсказке искателя на основе вероятности отката транзакции, полагаясь на репутацию или (вероятно, лучше всего) ориентируясь на симуляцию статуса N-2. . Это делает оценку блока менее достоверной.
Из-за отсутствия теоретических гарантий против отката транзакции поисковики сталкиваются с большей неопределенностью выполнения, когда валидаторы принимают блок, созданный разработчиком. Это контрастирует с Ethereum, где поисковики конкурируют в выделенных каналах передачи частных заказов разработчикам, выполняя относительно детерминированные стратегии. При такой настройке относительной вероятности в монадах поисковики теперь сталкиваются с более высоким риском отката пакета, что приводит к более неопределенному профилю PnL выполнения. Это похоже на высокочастотных трейдеров, которые совершают сделки на основе вероятностных сигналов и со временем достигают немного более высокой ожидаемой прибыли.
Рисунок 13: Концептуальная спектральная диаграмма, иллюстрирующая различные парадигмы проектирования MEVA, классифицированные в зависимости от степени проверки или моделирования предлагаемых блоков.
Как показано на рисунке 13, степень предварительной проверки пакетов/блоков со стороны застройщика создает спектр неопределенности с точки зрения ценообразования или оценки предлагаемых блоков. С одной стороны, это модель PBS в стиле Ethereum с точным ценообразованием, где разработчики должны использовать клиентов уровня исполнения (EL) для моделирования транзакций в предлагаемых блоках. Им необходимо ориентироваться в широком портфолио представленных пакетов. На другом конце находится оптимистичная модель компоновщика [16] с асинхронной проверкой блоков. В этой модели строитель обходит время, необходимое для любого моделирования в пределах рабочего окна, и обналичивает чаевые, показанные валидаторам или ретрансляторам, путем внесения залога (который может быть сокращен). Подход вероятностной проверки или частичного моделирования, предложенный здесь, в Monads, находится посередине, увеличивая вероятность того, что искатель успешно выполнит стратегию, несмотря на некоторую неопределенность.
Например, маркет-мейкер книги заказов DEX может заранее переместить свои позиции через MEVA при обнаружении крупных односторонних движений цен, чтобы избежать неблагоприятного выбора. Эта вероятностная стратегия позволяет им действовать быстро, даже без самой последней информации о состоянии, балансируя риск и вознаграждение в динамичной торговой среде.
Заключение
MEVA играет ключевую роль в оптимизации производства блоков, смягчении внешних воздействий и повышении стабильности системы. Продолжающееся развитие платформы MEVA, такой как Jito на Solana и различные реализации на Ethereum, значительно облегчило решение проблем масштабируемости и более согласованные стимулы для участников сети.
Monad — это многообещающая сеть, находящаяся в зачаточном состоянии, которая предлагает сообществу уникальную возможность разработать наилучшую MEVA. Учитывая уникальное разделение исполнения и консенсуса в Monad, мы приглашаем исследователей, разработчиков и валидаторов к сотрудничеству и обмену идеями. Это сотрудничество поможет создать надежный и эффективный процесс производства блоков, помогая Monad реализовать свои перспективы в качестве высокопроизводительной сети блокчейнов.
