Разработчики Ethereum внесли исправление в ошибку обработки депозитов в предстоящем обновлении Glamsterdam, которая могла позволить создателю блоков получить ETH, предназначенный для нового валидатора. Изначально было принято решение отклонить предложенное изменение, но затем от него отказались.

Согласно спецификациям консенсуса Ethereum, разработчик Джастин Тралья внес исправление 26 октября после того, как разработчик avsetsin выявил проблему в обработке ожидающих депозитов во время форка Gloas. Изменение разделяет депозиты создателей блоков и депозиты валидаторов в соответствии с их учетными данными для вывода средств, предотвращая попадание средств на неверный счет, если оба используют один и тот же публичный ключ.

Уязвимость касалась правил, находящихся в разработке, а не подтвержденного факта кражи из основной сети Ethereum. Разработчики внесли исправление в спецификации, хотя отдельные клиенты консенсуса все еще должны реализовать и протестировать измененное поведение.

Ошибка в Ethereum Glamsterdam выявила риск, связанный с внесением депозитов для валидаторов

Проблема возникла в результате изменений, запланированных в рамках внедрения разделения ролей создателя блоков и валидатора в Glamsterdam, которое определяет, что создание блоков и предложение блоков возлагаются на разные роли. Создатели блоков формируют пакеты транзакций, а валидаторы участвуют в предложении и подтверждении блоков посредством системы доказательства доли (proof-of-stake) Ethereum.

Исследователь avsetsin описал ошибку 12 октября, выявив проблему в правилах, используемых для обработки депозитов, ожидающих поступления во время обновления сети. Если создатель блоков зарегистрируется, используя публичный ключ, до того, как поступит депозит валидатора, использующий тот же ключ, предложенная логика может зачислить оба депозита создателю блоков.

Возможно, вам также будет интересно: Glamsterdam исключен из октябрьского плана Hoodi, поскольку Ethereum проверяет риски, связанные с контрактами

Исследователь описал сценарий, в котором оператор стейкинга получает средства от протокола ликвидного стейкинга для создания нового валидатора. Зарегистрировавшись сначала в качестве создателя блоков, оператор может привести к тому, что депозит валидатора протокола будет зачислен на баланс создателя блоков, где адрес для вывода средств может находиться под контролем оператора.

«Оператор может вывести средства протокола», — предупредил avsetsin в отчете на GitHub.

Поскольку ожидаемый валидатор не будет создан, служба стейкинга может столкнуться с трудностями в получении доказательств, необходимых для завершения обычных процедур внесения депозита и восстановления.

Исследователь изучил потенциальные риски, связанные с Lido, Origin и Rocket Pool, проведя предварительное исследование кода. Эти выводы зависели от того, как отдельные протоколы обрабатывают депозиты, и в отчете не было установлено, что проекты подверглись взлому.

Разработчики пересмотрели решение после дальнейшего анализа

Предложенная корректировка первоначально встретила сопротивление со стороны разработчиков клиентов Ethereum, несмотря на то, что исследователь описал риск, связанный с маршрутизацией депозитов. 19 октября Тралья закрыл запрос на внесение изменений после обсуждения среди основных разработчиков.

«В настоящее время недостаточно поддержки со стороны клиентов, чтобы внести эти изменения», — написал Тралья.

Однако это решение не было окончательным, и разработчики возобновили рассмотрение предложения 23 октября после дополнительного изучения.

Впоследствии рецензент potuz одобрил предложенный подход, но запросил проведение дополнительных тестов для конкретных комбинаций депозитов. Авсецин добавил эти тесты 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. Команды разработчиков должны внести изменения в спецификацию в свой программный продукт и провести дополнительные тесты, прежде чем обновленные правила смогут применяться во время будущего обновления сети.