Вступ

У постійній боротьбі за покращення продуктивності блокчейну для оптимізації масового прийняття, Monad виділяється як піонерська сила для оптимізації моделі віртуальної машини Ethereum (EVM) за допомогою серії оптимізацій на низькому рівні: асинхронний введення/виведення, оптимізоване Patricia Trie, відкладене виконання та оптимістичний контроль конкурентності для паралельної обробки [2]. Ці покращення ефективно вирішують проблеми у виконанні та неефективний доступ до стану, які спостерігаються на платформах, таких як Ethereum, не жертвуючи децентралізацією.

У цьому пості ми досліджуємо можливі втілення надійної інфраструктури аукціону вартості, яку можна видобути майнером (MEVA) на Monad. Ми також описуємо деякі цінні уроки, які можна передати з існуючих підходів, таких як Flashbots на Ethereum та Jito Network на Solana.

Ми хочемо підкреслити кілька ключових моментів:

1. MEV є властивістю будь-якої мережі блокчейн. Робустна інфраструктура MEVA є важливою для уникнення безладного процесу виробництва блоків з негативними зовнішніми наслідками та невідповідними стимулами.
2. Дизайн MEVA глибоко інтегрований з основною механікою ланцюга, особливо його етапом консенсус-виконання. Майбутні покращення будуть залежати від еволюції цих факторів та продуктивності мережі при різних рівнях стресу.
3. Історичні тенденції у розвитку блокування, які спостерігаються на Ethereum та Solana, можуть служити джерелом дизайну MEVA на Monad.
4. MEVA на високопродуктивних блокчейнах з відкладеною виконавчою системою, таких як Monad, ймовірно, потребуватимуть стратегій випадкового будівництва та пошуку блоків, подібних до високочастотної торгівлі, через обмеження часу.

Адресуючи ці питання, ми сподіваємося надати інформацію про виклики та розгляди, пов'язані з проектуванням інфраструктури MEVA, яка відповідає унікальній архітектурі та вимогам до продуктивності Monad.

MEVA Пейзаж в Ethereum

MEVA під Consensus-Execution Staging Ethereum

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

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

На рисунку 1 показана типова робоча послідовність будівельника в MEV-Boost для відокремлення пропозер-будівельника (PBS). Будівельники завершують будівництво блоків та надсилають їх на реле, яке пересилає блоки клієнту шару виконання (EL) для симуляції та перевірки на коректність.

Оскільки виконання є передумовою для згоди, коли будівник створює блок, він повинен передати побудований блок клієнту Execution Layer (EL) і симулювати блок для перевірки його валідності. Поза своєю необхідною роллю на етапі згоди-виконання, етап симуляції також приносить користь як будівникам, так і пошуковикам.

Перспектива будівельника: Будівельники можуть точно оцінити значення блоку як для себе, так і для валідаторів, симулюючи кожну транзакцію. Вони також можуть експериментувати з переупорядкуванням транзакцій для мінімізації відміток і максимізації отримання плати за газ або базових рекомендацій як з мемпула, так і з пакетних транзакцій. Їх точна оцінка дозволяє виставляти вищі ставки валідаторам.

Погляд пошукача: У результаті відсіву будівельників потенційно повертають зв'язки, перш ніж вони приземляться на ланцюг, пошукачі також бачать гарантоване виконання стратегії, додаючи детермінізм. Крім того, пошукачі також мають доступ до найновішого стану блоку. Коли шар консенсусу (CL) поширює новий блок, пошукачі можуть використовувати стан з цього блоку як вихідну точку для побудови прибуткових зв'язок. Тим часом, є показники для більш офф-протокольних угод або можливостей, що пропонуються будівельниками прямо зараз, що дозволяє пошукачам отримувати інформацію про стан навіть поточного блоку, який має бути побудований, щоб додати стратегії backrun до їх блоків, які мають бути приземлені.

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

Ітерація продукту по мірі зрілості мережі

Ми зараз розглянемо, як MEVA розвивався по мірі розвитку Ethereum, проілюстрований хронологічно на рисунку 2.

Рис. 2: Хронологічний погляд на те, як MEV розвивається в міру просування мережі Ethereum. Фігура трохи адаптована з [4].

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

Як показано на Рисунку 3, пошуковики ідентифікували прибуткові можливості MEV та надіслали свої транзакції, включені до громадського mempool. Ця громадська доступність привела до відкритих аукціонів першої ціни on-chain, де навіть неуспішні транзакції коштували газу.

У цей період були конкурентні та дорогі некеровані MEV-дії, такі як операції з однаковою парою (рахунок, номер) та зростаючі ставки [6], що призводить до перевантаження мережі або нестабільності консенсусу.

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

Flashbots та EIP-1559

Для вирішення цих проблем Flashbots запровадив реле, посередницькі аукціонні будинки між пошуковцями та виробниками блоків (шахтарями в ері Праці). Ця ініціатива перетворює ринок MEV з відкритого аукціону з першою ціною на запечатаний. Рисунок 4 показує, як реле допомагають запобігти ескалації ставок в громадському мемпулі та встановлюють більш впорядкований та безпечний процес виробництва блоку.

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

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

