Pendant la majeure partie de son histoire, Solana avec une seule implémentation de validateur. Cela lui conférait une grande rapidité, mais la rendait fragile, car un seul bug logiciel pouvait paralyser l'ensemble de la chaîne.

Firedancer cela. Il offre Solana deuxième client totalement indépendant, doté d'un code distinct, d'un langage différent et de sa propre équipe, ce modèle de sécurité multi-clients Ethereum comme la norme.

Voici comment Firedancer conçu, où il en est après son lancement, et ce que cela signifie pour la fiabilité et la feuille de route Solana. 👇

Qu'est-ce que Firedancer?

Firedancer est un client validateur pour Solana par Jump Crypto, la branche blockchain de la société de trading Jump Trading Group. Un client validateur est le logiciel qui traite les transactions, produit des blocs et vote lors du consensus ; ainsi, le client exécuté par un nœud détermine les performances du réseau.

Jump a lancé le projet en 2022 et a fait un choix délibéré. Au lieu de créer une branche du logiciel Solana écrit en Rust, l'équipe a réécrit le validateur de A à Z en C et C++, des langages qui permettent un contrôle précis de la mémoire et du matériel. Le nouveau client ne partage aucun code avec l'ancien, ce qui est justement le but recherché.

Le client par défaut Solana est Agave, géré par Anza, une équipe issue de Solana . La variante la plus utilisée est la version dérivée d'Agave MEV,Jito. Firedancer des deux autres en tant que version véritablement distincte, aux côtés de clients plus légers tels que Sig, Mithril et Tinydancer.

Bien que l'on confonde souvent ces concepts, Firedancer ni un jeton, ni airdrop, ni une modification du protocole. Il n'a aucune incidence sur SOL , staking ou les règles de transaction. Il modifie le fonctionnement des validateurs, sans pour autant changer le fonctionnement du réseau.

Comment fonctionne Firedancer ?

Firedancer le validateur comme un ensemble de composants spécialisés et isolés plutôt que comme un seul et même programme volumineux, ce qui lui permet d'éliminer la surcharge liée au système d'exploitation qui limite le débit à grande échelle.

1. Architecture par modules

Firedancer le travail des validateurs en processus indépendants appelés « tiles », chacun étant chargé d'une tâche spécifique telle que la gestion du réseau, la vérification des signatures, le regroupement des transactions ou la production de blocs. Chaque « tile » est affecté à un cœur de processeur spécifique et communique avec les autres via des canaux de mémoire partagée.

Agave s'exécute sous la forme d'un processus monolithique dans lequel la gestion du réseau, l'exécution et le consensus partagent la même mémoire. L'architecture segmentée Firedancer tire parti du matériel multicœur grâce au parallélisme et limite les défaillances, car une défaillance dans un segment entraîne rarement la panne de l'ensemble du validateur. Le placement de la mémoire adapté au modèle NUMA et les structures de données sans verrouillage empêchent les cœurs de se disputer les mêmes ressources.

2. Réseau sans passage par le noyau

Chaque paquet traité par un validateur standard effectue plusieurs allers-retours à travers la pile réseau du noyau Linux, qui s'engorge en cas de charge importante. Firedancer la majeure partie de ce chemin grâce à AF_XDP et eBPF, en lisant les paquets à proximité de la carte réseau ; ainsi, c'est le matériel qui devient la limite, et non plus le logiciel qui le précède.

Au-dessus de cela se trouve une version personnalisée de QUIC appelée fd_quic, ainsi qu'une fonctionnalité de répartition du trafic côté réception qui répartit le trafic entre les cœurs. Selon la Firedancer , les modules réseau ne se mettent jamais en veille et effectuent des interrogations en continu afin de maintenir une latence stable. En contrepartie, cela nécessite un accès root lors de la configuration ainsi qu'un matériel réseau spécifique.

3. Vérification accélérée des signatures

