Освітлення темного лісу: розкриття таємниці MEV

Зі збільшенням активності на ланцюгу та розвитком та збагаченням інфраструктури на ланцюгу, MEV на ланцюгу завжди вважався найнебезпечнішою частиною темного лісу Ethereum, що безпосередньо призводить до втрат прибутку та погіршення користувацького досвіду в фінансовій діяльності користувачів на ланцюгу. Мета цієї статті «Освітлення темного лісу» полягає в тому, щоб на основі механізму генерації блоків Ethereum 2.0 та технічного розвитку розділення пропозиційника та будівельника (PBS) зосередитися на аналізі природної централізації та проблеми довіри, які виникають внаслідок цього механізму, що має абсолютно протилежну реальність до цінностей Ethereum.

Посилення MEV на блокчейні є справжнім двосічним мечем, має свої позитивні та негативні зовнішні ефекти. Позитивні включають зменшення цінових різниць на DEX, допомога в ліквідації угод; негативні включають шкоду для користувачів від угод з «сендвічами». Отже, рішення для MEV більше спрямовані на зменшення негативних зовнішніх ефектів, а не на повну ліквідацію. У процесі дослідження механізмів для зменшення негативних зовнішніх ефектів MEV та вирішення проблем з поточними посередницькими Relayer на основі довіри, ми головним чином розділяємо заходи на три категорії: покращення аукціонних механізмів, покращення рівня консенсусу, покращення прикладного рівня. Ці три покращення вплинуть на сучасну картину MEV в різній мірі, але деякі рішення не можуть суттєво вирішити проблему атак «сендвічами», оскільки угоди користувачів залишаються в public pool. Тому необхідно впровадити більше технологій приватних пулів для захисту вибіркової конфіденційності угод користувачів, і ці рішення MEV варто спробувати об'єднати.

Окрім цього, MEV як невідворотний побічний продукт механізму проектування в майбутньому стане ще складнішим. Ми також досліджували в статті можливі технічні виклики та можливості MEV, які можуть виникнути внаслідок впровадження нових типів транзакцій, таких як архітектура Layer2 та абстракція облікових записів EIP-4337.

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

Ethereum 2.0

Відтоді, як відбулася The Merge, Ethereum перейшов на механізм POS для забезпечення безпеки мережі, водночас відмовившись від обчислювально інтенсивної конкуренції в процесі видобутку блоків, натомість запровадивши доказ участі. Після злиття Ethereum був поділений на виконавчий рівень та рівень консенсусу. А весь процес видобутку блоків також зазнав змін: кожен Epoch є циклом POS, кожен Epoch ділиться на 32 слоти, кожен слот відповідає одиниці часу видобутку блоку, що становить 12 секунд.

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

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

Насправді, коли валідатор обирається на роль пропозиціонера блоку, часто пропозиціонер не має мотивації виконувати Payload, тобто сортувати та виконувати транзакції, оскільки це вимагає значних обчислювальних потужностей для виконання зміни стану. Спочатку думалося, що якщо ми виберемо децентралізовану комісію, і якщо ми включимо виконання навантаження в цей процес, тоді сортування транзакцій стане децентралізованим. Але валідатори, здається, природно хочуть передати цю частину на виконання третій стороні, в той час як вони зосереджуються на пропозиції блоку. Таким чином виникла концепція PBS, яка полягає в розділенні пропозиції блоку та його побудови; пропозиціонери лише відповідають за верифікацію блоку і не беруть участі в його побудові. Розділення між пропозиціонерами та будівельниками сприяє відкритому ринку, на якому пропозиціонери блоків можуть отримувати блоки від будівельників. Ці будівельники конкурують один з одним за конструкцію блоків, пропонуючи пропозиціонерам найвищі збори, ми називаємо це "аукціоном блоків".

Ми коротко представимо всю модель першого аукціону PBS(Proposer Builder Seperate). Коли користувачі подають транзакції через RPC-проксі, RPC фактично виконує роль вузла, який відправляє транзакції в публічний мемпул, де кілька Builder знаходять найбільш підходящі транзакції для упорядкування з метою створення блоку з максимізацією прибутку(. Максимізація прибутку означає комісії за транзакцію Base + Priority + MEV), після чого кілька Builder взаємодіють з Proposer через MEV-Boost Relayer. Relayer є мостом між кількома Builder і Proposer, Builder подає свої пропозиції Relayer, а Relayer подає кілька заголовків блоків і відповідні пропозиції Proposer, який зазвичай приймає пропозицію з найвищим значенням. При цьому Relayer реалізує специфікацію MEVBboost, яка є технічною специфікацією, запропонованою Flashbot для регулювання взаємодії між Builder і Proposer. У цьому процесі вся інформація є закритою, Relayer лише подає заголовки блоків Proposer, тому Proposer має антикорупційні властивості.

Учасники та ігри в PBS

Основними учасниками є Builder, Relayer, Proposer, MEVbot(Searcher).

Будівельник

Builder в основному відповідає за формування вмісту блоку. Використання технології MEV-Boost надає йому більш вигідну позицію під час торгів, оскільки підтримує не лише Gas Fees, але й доходи від MEV. Builder може безпосередньо перевіряти транзакції користувачів та Searcher, що завжди критикувалося, особливо після публікації OFAC урядом США, коли багато Builder взяли участь в OFAC Compliant. Порівняно з початком, хоча частка перевірки блоків зменшилася в останні часи, ми можемо бачити, що у процесі формування блоку Builder має безпосередній вплив на перевірку транзакцій.

