
Спочатку може здатися, що MEV нешкідливий. Чорт забирай, це може навіть з'явитися як підсилювач мережевої безпеки, додаткові стимули для майнінгу або перевірки, чи не так? Окрім звичайних винагород за блоки та комісій за транзакції, тепер можна розіграти MEV. Але реальність далеко не безневинна. Якщо МЕВ не контролювати, він може стати потужною централізаторською силою. Ось історія, щоб проілюструвати це: уявіть, що ви щойно дізналися про цю гру MEV і почули, що валідатори заробляють понад 10% річних через неї. Заманливо, правда? Ви пішли ва-банк! Отже, ви відправляєте свої 32 ETH на контракт стейкінгу та запускаєте вузол валідатора. Але стривайте... Ви бачите лише 4% прибутку. Коли настає ваша черга пропонувати блок, транзакції просто вишиковуються за ціною газу. Ніякої магії MEV. Ви не озброєні хитромудрими алгоритмами та тактиками для видобутку цього золота MEV. Без ноу-хау ви застрягли за замовчуванням: замовлення транзакцій за ціною газу.
Ось тут і спрацьовує централізоване тяжіння. Навіть якщо ви квант, ваш простий комп'ютер, можливо, малинове пі, не витримає свічки перед суперкомп'ютерами, що працюють на наступному рівні відтворення MEV. Очевидним кінцевим результатом тут є вимкнення валідатора та натомість надсилання ETH цим надпотужним установкам, які обіцяють частку пирога MEV. Перенесемося вперед, і ви можете побачити, що кілька цих гігантів, по суті, керують мережею, що є справді тривожним централізованим результатом. Якщо справа йде саме в цьому, значить, фундаментальні цілі Ethereum зазнали невдачі. Мережа, в якій домінують кілька обраних, цілком може бути централізованою базою даних на той момент.
Фронт-ранінг передбачає виявлення транзакції в мемпулі, яка має на меті обміняти токен A на токен B. Потім лідер програмно ініціює аналогічну транзакцію, яка пропонує вищу ціну на газ. Ця стратегія гарантує, що транзакція лідера буде оброблена до початкової. Після того, як початкова транзакція буде оброблена, лідер може негайно обміняти токен B назад на токен A, отримавши більшу кількість токена A, ніж він починав. Цю тактику іноді називають сендвіч-атакою, оскільки транзакція користувача затиснута між двома транзакціями, ініційованими лідером. В результаті, в той час як лідер отримує прибуток, особа, яка стоїть за початковою транзакцією, отримує менше токена B. Хоча сендвіч-атаки є поширеним явищем, існують різні стратегії, які люди можуть використовувати для ефективного вилучення MEV.