La vérification des signatures Ed25519 est l'une des tâches les plus gourmandes en ressources pour un validateur à grande échelle. Firedancer les instructions vectorielles AVX-512 pour vérifier les signatures par lots en parallèle plutôt que l'une par l'autre. Les ingénieurs de Jump ont mesuré que leur routine était environ 3,9 fois plus rapide que la version scalaire standard sur la même puce.

4. Propagation des blocs

Firedancer optimise Firedancer Turbine, le mécanisme de propagation des blocs Solana, ainsi que son codage par effacement, afin que les données soient réparties efficacement en cas de charge élevée. C'est grâce à cela, combiné aux améliorations apportées au niveau du réseau et de la cryptographie, que le client atteint un débit bien supérieur à celui du logiciel d'origine.

Frankendancer contre Firedancer

Ces deux noms sont souvent confondus, c'est pourquoi il est important de bien faire la distinction. Frankendancer est un système hybride : il intègre le code de mise en réseau et de production de blocs Firedancer au runtime Rust et au mécanisme de consensus d'Agave, permettant ainsi aux validateurs d'adopter une partie de l'architecture sans avoir à se fier à un code de consensus non testé.

Frankendancer a été déployé mainnet 2024 et a connu un véritable essor tout au long de l'année 2025. Comme il s'appuie sur Agave pour l'exécution et le consensus, ses performances sont limitées par ce moteur d'exécution, et il ne résout pas entièrement le problème du client unique, puisque chaque nœud dépend toujours du consensus d'Agave.

Full Firedancer cette dépendance. Il implémente l'intégralité du pipeline de validation, y compris le consensus et l'exécution, dans une base de code indépendante en C et C++. C'est cette version qui offre Solana véritable deuxième client et un domaine de défaillance distinct d'Agave.

Mainnet et son adoption

Jump Crypto a annoncémainnet officielmainnet Firedancer le 12 décembre 2025 lors de l'événementSolana à Abu Dhabi. À cette date, le client fonctionnait déjà en production depuis environ 100 jours au sein d'un petit groupe de validateurs, ayant produit plus de 50 000 blocs sans incident. L'équipe avait auparavant organisé un audit de sécurité public, assorti d'une prime de 1 million de dollars pour la découverte de failles.

Le déploiement s'est fait progressivement, plutôt que d'un seul coup. L'ingénieur fondateur Ritchie Patel a déclaré à CoinDesk en mai 2026 que le client avait traité des dizaines de millions de transactions tandis que l'adoption se développait prudemment.

Au premier semestre 2026, la Firedancer fonctionnait sur environ 20 % ou plus des validateurs actifs, le client complet détenant une part à deux chiffres (faible) des SOL mis en jeu. La fourche Agave Jito détient toujours la majorité, de sorte qu'un réseau multi-clients équilibré n'est pas pour demain. SOL d'environ 6 % après le lancement, et l'ensemble des validateurs sat 840 nœuds, en baisse par rapport à un pic supérieur à 1 300.

Pourquoi la diversité de la clientèle est-elle importante ?

Le bilan des pannes Solana explique cet intérêt. L'analyse Helius sur les temps d'arrêt du réseau attribue cinq des sept pannes majeures à des bogues au niveau des validateurs ou des clients, plutôt qu'à la conception du mécanisme de consensus. Lorsque près de 90 % des participants utilisent un seul et même logiciel, une simple erreur de codage peut paralyser la production de blocs, quelle que soit la vitesse apparente de la chaîne.

Ethereum très tôt et considère la diversité des clients comme une règle de sécurité, en veillant à ce qu'aucun client ne détienne plus d'un tiers de la puissance de consensus. Un client dépassant ce seuil peut retarder la finalité ; au-delà des deux tiers, il pourrait valider des blocs erronés. Solana une concentration bien plus importante, avec près de 90 % de la puissance concentrée sur un seul client.

Firedancer la donne. Comme il ne partage ni code ni langage avec Agave, un bug de mémoire dans l'allocateur Rust d'Agave ne devrait pas affecter le code C++ Firedancer, et les deux systèmes peuvent tomber en panne indépendamment l'un de l'autre. Le réseau peut résister à un bug catastrophique dans l'un ou l'autre, à condition que les participations soient réparties de manière à ce qu'aucun client ne puisse mettre hors ligne une majorité qualifiée d'un seul coup.