З огляду на поточну частку ринку Builder, певний чистий безперевірений Build поступово розширює свою частку ринку, все орієнтовано на прибуток.

Пошуковик

Вessentialно, робота з максимізації прибутку потребує спільних зусиль Searcher та Builder. Searcher часто співпрацює з певними Builder, що призводить до утворення Dark Pool або Private Pool, де торги Searcher відображаються лише для певного Builder. Деякі Builder отримують максимізовані прибутки від MEV торгів, а потім змагаються за блоковий простір. Теоретично, якщо Builder чинить зло або здійснює цензуру, тоді Searcher може вибрати інших Builder, що призведе до поступового зниження частки ринку Builder. Таким чином, під тиском Searcher, Builder часто розглядає приховані витрати від злочинних дій. На зображенні показано, як виглядають доходи від MEV і щоденного Gas; можна побачити, що внесок MEV від Searcher в умовах значних коливань ринку може перевищувати щоденний дохід від Gas у два рази.

Для Searcher поділяється на CEX-DEX( арбітраж поза ланцюгом) та DEX, мезоні, ліквідацію двох основних категорій( чисто на ланцюгу).

Наразі одна з торгових платформ займає перше місце за часткою ринку в арбітражній торгівлі між CEX та DEX.

Щодо чисто ланцюгових можливостей MEV, спостерігається поступове формування тенденції до створення студій, одна з яких займає вражаючі 37,2% ринкової частки, спеціалізуючись на проведенні "сендвіч-атак" на користувачів Ethereum. Вона стала найбільшим споживачем газу в ланцюзі, витративши близько 1,5% від загального споживання газу за день. З лютого 2023 року до червня 2024 року цей бот витратив 76 916 ETH, що за оцінкою вартості під час виконання цих угод становить приблизно 175 мільйонів доларів. Оскільки зв'язок між Searcher та Builder є тісним, на практиці багато Searcher надсилають свої замовлення трьом найкращим Builder, хоча могли б транслювати їх усім Builder. Проте деякі маленькі Builder можуть розділити замовлення Searcher, що призводить до збоїв у стратегії MEV Searcher і, в свою чергу, до ризику збитків. Крім того, прив'язка до Builder може допомогти підтримувати їх вплив у екосистемі.

Релейер

Релейер відповідає за збирання аукціонних ставок, а потім виступає як проміжна станція для подачі заголовка блоку та ціни на аукціон блоку від Пропозера, при цьому Пропозер не знає деталей транзакцій у блоці. Як тільки Пропозер вибирає і підписує заголовок блоку, Релейер випускає всі деталі транзакцій для Пропозера. Ми помічаємо, що Релейер у цьому випадку виступає як третя сторона без економічних стимулів, отримуючи величезну довіру, Будівельник покладається на Пропозера для визначення ціни, а Пропозер покладається на ціну Релейера та вміст блоку. Історично також траплялися подібні проблеми, у одного Релейера існувала потенційна вразливість, що призвела до того, що Пропозер отримав понад 20 мільйонів доларів США MEV. Хоча ці вразливості можна виправити, сам Релейер все ще може вибрати діяти зловмисно та вкрасти MEV.

На малюнку представлено частку ринку Relayer, ми можемо побачити, що частка ринку Builder, який просто реалізує MAX Profit, поступово зростає з моменту Merge, тому в умовах вільного ринку неможливо контролювати MEV штучно через Builder.

Одночасно Relayer стикається з проблемою відсутності економічних стимулів. Тому деякі компанії також вийшли з розробки в напрямку Relayer. Наразі Relayer залежить від MEVBoost стандарту, запропонованого Flashbots, для побудови, а Ethereum покладається на сторонні компанії для надання PBS, що не є довгостроковим рішенням. Тому наразі спільнота Ethereum також досліджує можливість включення PBS на рівень протоколу.

Пропонент

Для Пропозера алгоритмічно вибирається група комісії серед усіх валідаторів, а в кожному слоті обирається пропонувальник блоку. Сам пропонувальник блоку має можливість виконувати навантаження, але оскільки пропонувальник природно прагне делегувати цю частину, це може призвести до вертикальної співпраці між Builder і Proposer. Relayer MEV-boost хоче виступати як посередник у цій схемі, щоб зменшити вертикальну співпрацю та змову, що виникає через пряму комунікацію між обома сторонами. Оскільки наразі всі знаходяться в пулі майнінгу як пул валідаторів, але цей пул майнінгу та пул валідаторів LSD мають сильний масштабний ефект, особливо з появою LSD, що звільняє потенціал закладених токенів, підвищуючи капітальну ефективність, а також вплив DEFI-елементів за їхньою спиною, пул валідаторів опиняється в ще більшій концентраційній тенденції.

Деяка платформа LSD наразі займає близько 28,7% ринкової частки, деяка торговельна платформа, деяка платформа LSD посідають друге і третє місця. У минулому, коли не було активно впроваджено рішення MEV-BOOST PBS, Пропозер повинен був виконувати завдання Будівельника, тобто виконувати навантаження (Payload), але більшість Пропозерів відмовилися від своїх можливостей щодо виконання сортування транзакцій, оскільки це в умовах важкої обчислювальної роботи серйозно позначалося на продуктивності верифікації, краще передати виконання навантаження на аутсорсинг, щоб третя сторона могла проводити аукціони блоків.

Користувач

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

Щоб не дозволити MEVbot відстежувати користувачів, що може призвести до шкоди для користувачів