Візуалізація сендвіч-атаки: як лідери наживаються за рахунок інших
Під час буму ICO Філ і його команда розгорнули бота, який заробляв близько мільйона доларів на рік. Після того, як вони поділилися своєю методологією в блозі, про який я згадував раніше, з'явилося кілька схожих ботів, створивши конкурентне середовище, де боти перевищували ціни на газ один одного, щоб досягти пріоритету транзакцій. Це спонукало Філа розгорнути вузли по всьому світу, збираючи дані про транзакції в режимі реального часу. Кульмінацією цього дослідження став його знаменитий стаття "Flash Boys 2.0", яка глибоко досліджує проблеми MEV, спричинені децентралізованими біржами.
Ось цікава пов'язана історія, яку Філ розповів, коли він був гостем на Блокування. Коли Хейден Адамс, засновник UniSwap, поділився своїм дизайном найпопулярнішої децентралізованої біржі на ethresear.ch. Філ негайно надіслав повідомлення про свої занепокоєння як Віталіку, так і Хейдену. Філ вважав, що дизайн UniSwap спричинить значну кількість MEV, що зробить його головною мішенню для експлуатації та піддасть користувачів ризику перезамовлення транзакцій та сендвіч-атак. Віталік відповів, припустивши, що їх можна розглядати просто як додатковий механізм комісії за використання блокчейну. Філ був настільки розлючений такою реакцією і думав, що впливові фінансові організації, такі як Goldman Sachs, прийдуть і з'їдять обід у роздрібній торгівлі, як і нинішня фінансова система. Однак з часом Філ прийшов до точки зору Віталіка (всі хвалять лорда Віталіка).
Усвідомлюючи важливість і виклики простору MEV, Філ став співзасновником Flashbots, компанії, що спеціалізується на дослідженнях і рішеннях на арені MEV. Флеш-боти зрозуміли, що MEV буде існувати, і Flashbots його місія полягає в тому, щоб переконатися, що існування MEV не призведе до системи, де бути поганою людиною або створювати негативні зовнішні ефекти краще для вас особисто і вигідніше, ніж бути хорошим актором. Прикладом цього є TradFi, де найприбутковіші стратегії часто передбачають використання країв системи. Крім того, Flashbots подумали, що може бути спосіб використовувати енергію MEV для користувачів і субсидувати людей, які захищають мережу, а також субсидувати транзакції в мережі, щоб отримати людям кращі ціни, щоб дати людям бажане виконання в цих системах. При правильному проектуванні MEV може стати частиною того, що змушує криптовалюту перевершувати традиційні системи.
З MEV GETH майнери отримали нову кінцеву точку. Вони могли отримувати оптимізовані для MEV пакети транзакцій від пошуковиків. Кожен пакет також містив транзакцію, яка забезпечувала майнерам комісію, що мотивувало їх вибирати саме цей пакет. Звичайно, майнери обирали пакет, який пропонував найвищу комісію. Коли пошуковики конкурують за можливості MEV у публічному мемпулі, їх ставки природно зростають через цю конкуренцію. Ця конкуренція забезпечує те, що майнери отримують основну частку користі від MEV.
Давайте розберемо це на прикладі: уявіть, що Аліса є пошукачем і помічає можливість арбітражу між двома децентралізованими біржами. Вона може отримати прибуток у розмірі 0,07 ETH, купивши токен X на UniSwap, а потім негайно продавши його на SushiSwap за вищою ціною. Тому вона створює пакет транзакцій, оптимізований для можливості 0,07 ETH MEV, і готова заплатити майнеру 0,05 ETH, щоб визначити пріоритетність її транзакцій у наступному блоці. Боб, інший шукач, визначає ту саму можливість. Він створює аналогічний пакет, але пропонує майнерам платіж у розмірі 0,06 ETH за той самий привілей. Еліс і Боб надсилають свої оптимізовані для MEV пакети транзакцій майнерам. З іншого боку, майнер отримує ці бандли і повинен вирішити, який з них включити в наступний блок. Природно, майнер вибирає пакет Боба через пропоновану вищу комісію, що гарантує, що майнер отримає максимальну вигоду. Це безпрограшна ситуація.
Майнер захоплює більшість можливості MEV, отримуючи 0,06 ETH з можливості в 0,07 ETH. Тим часом пошуковик забезпечує чистий прибуток у розмірі 0,01 ETH, який вони інакше не могли б отримати. Суть механізму MEV GETH полягає у цьому конкурентному укладанні угод. Аліса та Боб конкурують між собою, пропонуючи стимули майнеру, забезпечуючи таким чином те, що майнер захоплює значну частину переваг MEV.
Однак, якщо вони просто відкриють кінцеву точку для будь-кого, хто може надсилати майнерам пакети, зловмисники можуть скористатися цією відкритістю, щоб перевантажити свою систему, потенційно запустивши DOS-атаку. Щоб усунути цю вразливість, Flashbots представили Flashbots Relay. Цей ретранслятор виконує важливу фільтраційну роль: він оцінює вхідні пакети транзакцій на основі їх потенційної прибутковості для майнерів, дійсності транзакцій і запропонованої комісії. Після цього майнерам передаються лише оптимальні зв'язки. Цей метод дійсно вводить рівень централізації, оскільки процес залежить від ретранслятора Flashbots для відсіювання небажаного або потенційно шкідливого трафіку. Цікаво, що між оператором майнінг-пулу та його працівниками вже існував рівень PBS. Як правило, оператор конструював тіло блоку, включаючи пакети, надіслані з реле, хешував заголовок блоку один раз і відправляв його працівникам для продовження хешування та пошуку золотого нонсе.

