Автор: Георгіос Константопулос, Майк Нойдер

Компіляція: Kxp, BlockBeats

Вступ

2 квітня зловмисники мережі Ethereum скористалися вразливістю в реле MEV-Boost, щоб викрасти 20 мільйонів доларів у одного шукача MEV (див. звіт Flashbots). Протягом наступних кількох днів розробники усунули вразливість, випустивши п’ять патчів. Ці виправлення, у поєднанні із мережевими затримками та політикою перевірки, спричинили короткі коливання в мережі Ethereum 6 квітня. Реорганізація блоків може бути шкідливою для працездатності мережі, оскільки вона сповільнює швидкість виробництва блоків і зменшує гарантії розрахунків.

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

MEV-Boost і чому це важливо

MEV-Boost — це протокол, розроблений Flashbots і спільнотою для пом’якшення негативного впливу максимальної витягуваної вартості (MEV) на мережу Ethereum.

У MEV-Boost є 3 актори:

1. Естафета - аукціоністи, які довіряють один одному, з'єднуючи виробників блоків і будівельників блоків

2. Конструктори - складні сутності, які створюють блоки для максимізації MEV для себе та творців блоку

3. Виробники блоків - верифікатори доказу частки Ethereum

Приблизна послідовність подій для кожного блоку така:

1. Конструктори створюють блок, отримуючи транзакції від користувачів, шукачів або інших (приватних або публічних) потоків замовлень

2. Будівельник подає блок на естафету

3. Ретранслятор перевіряє дійсність блоку та обчислює суму, яку він сплачує виробнику блоку

4. Ретранслятор надсилає порожній заголовок і суму платежу виробнику блоку поточного слота

5. Виробники блоків оцінюють усі отримані ставки та підписують порожній заголовок, пов’язаний із найвищим платежем

6. Виробник блоку надсилає цей підписаний заголовок назад до ретранслятора

7. Ретранслятори публікують блоки, використовуючи власні вузли-маяки, і повертають їх постачальнику блоків. Винагороди розподіляються між розробниками та пропонентами через транзакції в межах блоків і винагород за блоки.

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

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

Правила вибору форка Ethereum і MEV-Boost

Перш ніж обговорювати атаку та відповідь, давайте подивимося на механізм підтвердження частки Ethereum і відповідні правила вибору форків. Правило вибору форка дозволяє мережі досягти консенсусу щодо голови ланцюга, як визначено в статті «Реорганізація Ethereum після злиття»:

«Правило вибору форка — це функція, оцінювана клієнтом, яка приймає як вхідні дані побачені блоки та іншу інформацію та виводить «канонічний ланцюжок» клієнту. Правило вибору розгалуження важливе, оскільки може бути кілька дійсних ланцюжків на вибір (наприклад, якщо два конкуруючі блоки з одним і тим самим батьківським блоком опубліковані одночасно). "

Правила вибору форка також залежать від часу, що суттєво впливає на генерацію блоків.

цикл слотів і підслотів

У механізмі Ethereum proof-of-stake час ділиться на слоти кожні 12 секунд. Алгоритм proof-of-stake випадковим чином призначає валідатору ліцензію на пропонування блоку в цьому слоті; цей валідатор називається виробником блоку. У тому самому слоті іншим валідаторам призначається завдання перевірки (голосування) за голову ланцюга, застосовуючи правила вибору форка відповідно до їхніх локальних поглядів. Цей 12-секундний інтервал розділений на три фази, кожна з яких коштує 4 секунди.

Події, які відбуваються в слоті, є такими, де t=0 вказує на початок слоту.


Під час слоту найбільш критичним моментом є крайній термін автентифікації при t=4. Якщо перевіряючі валідатори не побачать блок до кінцевого терміну атестації, вони проголосують за раніше прийняту голову ланцюга (відповідно до правила вибору форка). Чим раніше буде запропоновано блок, тим більше часу він матиме для поширення та, таким чином, накопичить більше схвалень (оскільки більше валідаторів бачать його до кінцевого терміну схвалення).

