Жахливий вразливість у Solana щойно викрита: хакер майже паралізував мережу

Коли команда підтримки Solana вимагає від валідаторів швидко оновитися до Agave v3.0.14, повідомлення було зроблено з високим рівнем терміновості, що виходить за межі технічних деталей.

Аккаунт Solana Status назвав цю версію «надзвичайною», що включає «серію важливих виправлень» для валідаторів на Mainnet Beta.

Лише за один день публічні обговорення перейшли до більш складного питання: що станеться, якщо мережа PoS, яка потребує швидкого оновлення, не зможе синхронізовано діяти?

Ця прогалина чітко проявилася у початкових даних. 11 січня широко поширений акаунт повідомив, що лише близько 18% стейку було перенесено на v3.0.14 на той момент, що означає, що більша частина «економічного ваги» мережі все ще працювала на старих версіях у період, позначений як надзвичайний.

З blockchain, який цілий рік просував ідею надійності одночасно з швидкістю, фокус швидко змістився з самого коду на питання, чи зможе команда швидко зібратися, коли ситуація стане критичною.

Протягом понад 10 днів ситуація стала яснішою і кориснішою, ніж початкові заголовки.

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

У той же час екосистема Solana дала сигнал, що координація тут — не лише питання доброї волі. Критерії делегування стейку від Solana Foundation тепер чітко вимагають відповідності версії програмного забезпечення, включаючи Agave 3.0.14 і Frankendancer 0.808.30014, як частини стандартів, яким мають відповідати валідатори для продовження отримання делегованого стейку.

Загалом, ці події перетворили v3.0.14 на кейс-стаді того, що означає «фінанси завжди працюють» на Solana — не лише з точки зору програмного забезпечення, а й з точки зору механізмів стимулювання та поведінки під тиском часу.

Високошвидкісний блокчейн все ще залежить від людей

Solana — proof-of-stake блокчейн, створений для обробки великого обсягу транзакцій із високою швидкістю. Валідатори голосують за блоки і забезпечують безпеку реєстру відповідно до кількості SOL, делегованих їм.

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

Ця конструкція має наслідки, які легко ігнорувати, дивлячись лише на графік цін токенів. Blockchain — це не машина, розташована в одному місці. На Solana «мережа» — це тисячі незалежних операторів, що запускають сумісне програмне забезпечення, оновлюють його в різний час, на різних інфраструктурах, з різним рівнем автоматизації і ризик-апетитом.

Коли все йде гладко, ця незалежність допомагає уникнути централізації контролю. Але коли оновлення стають надзвичайно терміновими, саме ця незалежність ускладнює координацію.

Зовнішній вигляд клієнтської частини Solana ще більше підкреслює важливість співпраці. Найпопулярніший клієнт — це форк Agave від Anza. Водночас мережа прагне диверсифікувати клієнтів через проект Firedancer від Jump Crypto, з Frankendancer як проміжною ціллю.

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

Саме в цьому контексті з’явилася v3.0.14. Терміновість спрямована на закриття шляхів, що можуть призвести до збоїв, до того, як їх виявлять і використають.

Що змінилося за 10 днів: публічне пояснення і економічна мотивація

Оголошення Anza заповнило прогалину у історії. Два потенційно серйозні вразливості були виявлені у грудні 2025 року через безпекові advisory на GitHub. Anza повідомила, що ці проблеми були виправлені у співпраці з Firedancer, Jito і Solana Foundation.

Перша вразливість стосувалася gossip-системи Solana — механізму, що дозволяє валідаторам поширювати деякі повідомлення мережі навіть при зупинці процесу створення блоків. За словами Anza, помилка у обробці певних типів повідомлень могла спричинити крах валідатора за певних умов. Якщо ця уразливість буде використана зкоординовано і достатньо багато стейку буде знищено, це може суттєво знизити доступність всієї мережі.

Друга вразливість стосувалася обробки голосів — ядра механізму консенсусу. За словами Anza, пропущений крок верифікації міг дозволити зловмиснику засипати валідатор неправомірними голосами, що ускладнює нормальну обробку голосів і може призвести до зупинки консенсусу на великому масштабі.

Виправлення гарантує правильну верифікацію голосових повідомлень перед їх обробкою у процесі створення блоків.

Ці відкриття змінюють уявлення про початкову ідею «повільного оновлення». Терміновість оновлення зумовлена тим, що воно закриває два можливі шляхи до серйозних збоїв: один — через крах валідатора, інший — через порушення процесу голосування у масштабі.

Питання про здатність до оперативних дій залишається актуальним, але стає більш конкретним: наскільки розподілена команда може швидко застосувати патч, коли системні збої вже очевидні і мають системний характер?

Паралельно, правила делегування стейку від Solana роблять механізм координації більш прозорим. Вимоги Solana Foundation включають версії програмного забезпечення і стандарти зворотного зв’язку. Оголошення обов’язкових версій, таких як Agave 3.0.14 і Frankendancer 0.808.30014, заплановані на кілька епох.

Для операторів, що отримують делегування від Foundation, оновлення стає економічним питанням: невідповідність вимогам може призвести до відкликання делегованого стейку до досягнення стандарту.

Це — реальність роботи, яка стоїть за концепцією «фінанси завжди працюють». Вона базується на коді, але підтримується економічними мотиваціями, системами моніторингу і стандартами, що стимулюють тисячі незалежних агентів збиратися у короткі часові рамки під час кризових ситуацій.

Навіть при чіткому оголошенні і наявності економічних стимулів швидке застосування оновлень залишається складним. Anza зазначила, що оператори мають самостійно збиратися з вихідного коду відповідно до їхніх інструкцій.

Збірка з джерела не є автоматично ризикованою, але ускладнює операційний процес, оскільки валідатор залежить від pipeline збірки, управління залежностями і внутрішнього тестування перед розгортанням у production.

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

Випуск v3.0.14 також не перервав ширше оновлення Solana.

19 січня кодова база Agave випустила v3.1.7, позначену як тестова мережа і рекомендовану для devnet і до 10% mainnet beta, що демонструє безперервний потік змін, за яким мають слідкувати і планувати оператори. 22 січня дорожня карта випуску v3.1 Agave була оновлена з новими планами розгортання.

Рівень готовності тепер можна вимірювати за допомогою конкретних показників.

Один із них — швидкість конвергенції версій під тиском, тобто наскільки швидко стейк переходить на рекомендовану версію у разі надзвичайного попередження. Початкові звіти щодо v3.0.14 показують ціну повільної міграції.

Інший — здатність протистояти масштабним одночасним збоїм. Різноманіття клієнтів через Firedancer і Frankendancer зменшує ризик того, що одна програма зламає мережу, але лише за умови широкого розгортання клієнтів.

Третій — рівень економічної синхронізації, де критерії делегування і вимоги до версій перетворюють «захист від уразливостей» у обов’язкову економічну умову для багатьох операторів.

Випуск v3.0.14 почався з позначки «надзвичайна ситуація» і побоювань щодо швидкості застосування, але з часом став більш ясним поглядом на те, як Solana виправляє помилки, координує і виконує стандарти у розподіленій команді валідаторів.

Ван Тянь