Огляд MEV GETH: Шлях від пошуку до включення пакету транзакцій у блок майнера
MEV GETH використовувався майже всіма пулами майнінгу, але з переходом Ethereum до PoS система потребувала модифікацій. PoS був розроблений для того, щоб забезпечити можливість працювати соло-валідаторам: індивідуальним валідаторам, які працюють на пристроях з низькими ресурсами, наприклад, Raspberry Pi. PoS був розроблений з метою забезпечення збалансованого ландшафту: чи ви соло-валідатор, чи частина великого стейкінг-пулу, не буде жодних вбудованих переваг у процесі валідації для жодного учасника. До переходу до PoS декілька пулів майнінгу домінували в хеш-швидкості. Це дозволяло довірчі стосунки між цими пулами та Flashbots Relay. Будь-які нечесні дії, наприклад, пул майнінгу крадіння MEV від пошукача, можуть підірвати ці відносини. Скажімо, майнер отримав пакет із атакою сендвіча від пошукача. Якщо майнер ще більше сендвічує пошукача своїми власними транзакціями, це принесе короткострокову вигоду, але відірветься від Flashbots, втративши майбутні доходи MEV, оскільки вони втратять доступ до Flashbots Relay.
У відповідь на цей новий вектор атак Flashbots запустив MEV Boost, систему, розроблену для середовища зі стакерами.
Механіка MEV Boost:

Процес MEV Boost
Ця налаштування створює проблеми з довір'ям:
Довіра між будівельником та реле: будівельники повинні довіряти, що реле не вкрадуть їх MEV. Розгляньте сценарій, де реле, після отримання блоку від будівельника, замінює адресу будівельника в транзакції-сендвічі на свою власну. Потім вони передають змінений заголовок пропоненту.- Довіряти Пропозеру-Релею: З іншого боку, пропозери повинні довіряти, що підписані ними заголовки блоків є дійсними. Пропозиція недійсного блоку призведе до втрати винагороди за блок, оскільки мережа відхилить такий блок.Дизайни PBS стикаються з постійним викликом: взаємодії між пропонентом та акторами упорядкування транзакцій є дані, але є чітка потреба у механізмі, де:
Пропоненти можуть зобов'язатися до блоку будівельника, не знаючи його вмісту, але залишатися впевненими в його валідності.- Будівельники можуть безпечно відправити свій блок пропоненту, впевнені, що їх MEV не буде вкрадено.
MEV Підвищення довіри до припущень
Перш ніж глибше зануритися в MEV Boost, важливо зрозуміти, як Ethereum створює блоки за замовчуванням без використання MEV Boost. Це налаштування залежить від співпраці між клієнтом виконання валідаторів і клієнтом консенсусу. Коли транзакція отримує Виконавчий клієнт, він перевіряє формат, додає її до свого мемпулу, але не обробляє. Одночасно клієнт консенсусу обробляє консенсус PoS, вибираючи валідатор для створення наступного блоку. Потім клієнт виконання обраного валідатора організовує транзакції за ціною газу в новий блок, який потім пересилається клієнту консенсусу та надсилається в мережу. Інші валідатори підтверджують точність блоку, і після перевірки він стає найновішою ланкою ланцюга.
Цей процес змінюється, якщо валідатор вирішить скористатися MEV Boost. Валідатори, які інтегрують MEV Boost, роблять це зі своїм клієнтом консенсусу. Коли вони готуються запропонувати блок, вони більше не покладаються на свій виконавчий клієнт і замість цього підключаються до мережі ретрансляторів. Валідатори можуть вибирати, до яких ретрансляторів підключатися.
MEV Boost є необов'язковим, але 95% перевіряючих використовують його. По суті, майже кожен перевіряючий, крім тих, що керуються Віталіком, делегує будівництво блоків третій стороні. Ця делегація свідчить про те, що основна функція протоколу Ethereum, будівництво блоків, зараз здійснюється в основному поза самою системою Ethereum. Одним з ключових учасників у цій схемі є ретранслятор, і їхня роль дещо контрастує з основними принципами Ethereum. Зараз діють приблизно 9 активних ретрансляторів, але лише 6 з них мають >9% частку переданих блоків.

Розбір топових реле та будівельників за часткою ринку за останні 7 днів. Джерело: https://www.relayscan.io/
Довіра стає питанням, оскільки відносини між реле та будівельником та реле та перевіряючим не є безпідставними. Також є питання про опір цензурі. Реле під час їх аукціонів мають волю визначати валідність блоків. Ця воля дозволяє їм виключати блоки з транзакціями, пов'язаними з санкційними адресами. Наприклад, коли сталися санкції OFAC Tornado Cash, деякі реле скористалися цією владою. Останні дані показують, що 38% блоків у минулому тижні відповідали вимогам OFAC через таку цензуру, накладену реле.

