Firedancer працює, але Solana порушує єдине правило безпеки, яке Ethereum вважає безкомпромісним

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

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

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

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

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

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

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

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

Проблема монокультури, від якої Solana не могла втекти

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

Інші інциденти були пов'язані з витоками пам'яті, надмірними дублікатами транзакцій та умовами гонки при створенні блоків. Аналіз повної історії збоїв від Helius приписує п'ять із семи відмов помилкам валідатора або клієнта, а не недолікам дизайну консенсусу.

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

Цифри підтверджують цю вразливість. Звіт про стан мережі Solana Foundation за червень 2025 року показав, що Agave та його модифікована версія Jito контролюють приблизно 92% стейкнутих SOL.

До жовтня 2025 року ця цифра знизилася. Однак лише незначно: огляд стейкінгу Cherry Servers та численні посібники для валідаторів повідомляли, що клієнт Jito-Agave все ще утримував понад 70% стейку, навіть коли гібридний клієнт Frankendancer виріс до приблизно 21% мережі.

Frankendancer використовує мережевий шар Firedancer з бекендом консенсусу Agave.

Незважаючи на те, що він все ще залишається в меншості, дані Cherry Servers відзначили, що частка Frankendancer зросла з приблизно 8% у червні. Ці здобутки представляють стабільне впровадження часткового рішення, але повноцінний клієнт Firedancer, що з'явився в основній мережі в грудні, змінює ситуацію.

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

Досвід Ethereum надає еталонну модель.

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

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

Клієнт	Мова	Статус	Частка стейку (жовт. 2025)	Валідатори	Справжня незалежність
Jito	Rust	Основна мережа	~72%	~700+	Форк Agave
Frankendancer	C + Rust	Основна мережа	~21%	207	Гібридна незалежність
Agave	Rust	Основна мережа	~7%	~85	Оригінальний
Firedancer	C	Неголосуюча основна мережа	0%	0	Повністю незалежний

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

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

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

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

Помилка пошкодження пам'яті в алокаторі Rust від Agave не поширюватиметься на кодову базу C++ Firedancer. Логічна помилка в планувальнику блоків Agave не вплине на модель виконання на основі плиток Firedancer.

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

Гібридне розгортання Frankendancer слугувало поетапним впровадженням. Оператори замінили компоненти мережевої взаємодії та виробництва блоків Agave на еквіваленти Firedancer, зберігаючи шари консенсусу та виконання Agave.

Такий підхід дозволив валідаторам прийняти покращення продуктивності Firedancer без ризику для всієї мережі на нетестованому коді консенсусу.

21% стейку, який Frankendancer захопив до жовтня, підтвердив гібридну модель, але також підкреслив її обмеження: доки всі валідатори все ще покладалися на Agave для консенсусу, помилка в цьому спільному шарі все ще могла зупинити ланцюг.

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

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

Історія виробництва вузька, 100 днів на кількох вузлах, але достатня, щоб відкрити двері для ширшого впровадження. Валідатори тепер мають справжню альтернативу, і стійкість мережі безпосередньо залежить від того, скільки з них вирішать мігрувати.

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

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

Пояснення Firedancer від Levex стверджує, що клієнт "вирішує ключові проблеми, які інституційні інвестори висловлювали щодо надійності та масштабованості Solana", і що надлишковість мультиклієнтів "забезпечує надійність, яку підприємства вимагають для критичних додатків".

Вересневе есе Binance Square про готовність Solana до інституційного використання представляє минулі збої як основну перешкоду для корпоративної взаємодії та позиціонує Firedancer як "потенційне лікування".

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

Логіка відображає структуру, встановлену для кампанії з різноманітності клієнтів Ethereum.

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

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

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

Приблизно 767 мільйонів доларів Solana в токенізованих активах реального світу представляють собою опорну точку, а не масштабне впровадження. Ethereum розміщує 12,5 мільярдів доларів у токенізованих казначейських облігаціях, стейблкоїнах та токенізованих фондах, згідно з даними rwa.xyz.

Розрив відображає не лише мережеві ефекти чи частку розробників, але й довіру до часу безперебійної роботи.

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

Крива впровадження попереду

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

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

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

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

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

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

Допис Firedancer запущено, але Solana порушує єдине правило безпеки, яке Ethereum вважає необговорюваним вперше з'явився на CryptoSlate.