2 апреля злоумышленники сети Ethereum воспользовались уязвимостью в ретрансляторе MEV-Boost, чтобы украсть 20 миллионов долларов у искателя MEV (см. отчет Flashbots). В течение следующих нескольких дней разработчики устранили уязвимость, выпустив пять патчей. Эти исправления в сочетании с сетевыми задержками и политиками валидатора вызвали кратковременные колебания в сети Ethereum 6 апреля. Реорганизация блоков может нанести ущерб работоспособности сети, поскольку она замедляет скорость производства блоков и снижает гарантии расчетов.
В этом посте, когда Seekers находится под атакой и сеть временно нестабильна, мы исследуем взаимодействие между MEV-Boost и консенсусом, анализируем тонкости механизма подтверждения доли Ethereum и перечисляем некоторые возможные пути продвижения вперед.
MEV-Boost и почему это важно
MEV-Boost — это протокол, разработанный Flashbots и сообществом для смягчения негативного воздействия максимальной извлекаемой стоимости (MEV) на сеть Ethereum.
В MEV-Boost есть 3 актера:
Эстафета — Аукционисты, которые доверяют друг другу, соединяют производителей блоков и строителей блоков.
Конструкторы — сложные сущности, которые строят блоки, чтобы максимизировать MEV для себя и создателей блоков.
Производители блоков — верификаторы Ethereum.
Примерная последовательность событий для каждого блока:
Строители создают блок, получая транзакции от пользователей, поисковиков или других (частных или общедоступных) потоков заказов.
Строитель подает блок на реле
Ретранслятор проверяет действительность блока и рассчитывает сумму, которую он платит производителю блока.
Ретранслятор отправляет пустой заголовок и значение платежа производителю блока текущего слота.
Производители блоков оценивают все полученные ими ставки и подписывают пустой заголовок, связанный с самой высокой оплатой.
Производитель блока отправляет этот подписанный заголовок обратно ретранслятору.
Ретрансляторы публикуют блоки, используя свои собственные узлы-маяки, и возвращают их поставщику блоков. Вознаграждения распределяются среди создателей и предлагающих посредством транзакций внутри блоков и вознаграждений за блоки.
Ретранслятор — это доверенная третья сторона, которая способствует справедливому обмену блочным пространством производителями блоков и упорядочению транзакций сборщиками для извлечения MEV. Реле защищают строителей, защищая строителей от кражи MEV, не позволяя производителям блоков копировать транзакции строителя, чтобы забрать MEV, не распределяя его среди искателей/строителей, которые его нашли. Реле защищает производителей блоков, подтверждая достоверность их блоков, обрабатывая сотни блоков в каждом слоте от их имени и обеспечивая точность платежей производителей блоков.
MEV-Boost является ключевой инфраструктурой протокола, поскольку он позволяет всем производителям блоков демократически получать доступ к MEV, не требуя доверительных отношений со строителями или поисковиками, что способствует долгосрочной децентрализации Ethereum.
Правила выбора форка Ethereum и MEV-Boost
Прежде чем обсуждать атаку и ответ, давайте взглянем на механизм подтверждения доли Ethereum и связанные с ним правила выбора форка. Правило выбора форка позволяет сети достичь консенсуса по голове цепочки, как это определено в статье «Реорганизация Эфириума после слияния»:
«Правило выбора форка — это оцениваемая клиентом функция, которая принимает на вход увиденные блоки и другую информацию и выводит клиенту «каноническую цепочку». Правило выбора форка важно, потому что может быть несколько допустимых цепочек на выбор (например, если два конкурирующих блока с одним и тем же родительским блоком публикуются одновременно). "
Правила выбора форка также зависят от времени, что оказывает существенное влияние на генерацию блоков.
цикл слота и подслота
В механизме Proof-of-Stake Ethereum время делится на слоты каждые 12 секунд. Алгоритм proof-of-stake случайным образом назначает валидатору лицензию на предложение блока в этом слоте; этот валидатор называется производителем блока. В том же слоте другим валидаторам назначается задача проверки (голосования) главы цепочки с применением правил выбора форка в соответствии с их локальными представлениями. Этот 12-секундный слот разделен на три фазы, каждая из которых стоит 4 секунды.
События, происходящие в слоте, следующие, где t=0 указывает на начало слота.
Во время слота самым критическим моментом является крайний срок аутентификации в t=4. Если аттестующие валидаторы не увидят блок к сроку аттестации, они проголосуют за ранее принятого руководителя цепочки (согласно правилу выбора форка). Чем раньше предлагается блок, тем больше времени у него есть на распространение и, следовательно, на накопление большего количества одобрений (поскольку больше валидаторов увидят его до истечения срока утверждения).
С точки зрения работоспособности сети оптимальное время для освобождения блока — t=0 (согласно спецификации). Однако, поскольку стоимость блока со временем монотонно увеличивается, у производителей блоков есть стимул откладывать выпуск своих блоков, чтобы накопилось больше MEV. Подробности см. в разделе «Игры на время» в Proof-of-Stake и в этом обсуждении.
Раньше производитель блоков мог опубликовать блок после крайнего срока сертификации (даже ближе к концу слота), если следующий валидатор наблюдал за блоком перед созданием блока для следующего слота. Это происходит из-за того, что дочерний блок наследует вес родительского блока, а правило выбора ответвления заканчивается на листовом узле. Таким образом, отсрочка выпуска блоков не имеет побочных эффектов. Чтобы помочь изменить рациональное поведение (откладывание выпусков блоков) на честное поведение (публикацию вовремя), была реализована «честная реорганизация».
Механизм вознаграждения производителей блоков и честная реорганизация
В клиенте консенсуса представлены две новые концепции, которые оказывают решающее влияние на крайний срок аутентификации.
Механизм поощрения производителей блоков. Направлен на минимизацию атак перебалансировки путем присуждения производителям блоков «вознаграждения» за выбор вилки, равного 40% от полного веса аутентификации. Важно отметить, что эта награда действует только в течение всего слота.
Честная реорганизация — воспользуйтесь преимуществом ускорения производителей блоков, позволяющим честным производителям блоков принудительно реорганизовать блоки с весами аутентификации ниже 20%. Это уже реализовано в Lighthouse и Prysm (начиная с v4.0 - релиз Capella). Это изменение является необязательным, поскольку это решение, принятое производителями блоков, и оно не влияет на поведение аутентифицирующих валидаторов. Поэтому мы не применяем его ко всем клиентам одновременно и не привязываем его к какому-то конкретному хардфорку.
Следует отметить, что в некоторых особых случаях добросовестной реорганизации избегают:
В эпоху пограничных блоков
Если цепочка не доработана
Если глава цепочки не является главой слота до реорганизации
Случай 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, честные производители блоков следующего слота не будут намеренно реорганизовываться, потому что эти блоки опаздывают. Однако, если срок подтверждения пропущен, блоки будут реорганизованы следующим производителем блоков.
Следовательно, количество разветвленных блоков резко возросло в первые дни после атаки.
Данные Метрики за две недели показали, что в худшем случае 13 блоков (4,3%) могут быть реорганизованы за час, что примерно в 5 раз превышает нормальную скорость. Резкое увеличение количества разветвленных блоков стало очевидным, когда ретрансляторы внесли различные изменения. Благодаря огромным усилиям сообщества операторов ретрансляции и основных разработчиков, как только стало известно о воздействии, многие изменения были отменены, и сеть была восстановлена до работоспособного состояния.
На сегодняшний день наиболее полезными изменениями являются проверка блока узла маяка и проверка отказа перед выпуском. Вредоносные производители блоков больше не могут выполнять атаки, отправляя недопустимые заголовки ретрансляторам и гарантируя, что узлы ретранслятора-маяка не увидят отвергнутые блоки перед их публикацией. Тем не менее, ретрансляторы по-прежнему сталкиваются с более общими атаками отказа, предложенными в MEV-Boost и ePBS.
Следующее действие
В этом посте мы расскажем, как работает MEV-Boost и насколько он важен для консенсуса Ethereum. Мы также предоставляем подробный анализ некоторых менее известных аспектов правил выбора форка Ethereum, связанных со временем. Используя атаку «разделения» и ответы разработчиков в качестве примера, мы подчеркиваем потенциальную уязвимость связанных со временем аспектов правила выбора форка и его влияние на стабильность сети.
Имея это в виду, исследовательское сообщество должно оценить «приемлемое» количество реорганизаций, принимая во внимание более общую подверженность атакам отказа, чтобы определить, следует ли внедрять меры по смягчению последствий.
Кроме того, в настоящее время активно изучаются несколько будущих направлений:
Реализовать механизм блокировки головы для защиты MEV-boost от атак с ошибками эквивалентности. Это также потребует внесения изменений в клиентское программное обеспечение консенсуса и, возможно, изменений в спецификации, чтобы продлить крайний срок подачи доказательств.
Увеличить количество и распространение программ вознаграждения за ошибки для программного обеспечения MEV-Boost.
Расширьте программное обеспечение для моделирования, чтобы изучить, как синхронизация подслотов влияет на стабильность сети, что может быть использовано для оценки того, как скорректировать крайние сроки отправки доказательств, чтобы уменьшить реорганизацию.
Оптимизировать путь освобождения блока на реле, чтобы уменьшить ненужные задержки — это уже изучается.
Признать усиление MEV основной функцией протокола и включить его в клиент консенсуса, т. е. «enshrined-PBS (ePBS)». Двухслотовый ePBS уязвим для очевидных атак, поэтому реализация «механизма блокировки головы» по-прежнему возможна.
Добавляя дополнительные тесты кустов и/или спецификаций для решения проблем, связанных с задержкой и крайними сроками сертификации.
Поощряйте разнообразие клиентов ретрансляции, создавая дополнительные реализации спецификации ретрансляции.
Рассмотрите возможность корректировки штрафов за очевидные атаки, но имейте в виду, что даже полный штраф в размере 32 ETH может не сдержать злонамеренное поведение, когда существует крайняя возможность MEV.
Пересмотрите синхронизацию подинтервалов и рассмотрите возможность корректировки фазы распространения блока (например, изменение крайнего срока сертификации с t=4 до t=6).
В целом, мы рады возрождению MEV и экосистемы mev-boost. Благодаря разделению атак и смягчению последствий мы узнали о критической взаимосвязи между задержкой, усилением MEV и механизмами консенсуса; мы надеемся, что протокол будет и впредь усилен, чтобы справляться с этим.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Подробное объяснение принципа работы MEV-Boost и правил выбора форка Ethereum.
Автор: Георгиос Константинопулос, Майк Нойдер
Сборник: Kxp, BlockBeats
Введение
2 апреля злоумышленники сети Ethereum воспользовались уязвимостью в ретрансляторе MEV-Boost, чтобы украсть 20 миллионов долларов у искателя MEV (см. отчет Flashbots). В течение следующих нескольких дней разработчики устранили уязвимость, выпустив пять патчей. Эти исправления в сочетании с сетевыми задержками и политиками валидатора вызвали кратковременные колебания в сети Ethereum 6 апреля. Реорганизация блоков может нанести ущерб работоспособности сети, поскольку она замедляет скорость производства блоков и снижает гарантии расчетов.
В этом посте, когда Seekers находится под атакой и сеть временно нестабильна, мы исследуем взаимодействие между MEV-Boost и консенсусом, анализируем тонкости механизма подтверждения доли Ethereum и перечисляем некоторые возможные пути продвижения вперед.
MEV-Boost и почему это важно
MEV-Boost — это протокол, разработанный Flashbots и сообществом для смягчения негативного воздействия максимальной извлекаемой стоимости (MEV) на сеть Ethereum.
В MEV-Boost есть 3 актера:
Эстафета — Аукционисты, которые доверяют друг другу, соединяют производителей блоков и строителей блоков.
Конструкторы — сложные сущности, которые строят блоки, чтобы максимизировать MEV для себя и создателей блоков.
Производители блоков — верификаторы Ethereum.
Примерная последовательность событий для каждого блока:
Строители создают блок, получая транзакции от пользователей, поисковиков или других (частных или общедоступных) потоков заказов.
Строитель подает блок на реле
Ретранслятор проверяет действительность блока и рассчитывает сумму, которую он платит производителю блока.
Ретранслятор отправляет пустой заголовок и значение платежа производителю блока текущего слота.
Производители блоков оценивают все полученные ими ставки и подписывают пустой заголовок, связанный с самой высокой оплатой.
Производитель блока отправляет этот подписанный заголовок обратно ретранслятору.
Ретрансляторы публикуют блоки, используя свои собственные узлы-маяки, и возвращают их поставщику блоков. Вознаграждения распределяются среди создателей и предлагающих посредством транзакций внутри блоков и вознаграждений за блоки.
Ретранслятор — это доверенная третья сторона, которая способствует справедливому обмену блочным пространством производителями блоков и упорядочению транзакций сборщиками для извлечения MEV. Реле защищают строителей, защищая строителей от кражи MEV, не позволяя производителям блоков копировать транзакции строителя, чтобы забрать MEV, не распределяя его среди искателей/строителей, которые его нашли. Реле защищает производителей блоков, подтверждая достоверность их блоков, обрабатывая сотни блоков в каждом слоте от их имени и обеспечивая точность платежей производителей блоков.
MEV-Boost является ключевой инфраструктурой протокола, поскольку он позволяет всем производителям блоков демократически получать доступ к MEV, не требуя доверительных отношений со строителями или поисковиками, что способствует долгосрочной децентрализации Ethereum.
Правила выбора форка Ethereum и MEV-Boost
Прежде чем обсуждать атаку и ответ, давайте взглянем на механизм подтверждения доли Ethereum и связанные с ним правила выбора форка. Правило выбора форка позволяет сети достичь консенсуса по голове цепочки, как это определено в статье «Реорганизация Эфириума после слияния»:
«Правило выбора форка — это оцениваемая клиентом функция, которая принимает на вход увиденные блоки и другую информацию и выводит клиенту «каноническую цепочку». Правило выбора форка важно, потому что может быть несколько допустимых цепочек на выбор (например, если два конкурирующих блока с одним и тем же родительским блоком публикуются одновременно). "
Правила выбора форка также зависят от времени, что оказывает существенное влияние на генерацию блоков.
цикл слота и подслота
В механизме Proof-of-Stake Ethereum время делится на слоты каждые 12 секунд. Алгоритм proof-of-stake случайным образом назначает валидатору лицензию на предложение блока в этом слоте; этот валидатор называется производителем блока. В том же слоте другим валидаторам назначается задача проверки (голосования) главы цепочки с применением правил выбора форка в соответствии с их локальными представлениями. Этот 12-секундный слот разделен на три фазы, каждая из которых стоит 4 секунды.
События, происходящие в слоте, следующие, где t=0 указывает на начало слота.
Во время слота самым критическим моментом является крайний срок аутентификации в t=4. Если аттестующие валидаторы не увидят блок к сроку аттестации, они проголосуют за ранее принятого руководителя цепочки (согласно правилу выбора форка). Чем раньше предлагается блок, тем больше времени у него есть на распространение и, следовательно, на накопление большего количества одобрений (поскольку больше валидаторов увидят его до истечения срока утверждения).
С точки зрения работоспособности сети оптимальное время для освобождения блока — t=0 (согласно спецификации). Однако, поскольку стоимость блока со временем монотонно увеличивается, у производителей блоков есть стимул откладывать выпуск своих блоков, чтобы накопилось больше MEV. Подробности см. в разделе «Игры на время» в Proof-of-Stake и в этом обсуждении.
Раньше производитель блоков мог опубликовать блок после крайнего срока сертификации (даже ближе к концу слота), если следующий валидатор наблюдал за блоком перед созданием блока для следующего слота. Это происходит из-за того, что дочерний блок наследует вес родительского блока, а правило выбора ответвления заканчивается на листовом узле. Таким образом, отсрочка выпуска блоков не имеет побочных эффектов. Чтобы помочь изменить рациональное поведение (откладывание выпусков блоков) на честное поведение (публикацию вовремя), была реализована «честная реорганизация».
Механизм вознаграждения производителей блоков и честная реорганизация
В клиенте консенсуса представлены две новые концепции, которые оказывают решающее влияние на крайний срок аутентификации.
Механизм поощрения производителей блоков. Направлен на минимизацию атак перебалансировки путем присуждения производителям блоков «вознаграждения» за выбор вилки, равного 40% от полного веса аутентификации. Важно отметить, что эта награда действует только в течение всего слота.
Честная реорганизация — воспользуйтесь преимуществом ускорения производителей блоков, позволяющим честным производителям блоков принудительно реорганизовать блоки с весами аутентификации ниже 20%. Это уже реализовано в Lighthouse и Prysm (начиная с v4.0 - релиз Capella). Это изменение является необязательным, поскольку это решение, принятое производителями блоков, и оно не влияет на поведение аутентифицирующих валидаторов. Поэтому мы не применяем его ко всем клиентам одновременно и не привязываем его к какому-то конкретному хардфорку.
Следует отметить, что в некоторых особых случаях добросовестной реорганизации избегают:
В эпоху пограничных блоков
Если цепочка не доработана
Если глава цепочки не является главой слота до реорганизации
Случай 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, честные производители блоков следующего слота не будут намеренно реорганизовываться, потому что эти блоки опаздывают. Однако, если срок подтверждения пропущен, блоки будут реорганизованы следующим производителем блоков.
Следовательно, количество разветвленных блоков резко возросло в первые дни после атаки.
Данные Метрики за две недели показали, что в худшем случае 13 блоков (4,3%) могут быть реорганизованы за час, что примерно в 5 раз превышает нормальную скорость. Резкое увеличение количества разветвленных блоков стало очевидным, когда ретрансляторы внесли различные изменения. Благодаря огромным усилиям сообщества операторов ретрансляции и основных разработчиков, как только стало известно о воздействии, многие изменения были отменены, и сеть была восстановлена до работоспособного состояния.
На сегодняшний день наиболее полезными изменениями являются проверка блока узла маяка и проверка отказа перед выпуском. Вредоносные производители блоков больше не могут выполнять атаки, отправляя недопустимые заголовки ретрансляторам и гарантируя, что узлы ретранслятора-маяка не увидят отвергнутые блоки перед их публикацией. Тем не менее, ретрансляторы по-прежнему сталкиваются с более общими атаками отказа, предложенными в MEV-Boost и ePBS.
Следующее действие
В этом посте мы расскажем, как работает MEV-Boost и насколько он важен для консенсуса Ethereum. Мы также предоставляем подробный анализ некоторых менее известных аспектов правил выбора форка Ethereum, связанных со временем. Используя атаку «разделения» и ответы разработчиков в качестве примера, мы подчеркиваем потенциальную уязвимость связанных со временем аспектов правила выбора форка и его влияние на стабильность сети.
Имея это в виду, исследовательское сообщество должно оценить «приемлемое» количество реорганизаций, принимая во внимание более общую подверженность атакам отказа, чтобы определить, следует ли внедрять меры по смягчению последствий.
Кроме того, в настоящее время активно изучаются несколько будущих направлений:
Реализовать механизм блокировки головы для защиты MEV-boost от атак с ошибками эквивалентности. Это также потребует внесения изменений в клиентское программное обеспечение консенсуса и, возможно, изменений в спецификации, чтобы продлить крайний срок подачи доказательств.
Увеличить количество и распространение программ вознаграждения за ошибки для программного обеспечения MEV-Boost.
Расширьте программное обеспечение для моделирования, чтобы изучить, как синхронизация подслотов влияет на стабильность сети, что может быть использовано для оценки того, как скорректировать крайние сроки отправки доказательств, чтобы уменьшить реорганизацию.
Оптимизировать путь освобождения блока на реле, чтобы уменьшить ненужные задержки — это уже изучается.
Признать усиление MEV основной функцией протокола и включить его в клиент консенсуса, т. е. «enshrined-PBS (ePBS)». Двухслотовый ePBS уязвим для очевидных атак, поэтому реализация «механизма блокировки головы» по-прежнему возможна.
Добавляя дополнительные тесты кустов и/или спецификаций для решения проблем, связанных с задержкой и крайними сроками сертификации.
Поощряйте разнообразие клиентов ретрансляции, создавая дополнительные реализации спецификации ретрансляции.
Рассмотрите возможность корректировки штрафов за очевидные атаки, но имейте в виду, что даже полный штраф в размере 32 ETH может не сдержать злонамеренное поведение, когда существует крайняя возможность MEV.
Пересмотрите синхронизацию подинтервалов и рассмотрите возможность корректировки фазы распространения блока (например, изменение крайнего срока сертификации с t=4 до t=6).
В целом, мы рады возрождению MEV и экосистемы mev-boost. Благодаря разделению атак и смягчению последствий мы узнали о критической взаимосвязи между задержкой, усилением MEV и механизмами консенсуса; мы надеемся, что протокол будет и впредь усилен, чтобы справляться с этим.