Варто також зазначити, що оскільки MEV Boost є зовнішнім програмним забезпеченням, розробленим компанією (Flashbots), воно не так ретельно тестується, як програмне забезпечення в протоколі. Це було очевидно з клієнтом Prism після оновлення Shapella: помилка інтеграції з MEV Boost спричинила проблеми з підписом ініціатора, що призвело до пропущених слотів і скорочення. Мета інтеграції цього процесу в протокол Ethereum полягає в тому, щоб вирішити ці проблеми, гарантуючи, що навіть якщо угода між ініціатором і розробником розвалиться, ініціатор пропозиції залишатиметься відшкодованим. Таким чином, якщо забудовник надає несправний блок, ініціатор все одно отримує повну ставку, залишаючи будівельнику нести наслідки. Незважаючи на те, що специфіка цієї інтеграції, яка називається ePBS (закріплене розділення пропонента-будівельника), все ще досліджується, і, можливо, через пару років після реалізації, вже є багато різних ідей про те, як це може виглядати.
Тепер перейдемо до конструкцій ePBS. Найбільш улюблена модель займає два слоти. Спочатку є фаза торгівлі, де будівельники надсилають свої ставки валідаторам. Потім слот 1 починається з того, що пропонент вибирає ставку та зобов'язується до неї, публікуючи блок, який зобов'язує цієї будівельникові ставці. Група атестаторів потім висловлює своє голосування за цим блоком, забезпечуючи його місце в ланцюжку. У слоті 2 будівельники бачать ставку, яка була зобов'язана в зобов'язаному блоку пропонента та атестації на ньому. Визнавши необоротнє зобов'язання пропонента, будівельник, чию ставку було вибрано, випускає свій блок та має впевненість, що їхні МЕВ не можуть бути вкрадені. Нарешті, атестатори підтверджують цей новий блок.

Дизайн "двослотової" ePBS
Недавно випущена модель схожа з підходом з двома слотами, але вводить комітет з вантажно-часовою важливістю. Спочатку будівельну ставку вибирає та зобов'язується виконати пропонент, а потім комітет валідаторів дає свою свідчення. Наступно будівельник розкриває вантаж блоку (його транзакції), і комітет вантажно-часової важливості підтверджує, що вантаж було надано вчасно та його валідність. Інші відмінності між цими двома методами полягають у конкретиках операцій Proof of Stake Ethereum, але це виходить за рамки цього повідомлення.

ePBS дизайн з Комітетом з вантажу та своєчасності
Ще один дизайн обертається навколо концепції аукціону слотів. Тут будівельники, під час своєї пропозиції, зобов'язуються взяти слот у епосі без вказівки блоку. Вони фактично обіцяють створити блок під час їх виділеного слоту, пропонуючи певну ціну за це. Це пропонує адаптивність, особливо для міждоменного MEV, який потребує дій в реальному часі.
Поки що всі дизайни ePBS надають розробнику повний контроль над транзакціями блоку. Потенційним обхідним шляхом є використання списку включень. Цей список, який ініціатор надсилає розробнику, в ідеалі всі транзакції, які зараз є в мемпулі або не обов'язково повинні бути, містить транзакції, які повинні бути частиною блоку builders, якщо є місце. Якщо блок забудовника заповнений, він повинен вказати це, підтвердивши, що він визнав список. Такий метод посилює стійкість мережі до цензури. Якщо забудовник хоче цензурувати транзакцію, з часом це стане складно і дорого зробити. Відповідно до EIP 1559, послідовно заповнені блоки призведуть до експоненціального зростання базової комісії. Тому, якщо забудовник постійно цензурує транзакцію, заповнюючи блок фіктивними транзакціями, зростаючі витрати роблять це неможливим понаднормово.
Існують випадки, коли пропонент хоче мати певний вплив на створення блоку. Ще одна функція ePBS може передбачати, що пропонент створює частину блоку (або початок, або кінець) та делегує решту будівельникові. Усі ці дизайни та функції не є взаємовиключними, це більше про балансування їх переваг і недоліків.

Оптимістичне передавання V1
Піднімаючи оптимістичне передавання ще на крок далі до V2, ми можемо усунути потребу реле в завантаженні блоку, скорочуючи ще 50-100 мілісекунд затримки. Ті ж гарантії застосовуються: якщо блок ніколи не завантажується, стягується застава будівельника.

