Большую часть своей истории Solana работала на одной реализации валидатора. Это обеспечивало высокую скорость, но делало сеть уязвимой, поскольку даже одна программная ошибка могла остановить всю цепь.

Firedancer решает эту проблему. Она предоставляет Solana второй, полностью независимый клиент с отдельным кодом, другим языком и собственной командой — ту модель безопасности с несколькими клиентами, которую Ethereum рассматривает как базовую.

Ниже описано, как устроен Firedancer, каково его положение после запуска и что это значит для надежности и дорожной карты Solana. 👇

Что такое Firedancer?

Firedancer — это клиент валидатора для Solana, созданный Jump Crypto, блокчейн-подразделением торговой фирмы Jump Trading Group. Клиент валидатора — это программное обеспечение, которое обрабатывает транзакции, производит блоки и голосует в консенсусе, поэтому клиент, запущенный на ноде, определяет производительность сети.

Jump начала проект в 2022 году и приняла взвешенное решение. Вместо форка программного обеспечения Solana на Rust, она переписала валидатор с нуля на C и C++, языках, которые дают точный контроль над памятью и оборудованием. Новый клиент не разделяет код с действующим, в чем и заключается главная идея.

Клиентом Solana по умолчанию является Agave, поддерживаемый Anza — командой, выделившейся из Solana Labs. Наиболее используемым вариантом является оптимизированный под MEV форк Agave от Jito. Firedancer стоит отдельно от обоих как подлинно отдельная сборка наряду с более мелкими клиентами, такими как Sig, Mithril и Tinydancer.

Несмотря на частые заблуждения, Firedancer — это не токен, не airdrop и не изменение протокола. Он не затрагивает эмиссию SOL, награды за staking или правила транзакций. Он меняет то, как работают валидаторы, не меняя то, что делает сеть.

Как работает Firedancer?

Firedancer рассматривает валидатор как набор специализированных изолированных компонентов вместо одной большой программы, а затем устраняет накладные расходы операционной системы, которые ограничивают пропускную способность в масштабе.

1. Плиточная архитектура

Firedancer разделяет работу валидатора на независимые процессы, называемые тайлами, каждый из которых выполняет одну задачу, такую как работа с сетью, проверка подписей, упаковка транзакций или производство блоков. Каждый тайл закреплен за собственным процессором (CPU) и общается с остальными через каналы с разделяемой памятью.

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

2. Сетевые технологии с обходом ядра

Каждый пакет, обрабатываемый стандартным валидатором, проходит полный цикл через сетевой стек ядра Linux, который захлебывается при высокой нагрузке. Firedancer пропускает большую часть этого пути с помощью AF_XDP и eBPF, считывая пакеты вблизи сетевой карты, так что пределом становится оборудование, а не стоящее перед ним программное обеспечение.

Поверх этого располагается кастомная сборка QUIC под названием fd_quic и масштабирование на стороне приема (receive-side scaling), распределяющее трафик по ядрам. Согласно документации Firedancer, сетевые тайлы никогда не спят, используя активное опросное ожидание (busy-polling) для поддержания стабильной задержки. Обратной стороной является то, что для этого требуются права root при настройке и специфическое сетевое оборудование.

3. Ускоренная проверка подписей

Верификация подписей Ed25519 является одной из самых ресурсоемких задач для валидатора в больших масштабах. Firedancer использует векторные инструкции AVX-512 для проверки подписей параллельными батчами, а не по одной. Инженеры Jump зафиксировали, что этот процесс выполняется примерно в 3,9 раза быстрее стандартной скалярной версии на том же чипе.

4. Распространение блоков

Firedancer также оптимизирует Turbine — механизм распространения блоков в Solana — и его код стирания, благодаря чему данные эффективно передаются под нагрузкой. В сочетании с улучшениями в сетевой части и криптографии именно это позволяет клиенту достигать пропускной способности, значительно превосходящей показатели исходного программного обеспечения.

Frankendancer против Firedancer

Эти два названия постоянно путают, поэтому разница имеет принципиальное значение. Frankendancer представляет собой гибрид: он объединяет сетевой код и код генерации блоков Firedancer со средой выполнения на Rust и консенсусом Agave, что позволяет валидаторам использовать часть архитектуры без необходимости доверять непроверенному коду консенсуса.

Frankendancer была развернута в mainnet в 2024 году и получила реальное распространение в течение 2025 года. Поскольку для выполнения и консенсуса она полагается на Agave, ее производительность ограничена этой средой выполнения и она не до конца решает проблему единственного клиента, так как каждая нода по-прежнему зависит от консенсуса Agave.

