Firedancer — це повністю незалежна реалізація клієнта валідатора Solana, розроблена командою Jump Crypto мовою C/C++. На відміну від форків або модифікацій існуючого коду, проєкт створено з нуля з орієнтацією на максимальну продуктивність, детермінованість та безпеку пам'яті. Для екосистеми це означає першу реальну альтернативу клієнту на базі Agave, що знижує ризик системної відмови через ваду в єдиному реалізаційному стеку.
Операційні вимоги для «Firedancer: архітектура від Jump Crypto та етапи реалізації» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Статус клієнтів для «Firedancer: архітектура від Jump Crypto та етапи реалізації» перевірено 2 серпня 2026 року. Frankendancer — гібрид Agave/Firedancer — працює на mainnet-beta щонайменше з 2025 року: офіційна програма делегування повідомляла майже про 200 валідаторів у вересні 2025 року. Повний Firedancer є окремою реалізацією мовою C; його поточне впровадження та частку валідаторів потрібно звіряти з офіційним звітом, а не з давніми твердженнями про «лише testnet».
Філософія та підхід до розробки
Повна реалізація з нуля на C/C++
Команда Jump Crypto свідомо відмовилася від використання Rust — мови, на якій написано Agave. Це не інженерний каприз, а структурне рішення: написання з нуля гарантує, що логічні помилки одного клієнта не буде скопійовано до іншого. Два клієнти, написані різними мовами з різними моделями управління пам'яттю, імовірно матимуть різні класи вад, що є ключовим для безпеки мережі.
C/C++ обрано не випадково. Jump Crypto має багаторічний досвід створення високочастотних торгових систем, де затримки в мікросекунди визначають прибутковість. Цей досвід безпосередньо перенесено в архітектуру Firedancer: ручне управління пам'яттю, кастомні аллокатори, мінімізація системних викликів та уникнення непередбачуваних затримок, притаманних збирачам сміття (garbage collectors).
Орієнтація на максимальну продуктивність та безпеку пам'яті
Продуктивність у контексті Firedancer — це не лише швидкість обробки транзакцій, а передусім передбачуваність (deterministic latency). Архітектура спроєктована так, щоб час обробки блоку не мав хвостів розподілу (tail latency), які в критичні моменти можуть призвести до пропуску слотів.
Безпека пам'яті реалізується через сувору ізоляцію компонентів, статичний аналіз коду, fuzzing та формальну верифікацію критичних шляхів. Усі операції з пам'яттю відбуваються у попередньо виділених буферах, що унеможливлює витоки та використання після звільнення (use-after-free) у типових сценаріях виконання.
Архітектурні компоненти
Firedancer Validator Client (FVC): заміна Banking Stage
Першим і найбільш критичним компонентом, який реалізували в рамках проєкту, став FVC — заміна Banking Stage з оригінальної архітектури Agave. Banking Stage відповідає за паралельну обробку транзакцій, перевірку підписів, блокування рахунків (account locking) та формування блоку перед передачею на наступний етап конвеєра.
FVC спроєктовано як високопаралельний конвеєр, де кожна фаза обробки транзакції виконується на окремому наборі потоків із мінімальними точками синхронізації. Ключова відмінність від Agave — явне управління чергами та відсутність залежності від глобальних блокувань (global locks) на критичних шляхах.
Firedancer Ledger (FDL): зберігання стану
FDL — це підсистема зберігання стану рахунків, розроблена з орієнтацією на швидкий послідовний та випадковий доступ. На відміну від підходу Agave, де стан зберігається у структурах, тісно пов'язаних із runtime Rust, FDL використовує власний формат зберігання, оптимізований для конкретних патернів доступу, що виникають під час валідації блоків.
FDL підтримує snapshot-и та відновлення стану, проте внутрішня організація цих механізмів відрізняється від AppendVec у Agave. Це дозволяє зменшити час завантаження стану при перезапуску валідатора та знизити дискове навантаження під час інтенсивної синхронізації.
Планування повної заміни Agave
Повна заміна Agave передбачає реалізацію всіх етапів конвеєра валідатора: від прийому транзакцій (FEC, Quic) через Banking Stage та Blockstore і до консенсусного модуля (Tower BFT), генерування блоків (Leader Schedule, PoH) та мережевого шару (Gossip, Turbine). Стратегія команди — послідовна заміна етапів, де кожен компонент проходить ізольоване тестування перед інтеграцією у повний конвеєр.
Важливо розуміти: нині FVC та FDL є найбільш зрілими компонентами. Інші модулі перебувають на різних стадіях розробки. Для актуального статусу кожного етапу варто звертатися до репозиторію проєкту та офіційних звітів команди, оскільки ця інформація змінюється швидко.
Стадія реалізації та тестування
Результати conformance testing
Conformance testing — це методика, за якої клієнт Firedancer проганяє однакові набори вхідних даних, що й Agave, і результати порівнюються побітово. Це ключовий інструмент перевірки коректності: якщо два незалежні клієнти на різних мовах видають ідентичний результат для одного й того ж блоку транзакцій, імовірність спільної логічної вади наближається до нуля.
Команда публічно демонструвала результати conformance testing, де FVC успішно обробляв реальні блоки з мейннету з повною збіжністю результатів із Agave. Проте варто враховувати: conformance покриває лише ті частини логіки, які вже реалізовано. Повне покриття всього конвеєра — це окреме завдання, що виконується поступово.
Досвід роботи в тестнеті та мейннеті
Firedancer пройшов шлях від локального тестування через ізольовані тестнети до роботи на публічних тестнетах та обмеженої присутності в мейннеті. У мейннеті клієнт працював у режимі спостерігача (watchtower), не беручи участі в консенсусі, але обробляючи реальні блоки та порівнюючи результати з Agave у реальному часі.
Наступним кроком є участь у консенсусі на тестнеті, де валідатор на базі Firedancer має голосувати та пропонувати блоки нарівні з Agave-валідаторами. Перехід до консенсусу в мейннеті — це окремий етап, що вимагає не лише технічної готовності, а й узгодження з екосистемою щодо ризиків для мережі.
Для валідаторів, які розглядають можливість переходу на Firedancer у майбутньому, рекомендується слідкувати за офіційними оголошеннями команди щодо статусу mainnet-ready, а не покладатися на непідтверджені джерела. Гібридний підхід, де частина конвеєра працює на Firedancer, а частина — на Agave, описується окремо в матеріалі про Frankendancer.