Ошибка в клиенте Prysm обошлась валидаторам Ethereum в 382 ETH после обновления Fusaka

После обновления сети Ethereum под кодовым названием Fusaka ошибка в программном обеспечении консенсус-клиента Prysm привела к сбоям в работе сети и финансовым потерям для валидаторов. Как сообщила команда разработчиков Offchain Labs, инцидент произошел 4 декабря 2025 года и был вызван проблемой исчерпания ресурсов, которая затронула почти все узлы Prysm.

В результате сбоя валидаторы пропустили 41 эпоху (epoch), не успев обработать 248 блоков из 1344 доступных слотов. Уровень пропущенных слотов достиг 18,5%, а общее участие в сети упало до 75% в пиковый период инцидента. Прямым финансовым последствием стала потеря вознаграждений за аттестации на сумму около 382 ETH, что на момент публикации новости эквивалентно более чем 1 миллиону долларов США.

Техническая причина заключалась в том, что узлы Prysm получали аттестации от нод, возможно, рассинхронизированных с сетью. Эти аттестации ссылались на корни блоков из предыдущих эпох. Для их валидации в соответствии с правилами консенсуса Ethereum клиент Prysm был вынужден многократно пересчитывать старые состояния Beacon Chain, что привело к чрезмерной нагрузке на вычислительные ресурсы. Как отмечается в отчете, подобные перерасчеты наблюдались почти 4000 раз.

В качестве временного решения команда рекомендовала пользователям активировать флаг --disable-last-epoch-target в версии 7.0.0. Позже в обновлениях 7.0.1 и 7.1.0 были внедрены постоянные исправления, которые изменили логику проверки аттестаций, исключив необходимость «перепроигрывания» исторических состояний.

Инцидент вновь обострил дискуссию о рисках, связанных с концентрацией клиентского ПО в сети Ethereum. По данным Miga Labs, на момент сбоя доминирующим консенсус-клиентом оставался Lighthouse с долей в 51,39% валидаторов. Доля Prysm составляла 19,06%, за ним следовали Teku (13,71%) и Nimbus (9,25%). Разработчики и участники экосистемы призвали валидаторов рассмотреть возможность перехода на альтернативные клиенты, чтобы снизить системные риски, связанные с возможными ошибками в одном программном обеспечении.