Час, слоти та порядок подій в атестації Ethereum

2 квітня зловмисник скористався вразливістю певної релейної платформи, вкрадучи 20 мільйонів доларів. Протягом наступних кількох днів розробники вирішили цю проблему, випустивши 5 патчів, але в поєднанні з існуючими затримками мережі та стратегіями валідаторів це призвело до короткочасної нестабільності мережі Ethereum 6 квітня. Ребалансування негативно впливає на здоров'я мережі, оскільки знижує швидкість створення блоків та зменшує гарантії розрахунків.

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

Важливість певного протоколу

Деякий протокол розроблений спільнотою, щоб пом'якшити негативний вплив максимальної витягуваної вартості (MEV) на мережу Ethereum.

У цій угоді є три ролі:

• Релей - з'єднує ініціатора з надійними аукціоністами будівельників блоків.
• Будівельник - будує блоки для максимізації складних сутностей для себе та пропонента MEV.
• Автор пропозиції - валідатор атестації Ethereum.

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

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

Правила вибору розгалуження Ethereum та деякого протоколу

Перед тим як перейти до глибокого аналізу атак і реагування, спочатку розглянемо механізм атестації Ethereum (PoS) та пов'язані з ним правила вибору гілок. Правила вибору гілок дозволяють мережі досягати консенсусу щодо голови ланцюга.

Правила вибору форків - це функція, яку оцінює клієнт, беручи до уваги побачені блоки та повідомлення як вхідні дані, а на виході отримуючи "офіційний ланцюг". Правила вибору форків необхідні, оскільки може бути кілька дійсних ланцюгів на вибір.

Одним із маловідомих аспектів правил вибору форку є їхній зв'язок із часом, що має суттєвий вплив на формування блоків.

слоти та підслоти циклу

У PoS Ethereum час ділиться на слотів тривалістю 12 секунд. Алгоритм PoS випадковим чином призначає валідаторів для пропозиції блоку в цей слот; цього валідатора називають пропонентом. У тому ж слоті інші валідатори призначаються для голосування на підтримку останнього блоку, який знаходиться на позиції голівки ланцюга у їхньому локальному уявленні, застосовуючи правила вибору розгалуження. Інтервал у 12 секунд ділиться на три етапи, кожен з яких триває 4 секунди.

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

З точки зору здоров'я мережі, оптимальний час створення блоку - це t=0. Але оскільки вартість блоку зростає з часом, пропонент має мотивацію затримати випуск, щоб накопичити більше MEV.

В історії, навіть після закінчення терміну сертифікації або близько до закінчення слота, пропонент все ще може публікувати блок, якщо наступний валідатор спостерігає його перед побудовою наступного слот-блоку. Щоб сприяти раціональній поведінці ( затримка публікації ) на чесну поведінку ( вчасно публікувати ) перетворення, було впроваджено "чесне перезавантаження".

Підвищення та чесна реорганізація пропозиції

Два нових поняття були впроваджені в консенсусний клієнт, які мають ключовий вплив на терміни підтвердження:

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

Чесна реорганізація - впровадження пропозиціонера, який посилює та дозволяє чесному пропозиціонеру використовувати його для примусового перетворення блоків з сертифікованою вагою нижче 20%. Це реалізовано в деяких клієнтах. Ця зміна є необов'язковою, оскільки є локальним рішенням пропозиціонера і не впливає на поведінку валідаторів.

Уникайте чесного перетворення в деяких особливих випадках:

1. Під час граничного блоку епохи
2. Якщо ланцюг не завершено
3. Якщо голова ланцюга не отримана з тимчасового інтервалу перед блоком перепідключення

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

Виправлення реле та узгоджувальних вузлів проти атак розв'язування

У атаці 2 квітня пропонент скористався вразливістю реле, надіславши заголовок з недійсним підписом для атаки. Протягом наступних кількох днів команди розробників реле та ядра випустили кілька патчів для зниження ризику повторних атак. Основні зміни такі:

1.Зміна реле:

• Перевірте, чи існують відомі зловмисні пропозиції в базі даних
• Перевірте, чи було передано повний блок у P2P-мережу за цей період
• Введення випадкової затримки перед випуском блоку

2. Зміна вузлів Beacon Chain ( стосується лише ретрансляційних вузлів Beacon ):

• Передача сигналу про блоки перед перевіркою їхньої дійсності
• Перед публікацією блоку перевірте, чи є в мережі еквіваленти

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

Непередбачувані наслідки

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

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

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

Тому, в перші кілька днів після атаки, кількість розгалужених блоків різко зросла. У найгіршому випадку, протягом години було повторно організовано 13 блоків (4.3%), що приблизно у 5 разів більше, ніж зазвичай. Завдяки впровадженню різних змін, різке зростання кількості розгалужених блоків стало очевидним. Завдяки зусиллям громади, багато змін були скасовані, і мережа відновила здоровий стан.

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

Майбутнє напрямок

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

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

• Реалізувати "headlock" для запобігання атакам еквівалентності
• Збільшення програми винагород за вразливості для відповідного програмного забезпечення
• Розширити програмне забезпечення для моделювання для дослідження впливу синхронізації підчасового проміжку на стабільність мережі
• Оптимізація шляху публікації блоків на релейній мережі для зменшення затримки
• Включити певний протокол до клієнта консенсусу
• Додати більше тестів на основі проблем затримки та термінів аутентифікації
• Заохочення різноманітності релейних клієнтів
• Розглянути можливість корекції еквівалентних покарань

В цілому, ми в захваті від відновленої енергії навколо MEV та відповідної екосистеми. Через цю подію ми зрозуміли ключові зв'язки між затримкою, певним протоколом та механізмом консенсусу; ми сподіваємося, що протокол зможе продовжувати зміцнюватися.