Поєднання Консенсусу ETH та MEV, щоб почати з дня, коли PoW переходить на PoS...

Написав: Tia, Techub News

Процес вирішення проблеми MEV насправді полягає в перегляді правил розподілу Блок простору. Щодо MEV, ви вже маєте знайомство, але якщо ви хочете знати, про що йдуть дискусії в пропозиціях управління MEV на Ethereum, можливо, вам все ще потрібна додаткова інформація про фон, тому ця стаття розглядає ряд пропозицій з управління MEV, таких як PBS, ePBS, PEPC, які були запропоновані після переходу Ethereum на PoS, сподіваємося, що це надасть вам деяку контекстну інформацію.

PBS(Proposer Builder Seperatioin)

До злиття ETH, способом вирішення MEV було використання MEV-Geth, розробленого Flashbots, який є модифікованим клієнтом go-ethereum. Його основна ідея полягає в тому, щоб Майнери зосередилися на своїй основній роботі - Майнінгу, а не взяли участь у боротьбі за MEV, тим самим уникнувши можливих проблем з потенційними перестановками. Механізм MEV-Geth дуже простий - це ринкове рішення, за яким Майнери можуть вибирати пакети Блоків, залежно від прибутку, який отримає searcher за bundle. Цей винахідливий ринковий механізм дозволяє сторонам отримувати прибуток і одночасно встановлює певні обмеження. Хоча searcher має поділитися частину прибутку з Майнером, він отримує гарантований захист від крадіжки Майнером. Коли searcher, як головний джерело прибутку, буде заблокований, Майнери також будуть змушені використовувати MEV-Geth та дотримуватися його механізму. MEV-Geth підтримує whitelist Майнерів, і тільки Майнери, які перебувають у whitelist, можуть приймати bundle від searcher. Шляхом обмеження довіри до Майнерів і виключення з whitelist тих Майнерів, які крадуть досягнення searcher, можна запобігти Майнерам вкраданню MEV-прибутку searcher.

Але після злиття, оскільки спосіб формування Блоку змінився на випадковий вибір proposer з валідаторів для запропонування Блоку, спосіб обмеження репутації для запобігання захоплення MEV proposer стає неможливим.

Можливим рішенням є зробити вміст Блок невидимим для валідаторів. Вздовж цього шляху подальше вдосконалення - це PBS (Proposer Builder Seperatioin, розділення пропонента-будівельника). PBS подальше деконструює обов’язки валідаторів в ролі пропонента на побудову Блоку та пропозицію Блоку, передаючи складні права на будівництво, які можуть брати участь у конкуренції за інтереси, будівельнику. Таким чином, робота пропонента стає дуже простою - потрібно лише вибирати пропозицію Блоку залежно від прибутку, який подає будівельник.

Спочатку Ethereum хотіла вбудувати PBS у протокол під час злиття, але через його потенційну складність цей процес було відкладено, що дало можливість MEV-Boost втрутитися в PBS. Наразі PBS реалізується за допомогою MEV-Boost, розробленого Flashbots. Окрім будівельника та пропозера, тут є ще одна важлива роль - реле. Будівельник не надсилає блоки безпосередньо пропозеру, а робить це через третю роль - реле.

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

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

У протоколі & з протоколу

Щоб взяти участь в ринку, побудованому MEV-Boost, валідатори повинні одночасно запускати клієнт ETH-блокчейну та виконувати програму MEV-Boost з іншої сторони, не пов’язану з ETH-блокчейном. ** Ось чому PBS виконує чудеса, дозволяючи стороннім учасникам приймати участь у проектуванні правил, сформованих Консенсусом ETH-блокчейну. ** З точки зору власності, це неймовірно.

Це також викликало роздуми щодо ‘довіри’ протокольного механізму, як довіра посилюється та яким чином вона може бути підірвана іншими механізмами. MEV-Boost - це хороший приклад, оскільки існує можливість, що зовнішні протоколи можуть змінити існуючий механізм. Коли сам протокол починає відставати, такі зміни можуть виникати ззовні, і вони обов’язково відповідатимуть поточним вимогам ринку. Але чи можна довіряти зовнішнім механізмам, чи вони були ретельно розроблені, щоб уникнути можливих проблем, навіть здатність зовнішніх механізмів підірвати протокол, все це ще не відомо.

Централізований реле

Найбільш критикованою частиною MEV-Boost є централізований ринок реле. Але така настройка вносить проблему довіри. Будівельникам потрібно довіряти реле, що вони не вкрадуть їх MEV. Також пропонентам потрібно довіряти, що блок-заголовки, які вони отримують і підписують від реле, є дійсними. Однак, незважаючи на важливу роль, Реле не має жодних економічних стимулів, і запуск реле також потребує значних витрат. Минулого року 11 реле надавали підтримку мережі Ethereum, але зараз лише 9 реле продовжують надавати послуги.