Розділення пропонента-будівельника (PBS)

Після переходу Ethereum до доказу власності (PoS) після злиття було впроваджено Розділення Пропонента-Будівника (PBS), щоб ще більше уточнити розділення ролей у процесі виробництва блоків. Як вже зазначалося раніше, реле тепер діють як посередники між будівниками блоків та пропонентами, виступаючи як піклувальники, які забезпечують доступність даних та валідність блоків. Оскільки пропонент може підключатися до кількох будівників для різних приватних транзакцій, будівники повинні конкурувати, пропонуючи платежі пропоненту. Ця динаміка проілюстрована на рисунку 5.

Рисунок 5: MEVA в ері PBS. Цей рисунок незначно адаптований з [6].

Ризики концентрації

Незважаючи на ці історичні досягнення, важливо підкреслити зростаюче занепокоєння щодо ризиків концентрації на ринку будівельників. Минулого року олігархія з 9 найбільших будівельників стабільно утримувала >50% ринку, що вказує на високий ступінь концентрації ринку, як показано на рисунку 6. Стан концентрації в даний час ще більш виражений, коли трійка лідерів покриває понад >90% блоків.

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

Jito на Solana

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

Як канонічний MEVA на Solana, Jito був створений для вирішення високої швидкості спамування на 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), так і до валідаторів.

Блоковий двигун - приймає транзакції від ретранслятора, координує з пошуковиками, приймає пакети, виконує симуляції пакетів та пересилає найкращі транзакції та пакети валідатору для обробки. Наприклад, Jito проводить часткові блокові аукціони для включення пакетів, а не повні блокові аукціони, історично обробляючи понад 80% пакетів протягом двох слотів [9].

Псевдо-пул пам'яті - створює робоче вікно часу приблизно 200 мілісекунд через клієнт Jito-Solana, що викликає дискретизовану аукціон для потоку замовлень [10]. Jito вимкнув цей пул пам'яті 9 березня 2024 року.

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

Давайте розглянемо конкретні компоненти системного дизайну Jito та розглянемо, як ці вибори дизайну випливають з процесу виробництва блоків Solana.

Jito підтримує лише часткові аукціони блоків, а не побудову повних блоків, ймовірно, через багатопотокову модель виконання Solana, в якій відсутнє глобальне планування. Зокрема, на рисунку 8 показані паралельні потоки, які виконують транзакції, кожен з яких підтримує свою власну чергу транзакцій, які очікують на виконання. Транзакції випадковим чином розподіляються за потоками та впорядковуються локально за пріоритетною комісією та часом. Без глобального впорядкування на стороні планувальника (до оновлення 1.18.x) транзакції Solana за своєю суттю зазнають недетермінізму від тремтіння планувальника [11]. Отже, в MEVA пошукачі або валідатори не можуть достовірно визначити поточний стан.

Рисунок 8: Модель багатопотокового виконання для клієнта Solana. Зверніть увагу, що Етап пакету MEVA додається як окремий потік всередині багатопотокової черги.

З інженерної точки зору інтеграція живлення блокового двигуна Jito як додаткової нитки, яка працює паралельно з існуючими, гармонійно вписується в багатопотокову архітектуру Solana. Хоча в аукціонах пакетів забезпечується пріоритетне упорядкування на основі плати в межах нитки блокового двигуна Jito, немає гарантії, що пакети завжди будуть розташовуватися перед глобальними транзакціями користувачів.

Для вирішення цього Jito передбачає попереднє розподілення частини блокпростору для потоку пакетів, гарантуючи наявність пакетів у блоках. Хоча індетермінізм залишається, такий підхід збільшує ймовірність успішного виконання стратегії. Крім того, це стимулює пошуковиків брати участь у аукціоні замість спаму мережі. Зберігаючи блокпростір для пакетів, Jito здатний знайти баланс, сприяючи організованим аукціонам і зменшуючи хаотичні ефекти спаму транзакцій.

Видалення псевдо-пулу пам'яті

Широке застосування Jito привело до позитивних результатів у зменшенні проблеми спаму на Solana. Дослідження, проведене p2p [12], та дані, показані на рис. 9, свідчать про статистично значний покращення відносної швидкості виробництва блоків після прийняття клієнта Jito. Це свідчить про те, що обробка транзакцій стала більш ефективною завдяки оптимізованому блоковому двигуну Jito, який був запроваджений у 2023 році.

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

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

