Объяснение Firedancer на Solana: mainnet, 1M TPS и разнообразие клиентов

Краткое описание: Firedancer независимый Solana , полностью разработанный компанией Jump Crypto на языках C и C++ с целью повышения скорости работы сети и защиты её от отключений.

  • Разработчик: Jump Crypto (Jump Trading Group)
  • Языки: C и C++, полностью независимые от клиента Agave, написанного на Rust
  • Mainnet: полный клиент запущен с декабря 2025 года, после запуска гибридной сети Frankendancer
  • Целевой показатель производительности: более 1 миллиона TPS, что значительно превышает текущую пропускную способность в рабочей среде
  • Почему это важно: устраняет зависимость Solana от одного клиента — причину большинства сбоев в работе, произошедших в прошлом

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

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

Вот как Firedancer , на каком этапе он находится после запуска и что это означает для надежности Solana и её планов на будущее. 👇

Что такое Firedancer?

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

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

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

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

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

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

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

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

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

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

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

Над этим уровнем расположена специальная сборка QUIC под названием fd_quic, а также механизм масштабирования на стороне приема, который распределяет трафик между ядрами. Согласно Firedancer , сетевые модули никогда не переходят в режим ожидания, а постоянно опрашивают сеть, чтобы поддерживать стабильную задержку. Недостатком является то, что для настройки требуется доступ с правами root и специальное сетевое оборудование.

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

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

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

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

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

«Франкендансер» против Firedancer

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

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

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

Mainnet и внедрение

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

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

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

Mainnet и внедрение

Почему важно разнообразие клиентов

Такое внимание объясняется статистикой сбоев Solana. Анализ Helius, посвященный периодам простоя сети, показывает, что пять из семи крупных сбоев были вызваны ошибками в программном обеспечении валидаторов или клиентов, а не недостатками архитектуры консенсуса. Когда примерно 90 % участников стейкинга используют одно и то же программное обеспечение, даже одна ошибка в коде может привести к остановке генерации блоков, независимо от того, насколько быстрой кажется цепочка.

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

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

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

Почему важно разнообразие клиентов

План развития Firedancer, Alpenglow и Solana

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

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

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

Firedancer требования для Firedancer

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

Прогнозы операторов на 2026 год сходятся в одном и том же профиле добычи:

  • Процессор: Минимальные требования — 12-ядерный процессор с 24 потоками и тактовой частотой 2,8 ГГц, однако в производственных валидаторах используются процессоры с 24 и более ядрами и тактовой частотой 3,5 ГГц и выше. В однопроцессорных конфигурациях преобладают процессоры AMD EPYC, такие как 9354 и 9355, что позволяет избежать задержек при взаимодействии между сокетами.
  • AVX-512: Требуется для ускоренной криптографии. Без него преимущества проверки подписи теряют смысл.
  • Оперативная память: примерно от 384 до 512 ГБ памяти с коррекцией ошибок (ECC), что значительно превышает прежние рекомендации, для обработки более крупных блоков данных и состояния учетных записей.
  • Хранение: корпоративные накопители NVMe Gen4 или Gen5, при этом операционная система размещается на отдельном диске, отличном от диска ledger .
  • Сеть: симметричный канал со скоростью 10 Гбит/с и сетевая карта с поддержкой XDP, без которых архитектура с обходом ядра просто не сможет работать.
  • Настройка: отключите технологию Hyper-Threading, изолируйте ядра от планировщика ядра и настройте привязку процессора таким образом, чтобы каждому блоку было выделено собственное ядро. Все эти требования следует рассматривать как обязательные.

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

Firedancer требования для Firedancer

Почему Jump Building — это Firedancer?

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

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

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

Firedancer серьезное инженерное достижение, и mainnet его mainnet вызывает столько же вопросов, сколько и дает ответов. Имейте это в виду.

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

Заключительные мысли

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

TPS 1 миллион TPS по-прежнему будет попадать в заголовки новостей, однако это наименее интересная часть. Настоящий прорыв заключается в том, что Solana есть реальный путь к обеспечению отказоустойчивости при работе с множеством клиентов — именно такой, которая позволит институциональным инвесторам рассматривать ее как рабочую инфраструктуру, а не как быстрый, но неустойчивый эксперимент.

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