Разработчики Ethereum объединили исправление уязвимости обработки депозитов в предстоящем обновлении Glamsterdam, которая могла позволить строителю блоков получить ETH, предназначенные для нового валидатора, после первоначального решения отклонить предложенное изменение.
Краткое содержание
- Ethereum объединил исправление обработки депозитов Glamsterdam 26 октября.
- Уязвимость могла зачислить стейкинговые депозиты строителям, использующим тот же публичный ключ.
- Разработчики первоначально отклонили исправление, прежде чем одобрить дополнительные тесты.
- Отдельное расследование совместимости контрактов задержало активацию Glamsterdam в Hoodi.
Согласно спецификациям консенсуса Ethereum, мейнтейнер Джастин Траглия объединил исправление 26 октября после того, как разработчик avsetsin выявил проблему с тем, как будут обрабатываться ожидающие депозиты во время форка Gloas. Изменение отделяет депозиты строителей от депозитов валидаторов в соответствии с их учётными данными для вывода, предотвращая попадание средств на неправильный счёт, когда оба используют один и тот же публичный ключ.
Уязвимость касалась правил, находящихся в разработке, а не подтверждённой кражи из основной сети Ethereum. Разработчики включили исправление в спецификации, хотя отдельным клиентам консенсуса всё ещё необходимо реализовать и протестировать пересмотренное поведение.
Уязвимость Glamsterdam в Ethereum выявила риск для депозитов валидаторов
Проблема возникла из изменений, запланированных в рамках закреплённого разделения предлагающего и строителя в Glamsterdam, которое распределяет построение блоков и предложение блоков между разными ролями. Строители собирают полезные нагрузки транзакций, в то время как валидаторы участвуют в предложении и подтверждении блоков через систему доказательства доли владения Ethereum.
Исследователь avsetsin описал уязвимость 12 октября, выявив проблему в правилах, используемых для обработки депозитов, ожидающих при обновлении сети. Если строитель зарегистрировался с использованием публичного ключа до того, как поступил депозит валидатора под тем же ключом, предложенная логика могла зачислить оба депозита строителю.
Исследователь обрисовал сценарий, в котором оператор стейкинга получает средства от протокола ликвидного стейкинга для создания нового валидатора. Зарегистрировавшись сначала как строитель, оператор мог бы заставить депозит валидатора протокола попасть на баланс строителя, где адрес для вывода мог бы находиться под контролем оператора.
«Оператор может вывести средства протокола», — предупредил avsetsin в отчёте на GitHub.
Поскольку ожидаемый валидатор не был бы создан, служба стейкинга могла бы испытывать трудности с получением доказательства, необходимого для завершения своих обычных процедур депозита и восстановления.
Исследователь изучил потенциальную подверженность риску, связанную с Lido, Origin и Rocket Pool, посредством предварительного исследования кода. Эти выводы зависели от того, как отдельные протоколы обрабатывали депозиты, и отчёт не устанавливал, что проекты подверглись эксплойту.
Разработчики отменили решение после дальнейшего рассмотрения
Предложенное исправление первоначально встретило сопротивление со стороны разработчиков клиентов Ethereum, несмотря на описание исследователем риска маршрутизации депозитов. 19 октября Траглия закрыл пул-реквест после обсуждений среди основных разработчиков.
«В настоящее время не было достаточной поддержки со стороны клиентов, чтобы внести это изменение», — написал Траглия.
Решение не осталось в силе: разработчики вновь открыли предложение 23 октября после дальнейшего изучения.
Впоследствии рецензент potuz одобрил подход, но запросил дополнительные тесты для конкретных комбинаций депозитов. Avsetsin добавил эти тесты 23 октября, охватывающие случаи, когда депозиты строителя и валидатора используют общий публичный ключ, но требуют раздельной обработки.
Окончательное изменение было объединено в спецификации консенсуса Ethereum 26 октября после дальнейшего рассмотрения клиентами. Оно направляет действительные депозиты валидаторов в очередь валидаторов, позволяя при этом законным депозитам строителей регистрироваться или добавлять средства к существующему строителю.
Новые правила различают депозиты по учётным данным для вывода, которые определяют разрешённые условия вывода. Они сохраняют отдельные записи строителя и валидатора даже там, где один и тот же публичный ключ появляется в обеих ролях.
Задержка Hoodi даёт разработчикам больше времени на исследование
Обновление спецификации появилось в тот момент, когда разработчики Ethereum рассматривали отдельную проблему, затрагивающую запланированную активацию Glamsterdam в тестовой сети Hoodi. Фонд Ethereum отложил обновление, намеченное на 26 октября, после того как исследователи выявили риски совместимости, связанные с EIP-8037.
Как crypto.news ранее сообщал об отсрочке, это решение исключило как изменения исполнения Amsterdam, так и изменения консенсуса Gloas из запланированной активации в Hoodi. Предложенное увеличение лимита газа до 200 миллионов было отложено вместе с ними.
Исследователь Ethereum Тони Варштеттер объяснил, что EIP-8037 может помешать смарт-контрактам, полагающимся на предположения об оставшемся газе во время исполнения. Он выявил случаи, когда учёт газа мог привести к неожиданному откату транзакции или позволить путь исполнения, который разработчики считали недостижимым.
Проблема совместимости контрактов отличается от дефекта депозита билдера, исправленного в правке на GitHub. Обе касаются Glamsterdam, но отсрочка Фонда от 22 октября конкретно ссылалась на дальнейшее исследование взаимодействия EIP-8037 с существующими контрактами.
Клиенты Ethereum должны реализовать пересмотренные правила
Glamsterdam уже активирован в тестовой сети Sepolia 6 октября, где разработчики изучили изменения построения блоков и более высокую пропускную способность обработки транзакций. Последующая репетиция в Hoodi остаётся не запланированной, без подтверждённой даты активации в основной сети Ethereum.
Объединённое исправление депозита содержит регрессионные тесты, охватывающие то, как депозиты классифицируются во время перехода Gloas. Команды клиентов должны внедрить изменение спецификации в своё программное обеспечение и завершить дальнейшее тестирование, прежде чем обновлённые правила смогут работать во время будущего обновления сети.
