Автор: Tia, Techub News
Процес вирішення проблеми MEV фактично полягає в переписуванні правил розподілу блокового простору. Я вважаю, що всі вже не знайомі з MEV, але якщо ви хочете знати, про що йдеться в деяких пропозиціях щодо управління Ethereum MEV, вам все одно може знадобитися доповнити деяку довідкову інформацію. Тому ця стаття розібрала низку запитань про управління MEV після того, як Ethereum перейшов на такі пропозиції, як PBS, ePBS і PEPC, я сподіваюся надати вам додаткову інформацію.
PBS（Proposer Builder Seperatioin）
До злиття Ethereum спосіб вирішення MEV полягав у використанні MEV-Geth, модифікованого клієнта go-ethereum, розробленого Flashbots. Основна ідея полягає в тому, щоб дозволити майнерам зосередитися на своїй роботі — видобутку корисних копалин, а не брати участь у змаганнях MEV, таким чином уникаючи потенційних проблем з реструктуризацією, які можуть виникнути. Механізм MEV-Geth дуже простий. Це орієнтоване на ринок рішення, тобто, коли майнери пакують блоки, вони можуть вибирати відповідно до розміру прибутку пакета, поданого шукачем. Завдяки цьому геніальному ринково-орієнтованому механізму всі сторони можуть отримати переваги, водночас створюючи певні обмеження. Хоча пошукач повинен ділитися частиною прибутку з майнерами, те, що він отримує в обмін, є надійнішою гарантією від крадіжки майнерами. Коли шукачі, основне джерело прибутку, потрапляють у пастку, майнери також пасивно почнуть використовувати MEV-Geth і будуть додатково обмежені механізмом MEV-Geth. MEV-Geth буде підтримувати білий список майнерів. Тільки майнери з білого списку можуть отримувати пакети пошуку. Встановлюючи репутаційні обмеження для майнерів і видаляючи майнерів, які крадуть результати шукача, з білого списку, майнерам можна запобігти крадіжці прибутку MEV шукача.
Однак після злиття, оскільки метод генерації блоків змінюється на випадковий вибір пропонентів із валідаторів для пропонування блоків, метод обмеження репутації, щоб запобігти пропонентам вихопити MEV, більше неможливий.
Можливим рішенням є зробити вміст блоку невидимим для валідаторів. Подальшим удосконаленням у цій лінії мислення є PBS (Proposer Builder Seperatioin, Proposer Builder Seperatioin). PBS додатково деконструює обов’язки верифікатора пропонента на блокову конструкцію та блокові пропозиції та передає складні права на конструкцію, які можуть включати конкуренцію за інтереси, будівельнику. Таким чином робота пропонента стає дуже простою, і потрібно лише пропонувати блоки на основі прибутку забудовника від подачі блоку.
Спочатку Ethereum хотів вбудувати PBS у протокол під час злиття, але через потенційну складність цей процес було відкладено, що дало MEV-Boost можливість втручатися в PBS. В даний час PBS реалізується через MEV-Boost, розроблений Flashbots. Крім будівельника і пропонента, є ще дуже важлива роль - естафета. Конструктор надсилає блок не безпосередньо тому, хто пропонує, а через ретранслятор третьої ролі.
Тому що є інші питання, які потрібно вирішити, наприклад, як переконатися, що розробник заплатить пропоненту та розкриє вміст блоку пропоненту в кінці, щоб уникнути покарання пропонента за подання порожнього блоку; наприклад, як переконатися, що область, надіслана будівельником Blocks, точно буде включена в ланцюжок маяків тощо. Ці питання захисту прав та інтересів забудовників та ініціаторів реалізуються переважно через естафету.
Конструктор надішле блоки до ретранслятора, а потім ретранслятор відсортує блоки відповідно до прибутку, який можна отримати від кожного блоку, а потім надішле заголовок блоку з найбільшим прибутком пропоненту, щоб переконатися, що пропонент не видимий вміст блоку. Ретранслятор не розкриє повний блок пропоненту, поки той не прийме пропозицію блоку (підпише заголовок блоку). Гонорар, який забудовник сплачує тому, хто пропонує, також потребує допомоги ретранслятора для забезпечення завершення. Транзакція, сплачена пропоненту, включена до поданого блоку, але оскільки пропонент не може бачити вміст блоку, його все одно потрібно підтвердити ретранслятором заздалегідь.
Вхідний протокол і вихідний протокол
Щоб брати участь у ринку, створеному MEV-Boost, валідаторам потрібно запустити сторонню програму MEV-Boost, яка не належить до Ethereum, під час роботи клієнта консенсусу Ethereum і клієнта виконання. Це магія PBS, яка зараз працює, що дозволяє третім сторонам за межами протоколу брати участь у розробці правил для формування консенсусу Ethereum. З точки зору власності, це неймовірно.
Це також спонукало до роздумів про «довіру» до механізму протоколу, про те, як довіра зміцнюється та як вона підривається іншими механізмами. MEV-Boost є гарним прикладом, оскільки можливі ситуації, коли зовнішні протоколи вносять зміни в існуючі механізми. Коли сам протокол починає відставати, такі зміни можуть почати проростати ззовні. Проростання зовнішніх механізмів має відповідати поточному ринковому попиту, але чи є зовнішній механізм надійним і чи він строго розроблений для запобігання появі потенційних. проблеми, і навіть зовнішні механізми, які можуть підірвати угоду, поки не відомі.
Централізоване реле
Найбільш критикований аспект MEV-Boost – це його централізований ринок реле. Але таке налаштування створює проблеми з довірою. Будівельники повинні довіряти реле, щоб не вкрасти їх MEV. Пропоненти також повинні вірити, що заголовки блоків, які вони отримують і підписують від ретранслятора, є дійсними. Однак, незважаючи на їх життєво важливу роль, для реле немає фінансового стимулу, а їх експлуатація потребує значних витрат. Минулого року мережу Ethereum підтримували 11 ретрансляторів, але сьогодні лише 9 ретрансляторів все ще надають послуги.
Варто зазначити, що реле не вимагає доступу до реле, як-от Eden, лише для реле своїх власних конструкторів. Існують також ретранслятори, такі як bloXroute, які стверджують, що відфільтровують транзакції, пов’язані з фронтальними та сендвіч-атаками. Певною мірою реле також має певні нормотворчі права.
Дані надходять із рейтингової мережі
Крім того, з точки зору Liveness, через існування реле, підтвердження атомарного рівня не може бути надано між розробником і пропонентом. Якщо пропонент підписує зобов’язання щодо заголовка блоку, а розробник також надає вміст корисного навантаження, але ретранслятор не встигає вчасно надіслати вміст (зловмисний чи не зловмисний), розробник і пропонент зазнають збитків.
ePBS: інкапсуляція PBS в Ethereum
Інкапсуляція PBS в ePBS Ethereum, схоже, стала обов’язковою для вирішення проблеми централізації ретрансляції чи для переміщення частин поза межами протоколу в протокол. Наразі ePBS більше не обговорюється, і редактор Ethereum EIP присвоїв йому номер – EIP-7732.
ePBS надає надійну інфраструктуру для пропонентів і забудовників, щоб аутсорсингувати права на будівництво блоків. Роль конструктора, яка спочатку була за межами протоколу, була включена в протокол, тобто ще одна роль конструктора розділена між валідаторами. Конструктор як валідатор також повинен завершити заставу в Ethereum. Оскільки обов’язки початкового пропонента консенсусного рівня були розділені, завершення ePBS потребує змін у консенсусному рівні. Серед них конструктор відповідає за створення корисного навантаження виконання (остаточний список транзакцій, які мають бути виконані в блоці). Відповідальність ініціатора полягає в тому, щоб запропонувати блоки маяків. Конкретний процес полягає в наступному:
Дізнавшись, що його вибрано як Пропонент, створіть і транслюйте список включення (IL, тобто транзакції, які повинні бути включені в цей слот).
Конструктори надсилають хеш блоку, що містить корисне навантаження виконання та зобов’язання «SignedExecutionPayloadHeader», яке бажає заплатити пропоненту, тому, хто пропонує (корисне навантаження виконання має відповідати IL)
Пропонент вибирає один із «SignedExecutionPayloadHeader», надісланих розробниками, щоб включити його (зазвичай той, який пропонує найвищу ціну). І транслюйте запропонований блок маяків «SignedBeaconBlock».
Свідки виконують обов'язки свідків
Агрегатори подають атестаційні агрегати, а розробники транслюють дані про виконання
PTC (Комітет своєчасності корисного навантаження, у кожному слоті 512 валідаторів буде обрано як члени PTC) перевіряє, чи розкриває конструктор вчасно корисне навантаження виконання, і транслює результат
ePBS також пройшла через багато дискусій від того часу, як було запропоновано до остаточного отримання номера EIP. Спочатку PBS було запропоновано Віталіком 21 червня, а через чотири місяці було вдосконалено рішення з одним слотом. Ідея PTC була офіційно запропонована лише 23 липня .
PEPC（Зобов'язання пропонента, що підтримуються протоколом）
Звичайно, є й ті, хто не погоджується з ePBS і сподівається використовувати інші рішення. PEPC такий. ePBS вбудовує певне правило в протокол, але тут, у PEPC, пропонент продає права на створення програмованих блоків.
PEPC був запропонований Barnabe у жовтні 2022 року. Барнабе вважає, що якщо механізм PBS буде реалізовано в рамках протоколу, йому слід розглянути можливість впровадження загального механізму для передачі довіреного сигналу, а не впровадження конкретного механізму довіреного сигналу (наприклад, якщо мене попросять створити блок). повернути вам xx ETH).
Подібно до назви PEPC (зобов’язання, що підтримуються протоколом), деякі механізми забезпечення прав та інтересів розробників і пропонентів виконуються через зобов’язання, подані пропонентом у протоколі. Ці зобов’язання можуть бути перевірені в ланцюжку, головним чином коди операції "BEACONROOT" для досягнення. Це більш загальний механізм. Зобов’язання можуть передаватися аутсорсингу на всі права на створення блоків або лише на частину блоків.
резюме
Вище наведено короткий вступ до PBS, ePBS і PEPC. З точки зору розробки протоколу, необхідно не тільки розробити ринковий механізм для перерозподілу MEV, але й розглянути, як зробити валідатори більш децентралізованими та як покращити опір цензурі. Крім того, існує багато компромісів у дизайні протоколу. Візьмемо, наприклад, ePBS, який отримав номер EIP. Хоча конструкція ePBS вирішує проблему централізованого реле, чи справді ключова роль стороннього ретранслятора за межами угоди має лише негативні наслідки? З точки зору механізму оплати забудовника, використання ретрансляції є кращим, ніж механізм ePBS, тому що ePBS є механізмом попередньої оплати. передплачений механізм повернення.