Рисунок 10: Інформаційна панель Dune (https://dune.com/queries/3537204/5951285) ілюстрація ботів, які спамлять активностями на Solana з травня 2022 року.

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

Рисунок 11: Щоденний прибуток від Sandwich Bot з приватним Mempool для Searcher “3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81”.

Рішення Jito закрити мемпул підкреслює тверду відданість команди вирішенню фундаментальних проблем в екосистемі Solana. Окрім ітерації MEVA або коригування механізму плати за газ Solana, Jito також допомагає навчати протоколи щодо пом'якшення векторів атак за допомогою вибору дизайну продукту інтерфейсу користувача, наприклад, обмеження параметрів прослизання за замовчуванням. Будь то коригування структури комісій, яке робить розсилку спаму дорожчою, або зміна протоколів зв'язку, інфраструктура Jito залишатиметься важливою для підтримки здоров'я та стабільності мережі Solana.

Дизайн MEVA на Monad

Відкладене виконання та наслідки для MEVA

У відміну від Ethereum, де погодження блоку потребує як списку транзакцій (з упорядковуванням), так і кореня Merkle, який узагальнює всі післяфактум стани, Monad розриває зв'язок попереднього виконання від консенсусу. Погодження вузлів потребує лише встановлення офіційного упорядкування. Як показано на рисунку 12, кожен вузол виконує транзакції в блоку N незалежно, починаючи погодження щодо блоку N+1. Це дозволяє витрачати газовий бюджет, що відповідає повному часу блоку, оскільки виконання потрібно тільки тримати крок з консенсусом. [15] Без потреби обчислення ведучим вузлом фактичного кореня стану, виконання може використовувати весь період консенсусу для наступного блоку.

Рисунок 12: Відкладена виконавча монада порівняно з Ethereum's Execution-Consensus staging. Операційне вікно часу також ілюструється з точки зору дизайну MEVA.

Ми визначаємо часове вікно операційного часу як проміжок часу, дозволений для MEVA на Monad, щоб завершити пропозицію щодо побудови блоку, яка є як можливо виконуваною та прибутковою порівняно з типовим методом побудови блоку. Є дві негайні наслідки відкладеного моделі виконання:

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

Стратегія ймовірнісного конструктора та пошуковика

З урахуванням обмежень завершення повної симуляції блоку протягом робочого вікна та симуляція за найостаннішим станом непрактична. Оскільки тепер конструкторам не вистачає часу та найостаннішого стану, щоб знати точний підхід з кожної транзакції, вони повинні виводити підказку від шукача на підставі ймовірності реверсування транзакції, покладаючись на репутацію або симулюючи проти (максимум) стану N-2. Це робить оцінку блоку менш визначеною.

Пошукачі стикаються з більшою невизначеністю виконання через відсутність теоретичної гарантії проти повернень транзакцій, як тільки валідатор приймає блок, побудований будівельником. Це відрізняється від Ethereum, де пошукачі конкурують за присвячені приватні канали для передачі замовлень будівельникам для відносно детермінованих стратегій виконання. У цьому відносно ймовірному середовищі на Monad пошукачі тепер стикаються з більшим ризиком повернень пакетів на ланцюгу, що призводить до більш невизначеного профілю виконання PnL. Це відбиває трейдерів високочастотного торгівлі, які виконують ймовірні сигнали з незначною позитивною очікуваною доходністю з часом.

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

Як показано на рисунку 13, ступінь попередньої перевірки зв'язки/блоку з боку забудовника створює спектр невизначеності щодо ціни або оцінки запропонованого блоку. На одному кінці знаходиться модель PBS в стилі Ethereum з точним ціноутворенням, де розробники повинні використовувати клієнт Execution Layer (EL) для імітації транзакції в запропонованому блоці. Вони повинні орієнтуватися в широкому діапазоні комбінаторики серед представлених бандлів. На іншому кінці знаходиться модель Optimistic Builder Model [16] з асинхронною перевіркою блоків. У цій моделі будівельники обходять час, необхідний для будь-якої симуляції протягом робочого часового вікна, і дотримуються підказок, показаних валідаторам або реле, вносячи заставу, що підлягає скороченню. Імовірнісний підхід до перевірки або часткового моделювання, запропонований тут на Monad, знаходиться посередині, підвищуючи ймовірність успішної реалізації стратегії для шукачів, незважаючи на деякий індетермінізм.

Наприклад, ринковий мейкер на децентралізованій біржі з книгою ордерів onchain може заплатити, щоб попередньо перемістити свої позиції через MEVA, коли вони помічають значний однонаправлений рух ціни, щоб уникнути небажаного вибору. Ця ймовірнісна стратегія дозволяє їм діяти швидко, навіть без найновішої інформації про стан, збалансовуючи ризик і винагороду в динамічному торговому середовищі.

Заключні слова

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

Monad є багатообіцяючою мережею в зародковому стані, що надає унікальну можливість для спільноти сформувати оптимальний дизайн MEVA. Беручи до уваги унікальну консенсусну постановку Monad, ми запрошуємо дослідників, розробників та валідаторів до співпраці та обміну ідеями. Ця співпраця відіграватиме важливу роль у створенні надійного та ефективного процесу виробництва блоків, що дозволить Monad реалізувати свій потенціал як високопродуктивної блокчейн-мережі.

Зауваження:

1. Ця стаття є перевиданням з [ 0xapr]. Усі авторські права належать оригінальному автору [АПРІОРІ ⌘]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно це вирішать.
2. Відмова відповідальності: Думки і погляди, висловлені в цій статті, є виключно думками автора і не становлять жодної інвестиційної поради.
3. Переклад статті на інші мови здійснює команда Gate Learn. Якщо не зазначено, копіювання, розповсюдження або плагіат перекладених статей заборонено.