Firedancer запущений у основну мережу, але Solana все ще не досягла стандартів безпеки Ethereum

Після трьох років розвитку Firedancer офіційно запущений у мережі mainnet Solana у грудні 2025 року, після створення понад 50 000 блоків за 100 днів тестування з кількома валідаторами.

Цей важливий етап, оголошений офіційним акаунтом Solana 12/12, не лише є оновленням продуктивності. Це перша серйозна спроба усунути архітектурний вузол, що стояв за найсерйознішими збоїми мережі: 거의 повністю залежність від одного клієнта-валідатора.

Протягом багатьох років Solana пропагує можливості швидкої завершальності транзакцій (менше ніж за секунду) та пропускної здатності тисячі транзакцій за секунду. Але швидкість стає безглуздою, коли 70%–90% обчислювальної потужності мережі працює на одній і тій же версії програмного забезпечення. Одна серйозна помилка у клієнті-валідаторі достатня, щоб зупинити всю блокчейн-мережу, незалежно від теоретичної високої продуктивності.

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

Що таке Firedancer і чому він відрізняється

Firedancer — це не патч або форк клієнта Agave, написаний на Rust. Це повністю переписаний з нуля клієнт на C/C++, розроблений Jump Crypto, з модульною архітектурою, натхненною системами високошвидкісної торгівлі.

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

З мережами, які зазнали семи збоїв за п’ять років, п’ять з яких були викликані помилками клієнта, ця ізоляція є ключовою.

Проблема «одностороннього керування», яку Solana ще не подолала

Історія зупинок Solana є класичним прикладом ризику залежності від одного клієнта. У червні 2022 року мережа зупинилася більш ніж на чотири з половиною години через помилку у функції durable-nonce, що призвела до розсинхронізації валідаторів і вимагала їх перезапуску з координацією.

Інші збої були спричинені витоками пам’яті, надмірною дуплікацією транзакцій і конфліктними умовами при створенні блоків. Аналіз усіх збоїв показав, що 5 з 7 випадків починалися з помилок валідаторів або клієнтів, а не з конструктивних недоліків у протоколі.

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

Ці дані підтверджують рівень цієї вразливості. Звіт про стан мережі Solana Foundation за червень 2025 року показує, що Agave та його варіанти Jito контролюють приблизно 92% SOL staking. До жовтня 2025 року цей показник знизився, але залишався вище 70%, тоді як Frankendancer зріс до близько 21%.

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

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

Модель-орієнтир від Ethereum

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

Спільнота Ethereum вважає збереження всіх клієнтів з часткою менше 33% за необхідну безпеку, а не за оптимізацію продуктивності. Позиція Solana, з клієнтом, що майже досягає 90%, виходить за межі цієї безпечної зони.

Що насправді змінює Firedancer

Firedancer повністю перепроектує pipeline валідатора Solana з високою паралелізацією, кастомізованим мережею та управлінням пам’яттю для досягнення стабільної продуктивності під високим навантаженням.

Бенчмарки, представлені на технічних конференціях, показують, що Firedancer обробля від 600 000 до понад 1 000 000 транзакцій за секунду у контрольованих умовах, значно перевищуючи Agave. Але межа продуктивності не є головним — важливо ізолювати зони помилок.

Згідно з документацією і інструкціями з розгортання, Firedancer є модульною системою: мережа, узгодження та виконання транзакцій — незалежні компоненти. Помилка у менеджері пам’яті Rust у Agave не поширюється на C++ код Firedancer; логічна помилка у планувальнику блоків Agave теж не впливає на модульну модель виконання Firedancer.

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

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

Проте, якщо валідатори все ще залежать від Agave для узгодження, спільний шар може спричинити збої. Вже коли Firedancer запущений у mainnet, ця залежність зникає.

Група валідаторів, що працює на Firedancer протягом 100 днів, створила понад 50 000 блоків і довела, що клієнт може брати участь у узгодженні, створювати валідні блоки і підтримувати стан без допомоги Agave. Це ще не повний профіль, але досить для подальшого масштабування.

Чому організації цікавляться програмним забезпеченням валідатора

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

У оцінках готовності для організацій, минулі збої вважаються головним бар’єром, тоді як Firedancer описується як потенційне рішення. Надійність є ключовим фактором конкурентної переваги Solana порівняно з іншими layer-1.

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

Мережа, де 90% валідаторів працюють з одним клієнтом, має критичну слабкість — односторонній збій, незалежно від розподілу токенів чи кількості валідаторів. Натомість мережа, що не має клієнта з часткою понад 33%, може втратити один клієнт через серйозну помилку, але продовжити роботу. Ця різниця є бінарною і визначає, як будуються продукти.

Глобальні активи на понад 767 мільйонів доларів, токенізовані на Solana — це лише початок, тоді як Ethereum зберігає понад 12,5 мільярдів доларів. Ця різниця відображає не лише мережевий ефект та розвиток спільноти, а й рівень довіри до стабільності роботи.

Firedancer дає Solana шанс скоротити цю різницю, досягнувши рівня різноманітності клієнтів, що вважається мінімальним стандартом для виробничої інфраструктури Ethereum.

Наступна крива прийняття

Перехід від домінування Agave з 70% до збалансованої багатоклієнтної мережі не буде швидким. Валідаторам доведеться пройти через витрати на перехід: Firedancer потребує інших апаратних налаштувань, інших процедур роботи та характеристик продуктивності.

100-денної історії роботи, навіть позитивної, все ще недостатньо порівняно з роками роботи Agave. Обережні оператори чекатимуть додаткових даних перед зміною стейку.

Проте структура стимулів сприяє диверсифікації. Звіт про стан валідаторів Solana Foundation відкрито публікує розподіл клієнтів, створюючи репутаційний тиск і змушуючи великих операторів уникати концентрації на одному розгортанні.

Історія збоїв мережі є чітким нагадуванням про ризики. А історія зацікавлення інституцій — ETF, випуск RWA, корпоративні платежі — залежить від доведення, що Solana подолала проблему надійності.

Архітектура готова. Зараз у мережі є два незалежних клієнти з різних мов програмування, із ізольованими зонами помилок. Відмовостійкість мережі тепер залежить від швидкості перемикання стейку — від початкової «односторонньої» моделі до розподілу, де жоден клієнт не може самостійно зламати мережу.

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