Введение

В постоянной борьбе за улучшение производительности блокчейна для обработки массовых принятий, Monad выделяется как пионерская сила для оптимизации модели Ethereum Virtual Machine (EVM) с помощью серии низкоуровневых улучшений: асинхронного ввода-вывода, оптимизированного Patricia Trie, отложенного выполнения и Optimistic Concurrency Control для параллельной обработки [2]. Эти улучшения эффективно решают проблемы узких мест выполнения и неэффективного доступа к состоянию, наблюдаемые на платформах, таких как Ethereum, не жертвуя децентрализацией.

В этом посте мы рассмотрим возможные варианты реализации надежной инфраструктуры аукциона Miner Extractable Value (MEV) на Monad. Мы также описываем некоторые переносимые, ценные уроки от существующих подходов, таких как Flashbots на Ethereum и Jito Network на Solana.

Мы хотим выделить несколько ключевых моментов:

1. MEV присущ любой блокчейн-сети. Надежная инфраструктура MEVA имеет решающее значение для предотвращения беспорядочного процесса производства блоков с негативными внешними эффектами и несогласованными стимулами.
2. Дизайн MEVA глубоко интегрирован с базовой механикой цепочки, особенно с ее этапом консенсус-исполнения. Будущие усовершенствования будут зависеть от эволюции этих факторов и производительности сети при разных уровнях нагрузки.
3. Исторические тенденции в эволюции производства блоков, как это видно на Ethereum и Solana, могут помочь разработке MEVA на Monad.
4. MEV на высокопроизводительных блокчейнах с отложенным выполнением, таких как Monad, скорее всего потребует вероятностных стратегий построения блоков и поиска, аналогичных высокочастотной торговле, из-за временных ограничений.

Адресуя эти моменты, мы надеемся предоставить понимание вызовов и соображений, связанных с разработкой инфраструктуры MEVA, адаптированной к уникальной архитектуре и производственным требованиям Monad.

Ландшафт MEV в Ethereum

MEVА в рамках стадии выполнения согласования Ethereum

В Ethereum согласование требует предварительного выполнения. Когда узлы соглашаются о блоке, они соглашаются как с списком транзакций в блоке, так и с корнем Меркля, подводящим итог постфактум-состояния после выполнения блока. Следовательно, лидеры должны выполнить все транзакции в предложенном блоке перед распространением предложения. Тем временем, проверяющие узлы должны выполнить транзакции перед голосованием.

Рисунок 1: Процесс сборки в MEV-Boost в рамках EL-CL разделения.

На рисунке 1 показан типичный рабочий процесс строителя в MEV-Boost для разделения Proposer-Builder (PBS). Строители завершают построение блоков и отправляют их на ретрансляцию, которая пересылает блоки клиенту Execution Layer (EL) для симуляции и проверки на валидность.

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

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

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

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

Итерация продукта по мере зрелости сети

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

Рисунок 2: Хронологический обзор того, как MEVA итерируется по мере продвижения сети Ethereum вперед. Рисунок немного адаптирован из [4].

Эра приоритетного газового аукциона (PGA)

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

В этот период происходили конкурентные и затратные неструктурированные MEV-активности, такие как транзакции с тем же (счет, номер) парой и увеличение ставок [6], что приводило к перегрузке сети или нестабильности консенсуса.

Рисунок 3: Простой приоритетный газовый аукцион. Рисунок слегка адаптирован из [6].

Flashbots и EIP-1559

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

Структура комиссий EIP-1559 также играет роль здесь [7]. Она упростила торговлю, введя частично размещенные цены через базовые сборы, но не решала проблему порядка транзакций внутри блоков, который по-прежнему определяет MEV через приоритетные сборы. На самом деле, многие поисковики раньше выражали свои ставки прямо майнерам через передачу coinbase. Они заканчивали с более жалобами на комиссии coinbase, потому что больше не могли отправлять пакеты из 0 газов.

Рисунок 4: MEVA с реле. Рисунок немного адаптирован из [6].

Разделение предложителя-строителя (PBS)

После перехода Ethereum к доказательству доли (PoS) после слияния, было внедрено разделение Пропозер-Строитель (PBS) для дальнейшего уточнения разделения ролей в процессе производства блоков. Как описано ранее, ретрансляторы теперь действуют в качестве посредников между строителями блоков и пропозерами, выступая в роли хранителей, обеспечивающих доступность данных и действительность блока. Поскольку пропозер может подключаться к нескольким строителям для различных частных транзакций, строители должны конкурировать, предлагая платежи пропозеру. Эта динамика иллюстрируется на рисунке 5.

Рисунок 5: MEVА в эпоху PBS. Этот рисунок немного адаптирован из [6].

Риски концентрации

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

