## История эволюции «иммунной системы» Solana: почему атака в 6 Тбит/с скорее подтверждает устойчивость сети

Обычно, оценивая мощь блокчейн-сети, мы фактически спрашиваем: сколько хаоса она способна выдержать, не потеряв стабильность? Недавний тест, пережитый Solana, как раз отвечает на этот вопрос.

Согласно данным инфраструктурной компании Pipe, недавно Solana столкнулась с атакой объемом примерно 6 Тбит/с — эта цифра уже входит в категорию «угрозы» в интернет-отчетах, обычно с такой нагрузкой сталкиваются только крупнейшие сайты. Но ключевое здесь не в масштабе атаки, а в реакции сети: она продолжила нормально создавать блоки, проверка транзакций не прервалась, расходы пользователей не выросли аномально. Не было экстренного перезапуска, не было хаоса между валидаторами.

Это резко контрастирует с прошлым опытом Solana. В сентябре 2021 года из-за потока ботов (вызванного IDO на Raydium) сеть была недоступна более 17 часов. В апреле 2022 года во время еще более мощной атаки сеть получала 60 миллионов транзакций в секунду, а у некоторых узлов трафик достигал 100 Гбит/с. Тогда это привело к остановке генерации блоков и необходимости перезагрузки всей сети.

И на этот раз история не повторилась.

## От «пассивного удара» к «активной защите»

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

Первое — обновление протокола связи. Solana заменил традиционную модель соединений на протокол QUIC. Основное преимущество QUIC — в его изначальной поддержке мультиплексирования, что делает невозможным для злоумышленников дешево создавать мусорный трафик, как это было раньше. В рамках фреймворка Transaction Processing Unit (Транзакционный блок) в Solana внедрены многоуровневые ограничения:

- Ограничения на одновременные соединения по идентификатору клиента
- Ограничения на поток данных в каждом соединении
- Динамическое регулирование на основе доли stake (стейка) отправителя

Самое изящное решение — stake-weighted QoS (качество обслуживания с учетом доли стейка). Проще говоря, валидатор, владеющий 1% всей сети, может отправлять 1% пакетов данных. Это создает новую «стену»: атакующий теперь нуждается не только в пропускной способности, но и в реальных долях стейка. Малые держатели стейка не смогут просто так «заглушить» сеть массовой рассылкой.

Второе — локализованные изменения в механизме ценообразования. Ранее, при атаке или большом количестве мусорных транзакций, вся сеть «оплачивала» — все транзакции становились в очередь, и сборы взлетали. Solana внедрил локальные рынки сборов (Local Fee Markets) и механизм приоритетных сборов (Priority Fees).

Пользователи могут установить лимит вычислительных единиц для своих транзакций и добровольно платить дополнительные сборы за приоритет. Важный момент — приоритетные сборы рассчитываются исходя из заявленного лимита, а не фактического расхода. Это стимулирует точное оценивание и предотвращает злоупотребление ресурсами — чем выше лимит, тем дороже его «перебор». Таким образом, злоупотребление вычислительными ресурсами становится дорогостоящим, а сеть получает механизм регулировки.

## От «коллективного краха» к «многоуровневой защите»

Что дают эти изменения в совокупности? Solana эволюционировала от модели «вся сеть — один узел, одна точка отказа» к системе с множеством защитных линий.

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

С другой стороны, валидатор превращается в участника с «билетом» — он уже не просто атакует, используя пропускную способность, а должен иметь реальный стейк. Это естественным образом фильтрует участников — в системе остаются только те, кто реально вкладывает деньги, что значительно повышает барьер для атаки.

## Реальность и компромиссы

Но стоит помнить, что ни одна система не идеальна. По поводу атаки в 6 Тбит/с внутри сообщества ведутся обсуждения: это постоянная «стена» трафика или кратковременный пик? Разные мнения влияют на оценку «успешности защиты». Измерение интернет-трафика — сложная задача, без независимого аудита трудно дать стопроцентную гарантию, что сеть не была скомпрометирована.

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

Тем не менее, важнейшее изменение уже произошло: Solana перешла от «пассивного ожидания краха» к «активной защиты». В прошлых сценариях — остановка производства, перезагрузка всей сети, долгие согласования. А сейчас — цепочка остается активной, транзакции подтверждаются, пользовательский опыт минимально затронут.

Это свидетельство того, что Solana эволюционировала из «уязвимой сети» в «сеть, которая заставляет атакующих уставать». Такой менталитет, возможно, важнее любой отдельной технической модернизации.