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

Когда разработчики Solana призвали валидаторов быстро перейти на Agave v3.0.14, это сообщение было передано с большей срочностью, чем подробностями.

Аккаунт Solana Status назвал выпуск "срочным" и сообщил, что он содержит "критический набор исправлений" для валидаторов Mainnet Beta.

В течение дня публичная дискуссия сместилась к более сложному вопросу: что происходит, если сети с консенсусом на основе доли (proof-of-stake) требуется быстрая и скоординированная модернизация, а операторы не действуют согласованно?

Этот разрыв стал очевидным в первых отчетах об использовании. 11 января широко распространенный отчет гласил, что только 18% доли были перенесены на v3.0.14, что оставляло значительную часть экономической мощи сети на более старых версиях в период, объявленный срочным.

Для сети, которая в течение последнего года рекламировала надежность наряду со скоростью, история сместилась от самого кода к тому, сможет ли операторский парк достаточно быстро прийти к согласию, когда это необходимо.

В течение следующих нескольких дней картина стала более четкой и полезной, чем это предполагали первые заголовки.

Команда Anza, стоящая за Agave, опубликовала сводку исправлений безопасности 16 января, объясняющую, почему v3.0.14 важен и почему операторам было рекомендовано быстро обновиться.

Примерно в то же время экосистема Solana дала понять, что координация не зависит только от доброй воли, поскольку критерии делегирования Solana Foundation теперь явно ссылаются на требуемые версии программного обеспечения, включая Agave 3.0.14 и Frankendancer 0.808.30014, как часть стандартов, которым должны соответствовать валидаторы для получения делегированной доли.

В совокупности эти события превращают v3.0.14 в пример того, что "всегда доступные финансы" требуют на практике на Solana, не только от программного обеспечения, но и от стимулов и поведения операторов в условиях цейтнота.

Высокоскоростная сеть все равно работает на основе действий человека.

Solana — это блокчейн с консенсусом на основе доли, предназначенный для быстрой обработки больших объемов транзакций, с валидаторами, которые голосуют за блоки и обеспечивают безопасность реестра пропорционально доле SOL, делегированной им.

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

Эта конструкция имеет следствие, которое легко упустить, если вы смотрите только на графики цен токенов. Блокчейн — это не один компьютер в одном месте. В Solana "сеть" — это тысячи независимых операторов, работающих с совместимым программным обеспечением, обновляющихся в разное время, на разных хостинговых платформах, с разными уровнями автоматизации и толерантности к риску.

Когда все идет гладко, эта независимость ограничивает единые точки контроля. Когда требуется срочное обновление, та же независимость затрудняет координацию.

Ландшафт валидаторов-клиентов Solana повышает требования к координации. Наиболее распространенной производственной версией является клиент, поддерживаемый форком Agave от Anza, и сеть также продвигается к более широкому разнообразию клиентов благодаря усилиям Jump Crypto под названием Firedancer, при этом Frankendancer является важной вехой на этом пути.

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

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

Что изменилось за последние 10 дней: причины стали публичными, а стимулы стали видимыми

Раскрытие информации от Anza восполнило недостающую часть истории. В декабре 2025 года через уведомления о безопасности в GitHub были раскрыты две критические потенциальные уязвимости, и Anza сообщила, что эти проблемы были устранены в сотрудничестве с Firedancer, Jito и Solana Foundation.

Одна из проблем касалась системы обмена сообщениями Solana, механизма, с помощью которого валидаторы обмениваются определенными сетевыми сообщениями даже при прерывании производства блоков. По словам Anza, дефект в обработке некоторых сообщений мог приводить к сбоям валидаторов в определенных условиях, и скоординированная атака, выводящая из строя достаточное количество стейка, могла бы снизить доступность кластера.

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

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

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

Вопрос об операторах по-прежнему важен, но он становится более конкретным: насколько быстро распределенный парк может развернуть исправление, когда режимы отказа являются конкретными и системными?

Параллельно с этим, правила делегирования в Solana сделали механизм координации более понятным. Критерии делегирования от Solana Foundation включают требования к версии программного обеспечения и заявленный стандарт реагирования.

Опубликованное расписание требуемых версий программного обеспечения для валидаторов указывает Agave 3.0.14 и Frankendancer 0.808.30014 в качестве требуемых версий в нескольких эпохах. Для операторов, получающих делегирование от Foundation, обновления становятся экономически выгодными, поскольку несоблюдение требований может привести к отзыву делегирования до тех пор, пока критерии не будут выполнены.

Это оперативная реальность, лежащая в основе концепции "финансов, работающих 24/7". Она создается с помощью кода, но поддерживается с помощью стимулов, панелей мониторинга и норм, которые побуждают тысячи независимых участников координировать свои действия в короткие промежутки времени, возникающие в связи с инцидентами безопасности.

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

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

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

Эпизод v3.0.14 также не остановил общий цикл выпуска обновлений для Solana.

19 января репозиторий Agave выпустил версию v3.1.7, помеченную как тестовая версия, рекомендованная для devnet и для до 10% основной сети (beta), что указывает на ряд изменений, которые операторам необходимо отслеживать и планировать. 22 января страница расписания выпуска версии v3.1 Agave была обновлена с предварительным планом внедрения.

Готовность становится измеримой в конкретных терминах.

Одним из показателей является скорость перехода к рекомендуемой версии в условиях давления, то есть насколько быстро доли переходят на рекомендуемую версию, когда появляется срочное предупреждение, и первые отчеты о v3.0.14 показали затраты, связанные с медленным внедрением.

Другим показателем является устойчивость к коррелированным сбоям, когда разнообразие клиентов, обеспечиваемое Firedancer и Frankendancer, снижает риск того, что одна версия программного обеспечения приведет к сбою сети, но только в том случае, если альтернативные клиенты достигнут значительного уровня внедрения.

Третьим показателем является соответствие стимулов, когда критерии делегирования и требуемые версии превращают соблюдение правил безопасности в экономическую необходимость для многих операторов.

Эпизод v3.0.14 начался как срочное предупреждение и опасение по поводу внедрения, а затем стал более четким пониманием того, как Solana выпускает обновления, координирует действия и обеспечивает соблюдение стандартов в распределенной сети валидаторов.