З точки зору працездатності мережі, оптимальний час для звільнення блоку становить t=0 (відповідно до специфікації). Однак, оскільки вартість блоку монотонно зростає з часом, виробники блоків мають стимул відкласти випуск своїх блоків, щоб накопичити більше MEV. Докладні відомості дивіться в іграх із визначенням часу в Proof-of-Stake і в цьому обговоренні.

Раніше виробник блоку міг опублікувати блок після кінцевого терміну сертифікації (навіть близько до кінця слота), якщо наступний валідатор спостерігав за блоком перед встановленням блоку для наступного слота. Це пов’язано з тим, що дочірній блок успадковує вагу батьківського блоку, а правило вибору розгалуження закінчується на кінцевому вузлі. Тому відкладення випуску блоку не має побічних ефектів. Щоб допомогти змінити раціональну поведінку (відкладення випусків блоків) на чесну поведінку (вчасна публікація), було реалізовано «чесну реорганізацію».

Блоковий механізм винагороди виробника та чесна реорганізація

Дві нові концепції вводяться в консенсус-клієнт, які мають критичний вплив на кінцевий термін автентифікації.

1. Механізм винагороди виробника блоків – спрямований на мінімізацію атак ребалансування шляхом надання виробникам блоків «винагороди» за вибір форка, що дорівнює 40% від повної ваги автентифікації. Важливо, що ця винагорода діє лише на весь слот.

2. Чесна реорганізація — скористайтеся прискоренням виробника блоків, що дозволяє чесним виробникам блоків примусово реорганізувати блоки з вагою автентифікації нижче 20%. Це вже реалізовано в Lighthouse та Prysm (починаючи з версії 4.0 – випуск Capella). Ця зміна є необов’язковою, оскільки це рішення приймається виробниками блоків і не впливає на поведінку валідаторів автентифікації. Тому ми не застосовуємо його до всіх клієнтів одночасно, і він не прив’язаний до якогось конкретного хардфорку.

Слід зазначити, що чесної реорганізації уникають у деяких особливих випадках:

1. Протягом епохи межові блоки

2. Якщо ланцюжок не завершено

3. Якщо голова ланцюга не є головою слота до реорганізації

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

На малюнку нижче показано, як можна змінити чесну поведінку для реалізації стратегії реструктуризації.


У цьому випадку нехай b1 представляє пізній блок. Через затримку b1 має лише 19% перевірочної ваги n-го слота. Решта 81% ваги перевірки призначається батьківському блоці HEAD, оскільки багато перевірників не бачили b1 до кінцевого терміну перевірки.

Якщо не буде чесної реорганізації, пропонент слота n+1 вважатиме b1 головою ланцюга та побудує підблок b2. Автор пропозиції не зробив жодних зусиль, щоб реорганізувати b1, хоча він має лише 19% доказової ваги. У слоті n+1 b2 має покращення пропонента, припускаючи, що воно буде доставлено вчасно, b2 стане нормою через накопичення більшості доказів для цього слота.

З Чесною реорганізацією все зовсім інакше. Тепер автор пропозиції слота n+1 бачить, що 19% ваг доказів b1 є нижчими за порогове значення реорганізації, тому вони створюють блок із HEAD як батьківським і змушують b1 реорганізуватися. Коли ми досягнемо крайнього терміну перевірки для слота n+1, чесний перевірник порівняє відносну вагу b1 (19%) з b2 (40% від посилення пропонента). Усі клієнти реалізують вдосконалення пропонента, тому b2 вважатиметься головою ланцюга та накопичуватиме докази для слота n+1.

Виправлення вузлів Relay і Beacon для атак роз'єднання

Під час атаки на роз’єднання 2 квітня автор використав уразливість ретранслятора, щоб надіслати на ретранслятор недійсний заголовок підпису. Протягом наступних кількох днів команди ретрансляторів і розробників ядра випустили численні виправлення програмного забезпечення, щоб зменшити ризик повторних атак. П’ять основних змін:

Зміни в реле: перевірте базу даних на наявність відомих зловмисників (використовувалося у виробництві лише Ultrasonic Relay і було видалено). Перевіряє, чи ретранслятор доставив повний блок до слота в мережі P2P. Вводить рівномірну випадкову затримку в діапазоні 0-500 мс перед публікацією блоку (вилучено з усіх реле).

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