Варто зауважити, що реле не є безперешкодним, наприклад, такий реле, як Eden, лише Реле свого будівельника. Деякі реле, наприклад, bloXroute, стверджують, що вони фільтрують угони та транзакції, пов’язані з атаками типу ‘сендвіч’. До певної міри реле також мають право встановлювати певні правила.

Дані надходять від Rated Network

І з точки зору живості, через присутність ретранслятора, будівельник і пропозер не можуть забезпечити підтвердження на атомному рівні. Навіть якщо пропозер підписав зобов’язання до заголовка блоку та будівельник надав вміст поліпшення, але через помилку ретранслятора (чи це було умисне чи неумисне) не вдалося надати цей вміст вчасно, це призведе до збитків для будівельника та пропозера.

ePBS: упаковує PBS в Ethereum

Незалежно від того, чи для вирішення проблеми централізації реле, чи для переміщення частини позапротокольної частини в межі протоколу, упакування PBS у ePBS ETH-ланцюжок, схоже, стало обов’язковим. На даний момент ePBS вже не є предметом обговорення, редакція EIP ETH вже надала йому номер - EIP-7732.

ePBS надає proposer та builder інфраструктуру безпеки, яка не потребує довіри, щоб вони могли здійснювати зовнішню передачу Блок права побудови. Роль builder, яка спочатку була поза протоколом, тепер включена в протокол, тобто валідатори розділили роль builder в лонг, що потребує завершення застейкання на блоках ETH. Оскільки Консенсус розбиває відповідальність proposer, для завершення ePBS потрібно вносити зміни в Консенсус . В цьому випадку builder відповідає за створення пакету виконання (остаточний список угод, які мають бути виконані у цьому Блоку), а proposer відповідає за запропонування блоку маяка. Конкретний процес виглядає наступним чином:

1. Після визначення вибору пропонента створюється і розповсюджується список включень (IL), який містить транзакції, що обов’язково повинні бути включені в цей слот.
2. Будівельники надіслали до пропонента підписану головку пакета SignedutionPayloadHeader, яка містить хеш блоку та обіцянку про оплату витрат пропоненту за передачу пакета. Пакет містить виконавчу навантаження та повинен відповідати IL.
3. пропозер вибирає один з «SignedutionPayloadHeader», надісланих від builders, щоб включити його (зазвичай вибирають найвищу ціну для пропонента). Також транслюється пропозиційний бітовий блок «SignedBeaconBlock».
4. Свідок виконує свої обов’язки свідка
5. агрегатори подають атестацію агрегаторів; водночас builder транслює пакет утіки
6. PTC (комітет своєчасності навантаження, у кожному слоті обирається 512 валідаторів як члени PTC), перевіряє, чи вчасно розкривається навантаження для виконання builder і розповсюджує результати

ePBS від заявки до остаточного отримання номера EIP також пройшов кілька обговорень. Спочатку PBS був запропонований Віталіком у червні 21 року, через 4 місяці вдосконалено схему Two-slot, через ще 3 місяці було запущено Single-slot PBS, і тільки в липні 23 року була офіційно запропонована ідея PTC.

PEPC（Протокол-забезпечені зобов’язання пропонента）

Звичайно, є також незгода з ePBS, хто хоче замінити його іншими рішеннями. PEPC - саме така альтернатива. У випадку PEPC пропонент продає право на побудову Блоку Програмованості, тоді як ePBS вбирає в себе певне правило в протоколі.

PEPC було запропоновано barnabe в жовтні 2022 року. barnabe вважає, що для реалізації механізму PBS в протоколі, слід розглянути реалізацію загального механізму для надійної передачі сигналів, а не механізму для конкретного надійного сигналу (наприклад, якщо дозволите мені побудувати Блок, я поверну вам xx ETH).

Як саме назва PEPC (Protocol-Enforced Proposer Commitments) вказує, деякі механізми, які гарантують інтереси будівельників та пропонувальників, здійснюються за допомогою зобов’язань, які пропонувальник подає в протоколі. Ці зобов’язання можуть бути перевірені в у блокчейні та головним чином реалізуються за допомогою операційного коду ‘BEACONROOT’. Це загальніший механізм, де зобов’язання можуть охоплювати повну підсумкову вартість блоку або лише часткову підсумкову вартість блоку, тобто пропонувальник продає програмовану можливість будівництва блоку.

Заключення

Це щойно була коротка інформація про PBS, ePBS, PEPC. З точки зору дизайну протоколу, потрібно не тільки розробити механізм ринку для перерозподілу MEV, але й розглянути, як зробити валідаторів більш децентралізованими і як підвищити стійкість до цензури. Крім того, в дизайні протоколу є багато компромісів. Нехай я розгляну приклад ePBS, який вже отримав номер EIP. Хоча дизайн ePBS вирішує проблему централізованого реле, але чи є у ролі стороннього реле, що знаходиться поза протоколом, тільки негативний вплив? З точки зору механізму оплати будівельника, використання реле є кращим варіантом порівняно з механізмом ePBS, оскільки ePBS є передплатою. Якщо будівельник упаковує блок з високим прибутком, то в попередній оплаті не можна надати високий прибуток пропоненту.