Час, слоти та впорядкування подій у атестації Ethereum
2 квітня один з учасників мережі Ethereum зі злими намірами скористався вразливістю mev-boost-relay для крадіжки 20 мільйонів доларів у одного MEV пошуковця. Розробники згодом випустили п'ять патчів для виправлення цієї вразливості, але взаємодія з існуючою затримкою в мережі та стратегією верифікаторів призвела до короткочасної нестабільності мережі Ethereum 6 квітня. Реорганізація мережі знижує продуктивність блоків і забезпечення розрахунків, що негативно впливає на здоров'я мережі.
Ця стаття має на меті дослідити взаємний вплив mev-boost та механізмів консенсусу, виявити тонкощі в атестації Ethereum та обговорити деякі можливі напрямки покращення. Наше натхнення походить від двох подій: атак на пошукачів і тимчасової нестабільності мережі.
роль mev-boost
mev-boost є протоколом, спрямованим на пом’якшення негативного впливу максимального витягу цінності (MEV) на мережу Ethereum.
у mev-boost є три ролі:
Релей - підключає пропонента до надійного посередника будівельника блоку.
Будівельник - створює блоки, щоб максимізувати власний та пропозиційний MEV складний об'єкт.
Пропонент - валіда тор Ethereum.
Приблизний порядок подій у кожному блоці:
Будівельники отримують транзакції для створення блоків від користувачів, шукачів або інших джерел.
Будівельники подають блоки до реле.
Перевірка дійсності блоків релейної верифікації, обчислення плати, яка сплачується пропоненту.
Ретранслятор надсилає "засліплений" заголовок блоку та суму платежу пропоненту поточного тимчасового слоту.
Автори пропозицій оцінюють усі отримані заявки та підписують заголовок закритого блоку, що відповідає найвищій оплаті.
Автор пропозиції поверне підписане заголовок блоку до реле.
Релей публікує блоки через локальний вузол-мітку та повертає їх пропоненту. Через транзакції в блоці та винагороду за блок будівельники та пропоненти отримують винагороду.
Релей як надійний третій учасник сприяє справедливому обміну блок-простором між пропонентами, а також порядку транзакцій для витягнення MEV будівельниками. Релей захищає будівельників від крадіжки MEV, а також захищає пропонентів у перевірці дійсності блоків, обробці великої кількості блоків і забезпеченні точних платежів.
mev-boost є ключовою інфраструктурою, оскільки дозволяє всім пропонентам справедливо отримувати MEV без необхідності встановлювати довірчі відносини, що сприяє довгостроковій децентралізації Ethereum.
Правила вибору розгалуження Ethereum та mev-boost
Перш ніж поглиблено обговорити атаки та відповіді на них, спочатку розглянемо механізм атестації Ethereum ( PoS ) та правила вибору розгалужень. Правила вибору розгалужень дозволяють мережі досягати консенсусу щодо голови ланцюга.
Правила вибору форкa – це функція, яку оцінює клієнт, вона використовує відомі блоки та інші повідомлення як вхідні дані та виводить, що таке "нормативний ланцюг". Правила вибору форкa необхідні, оскільки може існувати кілька дійсних ланцюгів для вибору.
Правила вибору форків і зв'язок з часом мало відомі, але це має значний вплив на виробництво блоків.
Слоти та підслоти циклів
У PoS Ethereum час ділиться на слоти тривалістю 12 секунд. Алгоритм PoS випадковим чином призначає валідатора, який пропонує блок для цього слоту, цього валідатора називають пропонувальником. У тому ж слоті інші валідатори призначаються для голосування за останній блок на позиції голови ланцюга у їхніх локальних візуалізаціях, застосовуючи правила вибору розгалужень. 12-секундний інтервал ділиться на три етапи по 4 секунди.
Події в слоті такі: t=0 означає початок слоту:
Ключовим моментом у слоті є термін сертифікації t=4. Якщо валідатор сертифікації не побачить блок до терміну, він проголосує за вже підтверджений заголовок на ланцюгу. Чим раніше пропонується блок, тим довший час поширення, і тим більше свідчень накопичується.
З точки зору здоров'я мережі, найкращий час публікації блоку - t=0. Але оскільки вартість блоку монотонно зростає з часом, запропонований має мотивацію затримати публікацію, щоб накопичити більше MEV.
В історії, навіть після закінчення терміну атестації і навіть ближче до закінчення слоту, якщо наступний валідатор спостерігає за блоком перед побудовою наступного блок-слоту, пропонент все ще може опублікувати блок. Щоб спонукати до раціональної поведінки ( затримка публікації блоку ) в напрямку чесної поведінки ( своєчасна публікація ) розвитку, "чесна реорганізація" була введена.
Підвищення пропонента та чесна реорганізація
Два нові концепти були введені в клієнт консенсусу, що має важливий вплив на терміни сертифікації.
Підвищення пропозиційника - спроба мінімізувати атаки на баланс реорганізації шляхом надання пропозиційнику підвищення, що дорівнює 40% повної ваги атестації. Це підвищення триває лише один слот.
Чесна реорганізація - використання підвищення пропозиціонера, що дозволяє чесним пропозиціонерам використовувати його для примусової реорганізації сертифікаційної ваги нижче 20% блоків. Це реалізовано в деяких клієнтах. Ця зміна є необов'язковою, оскільки це є локальне рішення пропозиціонера, що не впливає на поведінку валідаторів.
Уникнення чесного перетворення в деяких особливих випадках:
Протягом прикордонного блоку епохи
Якщо ланцюг не завершено
Якщо голова ланцюга не отримується з слота перед перезавантаженим блоком
Умова 3 Забезпечити, щоб чесна реструктуризація видаляла лише один блок з ланцюга, як запобіжник, щоб ланцюг міг продовжувати генерувати блоки під час екстремальних затримок у мережі.
Виправлення реле та маркерних вузлів проти атак на розв'язання
4 квітня під час атаки на зв'язок, автори пропозиції використали вразливість реле для відправлення недійсних підписів заголовку для атаки. Наступні кілька днів команди реле та основних розробників випустили кілька програмних патчів, щоб зменшити ризик повторних атак. П'ять основних змін такі:
Зміна реле:
Перевірте, чи існують у базі даних відомі зловмисні пропозиції.
Перевірте, чи було передано повний блок до P2P мережі протягом цього періоду.
Введення єдиного випадкового затримки в діапазоні від 0 до 500 мс перед публікацією блоку.
Зміна вузла сигнального ланцюга ( застосовується лише до релейного вузла сигнального ланцюга ):
Перевірте дійсність блоків мовлення перед їх підтвердженням.
Перед публікацією блоку перевірте, чи є на мережі еквіваленти.
Ці зміни спричинили нестабільність консенсусу, а більшість валідаторів, які використовують стратегію чесної перебудови, ще більше загострюють цю ситуацію.
Несподівані наслідки
Зазначені 5 змін кожна з яких збільшить затримку на гарячому шляху публікації проміжного блоку, тим самим збільшуючи ймовірність того, що проміжний блок буде передано, перевищивши термін атестації.
Перед виконанням цих перевірок, підписний заголовок, зазвичай, не буде проблемою, якщо досягне t=3. Витрати на ретрансляцію дуже низькі, блоки можуть бути опубліковані до t=4.
Однак, зі збільшенням затримки, пов'язаної з введенням п'яти патчів, релей може частково нести відповідальність за затримку трансляції. У деяких випадках, якщо пропонент надсилає підписаний заголовок пізно, а релей вводить додаткову затримку, це може призвести до пропуску терміну сертифікації. Без чесної реорганізації ці блоки, ймовірно, потраплять на ланцюг. Але в разі чесної реорганізації пропуск терміну сертифікації означає, що цей блок буде реорганізовано наступним пропонентом.
Отже, протягом кількох днів після атаки кількість відгалужених блоків різко зросла. У найгіршому випадку за годину було 13 блоків ( 4,3% ), що в 5 разів більше, ніж зазвичай. З появою різних змін у релейних системах стало очевидним різке зростання кількості відгалужених блоків. Завдяки зусиллям спільноти багато змін були скасовані, і мережа відновила своє здорове стан.
Найкорисніша зміна наразі - це еквівалентна перевірка перед валідацією та трансляцією блоків узлової сигнали. Зловмисні пропоненти більше не можуть здійснювати атаки, надсилаючи недійсні заголовки до реле та переконуючи, що узлові сигнали реле не бачать еквівалентні блоки перед публікацією. Тим не менш, реле все ще вразливе до більш загальних атак еквівалентності.
Майбутнє напрямок
Наукова спільнота повинна оцінити "прийнятну" кількість реорганізацій, врахувати загальні ризики, пов'язані з еквівалентними атаками, та визначити, чи потрібні заходи для їх пом'якшення.
Активно досліджуються кілька напрямків:
Реалізувати захист "headlock" для mev-boost від еквівалентних атак. Це вимагає зміни програмного забезпечення клієнта консенсусу, можливо, знадобиться продовження терміну сертифікації.
Збільшити програму винагород за вразливості програмного забезпечення mev-boost.
Розширене моделювальне програмне забезпечення досліджує вплив таймінгу підслотів на стабільність мережі.
Оптимізація шляху публікації проміжних блоків для зменшення непотрібних затримок.
Включіть mev-boost у клієнт консенсусу, тобто enshrined-PBS(ePBS).
Додати тестування на основі затримок і термінів сертифікації.
Стимулювання різноманітності релейних клієнтів.
Розгляньте можливість коригування еквівалентних санкцій.
В цілому, ми в захваті від відновленої енергії екосистеми MEV та mev-boost. Завдяки відв'язанню атак і заходів з пом'якшення, ми зрозуміли ключові зв'язки між затримкою, mev-boost та механізмом консенсусу; ми сподіваємося, що протокол буде постійно зміцнюватися.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
14 лайків
Нагородити
14
6
Репост
Поділіться
Прокоментувати
0/400
GasFeePhobia
· 08-13 08:57
А? 2000w так просто зникли?
Переглянути оригіналвідповісти на0
GlueGuy
· 08-13 08:55
Ну й справді, 2000w доларів просто так зникли.
Переглянути оригіналвідповісти на0
HalfBuddhaMoney
· 08-13 08:54
Я майстер збирання, тож спершу зберемо його. Але відчуваю, що трохи втрачено.
Переглянути оригіналвідповісти на0
MetaverseVagabond
· 08-13 08:46
Невірно, що у мене вкрали 20 мільйонів, це жахливо.
Переглянути оригіналвідповісти на0
BrokenDAO
· 08-13 08:42
Ще один випадок, коли атакувальники завжди розумніші за захисників... механізм проектування складний
Час і порядок подій в атестації Ethereum: тонка взаємодія між mev-boost і механізмом консенсусу
Час, слоти та впорядкування подій у атестації Ethereum
2 квітня один з учасників мережі Ethereum зі злими намірами скористався вразливістю mev-boost-relay для крадіжки 20 мільйонів доларів у одного MEV пошуковця. Розробники згодом випустили п'ять патчів для виправлення цієї вразливості, але взаємодія з існуючою затримкою в мережі та стратегією верифікаторів призвела до короткочасної нестабільності мережі Ethereum 6 квітня. Реорганізація мережі знижує продуктивність блоків і забезпечення розрахунків, що негативно впливає на здоров'я мережі.
Ця стаття має на меті дослідити взаємний вплив mev-boost та механізмів консенсусу, виявити тонкощі в атестації Ethereum та обговорити деякі можливі напрямки покращення. Наше натхнення походить від двох подій: атак на пошукачів і тимчасової нестабільності мережі.
роль mev-boost
mev-boost є протоколом, спрямованим на пом’якшення негативного впливу максимального витягу цінності (MEV) на мережу Ethereum.
у mev-boost є три ролі:
Приблизний порядок подій у кожному блоці:
Будівельники отримують транзакції для створення блоків від користувачів, шукачів або інших джерел.
Будівельники подають блоки до реле.
Перевірка дійсності блоків релейної верифікації, обчислення плати, яка сплачується пропоненту.
Ретранслятор надсилає "засліплений" заголовок блоку та суму платежу пропоненту поточного тимчасового слоту.
Автори пропозицій оцінюють усі отримані заявки та підписують заголовок закритого блоку, що відповідає найвищій оплаті.
Автор пропозиції поверне підписане заголовок блоку до реле.
Релей публікує блоки через локальний вузол-мітку та повертає їх пропоненту. Через транзакції в блоці та винагороду за блок будівельники та пропоненти отримують винагороду.
Релей як надійний третій учасник сприяє справедливому обміну блок-простором між пропонентами, а також порядку транзакцій для витягнення MEV будівельниками. Релей захищає будівельників від крадіжки MEV, а також захищає пропонентів у перевірці дійсності блоків, обробці великої кількості блоків і забезпеченні точних платежів.
mev-boost є ключовою інфраструктурою, оскільки дозволяє всім пропонентам справедливо отримувати MEV без необхідності встановлювати довірчі відносини, що сприяє довгостроковій децентралізації Ethereum.
Правила вибору розгалуження Ethereum та mev-boost
Перш ніж поглиблено обговорити атаки та відповіді на них, спочатку розглянемо механізм атестації Ethereum ( PoS ) та правила вибору розгалужень. Правила вибору розгалужень дозволяють мережі досягати консенсусу щодо голови ланцюга.
Правила вибору форкa – це функція, яку оцінює клієнт, вона використовує відомі блоки та інші повідомлення як вхідні дані та виводить, що таке "нормативний ланцюг". Правила вибору форкa необхідні, оскільки може існувати кілька дійсних ланцюгів для вибору.
Правила вибору форків і зв'язок з часом мало відомі, але це має значний вплив на виробництво блоків.
Слоти та підслоти циклів
У PoS Ethereum час ділиться на слоти тривалістю 12 секунд. Алгоритм PoS випадковим чином призначає валідатора, який пропонує блок для цього слоту, цього валідатора називають пропонувальником. У тому ж слоті інші валідатори призначаються для голосування за останній блок на позиції голови ланцюга у їхніх локальних візуалізаціях, застосовуючи правила вибору розгалужень. 12-секундний інтервал ділиться на три етапи по 4 секунди.
Події в слоті такі: t=0 означає початок слоту:
Ключовим моментом у слоті є термін сертифікації t=4. Якщо валідатор сертифікації не побачить блок до терміну, він проголосує за вже підтверджений заголовок на ланцюгу. Чим раніше пропонується блок, тим довший час поширення, і тим більше свідчень накопичується.
З точки зору здоров'я мережі, найкращий час публікації блоку - t=0. Але оскільки вартість блоку монотонно зростає з часом, запропонований має мотивацію затримати публікацію, щоб накопичити більше MEV.
В історії, навіть після закінчення терміну атестації і навіть ближче до закінчення слоту, якщо наступний валідатор спостерігає за блоком перед побудовою наступного блок-слоту, пропонент все ще може опублікувати блок. Щоб спонукати до раціональної поведінки ( затримка публікації блоку ) в напрямку чесної поведінки ( своєчасна публікація ) розвитку, "чесна реорганізація" була введена.
Підвищення пропонента та чесна реорганізація
Два нові концепти були введені в клієнт консенсусу, що має важливий вплив на терміни сертифікації.
Підвищення пропозиційника - спроба мінімізувати атаки на баланс реорганізації шляхом надання пропозиційнику підвищення, що дорівнює 40% повної ваги атестації. Це підвищення триває лише один слот.
Чесна реорганізація - використання підвищення пропозиціонера, що дозволяє чесним пропозиціонерам використовувати його для примусової реорганізації сертифікаційної ваги нижче 20% блоків. Це реалізовано в деяких клієнтах. Ця зміна є необов'язковою, оскільки це є локальне рішення пропозиціонера, що не впливає на поведінку валідаторів.
Уникнення чесного перетворення в деяких особливих випадках:
Умова 3 Забезпечити, щоб чесна реструктуризація видаляла лише один блок з ланцюга, як запобіжник, щоб ланцюг міг продовжувати генерувати блоки під час екстремальних затримок у мережі.
Виправлення реле та маркерних вузлів проти атак на розв'язання
4 квітня під час атаки на зв'язок, автори пропозиції використали вразливість реле для відправлення недійсних підписів заголовку для атаки. Наступні кілька днів команди реле та основних розробників випустили кілька програмних патчів, щоб зменшити ризик повторних атак. П'ять основних змін такі:
Перевірте, чи існують у базі даних відомі зловмисні пропозиції.
Перевірте, чи було передано повний блок до P2P мережі протягом цього періоду.
Введення єдиного випадкового затримки в діапазоні від 0 до 500 мс перед публікацією блоку.
Перевірте дійсність блоків мовлення перед їх підтвердженням.
Перед публікацією блоку перевірте, чи є на мережі еквіваленти.
Ці зміни спричинили нестабільність консенсусу, а більшість валідаторів, які використовують стратегію чесної перебудови, ще більше загострюють цю ситуацію.
Несподівані наслідки
Зазначені 5 змін кожна з яких збільшить затримку на гарячому шляху публікації проміжного блоку, тим самим збільшуючи ймовірність того, що проміжний блок буде передано, перевищивши термін атестації.
Перед виконанням цих перевірок, підписний заголовок, зазвичай, не буде проблемою, якщо досягне t=3. Витрати на ретрансляцію дуже низькі, блоки можуть бути опубліковані до t=4.
Однак, зі збільшенням затримки, пов'язаної з введенням п'яти патчів, релей може частково нести відповідальність за затримку трансляції. У деяких випадках, якщо пропонент надсилає підписаний заголовок пізно, а релей вводить додаткову затримку, це може призвести до пропуску терміну сертифікації. Без чесної реорганізації ці блоки, ймовірно, потраплять на ланцюг. Але в разі чесної реорганізації пропуск терміну сертифікації означає, що цей блок буде реорганізовано наступним пропонентом.
Отже, протягом кількох днів після атаки кількість відгалужених блоків різко зросла. У найгіршому випадку за годину було 13 блоків ( 4,3% ), що в 5 разів більше, ніж зазвичай. З появою різних змін у релейних системах стало очевидним різке зростання кількості відгалужених блоків. Завдяки зусиллям спільноти багато змін були скасовані, і мережа відновила своє здорове стан.
Найкорисніша зміна наразі - це еквівалентна перевірка перед валідацією та трансляцією блоків узлової сигнали. Зловмисні пропоненти більше не можуть здійснювати атаки, надсилаючи недійсні заголовки до реле та переконуючи, що узлові сигнали реле не бачать еквівалентні блоки перед публікацією. Тим не менш, реле все ще вразливе до більш загальних атак еквівалентності.
Майбутнє напрямок
Наукова спільнота повинна оцінити "прийнятну" кількість реорганізацій, врахувати загальні ризики, пов'язані з еквівалентними атаками, та визначити, чи потрібні заходи для їх пом'якшення.
Активно досліджуються кілька напрямків:
Реалізувати захист "headlock" для mev-boost від еквівалентних атак. Це вимагає зміни програмного забезпечення клієнта консенсусу, можливо, знадобиться продовження терміну сертифікації.
Збільшити програму винагород за вразливості програмного забезпечення mev-boost.
Розширене моделювальне програмне забезпечення досліджує вплив таймінгу підслотів на стабільність мережі.
Оптимізація шляху публікації проміжних блоків для зменшення непотрібних затримок.
Включіть mev-boost у клієнт консенсусу, тобто enshrined-PBS(ePBS).
Додати тестування на основі затримок і термінів сертифікації.
Стимулювання різноманітності релейних клієнтів.
Розгляньте можливість коригування еквівалентних санкцій.
В цілому, ми в захваті від відновленої енергії екосистеми MEV та mev-boost. Завдяки відв'язанню атак і заходів з пом'якшення, ми зрозуміли ключові зв'язки між затримкою, mev-boost та механізмом консенсусу; ми сподіваємося, що протокол буде постійно зміцнюватися.