Ethereum на грани краха: как одна ошибка в коде чуть не обрушила блокчейн с активами на миллиарды долларов

Развертывание Fusaka спровоцировало выход из строя части валидаторов Ethereum

Неожиданный сбой в одном из ключевых компонентов инфраструктуры Ethereum едва не привёл к масштабной дестабилизации сети. Ошибка в версии клиента Prysm v7.0.0 стала причиной того, что часть валидаторов перестала корректно участвовать в подтверждении блоков. Последствия инцидента оказались ощутимыми, но система в итоге восстановилась. Об этом сообщает TradingView.

Как возникла ошибка

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

"Проблема нарушила корректную работу нод, использующих этот клиент", — пояснил ведущий разработчик Теренс Цао.

Инженеры оперативно представили временное исправление, отключив неисправный участок кода. Несмотря на это, на эпохе 411 448 сеть зафиксировала резкое падение ключевых метрик: лишь 75% валидаторов подписывали актуальные заголовки блоков, а участие в консенсусе снизилось до 74,7%. Ethereum оказался на грани полной потери финализации — до критического порога оставалось менее девяти процентных пунктов.

Позже показатели стабилизировались:

участие в консенсусе — около 99%;
синхронизация — 97%.

До инцидента значения превышали 99%, и даже такое снижение показало, насколько чувствителен механизм финализации к отдельным сбоям.

Доля Prysm и уязвимость экосистемы

Снижение активности примерно совпало с долей валидаторов, использующих Prysm: если 3 декабря она составляла 22,71%, то после сбоя упала до 15,65%. Для децентрализованной сети это тревожный сигнал, ведь отказ даже одного клиента способен пошатнуть устойчивость всей экосистемы.

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

приостановка вывода средств через L2-мосты и роллапы;
повышение числа подтверждений депозитов на биржах;
рост рисков и неопределённости для всех финансовых операций в Ethereum.

Подобное уже случалось в мае 2023 года: сеть дважды за сутки теряла финализацию из-за ошибок в клиентах Prysm и Teku.

Проблема недостаточного разнообразия клиентов

Хотя нынешний сбой оказался локальным, исторически зависимость Ethereum от отдельных клиентов была куда выше. Осенью 2021 года Prysm контролировал более 66% валидаторов — одна ошибка тогда могла парализовать всю сеть.

К январю 2022 года доля Prysm выросла до 68,1%, оставляя экосистему в уязвимом положении. С тех пор разработчики добились прогресса, однако до безопасного распределения ещё далеко. Считается, что ни один клиент не должен превышать 33% доли. Сегодня лидером остаётся Lighthouse с показателем 52,55%.

"Мы избежали катастрофы лишь по счастливой случайности. Если бы ошибка произошла в Lighthouse, сеть могла утратить финализацию", — отметил эксперт по Ethereum Энтони Сассано.

Ранее, в сентябре, аналогичные трудности возникли у Reth — клиента уровня исполнения от Paradigm: баг привёл к остановке синхронизации узлов, но был устранён.

Сравнение клиентов Ethereum

Ethereum функционирует благодаря множеству клиентов, реализующих одинаковый протокол, но с разными кодовыми базами. Ключевые из них — Prysm, Lighthouse, Teku, Nimbus и Lodestar. Каждый имеет свои преимущества.

Prysm — распространён благодаря стабильной работе и активной команде поддержки, но теперь доказал, что монокультура опасна.
Lighthouse — выделяется скоростью и эффективностью, однако излишняя доля рынка повышает системные риски.
Teku и Nimbus — реже используются, но обеспечивают необходимое разнообразие клиентов и повышают устойчивость сети.

Диверсификация — главный фактор безопасности Ethereum: чем равномернее распределены клиенты, тем меньше вероятность, что единичный баг приведёт к глобальному сбою.