Полноценный Firedancer избавляется от этой зависимости. Он реализует весь конвейер валидатора, включая консенсус и выполнение, в виде независимой кодовой базы на C и C++. Именно эта версия обеспечивает Solana полноценный второй клиент и независимую от Agave зону отказа.

Запуск в mainnet и принятие

Jump Crypto объявила о запуск полного Firedancer в mainnet 12 декабря 2025 года на конференции Solana Breakpoint в Абу-Даби. К тому моменту клиент уже около 100 дней тихо работал в продакшене у небольшой группы валидаторов, успешно сформировав более 50 000 блоков. Перед этим команда провела публичный аудит безопасности, подкрепленный программой вознаграждений за поиск уязвимостей на сумму 1 млн долларов.

Внедрение происходило намеренно медленно, а не в виде резкого переключения. Инженер-основатель Ричи Пател сообщил изданию CoinDesk в мае 2026 года, что через клиент прошли десятки миллионов транзакций, в то время как масштабирование происходило аккуратно.

К первой половине 2026 года семейство Firedancer работало примерно на 20% или более активных валидаторов, причем на долю полноценного клиента приходилась небольшая двузначная доля staked SOL. Форк Agave от Jito по-прежнему занимает большую часть, поэтому до сбалансированной мультиклиентской сети еще далеко. SOL выросла примерно на 6% после запуска, а набор валидаторов закрепился на отметке около 840 нод по сравнению с пиковым значением выше 1 300.

Почему важна клиентская диверсификация

История сбоев Solana объясняет это внимание. Анализ простоев сети от Helius связывает пять из семи крупных остановок работы с багами валидаторов или клиентов, а не с дизайном консенсуса. Когда примерно 90% stake работает на одном ПО, одна ошибка в коде может заморозить производство блоков независимо от того, насколько быстро выглядит сеть.

Ethereum усвоил это рано и относится к клиентской диверсификации как к правилу безопасности, стремясь удерживать любой отдельный клиент ниже трети мощности консенсуса. Клиент выше этого уровня может остановить финализацию; выше двух третей он может финализировать неверные блоки. Solana начинала с гораздо большей концентрации: около 90% на одном клиенте.

Firedancer меняет этот расклад. Не разделяя никакого кода или языка с Agave, баг памяти в Rust-аллокаторе Agave не должен затронуть кодовую базу C++ в Firedancer, и они могут сбоить независимо друг от друга. Сеть сможет пережить катастрофический баг в любой из сторон, пока stake распределен так, что ни один клиент не сможет одновременно вывести из строя супербольшинство.

Это также ключевой аргумент для институциональных инвесторов. Риск-менеджеры хотят знать, что происходит, когда что-то ломается, и два независимых клиента выглядят для них совершенно иначе. Поскольку JPMorgan организует выпуск коммерческих бумаг в сети Solana, а State Street готовит токенизированный фонд ликвидности для нее, устранение рисков единственного клиента снимает главное возражение против создания регулируемых финансовых сервисов на ее базе.

Firedancer, Alpenglow и дорожная карта Solana

Firedancer — это лишь половина масштабного обновления, и люди часто путают ее со второй половинкой. Alpenglow — это новый механизм консенсуса от Anza, который заменяет Proof of History и TowerBFT и нацелен на финализацию около 150 миллисекунд. Firedancer — это клиент; Alpenglow — протокол консенсуса. Валидаторы одобрили его, и он проходит тестирование в преддверии активации mainnet, ожидаемой позднее в 2026 году.

Лимиты вычислений тоже имеют значение. Solana увеличивала объем вычислений на блок с помощью таких предложений, как SIMD-0256, которые подняли потолок выше 60 миллионов units, и обсуждаются новые повышения. Более высокие лимиты сильнее нагружают аппаратное обеспечение валидаторов, создавая именно то давление, на которое рассчитана архитектура Firedancer.

Обе команды также планируют защиту от постквантовых угроз. В апреле 2026 года Anza и команда Firedancer независимо друг от друга остановились на Falcon — выбранной NIST схеме цифровых подписей, компактность которой подходит для высокопроизводительной сети без ущерба для ее производительности.

Аппаратные требования Firedancer

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

Руководства для операторов на 2026 год сходятся на схожем производственном профиле:

