Изменение спецификации, принятое 26 октября, устраняет уязвимость в обработке депозитов Ethereum, которая могла бы позволить операторам узлов перенаправлять депозиты стейкеров, ожидающие в очереди, в подконтрольные им балансы после активации обновления Glamsterdam. Исправление появилось в репозитории consensus-specs — эталонных правилах, которые реализуют команды клиентов Ethereum — через две недели после того, как уязвимость была сообщена на GitHub. Ошибочному перенаправлению могли подвергнуться только депозиты, остававшиеся в очереди на момент активации форка, а поскольку Glamsterdam ещё не достиг основной сети, средства не были потеряны.

Как оператор мог бы завладеть депозитом стейкера

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

Glamsterdam сочетает изменения на исполнительном уровне с обновлением консенсусного уровня под названием Gloas и добавляет билдеров как новый тип участников в рамках закреплённого разделения пропозера и билдера. Билдеры собирают часть блока с транзакциями и держат собственные балансы. При форке Ethereum конвертирует подходящие депозиты, ещё ожидающие в очереди, в аккаунты билдеров.

Именно в этой конвертации и заключалась уязвимость. По старому правилу, как только ожидающий депозит регистрировал билдера для ключа, каждый последующий депозит с этим ключом пополнял баланс билдера — независимо от того, куда указывали его реквизиты вывода. Оператор мог поставить в очередь депозит билдера для нового ключа с адреса, который он контролировал. Если затем протокол стейга вносил депозит валидатора для того же ключа, и оба депозита оставались в очереди на момент форка, ETH протокола зачислялся бы на баланс билдера оператора, который оператор мог бы затем вывести. Валидатор при этом не создавался бы. Некоторые протоколы высвобождают остальную часть стейка только после подтверждения, что новый валидатор несёт их реквизиты вывода, — и такое подтверждение никогда не поступило бы.

В последующем комментарии автор проблемы перечислил дизайны, которые ошибка могла бы нарушить: гарантию преддепозитов Lido, OETH от Origin и Saturn от Rocket Pool, указав при этом, что список — быстрое исследование с помощью ИИ, которое может содержать ошибки. Во всех случаях уязвимость касалась первого депозита — 1 ETH в примерах Lido и Rocket Pool, — а остальная часть стейка оставалась бы заблокированной до выполнения шагов восстановления. Автор охарактеризовал эти выводы как условные находки в коде, а не действующие эксплойты.

Отклонено 19 октября, принято неделю спустя

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

Три дня спустя Ethereum Foundation отложила активацию Glamsterdam на Hoodi, чтобы изучить взаимодействие EIP-8037 с существующими смарт-контрактами, — проблему, не связанную с депозитами. Дополнительное время возобновило дискуссию. Комментарий от 23 октября в повестке следующего тестирующего звонка связал изменение депозитов с обновлённым графиком, в тот же день автор добавил тесты порядка депозитов, и 26 октября изменение было принято.

Что делает новое правило

После форка депозиты билдеров и валидаторов уже идут отдельными путями согласно EIP-8282. Исправление применяет ту же логику к очереди на момент форка: направление каждого ожидающего депозита определяют реквизиты вывода, а не публичный ключ.

Повторное использование одного ключа для валидатора и билдера по-прежнему допустимо; теперь назначение, указанное в каждом депозите, определяет, какой аккаунт он пополняет.

Что ещё должно произойти до форка

Принятие спецификации — лишь первый шаг; командам клиентов теперь предстоит реализовать то же правило. Изменение в Teku, открытое 27 октября, всё ещё находилось на рассмотрении, а аналогичное в Lodestar оставалось открытым.

Позднее изменение также должно одинаково попасть в каждый клиент. Старые референс-тесты кодируют прежнюю маршрутизацию, поэтому клиент, применяющий новое правило, их не пройдёт. Автор изменения в Teku сообщает об успешном прохождении тестов, сгенерированных из обновённой спецификации, которая ещё не выпущена в составе релиза спецификации. Если бы клиенты подошли к форку с разными правилами для одной и той же очереди, они вычисляли бы разные балансы и расходились бы в состоянии цепи.

Foundation не назначила новых дат ни для Hoodi, ни для запуска Glamsterdam в основной сети. У протоколов стейкинга, полагающихся на подтверждения депозитов, есть и собственная линия защиты: по словам автора проблемы, проверки перед депозитом, отклоняющие ключ, за которым уже закреплён депозит билдера, могут предотвратить этот сценарий. Дальше стоит следить за двумя открытыми pull request клиентов, релизом спецификации с обновлёнными тестами и новыми датами Hoodi и основной сети.