C'est également l'argument institutionnel. Les équipes chargées de la gestion des risques veulent savoir ce qui se passe en cas de défaillance, et le fait d'avoir deux clients indépendants est perçu très différemment par elles. Alors que JPMorgan organise une émission de papier commercial sur Solana State Street prépare un fonds de liquidité tokenisé pour le réseau, la réduction du risque lié à un client unique répond à l'une des principales objections soulevées quant à la mise en place d'une finance réglementée sur cette plateforme.

Firedancer, Lueur alpine et Feuille de route Solana

Firedancer une partie d'une mise à niveau plus vaste, et les gens ont tendance à le confondre avec l'autre partie. Alpenglow est un nouveau moteur de consensus développé par Anza qui remplace Proof of History et TowerBFT et vise une finalité de l'ordre de 150 millisecondes. Firedancer un client ; Alpenglow est un protocole de consensus. Les validateurs l'ont approuvé, et il est actuellement en phase de test en vue d'une mainnet prévue plus tard en 2026.

Les limites de puissance de calcul ont également leur importance. Solana augmenté la puissance de calcul par bloc grâce à des propositions telles que SIMD-0256, qui a fait passer le plafond au-delà de 60 millions d'unités, et d'autres augmentations sont actuellement à l'étude. Des limites plus élevées sollicitent davantage le matériel des validateurs, ce qui correspond exactement au type de pression que l'architecture Firedancer a été conçue pour absorber.

Les deux équipes se préparent également à l'ère de la sécurité post-quantique. En avril 2026, Anza et Firedancer ont chacune opté pour Falcon, un schéma de signature sélectionné par le NIST dont les signatures compactes conviennent à un réseau à haut débit sans nuire aux performances.

Configuration Firedancer requise pour Firedancer

Les premières analyses laissaient entendre que Firedancer réduire le coût de la validation. C'est tout le contraire qui s'est produit. Ce système favorise les machines dotées d'un grand nombre de cœurs et certains équipements réseau spécifiques, et l'augmentation des limites de puissance de calcul Solana a relevé la barre, et non l'abaissée.

Les prévisions des opérateurs pour 2026 s'accordent sur un profil de production similaire :

• Processeur : un processeur à 12 cœurs et 24 threads cadencé à 2,8 GHz constitue le minimum requis, mais les validateurs de production visent des configurations de plus de 24 cœurs cadencés à 3,5 GHz ou plus. Les processeurs AMD EPYC, tels que les modèles 9354 et 9355, dominent le marché, notamment dans les configurations à un seul socket afin d'éviter les latences liées à l'interconnexion entre sockets.
• AVX-512 : indispensable pour l'accélération cryptographique. Sans cette fonctionnalité, les gains en matière de vérification des signatures disparaissent.
• Mémoire vive (RAM) : environ 384 Go à 512 Go de mémoire ECC, ce qui dépasse largement les estimations précédentes, pour prendre en charge des blocs plus volumineux et l'état des comptes.
• Stockage : disques NVMe Gen4 ou Gen5 d'entreprise, le système d'exploitation étant installé sur un disque distinct de celui contenant ledger .
• Réseau : une liaison symétrique de 10 Gbit/s et une carte réseau compatible XDP, indispensables au bon fonctionnement de la conception en contournement du noyau.
• Réglages : désactivez l'Hyper-Threading, isolez les cœurs du planificateur du noyau et configurez l'affinité CPU de manière à ce que chaque tuile dispose de son propre cœur. Considérez toutes ces mesures comme des exigences impératives.

Firedancer une infrastructure de niveau professionnel conçue pour du matériel performant. Elle ne rend pas l'exploitation d'un nœud lighter moins coûteuse.

Pourquoi Jump Building s'appelle-t-il Firedancer?

