Месячная ошибка в клиенте Ethereum стала причиной сбоя Prysm

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

Разработчик Ethereum Теренс Цао опубликовал в воскресенье подробный разбор инцидента, произошедшего 4 декабря. Согласно отчету, узлы Prysm столкнулись с «исчерпанием ресурсов» при обработке аттестаций от узлов, выпавших из синхронизации. Это заставляло клиент повторно обрабатывать блоки прошлых эпох и заново вычислять сложные переходы состояний, что создавало чрезмерную нагрузку и серьезно снижало производительность.

В отчете указано, что баг присутствовал в тестовых сетях целый месяц до инцидента, но не был активирован. «Ошибка была внесена в Pull Request Prysm №15965 и развернута в тестовых сетях за месяц до происшествия, но триггер не сработал», — говорится в сообщении. Этот случай напоминает, что тестовые сети, хотя и предназначены для выявления багов, не являются стопроцентной гарантией.

Проблема устранена

Вместо использования текущего состояния сети (head state) Prysm начинал заново генерировать предыдущие состояния с нуля, что создавало огромную вычислительную нагрузку.

В течение более чем 42 эпох в сети наблюдался пропуск 18.5% слотов, а участие валидаторов упало до 75%. В результате валидаторы потеряли приблизительно 382 Ether (ETH) в виде наград за аттестации. Операторам узлов было рекомендовано временное решение, пока разработчики готовили патч для обновления клиентов Prysm.

Клиентское разнообразие спасло ситуацию

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

Согласно данным ClientDiversity, Prysm от Offchain Labs является вторым по популярности клиентом Ethereum с долей в 17.6%. «Клиентское разнообразие предотвратило заметное влияние на пользователей Ethereum. Если бы клиент, контролирующий более 1/3 сети, столкнулся с такой проблемой, это привело бы к временной потере финализации и большему количеству пропущенных блоков», — подчеркивается в отчете.

Однако инцидент высветил, что доля клиента Lighthouse (52.6% на момент публикации, снизившаяся с примерно 56% во время сбоя) опасно близка к порогу в две трети, при котором баг в одном клиенте может привести к финализации неверной цепи.