Рисунок 6: Доля рынка строителей. График указывает на высокую концентрацию, преобладающую на рынке строителей. График взят из https://arxiv.org/pdf/2405.01329

Jito на Solana

Архитектура Jito

Jito, как канонический MEVA на Solana, был создан для решения проблемы высокой скорости спама на Solana из-за низких транзакционных издержек. Спам-сделки эффективно стимулируются, пока стоимость неудачной транзакции (примерно 0,000005 SOL) не превышает ожидаемую прибыль.

Согласно отчету Jito Labs за 2022 год [8], более 96% попыток арбитража и ликвидации завершились неудачей, при этом блоки содержали более 50% транзакций, связанных с MEV. Отчет также подчеркивает, что боты по ликвидации спамят сеть миллионами дублированных пакетов, лишь чтобы осуществить несколько тысяч успешных ликвидаций, что приводит к проценту неудач выше 99% [8].

Рисунок 7: Общий вид MEVA Jito на Solana.

Серьезность внешних эффектов MEV на Solana привела Jito к созданию слоя MEVA, направленного на введение порядка и детерминизма в процесс производства блоков. Давайте рассмотрим оригинальную архитектуру MEVA, предложенную Jito, как показано на рисунке 7.

Jito имеет следующие компоненты:

Реле - действует как прокси-сервер для получения транзакций и пересылает их как к движку блоков (или цепочке поставок MEVA), так и валидаторам.

Block Engine - поглощает транзакции от ретранслятора, координируется с поисковиками, принимает пакеты, выполняет симуляции пакетов и пересылает лучшие транзакции и пакеты валидатору для обработки. Особенно Jito проводит частичный аукцион блоков для включения пакетов вместо полного блочного аукциона, исторически обрабатывая более 80% пакетов в пределах двух слотов [9].

Псевдо Mempool - создает операционное временное окно примерно в 200 миллисекунд с помощью клиента Jito-Solana, вызывая дискретизированный аукцион для потока ордеров [10]. Jito закрыл этот mempool 9 марта 2024 года.

Выборы дизайна Jito

Давайте изучим конкретные компоненты системы Jito и рассмотрим, как эти выборы дизайна проистекают из процесса производства блоков в Solana.

Jito поддерживает только частичные аукционы блоков, а не полное построение блоков, вероятно из-за многопоточной модели выполнения Solana, которой не хватает глобального планирования. В частности, на рисунке 8 показаны параллельные потоки, выполняющие транзакции, каждый из которых поддерживает свою собственную очередь транзакций, ожидающих выполнения. Транзакции случайным образом назначаются потокам и локально упорядочиваются по приоритетной комиссии и времени. Без глобального упорядочивания со стороны планировщика (до обновления 1.18.x), транзакции Solana неизбежно испытывают недетерминизм от дрожания планировщика [11]. Следовательно, в MEVA искатели или валидаторы не могут надежно определить текущее состояние.

Рисунок 8: Многопоточная модель выполнения для клиента Solana. Обратите внимание, что MEVA’s Bundle Stage добавляется как отдельный поток в многопоточную очередь.

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

Для решения этой проблемы Jito предварительно выделяет часть блокчейн-пространства для потоков пакетов, обеспечивая наличие места для пакетов в блоке. Хотя неопределенность остается, такой подход увеличивает вероятность успешного выполнения стратегии. Он также стимулирует поисковиков принимать участие в аукционе вместо спама сети. Резервирование блокчейн-пространства для пакетов позволяет Jito найти баланс между продвижением организованных аукционов и смягчением хаотических последствий спама транзакциями.

Удаление псевдо-пула памяти

Широкое принятие Jito привело к положительным результатам в смягчении проблемы спама в Solana. Исследования, проведенные p2p [12] и данные, представленные на рисунке 9, показывают статистически значимое улучшение относительной скорости производства блоков после принятия клиента Jito. Это указывает на то, что обработка транзакций стала более эффективной благодаря оптимизированному блочному движку Jito, введенному в 2023 году.

Рисунок 9: Доказательства эффективности Jito в устранении проблемы спама на Solana. График извлечен из исследования [12], проведенного командой p2p.

Хотя был сделан значительный прогресс, остаются многие проблемы. Поскольку пакеты Jito заполняют только частично блоки, транзакции, вызывающие MEV, все еще могут обходить аукционный канал Jito. Эта проблема по крайней мере частично подтверждается панелью управления Dune на рисунке 10 [13], которая показывает, что сеть по-прежнему сталкивается со средним более чем 50% неудачных транзакций из-за спама ботов с 2024 года.