La motivation de Jump trouve son origine dans son activité principale. Jump Trading Group a passé deux décennies à mettre au point des systèmes à faible latence capables de traiter d'énormes volumes de données avec un délai minimal, et Firedancer cette culture à un validateur. M. Patel a décrit le client comme fonctionnant à la manière d'un véritable moteur de négociation, et Kevin Bowers, directeur scientifique, a dirigé les premières démonstrations de débit.

L'objectif déclaré est d'assurer la fiabilité et la performance de Solana, un réseau dans lequel Jump s'est fortement investi. L'aspect financier entre également en jeu. Les validateurs tirent leurs revenus de la valeur maximale extractible ( MEV ), c'est-à-dire le profit généré par l'ordre des transactions au sein des blocs, et MEV Solana est désormais une véritable activité commerciale. Firedancer directement MEV , celle-ci s'exerçant principalement dans des variantes telles que Jito, mais un client plus rapide et plus stable renforce l'infrastructure sur laquelle s'appuient les opérateurs MEV.

Risques et questions en suspens

Firedancer une véritable prouesse technique, et son mainnet soulève autant de questions qu'elle n'apporte de réponses. Gardez cela à l'esprit.

• Débit en conditions de test vs débit en production : TPS de plus d'un million TPS provient de démonstrations en conditions contrôlées. mainnet réel mainnet est bien inférieur, de l'ordre de quelques milliers, et les tests de performance ne donnent que peu d'indications sur le comportement du système en cas de charge malveillante ou de fragmentation du réseau.
• Migration lente : changer de client nécessite un réel effort en matière d'optimisation matérielle et d'exploitation, et Agave bénéficie mainnet de plusieurs années mainnet Firedancer encore Firedancer égaler. Les opérateurs prudents vont attendre, ce qui explique que les parts de marché évoluent progressivement.
• Risque persistant lié à la dépendance vis-à-vis d'un seul client : tant qu'une part suffisante de la mise n'aura pas été transférée vers des clients indépendants, un bug dans le logiciel dominant basé sur Agave pourrait encore paralyser la chaîne. La diversité n'apporte de solution que lorsque la répartition est véritablement équilibrée.
• Nouvelle base de code : une réécriture complète en C et C++ comporte ses propres risques en matière de mémoire et de concurrence, raison pour laquelle le lancement a été précédé d'un long audit et d'un programme de prime. L'historique de production étant encore limité, des surprises sont possibles.
• Pression à la centralisation : la configuration matérielle lourde favorise les opérateurs professionnels et les grands centres de données, et les règles de concentration des participations prévues dans le programme de délégation Solana pourraient faire pencher la balance de la validation vers un nombre réduit d'acteurs disposant de moyens financiers plus importants.
• Pas d'investissement direct : il n'existe pas Firedancer ; l'exposition se fait donc par l'intermédiaire SOL, avec la volatilité habituelle des cryptomonnaies, indépendamment de toute mise à jour spécifique.

Conclusion

Firedancer la donne dans le Solana . Le réseau a toujours mis en avant sa rapidité, et cette rapidité était bien réelle, mais il sat un point de défaillance logiciel unique qui a entraîné des pannes répétées et embarrassantes. Un deuxième client indépendant constitue la solution structurelle, et celui-ci a été déployé en version de production en décembre 2025.

TPS d'un million TPS continuera de faire la une des journaux, mais c'est en réalité l'aspect le moins intéressant. Le véritable changement réside dans le fait que Solana dispose Solana d'une voie crédible vers une résilience multi-clients, celle qui permet aux institutions de la considérer comme une infrastructure de production plutôt que comme une expérience rapide mais fragile.

La mise en œuvre à grande échelle reste une inconnue. Le staking doit être migré, le nouveau code doit résister à des années de conditions difficiles, et les exigences matérielles ne doivent pas entraîner une recentralisation insidieuse de l'ensemble des validateurs. Firedancer Solana elle avait besoin ; quant à savoir si le réseau en tirera pleinement parti, tout dépendra de la mise en œuvre.