Тревожный случай с Solana: как сеть оказалась в пределах 4,5% от полной остановки
12 августа 2026 года Solana пережила самое близкое за весь период событие, грозящее остановкой сети целиком, после последнего полного сбоя в феврале 2024 года — но на этот раз причина не имела ничего общего с ошибками в коде или бот-спамом. Это был сбой маршрутизации, произошедший глубоко в инфраструктуре интернета.
Что произошло
Сбой маршрутизации BGP (Border Gateway Protocol) поразил TeraSwitch — хостинг-провайдера, который использует значительная доля валидаторов Solana. BGP — это протокол, определяющий, как данные находят путь через интернет между сетями: когда он работает некорректно, целые блоки серверов могут фактически исчезнуть с карты интернета, хотя сами серверы продолжают работать исправно.
Сбой одновременно выбил из работы примерно 90 валидаторов, что составило 28,83% от всех размещённых SOL.
Почему это число имело значение
У механизма консенсуса Solana есть критический порог: если 33,34% размещённых SOL одновременно уйдут в офлайн, сеть больше не сможет финализировать транзакции, а производство блоков полностью остановится — потребуется такой же скоординированный перезапуск валидаторов, который уже отмечал прошлые простои Solana.
12 августа сеть подошла на 4,51 процентного пункта к этому порогу. Было близко, но Solana так и не остановилась полностью.
Почему сеть продолжала работать
В отличие от предыдущих крупных инцидентов Solana — например, ~8,5-часового сбоя в выборе ветки в сентябре 2022 года или пятиичасовой остановки в феврале 2024 года, вызванной циклом перекомпиляции в загрузчике Berkeley Packet Filter (BPF) — в этот раз событие вообще не было связано с багом консенсуса или отказом на уровне клиента.
В течение примерно 30–33 минутного окна:
Производство блоков продолжалось без перебоев
Транзакции продолжали обрабатываться и завершаться в обычном режиме
Никогда не было риска для средств пользователей
597 из 699 размещённых валидаторов продолжали голосовать
Поскольку это было исключительно сетевое/инфраструктурное, а не дефект ядра протокола Solana, проблема разрешилась сама собой, когда затронутый маршрутизатор снова пересогласовал маршруты — не потребовалось аварийное исправление, скоординированный перезапуск или обновление клиента.
Урок реальности: концентрация инфраструктуры
Этот инцидент изменил разговор о надёжности Solana. Годы подряд сбои сети объясняли спамом транзакций и программными ошибками в клиенте валидатора. На этот раз уязвимость была в концентрации инфраструктуры — слишком много валидаторов полагались на одного и того же хостинг-провайдера и на один и тот же путь интернет-маршрутизации, создавая единую точку отказа, которая не имела ничего общего с кодом блокчейна.
В ответ Фонд Solana ужесточил правила разнообразия инфраструктуры. По состоянию на 1 мая 2026 года валидаторы, поддерживаемые Фондом, должны обеспечивать:
Ни один ASN (автономная система / хостинговая сеть) не удерживает более 25% сетевой доли
Ни один оператор дата-центра не удерживает более 15% сетевой доли
Эти ограничения не предотвратят любой будущий переполох, но они созданы для того, чтобы сбой маршрутизации одного провайдера больше никогда не ставил под угрозу консенсус.
Контекст: длительный период стабильности
Время этого события примечательно. До него Solana поддерживала 100% аптайма кластера на протяжении примерно 30 последовательных месяцев после своего последнего полного простоя в феврале 2024 года — это её самый длинный период надёжности с момента запуска. Августовский эпизод не сломал серию реальных остановок, но напомнил, что «аптайм» зависит не только от чистого кода — он зависит также от физической и сетевой инфраструктуры под ним.
Источники: отчёты о статусе Фонда Solana; анализ инцидента от Spotted Crypto и Bitcoin Foundation, август 2026.