НЕПРЕДБАЧЕНІ НАСЛІДКИ

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

Велика кількість підписаних заголовків із затримкою t = 0 (наприклад, t = 3) зазвичай не викликає проблем, доки ці перевірки не будуть реалізовані. Оскільки реле має дуже низькі накладні витрати, воно опублікує блок до t = 4, не чекаючи кінцевого терміну підтвердження.

Однак через затримку впровадження цих п’яти патчів ретранслятор тепер може бути частково відповідальним за затримку трансляції. Давайте розглянемо гіпотетичний процес публікації блоку нижче.


Реле отримує підписаний заголовок від виробника блоку в t = 3. До моменту t = 4 реле все ще виконує перевірки, тому трансляція відбудеться після кінцевого терміну підтвердження. У цьому випадку комбінація відкладеного підписаного заголовка, надісланого виробником блоку, і деякої додаткової затримки, внесеної ретранслятором, спричинили збій трансляції до кінцевого терміну підтвердження. Якби не було чесної реорганізації, ці блоки, швидше за все, потрапили б у ланцюг. Як показано на малюнку 2, чесні виробники блоків наступного слота не будуть навмисно реорганізовуватись, оскільки ці блоки запізнюються. Однак, якщо кінцевий термін підтвердження пропущено, блоки буде реорганізовано наступним виробником блоків.

Отже, кількість роздвоєних блоків різко зросла в наступні дні після атаки.


Двотижневі дані з Metrika показали, що за найгіршого сценарію 13 блоків (4,3%) можуть бути реорганізовані за годину, що приблизно в 5 разів перевищує звичайну швидкість. Різке збільшення кількості роздвоєних блоків стало очевидним, коли ретранслятори внесли різні зміни. Завдяки величезним зусиллям спільноти операторів ретрансляції та основних розробників, як тільки вплив стало відомо, багато змін було скасовано, а мережу відновлено до працездатного стану.

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

Наступна дія

У цій публікації ми висвітлюємо, як працює MEV-Boost і наскільки це важливо для консенсусу Ethereum. Ми також надаємо детальний аналіз деяких менш відомих аспектів правил вибору форка Ethereum, пов’язаних із часом. Використовуючи атаку «відокремлення» та відповіді розробників як тематичне дослідження, ми підкреслюємо потенційну вразливість залежних від часу аспектів правила вибору розгалуження та його вплив на стабільність мережі.

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

Крім того, зараз активно досліджуються кілька напрямків майбутнього:

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

2. Збільште кількість і розповсюдження програм винагороди за помилки для програмного забезпечення MEV-Boost.

3. Розширте програмне забезпечення для моделювання, щоб дослідити, як синхронізація підслотів впливає на стабільність мережі, що можна використовувати для оцінки того, як налаштувати терміни подання доказів, щоб зменшити реорганізацію.

4. Оптимізуйте шлях звільнення блоку на реле, щоб зменшити непотрібні затримки - це вже вивчається.

5. Визнайте MEV-boost основною функцією протоколу та включіть її в консенсусний клієнт, тобто «enshrined-PBS (ePBS)». ePBS з двома слотами вразливий до очевидних атак, тому реалізація «механізму блокування голови» все ще є варіантом.

6. Додавши більше тестів вулика та/або специфікацій щодо проблем із затримкою та термінами сертифікації.

7. Заохочуйте різноманітність клієнтів ретрансляції шляхом створення додаткових реалізацій специфікації ретрансляції.

8. Розгляньте можливість коригування штрафів за очевидні атаки, але майте на увазі, що навіть повний штраф у розмірі 32 ETH може не зупинити зловмисну поведінку, коли існує надзвичайна можливість MEV.

9. Перегляньте хронометраж підінтервалів і розгляньте можливість коригування фази поширення блоку (наприклад, коригування терміну сертифікації з t=4 до t=6).

Загалом ми раді відродженню MEV та екосистеми mev-boost. Завдяки атакам роз’єднання та пом’якшенню ми дізналися про критичний взаємозв’язок між затримкою, посиленням MEV і механізмами консенсусу; ми сподіваємося, що протокол продовжуватиме посилюватися, щоб справлятися з цим.