Оптимістичне ретранслювання V2
В кінцевому підсумку, кінцева гра для Оптимістичного Релейного починає нагадувати модель комітету з вчасності пакунків, про яку я вже згадував. Ось послідовність: Будівельники надсилають свої ставки на рівень peer to peer. Пропонувач приймає ставку і надсилає підписаний заголовок. Потім будівельник випускає блок. На цьому етапі єдине завдання реле - це контроль за пам'яткою peer to peer, в основному відслідковування часу виникнення різних подій. Роль реле стає дуже легкою, йому просто потрібно відстежувати пам'ятку. Це добре демонструє, як реле працює дуже схоже на комітет з вчасності пакунків. Всі ці кроки спрямовані на майбутнє, де реле буде замінено комітетом з вчасності пакунків, що спростить весь протокол.

Дизайн Danksharding дослідника Ефір Данкрада Фейста пропонує, що ці високоресурсні будівельники можуть побудувати один великий блок, що містить усі дані. Ці дані потім сегментуються і фіксуються кількома зобов'язаннями KZG. Побудова цього блоку вимагає значних ресурсів, але їх перевірка відносно недорога. Легкі валідатори можуть застосовувати вибірковий доступ до даних для інспекції невеликого розділу блоку та майже впевненої доступності всього набору даних, що призводить до додаткового збільшення пропускної здатності даних від Proto-Danksharding на ~16 разів. Складнощі Danksharding складні і не розглядаються тут, але ключовий момент полягає в тому, що цим вдосконаленим будівельникам можуть делегувати додаткові ролі для подальшого покращення мережі.
Ще одна ідея використовувати будівельників - це потенційне втілення роллапів на основі. Кілька років тому Віталік обговорював моделі послідовності роллапу, придумавши термін однієї з них - Total Anarchy, в якій будь-хто може публікувати блок роллапу, і перша послідовність, яка натрапляє на ланцюг, є офіційним блоком. Цей підхід мав багато недоліків, таких як спам на ланцюгу та неоднозначність щодо переможної послідовності. Однак нещодавня стаття Джастина Дрейка прозасновані на rollupsвиділений більш ефективна стратегія, використовуючи будівельників. У цій моделі будівельник на першому рівні працює як послідовник rollup, відбираючи оптимальну послідовність для включення в ланцюжок. Це забезпечує включення тільки оптимальних послідовностей.
Поза роллапами, введення потужних будівничих може спонукати до інших інноваційних структур, таких як безстандартні клієнти. Вони надають можливість вузлам працювати як зазвичай, але без багажу збереження застарілих станів. Це дозволяє вузлам бути більш легкими і покладатися на здатність будівельника генерувати конкретні криптографічні докази.
Уявіть, що Аліса є ініціатором у мережі Ethereum. З PEPC, Аліса має гнучкість, щоб взяти на себе конкретні зобов'язання щодо майбутнього блоку. Вона може взяти на себе зобов'язання, що її блок міститиме принаймні три транзакції, що стосуються конкретного смарт-контракту, і вона готова виділити на них 70% газу блоку. Вона повідомляє про це зобов'язання, і воно стає частиною умов дії її блоку. Тепер Боб, будівельник, бачить відданість Аліси. Він пакує пакет транзакцій, що відповідають критеріям Аліси, і відправляє його по-своєму. Якщо блок Аліси після побудови відповідає її зобов'язанням (тобто містить зазначені транзакції, що споживають визначений газ), то блок вважається дійсним і може бути доданий до блокчейну. Якщо ні, блокування Аліси не буде прийнято, гарантуючи, що вона дотримується своїх заявлених зобов'язань.
Однією з ключових відмінностей між ePBS та PEPC є характер зобов'язань. У ePBS пропозиції та будівельники дотримуються фіксованої, однакової процедури. Це свого роду універсальний підхід. Пропонент зобов'язується до конкретного хешу блоку, після чого будівельник створює відповідний навантаження. Проте PEPC вводить різноманіття. Кожен пропонент може встановлювати унікальні умови, пропонуючи набагато більше гнучкості. Важливо зауважити, що існування PEPC залежить від ePBS, вони доповнюють один одного. Точні принципи роботи PEPC все ще обговорюються та досліджуються.





