Временной порядок, слоты и события в аттестации Ethereum
2 апреля злоумышленник использовал уязвимость определенной релейной платформы для кражи 20 миллионов долларов. В последующие дни разработчики выпустили 5 патчей для решения этой проблемы, но в сочетании с существующей задержкой сети и стратегиями валидаторов это привело к кратковременному нестабильному состоянию сети Ethereum 6 апреля. Реконструкция негативно сказывается на здоровье сети, так как снижает скорость создания блоков и уменьшает гарантии расчетов.
Данная статья направлена на исследование взаимодействия между определенным протоколом и консенсусом, раскрывая тонкости механизма аттестации Ethereum и перечисляя некоторые возможные направления для продвижения. Мы вдохновлены атаками на искателей и временной нестабильностью сети.
Важность определенного протокола
Некоторый протокол был разработан сообществом и направлен на смягчение негативного влияния максимальной извлекаемой ценности (MEV) на сеть Ethereum.
В этом протоколе три роли:
Ретранслятор - соединяет предложителей с надежными аукционистами строителей блоков.
Строители - создают блоки для максимизации MEV для себя и инициаторов предложений.
Предложитель - Эфир аттестации валидатор.
Приблизительная последовательность событий каждого блока: строители создают блок и отправляют его в реле; реле проверяет действительность блока и вычисляет плату, выплачиваемую предложителю; реле отправляет "слепую подпись" заголовка и сумму платежа текущему предложителю; предложитель оценивает все полученные ставки и подписывает заголовок слепой подписи с самой высокой выплатой; предложитель отправляет подписанный заголовок обратно в реле; реле использует локальный сигнальный узел для публикации блока и возвращает его предложителю.
Данный протокол является ключевой инфраструктурой, так как он позволяет всем заявителям справедливо получать MEV, не устанавливая доверительных отношений с строителями или искателями, что способствует долгосрочной децентрализации Ethereum.
Правила выбора веток Ethereum и некоторый протокол
Перед тем как углубиться в атаки и ответы, давайте сначала рассмотрим механизм аттестации Эфира ( PoS ) и связанные с ним правила выбора форка. Правила выбора форка позволяют сети достигать консенсуса по поводу головы цепи.
Правила выбора форка — это функция, которую оценивает клиент, принимающая увиденные блоки и сообщения в качестве входных данных и выводящая "официальную цепь". Правила выбора форка необходимы, потому что может быть несколько действительных цепей на выбор.
Одним из малоизвестных аспектов правил выбора форка является его связь со временем, что имеет значительное влияние на создание блоков.
Слоты и подсистемные слоты
В Ethereum PoS время делится на 12-секундные слоты. Алгоритм PoS случайным образом назначает валидатора, который предлагает блок в этом слоте; этот валидатор называется предложителем. В одном и том же слоте другие валидаторы назначаются для голосования в поддержку последних блоков, находящихся в месте, где, по их локальному представлению, находится цепочка, применяя правила выбора разветвлений. 12-секундный интервал делится на три этапа, каждый из которых длится 4 секунды.
Ключевым моментом в слоте является срок окончания аттестации t=4. Если аттестующий валидатор не увидит блок до окончания срока, он проголосует за предыдущую цепочку. Чем раньше представлен блок, тем больше у него времени на распространение и накопление большего количества свидетельств.
С точки зрения здоровья сети, оптимальное время для создания блока - t=0. Однако, поскольку ценность блока увеличивается с течением времени, предлагающие имеют стимул задерживать публикацию, чтобы накопить больше MEV.
В истории, даже после окончания срока аттестации и даже близко к окончанию слота, предложители все еще могут публиковать блоки, если следующий валидатор наблюдает за ними перед созданием последующих слотов блоков. Для того чтобы продвигать рациональное поведение ( задержка публикации ) к честному поведению ( своевременная публикация ) изменения, была внедрена "честная реорганизация".
Повышение предложений и честная реорганизация
Две новые концепции были введены в клиент консенсуса, которые имеют ключевое значение для срока сертификации:
Повышение инициатора - минимизировать атаки на сбалансированность реорганизации, предоставив инициатору выбор "повышение" с весом 40% от полного веса аттестации. Это улучшение длится всего один временной интервал.
Честная реорганизация - применение усиления предложителя и разрешение честному предложителю использовать его для принудительной реорганизации блоков с менее чем 20% аттестационного веса. Это реализовано в некоторых клиентах. Это изменение является необязательным, поскольку оно является местным решением предложителя и не влияет на поведение валидаторов.
Избегайте честной реконструкции в некоторых особых случаях:
В период граничного блока эпохи
Если цепочка не завершена
Если голова цепи не получена из временного слота перед перестройкой блока
Условие 3 гарантирует, что честная переработка удаляет только один блок из цепи, действуя как автомат отключения, позволяя цепи продолжать создавать блоки в условиях экстремальной сетевой задержки. Это также отражает снижение уверенности инициатора в своем представлении о сети.
Исправление реле и узлов сигнализации для защиты от атак отвязки
В атаке 2 апреля предложитель воспользовался уязвимостью реле, отправив недействительный заголовок подписи для атаки. В последующие дни команда реле и команда основных разработчиков выпустила несколько патчей для снижения риска повторных атак. Основные изменения следующие:
1.Изменение промежуточного узла:
Проверьте, существует ли в базе данных известный злонамеренный предложитель
Проверьте, были ли переданы полные блоки в P2P сеть за этот период.
Введение случайной задержки перед публикацией блока
Изменение узла цепи Beacon ( применимо только к узлам промежуточного Beacon ):
Проверка действительности блока сигнала перед его трансляцией
Проверьте, есть ли эквиваленты в сети перед выпуском блока
Эти изменения привели к нестабильности консенсуса, и большинство валидаторов сейчас используют честную стратегию реорганизации, что еще больше усугубляет эту ситуацию.
Непредвиденные последствия
Каждое из вышеупомянутых 5 изменений увеличивает задержку на горячем пути публикации промежуточных блоков, что увеличивает вероятность того, что промежуточный блок может превысить срок сертификации.
Перед выполнением этих проверок время прибытия заголовка подписи значительно позже t=0(, как t=3), обычно проблем не возникает. Расходы на ретрансляцию очень низкие, поэтому блок будет опубликован до t=4.
Однако, с увеличением задержки, вызванной введением патча, релей может вызвать задержку трансляции. В некоторых случаях, когда предлагающий отправляет подписанные заголовки поздно, и дополнительные задержки, вызванные релеем, приводят к пропуску срока подтверждения. Если не будет честной реорганизации, эти блоки, скорее всего, войдут в цепочку. Но в случае честной реорганизации, пропуск срока подтверждения означает, что этот блок будет реорганизован следующим предлагающим.
Таким образом, в течение нескольких дней после атаки количество разветвленных блоков резко увеличилось. В худшем случае за час было переорганизовано 13 блоков (4.3%), что примерно в 5 раз больше, чем обычно. С выходом различных изменений от реле стало очевидно резкое увеличение количества разветвленных блоков. Благодаря усилиям сообщества многие изменения были отменены, и сеть восстановила свое здоровье.
На данный момент наиболее полезным изменением является эквивалентная проверка перед валидацией и трансляцией блоков узлов Beacon. Злоумышленники больше не могут осуществлять атаки, отправляя недействительные заголовки в реле и гарантируя, что узлы Beacon реле не увидят эквивалентные блоки до их публикации. Тем не менее, реле по-прежнему подвержены более общим атакам эквивалентности.
Будущее направление
Учитывая это, исследовательское сообщество должно оценить, какое количество "приемлемо" для реорганизации, и рассмотреть риски, связанные с эквивалентной атакой, чтобы определить, нужны ли меры по смягчению.
В настоящее время активно исследуются несколько направлений будущего:
Реализовать "headlock" для предотвращения атак эквивалентности
Увеличить программу вознаграждений за уязвимости, связанную с соответствующим программным обеспечением
Расширение программного обеспечения для моделирования с целью изучения влияния таймингa подслотов на стабильность сети
Оптимизация пути публикации блоков на реле для уменьшения задержки
Интеграция протокола в клиент консенсуса
Добавить больше тестов, основанных на проблемах задержки и сроков аттестации.
В целом, мы рады вновь возникающей энергии вокруг MEV и связанной экосистемы. Благодаря этому событию мы поняли ключевые отношения между задержкой, некоторыми протоколами и механизмом согласования; мы надеемся, что протокол сможет продолжать укрепляться.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
20 Лайков
Награда
20
6
Репост
Поделиться
комментарий
0/400
NFTFreezer
· 08-17 04:05
eth столкнулся с Хакером, и что с того?
Посмотреть ОригиналОтветить0
MevHunter
· 08-17 03:03
Снова началось мозговое печение?
Посмотреть ОригиналОтветить0
Deconstructionist
· 08-14 17:13
Уже голова кружится, этот механизм POS слишком запутан.
Посмотреть ОригиналОтветить0
GasWaster
· 08-14 17:08
только что потратил 5 эфиров на неудачные транзакции... PoS больше не безопасен, смешно
Посмотреть ОригиналОтветить0
Degen4Breakfast
· 08-14 16:58
Снова один день мир криптовалют обеденной компании
Анализ механизма консенсуса PoS Ethereum: время, слоты и порядок событий
Временной порядок, слоты и события в аттестации Ethereum
2 апреля злоумышленник использовал уязвимость определенной релейной платформы для кражи 20 миллионов долларов. В последующие дни разработчики выпустили 5 патчей для решения этой проблемы, но в сочетании с существующей задержкой сети и стратегиями валидаторов это привело к кратковременному нестабильному состоянию сети Ethereum 6 апреля. Реконструкция негативно сказывается на здоровье сети, так как снижает скорость создания блоков и уменьшает гарантии расчетов.
Данная статья направлена на исследование взаимодействия между определенным протоколом и консенсусом, раскрывая тонкости механизма аттестации Ethereum и перечисляя некоторые возможные направления для продвижения. Мы вдохновлены атаками на искателей и временной нестабильностью сети.
Важность определенного протокола
Некоторый протокол был разработан сообществом и направлен на смягчение негативного влияния максимальной извлекаемой ценности (MEV) на сеть Ethereum.
В этом протоколе три роли:
Приблизительная последовательность событий каждого блока: строители создают блок и отправляют его в реле; реле проверяет действительность блока и вычисляет плату, выплачиваемую предложителю; реле отправляет "слепую подпись" заголовка и сумму платежа текущему предложителю; предложитель оценивает все полученные ставки и подписывает заголовок слепой подписи с самой высокой выплатой; предложитель отправляет подписанный заголовок обратно в реле; реле использует локальный сигнальный узел для публикации блока и возвращает его предложителю.
Данный протокол является ключевой инфраструктурой, так как он позволяет всем заявителям справедливо получать MEV, не устанавливая доверительных отношений с строителями или искателями, что способствует долгосрочной децентрализации Ethereum.
Правила выбора веток Ethereum и некоторый протокол
Перед тем как углубиться в атаки и ответы, давайте сначала рассмотрим механизм аттестации Эфира ( PoS ) и связанные с ним правила выбора форка. Правила выбора форка позволяют сети достигать консенсуса по поводу головы цепи.
Правила выбора форка — это функция, которую оценивает клиент, принимающая увиденные блоки и сообщения в качестве входных данных и выводящая "официальную цепь". Правила выбора форка необходимы, потому что может быть несколько действительных цепей на выбор.
Одним из малоизвестных аспектов правил выбора форка является его связь со временем, что имеет значительное влияние на создание блоков.
Слоты и подсистемные слоты
В Ethereum PoS время делится на 12-секундные слоты. Алгоритм PoS случайным образом назначает валидатора, который предлагает блок в этом слоте; этот валидатор называется предложителем. В одном и том же слоте другие валидаторы назначаются для голосования в поддержку последних блоков, находящихся в месте, где, по их локальному представлению, находится цепочка, применяя правила выбора разветвлений. 12-секундный интервал делится на три этапа, каждый из которых длится 4 секунды.
Ключевым моментом в слоте является срок окончания аттестации t=4. Если аттестующий валидатор не увидит блок до окончания срока, он проголосует за предыдущую цепочку. Чем раньше представлен блок, тем больше у него времени на распространение и накопление большего количества свидетельств.
С точки зрения здоровья сети, оптимальное время для создания блока - t=0. Однако, поскольку ценность блока увеличивается с течением времени, предлагающие имеют стимул задерживать публикацию, чтобы накопить больше MEV.
В истории, даже после окончания срока аттестации и даже близко к окончанию слота, предложители все еще могут публиковать блоки, если следующий валидатор наблюдает за ними перед созданием последующих слотов блоков. Для того чтобы продвигать рациональное поведение ( задержка публикации ) к честному поведению ( своевременная публикация ) изменения, была внедрена "честная реорганизация".
Повышение предложений и честная реорганизация
Две новые концепции были введены в клиент консенсуса, которые имеют ключевое значение для срока сертификации:
Повышение инициатора - минимизировать атаки на сбалансированность реорганизации, предоставив инициатору выбор "повышение" с весом 40% от полного веса аттестации. Это улучшение длится всего один временной интервал.
Честная реорганизация - применение усиления предложителя и разрешение честному предложителю использовать его для принудительной реорганизации блоков с менее чем 20% аттестационного веса. Это реализовано в некоторых клиентах. Это изменение является необязательным, поскольку оно является местным решением предложителя и не влияет на поведение валидаторов.
Избегайте честной реконструкции в некоторых особых случаях:
Условие 3 гарантирует, что честная переработка удаляет только один блок из цепи, действуя как автомат отключения, позволяя цепи продолжать создавать блоки в условиях экстремальной сетевой задержки. Это также отражает снижение уверенности инициатора в своем представлении о сети.
Исправление реле и узлов сигнализации для защиты от атак отвязки
В атаке 2 апреля предложитель воспользовался уязвимостью реле, отправив недействительный заголовок подписи для атаки. В последующие дни команда реле и команда основных разработчиков выпустила несколько патчей для снижения риска повторных атак. Основные изменения следующие:
1.Изменение промежуточного узла:
Эти изменения привели к нестабильности консенсуса, и большинство валидаторов сейчас используют честную стратегию реорганизации, что еще больше усугубляет эту ситуацию.
Непредвиденные последствия
Каждое из вышеупомянутых 5 изменений увеличивает задержку на горячем пути публикации промежуточных блоков, что увеличивает вероятность того, что промежуточный блок может превысить срок сертификации.
Перед выполнением этих проверок время прибытия заголовка подписи значительно позже t=0(, как t=3), обычно проблем не возникает. Расходы на ретрансляцию очень низкие, поэтому блок будет опубликован до t=4.
Однако, с увеличением задержки, вызванной введением патча, релей может вызвать задержку трансляции. В некоторых случаях, когда предлагающий отправляет подписанные заголовки поздно, и дополнительные задержки, вызванные релеем, приводят к пропуску срока подтверждения. Если не будет честной реорганизации, эти блоки, скорее всего, войдут в цепочку. Но в случае честной реорганизации, пропуск срока подтверждения означает, что этот блок будет реорганизован следующим предлагающим.
Таким образом, в течение нескольких дней после атаки количество разветвленных блоков резко увеличилось. В худшем случае за час было переорганизовано 13 блоков (4.3%), что примерно в 5 раз больше, чем обычно. С выходом различных изменений от реле стало очевидно резкое увеличение количества разветвленных блоков. Благодаря усилиям сообщества многие изменения были отменены, и сеть восстановила свое здоровье.
На данный момент наиболее полезным изменением является эквивалентная проверка перед валидацией и трансляцией блоков узлов Beacon. Злоумышленники больше не могут осуществлять атаки, отправляя недействительные заголовки в реле и гарантируя, что узлы Beacon реле не увидят эквивалентные блоки до их публикации. Тем не менее, реле по-прежнему подвержены более общим атакам эквивалентности.
Будущее направление
Учитывая это, исследовательское сообщество должно оценить, какое количество "приемлемо" для реорганизации, и рассмотреть риски, связанные с эквивалентной атакой, чтобы определить, нужны ли меры по смягчению.
В настоящее время активно исследуются несколько направлений будущего:
В целом, мы рады вновь возникающей энергии вокруг MEV и связанной экосистемы. Благодаря этому событию мы поняли ключевые отношения между задержкой, некоторыми протоколами и механизмом согласования; мы надеемся, что протокол сможет продолжать укрепляться.