Операційні вимоги для «Frankendancer: гібридний підхід до клієнта валідатора» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Статус клієнтів для «Frankendancer: гібридний підхід до клієнта валідатора» перевірено 2 серпня 2026 року. Frankendancer — гібрид Agave/Firedancer — працює на mainnet-beta щонайменше з 2025 року: офіційна програма делегування повідомляла майже про 200 валідаторів у вересні 2025 року. Повний Firedancer є окремою реалізацією мовою C; його поточне впровадження та частку валідаторів потрібно звіряти з офіційним звітом, а не з давніми твердженнями про «лише testnet».
Frankendancer — це гібридна реалізація клієнта валідатора Solana, яка поєднує Banking Stage від Firedancer з Runtime від Agave. Мета проєкту — дати мережі переваги у швидкості обробки транзакцій від нового C-клієнта, не відмовляючись від перевіреного виконавчого середовища Rust-клієнта. Для валідатора це означає можливість тестувати продуктивність Firedancer у реальній мережі з мінімальними змінами в операційній моделі.
Що таке Frankendancer
Комбінація Agave Runtime з Firedancer Banking Stage
У класичному конвеєрі валідатора Solana Banking Stage відповідає за прийом транзакцій із блокстріму, їхню валідацію підписів, базову перевірку та формування банків — пакетів транзакцій, готових до виконання. Runtime безпосередньо виконує транзакції, змінює стан акаунтів і обчислює результати.
Frankendancer замінює лише Banking Stage на реалізацію від Firedancer, залишаючи Runtime від Agave без змін. Транзакції проходять через C-код Firedancer на етапі сортування та підготовки, а потім передаються до Rust-коду Agave для фактичного виконання.
Причини створення гібридного підходу
Повний перехід на Firedancer вимагає переписування всього конвеєра валідатора, включно з Runtime, етапами консенсусу (Tower BFT), shred-обробкою та мережевим шаром. Це масштабна інженерне завдання з невизначеним горизонтом стабілізації. Гібридний підхід дозволяє:
- Отримати вимірюваний приріст продуктивності на найбільш вузькій ділянці конвеєра — обробці банків.
- Залишити виконання транзакцій у перевіреному Agave Runtime, де вже існує стабільна підтримка всіх інструкцій, BPF-програм та складних станів.
- Протестувати інтеграцію C- і Rust-компонентів у продакшн-середовищі до того, як буде готовий повноцінний Firedancer.
- Знизити ризик для валідаторів: якщо Banking Stage від Firedancer дає збій, можна відкотитися до чистого Agave без міграції стану.
Технічна архітектура
Як компоненти Agave та Firedancer інтегруються
Інтеграція базується на чіткому контракті між двома модулями. Firedancer Banking Stage отримує потік транзакцій від мережевого шару Agave (або частково від Firedancer Net, залежно від конфігурації), формує банки та передає їх у Agave Runtime через визначений інтерфейс. Runtime виконує транзакції й повертає результати назад у конвеєр для подальшої обробки на етапах консенсусу.
Ключове інженерне завдання — забезпечити коректну передачу даних між C- і Rust-середовищами без зайвого копіювання та з прийнятною затримкою. Для цього використовується спільна пам'ять із чітко визначеною структурою банку, яка є сумісною для обох клієнтів.
Межі відповідальності кожного модуля
| Модуль | Джерело | Відповідальність |
|---|---|---|
| Banking Stage | Firedancer (C) | Прийом транзакцій, валідація підписів, перевірка лімітів, формування банків, базова фільтрація дублікатів |
| Runtime | Agave (Rust) | Виконання транзакцій, інтерпретація BPF-програм, управління станом акаунтів, обчислення комісій |
| Консенсус (Tower BFT) | Agave (Rust) | Голосування, фіналізація слотів, управління вежею голосів |
| Мережевий шар | Agave (Rust) | Обмін shred-ами, Gossip-протокол, discovery |
| Зберігання (Ledger) | Agave (Rust) | Запис слотів, RocksDB, AccountsDB |
З цієї таблиці видно, що Frankendancer замінює лише один рівень із п'яти. Усі інші компоненти залишаються від Agave, що різко зменшує поверхню атаки та зону невизначеності.
Статус та практичне застосування
Доступність для валідаторів
Статус Frankendancer змінюється з часом. На момент написання цього матеріалу проєкт перебуває на стадії активної розробки та тестування. Конкретна версія, готовність до mainnet-розгортання та рекомендації щодо використання в production вимагають перевірки в офіційних репозиторіях Anza та Firedancer на GitHub. Не існує фіксованої дати релізу, яку можна було б вважати надійною без прямого підтвердження від розробників.
Для валідаторів, які розглядають Frankendancer як потенційний клієнт, рекомендується:
- Моніторити офіційні репозиторії та release-нотатки Anza (агрегатор розробки Agave) щодо статусу гібридної інтеграції.
- Перевіряти наявність інструкцій із розгортання саме для гібридної конфігурації, а не для чистого Firedancer чи чистого Agave.
- Оцінювати вимоги до заліза: Firedancer Banking Stage оптимізований під конкретні архітектури процесорів (зокрема, з акцентом на SIMD-інструкції), що може відрізнятися від вимог Agave.
Різниця з повним Firedancer та чистим Agave
Три реалізації утворюють спектр від повної сумісності до максимальної зміни архітектури:
- Agave — повністю Rust-клієнт, єдиний стабільний варіант для mainnet на сьогодні. Максимальна перевірена сумісність із усіма програмами та станами мережі.
- Frankendancer — гібрид: Banking Stage від Firedancer, решта від Agave. Проміжний варіант, що дозволяє виміряти приріст продуктивності на одному етапі конвеєра без зміни виконавчого середовища.
- Firedancer — повністю самостійний C-клієнт із власними реалізаціями всіх етапів конвеєра, Runtime, консенсусу та мережевого шару. Найбільший потенціал продуктивності, але найвищий рівень інженерного ризику та найдовший шлях до production-стабільності.
Вибір між ними — це не питання «краще чи гірше», а питання співвідношення ризику та очікуваного приросту пропускної здатності на конкретному етапі розвитку мережі. Frankendancer займає нішеву позицію: він корисний там, де валідатор хоче отримати реальні дані про поведінку Firedancer-компонентів у мережі, але не готовий брати на себе ризики повного клієнта.
Увага: Оскільки статус Frankendancer змінюється активно, перед будь-якими діями з розгортання перевірте актуальну документацію в репозиторіях Anza та Firedancer. Інформація про конкретні версії, бінарні збірки та інструкції із запуску може застаріти швидко, ніж оновлюється цей матеріал.