Рисунок 10: Приборная панель Dune ( https://dune.com/queries/3537204/5951285) иллюстрирующий активности спам-ботов на Solana с мая 2022 года.

9 марта 2024 года Jito приняла решение приостановить работу своего флагманского мемпула. Это решение было вызвано ростом транзакций мемкоинов и соответствующим всплеском сэндвич-атак (тип опережения, когда пользователи размещают транзакции до и после целевой транзакции), что в конечном итоге ухудшило пользовательский опыт. Подобно тенденциям, наблюдаемым в Ethereum с частными каналами потока ордеров в MEVA, закрытие публичного мемпула может стимулировать рост потока частных заказов за счет партнерства с фронтенд-сервисами, такими как поставщики кошельков и боты Telegram. Поисковики могут формировать партнерские отношения с валидаторами напрямую для предпочтительного исполнения, включения, исключения. На самом деле, доказательство этого можно увидеть на рисунке 11, который иллюстрирует почасовой профиль прибыли сэндвич-бота для крупнейшего частного искателя мемпула (3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81) после завершения работы мемпула.

Рисунок 11: Часовая прибыль для Sandwich Bot с частным Mempool для Searcher “3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81”.

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

Дизайн MEVA на Monad

Отложенное выполнение и его последствия для MEV

В отличие от Ethereum, где согласование блока требует как списка транзакций (с учетом порядка), так и корневого дерева Меркля, подводящего итоги всех состояний после факта, Monad отделяет предшествующее выполнение от консенсуса. Согласование узлов требует только урегулирования официального порядка. Как показано на рисунке 12, каждый узел выполняет транзакции в блоке N независимо, начиная согласование по блоку N+1. Такая организация позволяет использовать газовый бюджет, соответствующий полному времени блока, поскольку выполнение должно лишь удерживать темп с консенсусом. [15] Без необходимости для ведущего узла вычислять фактический корень состояния, выполнение может использовать весь период консенсуса для следующего блока.

Рисунок 12: Отложенное выполнение Monad в сравнении со стадией Execution-Consensus в Ethereum. Операционное временное окно также проиллюстрировано с точки зрения проектирования MEVA.

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

1. Когда MEVA строится для N-го блока в течение операционного временного окна, валидаторы одновременно согласовывают список транзакций для N-го блока, пытаясь завершить выполнение N-1-го блока. Следовательно, в пределах операционного окна в точке N, вполне возможно, что доступное состояние все еще находится на уровне N-2. Это означает, что в этой архитектуре отложенного выполнения не гарантируется «самое последнее состояние» для ретранслятора или построителя. Следовательно, невозможно смоделировать последний блок до того, как будет создан следующий, что приводит к индетерминизму.
2. Учитывая 1-секундное время блока Monad, оперативное время для MEVA крайне ограничено. Это означает, что строители могут не иметь достаточно времени, чтобы последовательно моделировать полные блоки транзакций и пакеты, как они обычно делают в Ethereum. Многие переменные могут повлиять на время, необходимое для моделирования транзакции на EVM. Однако, предполагая, что моделирование транзакции занимает от 10^1 до 10^2 микросекунд (грубо говоря), и с целью Monad в 10^4 транзакций в секунду, для моделирования полного блока в течение оперативного временного окна может потребоваться примерно 1 полная секунда. Учитывая 1-секундное время блока Monad, строителям или реле будет сложно завершить несколько полных моделирований блоков для оптимизации построенного блока.

Стратегия вероятностного построителя и поисковика

Учитывая ограничения, завершение полной симуляции блока в рамках рабочего временного интервала и симуляция против самого последнего состояния является непрактичным. Поскольку строители теперь лишены как времени, так и самого последнего состояния, чтобы знать точный кончик от каждой транзакции, они должны делать выводы о кончике исследователя на основе вероятности отмены транзакции, полагаясь на репутацию или симулируя против (возможно, в лучшем случае) N-2 состояния. Это делает оценку блока менее детерминированной.

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

Рисунок 13: Концептуальная спектральная диаграмма, иллюстрирующая различные парадигмы проектирования MEVA, классифицированные по степени предлагаемой блочной проверки или симуляции.

Как показано на рисунке 13, степень предварительной проверки пакета/блока со стороны строителя создает спектр неопределенности в отношении цены или оценки предлагаемого блока. С одной стороны, это модель PBS в стиле Ethereum с точным ценообразованием, где разработчики должны использовать клиент уровня исполнения (EL) для имитации транзакции в предлагаемом блоке. Им приходится перемещаться по широкому спектру комбинаторик среди представленных пакетов. На другом конце находится Optimistic Builder Model [16] с асинхронной проверкой блоков. В этой модели строители обходят время, необходимое для любой симуляции в течение рабочего временного окна, и соблюдают советы, показанные валидаторам или ретранслятору, внося залог, подлежащий слэшингу. Вероятностная проверка или частичное моделирование, предложенная здесь, на Monad, находится где-то посередине, повышая вероятность успешного выполнения стратегии для искателей, несмотря на некоторый индетерминизм.

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

Заключительные замечания

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

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

Disclaimer：

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