В постоянном стремлении улучшить производительность блокчейна для массового использования, Monad выделяется как ведущая сила, оптимизирующая модель Ethereum Virtual Machine (EVM) с рядом низкоуровневых улучшений: асинхронный ввод/вывод, оптимизированное Patricia Trie, отложенное выполнение и Оптимистичный контроль параллелизма для параллельной обработки. Эти улучшения эффективно устраняют узкие места в исполнении и неэффективный доступ к состоянию, наблюдаемые на таких платформах, как Ethereum, не жертвуя децентрализацией.
В этом посте мы исследуем возможные реализации надежной инфраструктуры аукционов Miner Extractable Value (MEVA) на Monad. Мы также описываем некоторые полезные уроки, перенятые из существующих подходов, таких как Flashbots на Ethereum и Jito Network на Solana.
Мы хотим выделить несколько ключевых моментов:
MEV присущ любой блокчейн-сети. Надежная инфраструктура MEVA важна, чтобы избежать беспорядочного процесса создания блоков с негативными внешними эффектами и несогласованными стимулами.
Дизайн MEVA тесно интегрирован с основными механиками цепочки, особенно с ее этапами консенсуса и выполнения. Будущие улучшения будут зависеть от эволюции этих факторов и производительности сети при различных уровнях нагрузки.
Исторические тенденции в эволюции производства блоков, как это видно на Ethereum и Solana, могут помочь в дизайне MEVA на Monad.
MEVA на высокопроизводительных блокчейнах с отложенным выполнением, таких как Monad, вероятно, потребует вероятностных стратегий построения и поиска блоков, подобных высокочастотной торговле, из-за ограниченного времени.
Рассматривая эти моменты, мы надеемся предоставить представление о вызовах и соображениях, связанных с проектированием инфраструктуры MEVA, адаптированной к уникальной архитектуре и требованиям производительности Monad.
В Ethereum консенсус требует предварительного выполнения. Когда узлы соглашаются на блок, они соглашаются как на список транзакций в блоке, так и на корень Меркла, суммирующий состояние после выполнения блока. Следовательно, лидеры должны выполнить все транзакции в предлагаемом блоке до его распространения. Между тем, узлы, проверяющие, должны выполнить транзакции перед голосованием.
Рисунок 1 иллюстрирует типичный рабочий процесс builder в MEV-Boost для Разделения Пропозера и Builder (PBS). Builders заканчивают построение блоков и отправляют их на ретранслятор, который пересылает блоки клиенту Execution Layer (EL) для симуляции и проверки.
Поскольку выполнение является предварительным условием для консенсуса, когда builder строит блок, он должен переслать построенный блок клиенту EL и симулировать блок, чтобы проверить его действительность. Помимо необходимой роли в этапах консенсуса и выполнения, стадия симуляции приносит пользу как строителям, так и поисковикам.
Строители могут точно оценить стоимость блока как для себя, так и для валидаторов, симулируя каждую транзакцию. Они также могут экспериментировать с переупорядочением транзакций, чтобы минимизировать возвраты и максимизировать извлечение комиссий за газ или базовые чаевые из как mempool, так и пакетных транзакций. Их точная оценка позволяет делать более высокие ставки для валидаторов.
В результате того, что строители отсеивают потенциально возвращающиеся пакеты до их выхода на цепочку, поисковики также видят гарантированное выполнение стратегий, добавляя детерминизм. Кроме того, поисковики получают доступ к наиболее актуальному состоянию блока. Когда слой консенсуса (CL) распространяет новый блок, поисковики могут использовать состояние из этого блока в качестве отправной точки для создания прибыльных пакетов. Между тем, существуют признаки более внепротокольных сделок или функций, предлагаемых строителями, которые позволяют поисковикам получать информацию о состоянии даже для текущего блока, который будет построен, для добавления стратегий обратного хода в их будущие блоки.
Однако развитие PBS привело к росту централизации в построении блоков, что отражает традиционную торговлю, где фирмы соревнуются за выделенные каналы микроволновых сетей для получения приоритета при выполнении арбитражных стратегий.
Теперь мы исследуем, как MEVA эволюционировала по мере прогресса Ethereum, что иллюстрируется хронологически на Рисунке 2.
Как показано на Рисунке 3, поисковики определяли прибыльные возможности MEV и отправляли свои транзакции, поддерживающие смарт-контракты, в публичный mempool. Эта публичная видимость привела к открытому аукциону первой цены на цепочке, где даже неудачные транзакции несли затраты на газ.
Этот период характеризовался конкурентными и дорогостоящими неструктурированными активностями MEV, такими как транзакции с одинаковыми (аккаунт, nonce) парами и увеличивающимися ставками, что добавляло перегрузки сети или нестабильности консенсуса.
Чтобы решить эти проблемы, Flashbots представили ретрансляторы, промежуточные аукционные дома между поисковиками и производителями блоков (майнерами в эпоху PoW). Эта инициатива преобразует рынок MEV из открытого аукциона первой цены в закрытый. Рисунок 4 показывает, как ретрансляторы помогают предотвратить эскалацию ставок в публичном mempool и устанавливают более упорядоченный и безопасный процесс производства блоков.
Структура комиссий EIP-1559 также играет здесь роль. Она упростила ставки, введя частично фиксированные цены через базовые комиссии, но не решила вопрос порядка транзакций в блоках, что по-прежнему вызывает MEV через приоритетные комиссии. В реальности многие поисковики ранее выражали ставки майнерам напрямую через передачу на coinbase. Они чаще жаловались на комиссии coinbase, так как больше не могли отправлять пакеты с нулевым газом.
После перехода Ethereum на Proof of Stake (PoS) после слияния, было внедрено Разделение Пропозера и Builder (PBS) для дальнейшего уточнения разделения ролей в процессе производства блоков. Как описано ранее, ретрансляторы теперь действуют как посредники между строителями блоков и пропозерами, выступая в роли хранителей, обеспечивающих доступность данных и действительность блоков. Поскольку пропозер может подключаться к нескольким строителям для различных частных транзакций, строители должны соревноваться, предлагая платежи пропозеру. Эта динамика иллюстрируется на Рисунке 5.
Несмотря на эти исторические достижения, важно подчеркнуть растущие опасения по поводу рисков концентрации на рынке строителей. В прошлом году олигархия из 9 крупнейших строителей стабильно удерживала >50% рынка, указывая на высокую степень концентрации рынка, как показано на Рисунке 6. Текущая ситуация еще более выражена, когда три крупнейших строителя покрывают более >90% блоков.
Как основная платформа MEVA на Solana, Jito была создана для решения проблемы высокого уровня спама из-за низкой стоимости транзакций. Спам-транзакции фактически становятся выгодными, пока стоимость неудачной транзакции (примерно 0.000005 SOL) не превышает ожидаемую прибыль.
Согласно отчету Jito Labs за 2022 год [8], более 96% попыток арбитража и ликвидации в тот год не увенчались успехом, при этом блоки содержали более 50% транзакций, связанных с MEV. В отчете также отмечается, что боты ликвидации спамили сеть миллионами дублирующих пакетов, чтобы достичь нескольких тысяч успешных ликвидаций, что привело к уровню неудач выше 99% [8].
Тяжесть внешних эффектов MEV на Solana побудила Jito разработать слой MEVA, направленный на упорядочение и детерминизацию процесса производства блоков. Давайте рассмотрим оригинальную архитектуру MEVA, предложенную Jito, как показано на рисунке 7.
Jito включает следующие компоненты:
Реле: действует как прокси для получения транзакций и перенаправляет их как в Block Engine (или цепочку поставок MEVA), так и валидаторам.
Block Engine: принимает транзакции от релеера, координируется с поисковиками, принимает бандлы, выполняет симуляции бандлов и перенаправляет лучшие транзакции и бандлы валидатору для обработки. Примечательно, что Jito проводит частичный аукцион блока для включения бандлов вместо полного аукциона блока, исторически обрабатывая более 80% бандлов в течение двух слотов [9].
Псевдо-Mempool: создает рабочее окно времени примерно в 200 миллисекунд через клиент Jito-Solana, что вызывает дискретизированный аукцион для порядка транзакций [10]. Jito прекратил работу этого mempool 9 марта 2024 года.
Давайте рассмотрим конкретные компоненты системы Jito и их проектные решения, исходя из процесса производства блоков Solana.
Jito поддерживает только частичные аукционы блоков, а не полное построение блоков, вероятно, из-за многопоточной модели выполнения Solana, в которой отсутствует глобальное планирование. На рисунке 8 показаны параллельные потоки, которые выполняют транзакции, каждый из которых поддерживает свою очередь ожидающих выполнения транзакций. Транзакции случайным образом назначаются потокам и упорядочиваются локально по приоритету и времени. Без глобального упорядочения на стороне планировщика (до обновления 1.18.x) транзакции Solana изначально испытывают недетерминизм из-за "дребезга" планировщика [11]. Следовательно, в MEVA поисковики или валидаторы не могут надежно определить текущее состояние.
С инженерной точки зрения, интеграция блока данных Jito в виде дополнительного потока, работающего параллельно с существующими, хорошо сочетается с многопоточной архитектурой Solana. Хотя аукционы бандлов обеспечивают приоритетное упорядочение по оплате в потоке блоков Jito, нет гарантии, что бандлы всегда будут размещены перед пользовательскими транзакциями глобально.
Для решения этой проблемы Jito заранее выделяет часть пространства блока для потока бандлов, гарантируя, что бандлы будут иметь место в блоке. Хотя недетерминизм остается, этот подход увеличивает вероятность успешного выполнения стратегий. Это также стимулирует поисковиков участвовать в аукционе, а не спамить сеть. Выделяя пространство блока для бандлов, Jito удается достичь баланса, способствуя упорядоченным аукционам и смягчая хаотические эффекты спам-транзакций.
Широкое распространение Jito привело к положительным результатам в борьбе с проблемой спама на Solana. Исследование команды p2p [12] и данные, представленные на рисунке 9, показывают статистически значимое улучшение относительной скорости производства блоков после принятия клиента Jito. Это свидетельствует о том, что обработка транзакций стала более эффективной благодаря оптимизированному блочному движку Jito, введенному в 2023 году.
Хотя достигнут значительный прогресс, остается много проблем. Поскольку бандлы Jito заполняют блоки только частично, транзакции, вызывающие MEV, все еще могут обходить канал аукциона Jito. Эта проблема частично подтверждается панелью Dune на рисунке 10 [13], которая показывает, что сеть по-прежнему испытывает в среднем более 50% неудачных транзакций из-за спама ботами с 2024 года.
9 марта 2024 года Jito принял решение прекратить работу своего основного mempool. Это решение было вызвано ростом транзакций мемкоинов и соответствующим всплеском сэндвич-атак (типа фронт-раннинга, при котором поисковики размещают транзакции до и после целевой транзакции), что в конечном итоге ухудшало пользовательский опыт. Подобно тенденциям, наблюдаемым на Ethereum с частными каналами ордеров в MEVA, закрытие публичного mempool может способствовать росту частного ордерного потока через партнерства с фронт-энд сервисами, такими как провайдеры кошельков и боты в Telegram. Поисковики могут формировать партнерства с валидаторами напрямую для предпочтительного выполнения, включения и исключения. Доказательства этого можно увидеть на рисунке 11, который иллюстрирует почасовой профиль прибыли сэндвич-бота для крупнейшего поисковика в частном mempool (3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81) после закрытия mempool.
Решение Jito закрыть mempool подчеркивает сильную приверженность команды к решению фундаментальных проблем в экосистеме Solana. Помимо итераций на MEVA или корректировки механизма оплаты газа Solana, Jito также помогает протоколам смягчать векторы атак через выборы дизайна UI продуктов, такие как ограничение параметров проскальзывания по умолчанию. Будь то через корректировки структуры платы, делающие спам более дорогим, или через модификацию коммуникационных протоколов, инфраструктура Jito останется важной для поддержания здоровья и стабильности сети Solana.
В отличие от Ethereum, где для согласования блока требуется как список транзакций (с их порядком), так и меркель-корень, обобщающий все состояния после выполнения, Monad разделяет предварительное выполнение и консенсус. Согласование узлов требует только урегулирования официального порядка. Как показано на рисунке 12, каждый узел выполняет транзакции в блоке N независимо, начиная консенсус по блоку N+1. Это позволяет использовать газовый бюджет, соответствующий всему времени блока, так как выполнение должно только успевать за консенсусом [15]. Поскольку лидирующему узлу не нужно вычислять де-факто корень состояния, выполнение может использовать весь период консенсуса для следующего блока.
Мы определяем операционное временное окно как временной промежуток, позволенный для MEVA на Monad, чтобы завершить предложение по построению блока, которое будет как выполнимым, так и прибыльным по сравнению с методом построения блока по умолчанию. Существует два немедленных последствия модели отложенного выполнения:
Когда MEVA строит блок N в пределах операционного временного окна, валидаторы одновременно соглашаются на список транзакций для блока N, пытаясь завершить выполнение для блока N-1. Следовательно, в пределах операционного временного окна на этапе N возможно, что доступное состояние все еще на этапе N-2. Это означает, что нет гарантии "самого последнего состояния" для релеера или билдера в этой архитектуре отложенного выполнения. Поэтому невозможно симулировать с учетом последнего блока перед производством следующего, что приводит к недетерминизму.
Учитывая 1-секундное время блока Monad, операционное временное окно для MEVA чрезвычайно ограничено. Это означает, что у билдоверов может не быть достаточно времени для последовательной симуляции полных блоков транзакций и бандлов, как это обычно происходит в Ethereum. Многие переменные могут влиять на время, необходимое для симуляции транзакций на EVM. Однако, предполагая, что симуляция транзакции занимает от 10^1 до 10^2 микросекунд (приблизительная оценка), и с целью Monad на 10^4 транзакций в секунду, может потребоваться примерно 1 полная секунда, чтобы симулировать полный блок в пределах операционного временного окна. Учитывая 1-секундное время блока Monad, билдерам или релеерам будет сложно завершить несколько полных симуляций блоков для оптимизации построенного блока.
Учитывая ограничения, завершение полной симуляции блока в пределах операционного временного окна и симуляция с учетом самого последнего состояния непрактичны. Поскольку у билдоверов теперь нет ни времени, ни самого последнего состояния, чтобы знать точный тип каждой транзакции, они должны делать вывод о типе поисковика на основе вероятности отката транзакции, полагаясь на репутацию или симулируя с учетом (возможно, в лучшем случае) состояния N-2. Это делает оценку блока менее детерминированной.
Поисковики сталкиваются с большей неопределенностью выполнения из-за отсутствия теоретической гарантии против отката транзакций после того, как валидатор принимает блок, построенный билдером. Это контрастирует с Ethereum, где поисковики конкурируют за выделенные частные каналы ордеров для билдера для относительно детерминированного выполнения стратегий. В этой относительно вероятностной среде на Monad поисковики теперь сталкиваются с более высоким риском отката бандлов на блокчейне, что приводит к более неопределенному профилю прибыли и убытков. Это похоже на трейдеров, занимающихся высокочастотной торговлей, которые исполняют сделки на основе вероятностных сигналов с слегка положительными ожидаемыми доходами с течением времени.
Как показано на рисунке 13, степень предварительной проверки бандла / блока на стороне билдера создает спектр неопределенности относительно ценообразования или оценки предложенного блока. На одном конце находится модель PBS в стиле Ethereum с точным ценообразованием, где билдеры должны использовать клиент уровня выполнения (EL) для симуляции транзакций в предложенном блоке. Им приходится справляться с широким спектром комбинаций среди представленных бандлов. На другом конце находится модель оптимистического билдера [16] с асинхронной проверкой блока. В этой модели билдеры обходят время, необходимое для любой симуляции в операционном временном окне, и учитывают чаевые, показанные валидаторам или релееру, внося залог, подлежащий срезанию. Предложенный здесь вероятностный подход проверки или частичной симуляции на Monad находится между этими крайностями, повышая вероятность успешного выполнения стратегии для поисковиков, несмотря на некоторый недетерминизм.
Например, маркетмейкер на децентрализованной бирже с книгой ордеров на блокчейне может заплатить за предварительное перемещение своих позиций через MEVA, когда они заметят значительное однонаправленное движение цены, чтобы избежать неблагоприятного выбора. Эта вероятностная стратегия позволяет им действовать быстро, даже без самой последней информации о состоянии, балансируя риск и награду в динамичной торговой среде.
MEVA играет ключевую роль в оптимизации производства блоков, смягчая внешние эффекты и повышая общую стабильность системы. Постоянная эволюция рамок MEVA, примером которой являются Jito на Solana и различные реализации на Ethereum, очень полезна для решения проблем масштабируемости и выравнивания стимулов участников сети.
Monad - это перспективная сеть на ранней стадии, предоставляющая уникальную возможность для сообщества сформировать оптимальный дизайн MEVA. Учитывая уникальную постановку выполнения и консенсуса Monad, мы приглашаем исследователей, разработчиков и валидаторов к сотрудничеству и обмену идеями. Это сотрудничество будет важно для создания надежного и эффективного процесса производства блоков, позволяя Monad достичь своего потенциала как высокопроизводительной блокчейн-сети.