• CPU: 12-ядерный, 24-поточный чип с частотой 2,8 ГГц является минимальным порогом, но производственные валидаторы ориентируются на 24+ ядра с частотой 3,5 ГГц и выше. Доминируют процессоры AMD EPYC, такие как 9354 и 9355, в конфигурациях с одним сокетом во избежание межсокетной задержки.
• AVX-512: Обязательно для ускоренной криптографии. Без него прирост скорости верификации подписей исчезает.
• RAM: Примерно от 384 ГБ до 512 ГБ памяти ECC, что значительно выше прежних рекомендаций, для работы с более крупными блоками и состоянием учетных записей.
• Storage: Накопители Enterprise NVMe Gen4 или Gen5, причем операционная система должна находиться на отдельном диске от данных ledger.
• Network: Симметричный канал 10 Гбит/с и сетевая карта с поддержкой XDP, которая необходима для работы архитектуры обхода ядра (kernel-bypass).
• Tuning: Отключите гиперпоточность, изолируйте ядра от планировщика ядра ОС и настройте сходство CPU (CPU affinity), чтобы каждый модуль (tile) владел своим ядром. Все это следует воспринимать как жесткие требования.

Firedancer — это инфраструктура профессионального уровня, созданная для мощного оборудования. Она не делает запуск ноды проще или дешевле.

Зачем Jump строит Firedancer?

Мотивация Jump проистекает из ее основной деятельности. Jump Trading Group потратила два десятилетия на создание низколатентных систем, обрабатывающих огромные объемы данных с минимальной задержкой, и Firedancer переносит эту культуру на валидатор. Пател описывал клиента как ведущего себя подобно реальному торговому движку, а главный научный сотрудник Кевин Бауэрс руководил первыми демонстрациями пропускной способности.

Заявленная цель заключается в обеспечении надежности и производительности Solana, сети, в которую Jump глубоко инвестирует. Деньги здесь тоже играют роль. Валидаторы зарабатывают на максимальном извлекаемом значении (MEV), то есть на прибыли от упорядочивания транзакций внутри блоков, и рынок MEV в Solana теперь представляет собой реальный бизнес. Firedancer напрямую не меняет экономику MEV, поскольку она в основном завязана на такие варианты, как решения от Jito, но более быстрый и стабильный клиент укрепляет инфраструктуру, на которую полагаются MEV-осведомленные операторы.

Риски и открытые вопросы

Firedancer представляет собой серьезное инженерное достижение, и его появление в основной сеть открывает столько же вопросов, сколько и решает. Держите их в поле зрения.

• Тест производительности против реального TPS: показатель в более чем 1 миллион TPS получен в ходе контролируемых демонстраций. Реальный показатель основной сети значительно ниже — исчисляется тысячами, а тесты мало что говорят о поведении системы при неблагоприятной нагрузке или разделении сети.
• Медленная миграция: переключение клиентов требует реальных усилий по настройке оборудования и операционной деятельности, а у Agave за плечами годы истории в основной сеть, с которыми Firedancer пока не может тягаться. Осторожные операторы будут выжидать, поэтому перераспределение stake происходит постепенно.
• Сохраняющийся риск единственного клиента: пока достаточный объём stake не перейдёт к независимым клиентам, ошибка в доминирующем программном обеспечении на базе Agave всё ещё может привести к остановке цепи. Разнообразие помогает только тогда, когда распределение действительно сбалансировано.
• Новая кодовая база: написанный с нуля код на C и C++ несёт в себе собственные риски для памяти и параллелизма, именно поэтому запуск предварялся длительным аудитом и программой вознаграждений за ошибки. Скромный послужной список в продакшене оставляет место для сюрпризов.
• Давление централизации: высокие требования к оборудованию благоприятствуют профессиональным операторам и крупным дата-центрам, а правила концентрации stake в Solana Foundation Delegation Program могут подтолкнуть валидацию в сторону меньшего числа более обеспеченных игроков.
• Отсутствие прямых инвестиций: токена Firedancer не существует, поэтому экспозиция осуществляется через SOL со всеми вытекающими криптовалютными рисками независимо от любого отдельного обновления.

Заключение

Firedancer меняет суть дискуссии вокруг Solana. Сеть всегда продавала скорость, и эта скорость была реальной, но она опиралась на единственную точку сбоя в ПО, которая приводила к повторяющимся и неприятным сбоям. Второй независимый клиент — это структурное решение, которое появилось в продакшене в декабре 2025 года.

Цифра в 1 миллион TPS продолжит привлекать заголовки СМИ, однако это наименее интересная часть. Реальный сдвиг заключается в том, что у Solana теперь есть надежный путь к многоклиентской устойчивости — такой, которая позволяет институциональным инвесторам относиться к ней как к производственной инфраструктуре, а не как к быстрому, но хрупкому эксперименту.

Исполнение в масштабе — это открытый вопрос. Stake должен мигрировать, новый код должен пережить годы неблагоприятных условий, а требования к оборудованию не должны незаметно привести к рецентрализации набора валидаторов. Firedancer дает Solana архитектуру, которая ей была нужна; получит ли сеть всю полноту выгод, зависит от внедрения.