Время, слоты и порядок событий в аттестации Ethereum
2 апреля недоброжелательный участник сети Ethereum использовал уязвимость mev-boost-relay для кражи 20 миллионов долларов у одного из MEV-искателей. Разработчики вскоре выпустили пять патчей для исправления этой уязвимости, но взаимодействие с существующими задержками сети и стратегиями валидаторов привело к кратковременному нестабильному состоянию сети Ethereum 6 апреля. Реструктуризация сети снижает производительность блоков и гарантии расчетов, что негативно сказывается на здоровье сети.
В данной статье рассматривается взаимное влияние mev-boost и механизма консенсуса, раскрываются тонкости аттестации Ethereum и обсуждаются возможные направления для улучшения. Наше вдохновение пришло от двух событий: атак на поисковиков и временной нестабильности сети.
действие mev-boost
mev-boost — это протокол, предназначенный для смягчения негативного влияния максимальной извлекаемой стоимости (MEV) на сеть Ethereum.
В mev-boost есть три роли:
Ретранслятор - соединяет предложителей с надежными посредниками, строящими блоки.
Строитель - строит блоки для максимизации собственного MEV и MEV предложителя.
Предложитель - валидатор аттестации Ethereum.
Приблизительная последовательность событий в каждом блоке:
Создатели получают транзакции для создания блоков от пользователей, искателей или других источников.
Строители отправляют блоки в реле.
Проверка действительности блоков через ретрансляцию, расчет вознаграждения, выплачиваемого предложителю.
Реле отправляет "ослепленный" заголовок блока и сумму платежа предложителю текущего временного интервала.
Представитель оценивает все полученные ставки и подписывает заголовок скрытого блока с самой высокой оплатой.
Предложитель отправит подписанный заголовок блока обратно в реле.
Ретранслятор публикует блоки через локальные узлы-ретрансляторы и возвращает их инициатору. За счет транзакций внутри блока и вознаграждения за блок, строители и инициаторы получают вознаграждение.
Реле как доверенная третья сторона способствует справедливому обмену блок-пространством между инициатором и упорядочиванием сделок для извлечения MEV строителями. Реле защищает строителей от кражи MEV, а также защищает инициаторов, проверяющих действительность блоков, обрабатывающих большое количество блоков и обеспечивающих точные выплаты.
mev-boost является ключевой инфраструктурой, поскольку он позволяет всем заявителям справедливо получать MEV без необходимости устанавливать доверительные отношения, что способствует долгосрочной децентрализации Ethereum.
Правила выбора форка Ethereum и mev-boost
Перед тем как углубиться в обсуждение атак и ответных мер, давайте сначала разберёмся в механизме аттестации Ethereum ( PoS ) и правилах выбора разветвлений. Правила выбора разветвлений позволяют сети достигать консенсуса по головной цепи.
Правила выбора ветки — это функция, оцениваемая клиентом, которая использует известные блоки и другие сообщения в качестве входных данных и выводит, что такое "нормальная цепь". Правила выбора ветки необходимы, потому что может существовать несколько действительных цепей на выбор.
Правила выбора разветвлений и их связь со временем мало известны, но это имеет значительное влияние на производство блоков.
Слоты и подслоты циклы
В Ethereum PoS время делится на слоты по 12 секунд. Алгоритм PoS случайным образом назначает валидатора, который предлагает блок для этого слота, этот валидатор называется предложителем. В одном слоте другие валидаторы назначаются для голосования за последний блок на позиции головы цепочки в их локальном представлении, применяя правила выбора разветвлений. 12-секундный интервал делится на три этапа по 4 секунды.
События в слоте следующие, t=0 означает начало слота:
Ключевым моментом в слоте является срок аттестации в t=4. Если валидатор аттестации не увидит блок до срока, он проголосует за ранее подтвержденный заголовок в цепи. Чем раньше предлагается блок, тем дольше время распространения, и тем больше накопленных свидетельств.
С точки зрения здоровья сети, оптимальное время публикации блока - t=0. Но поскольку ценность блока монотонно увеличивается со временем, у предложителя есть мотив задерживать публикацию, чтобы накопить больше MEV.
В истории, даже после истечения срока аттестации и близко к окончанию слота, если следующий валидатор наблюдает этот блок до построения блока следующего слота, proposer все еще может опубликовать блок. Для того чтобы способствовать рациональному поведению ( задержка публикации блока ) в сторону честного поведения ( своевременной публикации ) было введено "честное переупорядочение".
Повышение предложителя и честная реорганизация
В консенсус-клиент были введены два новых концепта, которые имеют важное значение для срока окончания аттестации.
Повышение предложений - попытка минимизировать атаки на сбалансированность переработки, предоставляя предложителю"повышение" на выбор разветвления, эквивалентное 40% полного веса аттестации. Это повышение длится всего один слот.
Честная реорганизация - использование повышения предложения, позволяющее честным предложителям принудительно реорганизовать блоки с весом аттестации менее 20%. Это реализовано в некоторых клиентских приложениях. Это изменение является необязательным, так как это локальное решение предложителя и не влияет на поведение валидаторов.
В некоторых особых случаях избегайте честной реорганизации:
В период пограничного блока эры
Если цепочка не завершена
Если голова цепи не получена из слота перед реорганизованным блоком
Условие 3: убедитесь, что честная реконструкция удаляет только один блок из цепи, чтобы прерыватель позволил цепи продолжать генерировать блоки при экстремальной сетевой задержке.
Исправление реле и узлов подтверждения для защиты от атак на разъединение
Во время атаки на разъединение 2 апреля, инициаторы использовали уязвимость реле для отправки недействительных заголовков подписи. В последующие дни команды реле и основного разработчика выпустили несколько программных патчей для снижения риска повторных атак. Пять основных изменений следующие:
Изменение ретранслятора:
Проверьте, существует ли в базе данных известный злонамеренный заявитель.
Проверьте, были ли полные блоки переданы в P2P сеть за этот период.
Ввести унифицированную случайную задержку в диапазоне от 0 до 500 мс перед публикацией блока.
Изменение узла цепи Beacon ( применяется только к узлам промежуточной цепи Beacon ):
Проверка действительности блока сигнала перед его трансляцией.
Проверьте, есть ли эквиваленты в сети перед публикацией блока.
Эти изменения приводят к нестабильности консенсуса, а большинство валидаторов применяют честную стратегию реорганизации, что усугубляет эту ситуацию.
Неожиданные последствия
Каждое из вышеупомянутых 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
Хороший парень, 20 миллионов долларов сказали, что их нет.
Посмотреть ОригиналОтветить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 ) и правилах выбора разветвлений. Правила выбора разветвлений позволяют сети достигать консенсуса по головной цепи.
Правила выбора ветки — это функция, оцениваемая клиентом, которая использует известные блоки и другие сообщения в качестве входных данных и выводит, что такое "нормальная цепь". Правила выбора ветки необходимы, потому что может существовать несколько действительных цепей на выбор.
Правила выбора разветвлений и их связь со временем мало известны, но это имеет значительное влияние на производство блоков.
Слоты и подслоты циклы
В Ethereum PoS время делится на слоты по 12 секунд. Алгоритм PoS случайным образом назначает валидатора, который предлагает блок для этого слота, этот валидатор называется предложителем. В одном слоте другие валидаторы назначаются для голосования за последний блок на позиции головы цепочки в их локальном представлении, применяя правила выбора разветвлений. 12-секундный интервал делится на три этапа по 4 секунды.
События в слоте следующие, t=0 означает начало слота:
Ключевым моментом в слоте является срок аттестации в t=4. Если валидатор аттестации не увидит блок до срока, он проголосует за ранее подтвержденный заголовок в цепи. Чем раньше предлагается блок, тем дольше время распространения, и тем больше накопленных свидетельств.
С точки зрения здоровья сети, оптимальное время публикации блока - t=0. Но поскольку ценность блока монотонно увеличивается со временем, у предложителя есть мотив задерживать публикацию, чтобы накопить больше MEV.
В истории, даже после истечения срока аттестации и близко к окончанию слота, если следующий валидатор наблюдает этот блок до построения блока следующего слота, proposer все еще может опубликовать блок. Для того чтобы способствовать рациональному поведению ( задержка публикации блока ) в сторону честного поведения ( своевременной публикации ) было введено "честное переупорядочение".
Повышение предложителя и честная реорганизация
В консенсус-клиент были введены два новых концепта, которые имеют важное значение для срока окончания аттестации.
Повышение предложений - попытка минимизировать атаки на сбалансированность переработки, предоставляя предложителю"повышение" на выбор разветвления, эквивалентное 40% полного веса аттестации. Это повышение длится всего один слот.
Честная реорганизация - использование повышения предложения, позволяющее честным предложителям принудительно реорганизовать блоки с весом аттестации менее 20%. Это реализовано в некоторых клиентских приложениях. Это изменение является необязательным, так как это локальное решение предложителя и не влияет на поведение валидаторов.
В некоторых особых случаях избегайте честной реорганизации:
Условие 3: убедитесь, что честная реконструкция удаляет только один блок из цепи, чтобы прерыватель позволил цепи продолжать генерировать блоки при экстремальной сетевой задержке.
Исправление реле и узлов подтверждения для защиты от атак на разъединение
Во время атаки на разъединение 2 апреля, инициаторы использовали уязвимость реле для отправки недействительных заголовков подписи. В последующие дни команды реле и основного разработчика выпустили несколько программных патчей для снижения риска повторных атак. Пять основных изменений следующие:
Проверьте, существует ли в базе данных известный злонамеренный заявитель.
Проверьте, были ли полные блоки переданы в 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 и механизмом консенсуса; мы надеемся, что протокол будет постоянно укрепляться.