Solana залишалася працездатною під час збою інфраструктури, який тимчасово порушив роботу частини її мережі валідаторів 12 серпня, повідомив технічний керівник Solana Foundation Джейкоб Кріч.
Підсумок
- 597 із 699 валідаторів Solana зі стейкінгом продовжували голосувати, тоді як мережа продовжувала нормально створювати блоки.
- 102 валідатори тимчасово припинили голосування, а постраждалі оператори відновили роботу протягом сорока хвилин після збою.
- 28,83% стейкованого SOL стало неактивним, наближаючись до порогу 33,34%, при якому фіналізація транзакцій повністю припиняється.
- Teraswitch повідомив, що неправильно сформований маршрут порушив роботу дванадцяти європейських та азійських сайтів, перш ніж інженери відновили з'єднання.
- На сторінці статусу Solana не зафіксовано інциденту в основній мережі, і вона показує 100% аптайму кластера протягом дев'яноста днів.
З 699 валідаторів Solana зі стейкінгом 597 продовжували голосувати, тоді як блоки та транзакції продовжували оброблятися. Постраждалі валідатори відновили роботу протягом 40 хвилин.
Кріч повідомив, що валідатори в програмі делегування Solana Foundation не постраждали. На офіційній сторінці статусу Solana не зафіксовано інциденту в основній мережі 12 або 13 серпня, і вона показує 100% аптайму кластера Mainnet Beta за попередні 90 днів.
Валідатори Solana зберегли фіналізацію, незважаючи на різке падіння
Хоча основна мережа залишалася онлайн, окремий аналіз показав, що інцидент був ближчим до порушення фіналізації, ніж свідчить кількість валідаторів. Marinade Finance виявила, що 28,83% всього стейкованого SOL стало неактивним приблизно на 33 хвилини. Solana вимагає участі понад двох третин стейку для досягнення фіналізації транзакцій, що встановлює відповідний поріг відключення на рівні 33,34%.
Marinade виявила приблизно 90 валідаторів, постраждалих від збою маршрутизації, тоді як цифра Кріча 597 із 699 означає, що 102 валідатори в певний момент не голосували. Різниця відображає окремі вимірювання, а не доказ того, що всі 102 валідатори мали однаковий збій інфраструктури.
Кріч описав інцидент як «доказ стійкості Solana». Мережа дійсно витримала збій, але дані Marinade також показали, що неактивний стейк досяг приблизно 86% рівня, при якому фіналізація була б зупинена.
Збій маршрутизації Teraswitch поширився від Маямі до Азії
У звіті про статус Teraswitch простежується проблема інфраструктури до неправильно сформованого маршруту за замовчуванням, що походить з її об'єкта MIA1 у Маямі. Рефлектор маршрутів в Амстердамі поширив змінений маршрут на європейські та азійсько-тихоокеанські ринки, де локальні маршрутизатори віддали йому перевагу над дійсними маршрутами. Дванадцять сайтів у Лондоні, Амстердамі, Дубліні, Франкфурті, Сінгапурі та Токіо втратили доступність. Північноамериканські сайти не постраждали.
Інженери виявили неправильно сформований маршрут протягом 10 хвилин і видалили Маямі з приватної магістралі. Сервіс повернувся о 04:16:15 UTC. Пізніше Teraswitch розгорнула глобальну зміну на своїх обчислювальних майданчиках, щоб подібний неправильно сформований маршрут не блокував пересилання трафіку. Постачальник повідомив, що основний дефект залишається під розслідуванням, і повний звіт про причини буде надано пізніше.
Подія також виявила концентрацію інфраструктури серед валідаторів. Marinade підрахувала, що одна автономна система тримала близько 118,9 мільйона SOL, тобто понад чверть всього стейкованого SOL, і приблизно 94% цього стейку вийшло з ладу одночасно.
Solana уникає повторення зупинки мережі 2024 року
Результат контрастує з перезапуском мережі у лютому 2024 року після зупинки виробництва блоків. Під час того інциденту валідатори потребували скоординованого перезапуску, і Solana залишалася офлайн майже п'ять годин. Відмова інфраструктури 12 серпня не вимагала перезапуску основної мережі.
З того часу Solana продовжила підвищувати стійкість за допомогою незалежного програмного забезпечення валідаторів. У відповідному матеріалі Firedancer почав виробляти блоки основної мережі Solana у 2026 році, додавши ще один шлях клієнта валідатора поряд із домінуючою екосистемою Agave.
Останній збій випробував інший тип децентралізації: фізичний хостинг і мережеве з'єднання, а не програмне забезпечення валідатора. Solana продовжувала обробляти транзакції, але концентрація частки голосів за загальною інфраструктурою дозволила відмові одного провайдера одночасно видалити велику частку голосуючої частки.
Що далі
Негайне виправлення конфігурації Teraswitch вже розгорнуто, але його розслідування ще не завершено. Провайдер досі з'ясовує, чому маршрут за замовчуванням у Маямі був оголошений з неправильними атрибутами, і залучив свого постачальника обладнання. Повний звіт очікується після завершення цієї роботи.
Оператори валідаторів також, ймовірно, зіткнуться з більш пильною перевіркою надмірності інфраструктури. Marinade заявила, що планує переглянути обмеження концентрації за автономною системою та центром обробки даних і забезпечити більшу прозорість щодо автоматичних механізмів перемикання. Для Solana наступним випробуванням є те, чи зменшать ці інфраструктурні зміни частку частки, що піддається впливу будь-якої окремої відмови маршрутизації.
