Pendant la majeure partie de son histoire, Solana a fonctionné sur une seule implémentation de validateur. Cela l'a rendu rapide mais fragile, car un simple bogue logiciel pouvait paralyser toute la chaîne.

Firedancer résout ce problème. Il dote Solana d'un second client entièrement indépendant, doté d'un code séparé, d'un langage différent et de sa propre équipe, soit le modèle de sécurité multi-client qu'Ethereum applique comme référence de base.

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

Qu'est-ce que Firedancer ?

Firedancer est un client validateur pour Solana créé par Jump Crypto, la division blockchain de la société de trading Jump Trading Group. Un client validateur est le logiciel qui traite les transactions, produit les blocs et vote lors du consensus, de sorte que 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é. Plutôt que de forker le logiciel de Solana basé sur Rust, l'entreprise a réécrit le validateur de zéro en C et C++, des langages qui offrent un contrôle précis de la mémoire et du matériel. Le nouveau client ne partage aucun code avec l'historique, ce qui est précisément le but recherché.

Le client par défaut de Solana est Agave, maintenu par Anza, une équipe issue de Solana Labs. La variante la plus utilisée est le fork optimisé pour le MEV par Jito d'Agave. Firedancer se distingue des deux en tant que version véritablement séparée, aux côtés de clients plus modestes comme Sig, Mithril et Tinydancer.

Malgré de fréquentes confusions, Firedancer n'est ni un token, ni un airdrop, ni une modification de protocole. Il n'affecte pas l'émission de SOL, les récompenses de staking ni les règles de transaction. Il modifie le fonctionnement des validateurs, sans changer l'action du réseau.

Comment fonctionne Firedancer ?

Firedancer traite le validateur comme un ensemble de composants spécialisés et isolés plutôt que comme un programme unique et volumineux, puis supprime la surcharge du système d'exploitation qui limite le débit à grande échelle.

1. Architecture basée sur des tuiles (tiling)

Firedancer divise le travail du validateur en processus indépendants appelés tuiles, chacune gérant une tâche telle que le réseau, la vérification des signatures, l'empaquetage des transactions ou la production de blocs. Chaque tuile est épinglée à son propre cœur CPU et communique avec les autres via des canaux à mémoire partagée.

Agave fonctionne comme un processus monolithique unique où le réseau, l'exécution et le consensus partagent la mémoire. La division de Firedancer exploite le matériel multicœur grâce au parallélisme et contient les pannes, car un défaut dans une tuile met rarement hors service l'ensemble du validateur. L'attribution de mémoire consciente de la topologie NUMA et les structures de données sans verrou empêchent les cœurs de se disputer les mêmes ressources.

2. Réseau à contournement du noyau

Chaque paquet traité par un validateur standard fait un aller-retour à travers la pile réseau du noyau Linux, qui s'essouffle sous une forte charge. Firedancer contourne la majeure partie de ce chemin grâce à AF_XDP et eBPF, en lisant les paquets à proximité de la carte réseau afin que le plafond devienne le matériel, et non le logiciel en amont.

Au-dessus se trouve une version QUIC personnalisée appelée fd_quic et une mise à l'échelle du côté de la réception qui répartit le trafic entre les cœurs. Selon la documentation de Firedancer, les tuiles réseau ne dorment jamais, effectuant un scrutin d'attente (busy-polling) pour maintenir une latence stable. Le coût de cette approche est qu'elle nécessite un accès root lors de la configuration et 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 coûteuses d'un validateur à grande échelle. Firedancer utilise des instructions vectorielles AVX-512 pour vérifier les signatures par lots parallèles plutôt qu'une par une. Les ingénieurs de Jump ont chronométré leur routine à environ 3,9 fois la vitesse de la version scalaire standard sur la même puce.

4. Propagation des blocs

Firedancer optimise également Turbine, le mécanisme de propagation des blocs de Solana, ainsi que son code d'effacement afin que les données se propagent efficacement sous charge. Conjugué aux gains en matière de réseau et de cryptographie, c'est ainsi que le client pousse le débit bien au-delà de ce que le logiciel d'origine affichait.

Frankendancer vs Firedancer

Les deux noms sont constamment confondus, la distinction a donc son importance. Frankendancer est un hybride : il intègre le code de réseau et de production de blocs de Firedancer au moteur d'exécution et au consensus Rust d'Agave, permettant aux validateurs d'adopter une partie de l'architecture sans avoir à faire confiance à un code de consensus non testé.

Frankendancer a atteint le mainnet en 2024 et a gagné en popularité tout au long de 2025. S'appuyant 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 totalement le problème du client unique, puisque chaque nœud dépend toujours du consensus d'Agave.

Le Firedancer complet supprime cette dépendance. Il met en œuvre l'intégralité du pipeline de validateur, consensus et exécution compris, dans sa base de code indépendante en C et C++. Cette version offre à Solana un véritable second client et un domaine de défaillance distinct d'Agave.

Le lancement sur le mainnet et l'adoption

Jump Crypto a annoncé le lancement complet de Firedancer sur le mainnet le 12 décembre 2025 lors de Solana Breakpoint à Abu Dhabi. À cette date, le client tournait déjà discrètement en production sur un petit groupe de validateurs depuis environ 100 jours, produisant plus de 50 000 blocs de manière irréprochable. L'équipe a d'abord mené un audit de sécurité public soutenu par une prime aux bugs d'un million de dollars.

Le déploiement s'est fait de manière délibérément lente plutôt que par une transition brusque. L'ingénieur fondateur Ritchie Patel a déclaré à CoinDesk en mai 2026 que le client avait empaqueté des dizaines de millions de transactions alors que l'adoption progressait prudemment.

Au cours du premier semestre 2026, la famille Firedancer tournait sur environ 20 % ou plus des validateurs actifs, le client complet détenant une faible part à deux chiffres des SOL staked. Le fork d'Agave par Jito conservant la majorité, un réseau multiclient équilibré est encore à des années. Le SOL a progressé d'environ 6 % après le lancement, et l'ensemble des validateurs s'est établi autour de 840 nœuds, en baisse par rapport à un pic supérieur à 1 300.

Pourquoi la diversité des clients est essentielle

L'historique des pannes de Solana explique l'attention portée à ce sujet. L'analyse des pannes du réseau réalisée par Helius relie cinq des sept arrêts majeurs à des bugs de validateurs ou de clients plutôt qu'à la conception du consensus. Lorsque près de 90 % du stake exécute le même logiciel, une seule erreur de code peut figer la production de blocs, quelle que soit la rapidité apparente de la chaîne.

Ethereum l'a appris tôt et traite la diversité des clients comme une règle de sécurité, visant à maintenir chaque client individuel en deçà d'un tiers de la puissance de consensus. Un client dépassant ce niveau peut bloquer la finalisation ; au-delà de deux tiers, il pourrait finaliser de mauvais blocs. Solana a démarré de manière bien plus concentrée, avec près de 90 % sur un seul client.

Firedancer change la donne. Ne partageant aucun code ni langage avec Agave, un bug de mémoire dans l'allocateur Rust d'Agave ne devrait pas atteindre la base de code C++ de Firedancer, et les deux peuvent tomber en panne de manière indépendante. Le réseau peut survivre à un bug catastrophique dans l'un ou l'autre, à condition que le stake soit réparti de sorte qu'aucun client ne puisse mettre hors ligne une supermajorité en même temps.

C'est également l'argument de vente auprès des institutionnels. Les équipes de gestion des risques veulent savoir ce qui se passe en cas de défaillance, et deux clients indépendants leur inspirent une confiance très différente. Alors que JPMorgan organise une émission de billets de trésorerie sur Solana et que State Street prépare un fonds de liquidité tokenisé pour le réseau, l'élimination du risque lié au client unique lève un obstacle majeur au développement de la finance réglementée sur cette blockchain.

Firedancer, Alpenglow et la feuille de route de Solana

Firedancer constitue la moitié d'une mise à niveau plus vaste, et certains le confondent avec l'autre moitié. Alpenglow est un nouveau moteur de consensus développé par Anza qui remplace Proof of History et TowerBFT et vise une finalisation proche de 150 millisecondes. Firedancer est 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 activation sur le mainnet prévue plus tard en 2026.

Les limites de calcul ont également leur importance. Solana a relevé la puissance de calcul par bloc via des propositions telles que SIMD-0256, qui a poussé le plafond au-delà de 60 millions de Unit, d'autres augmentations étant à l'étude. Des limites plus élevées soumettent le matériel des validateurs à rude épreuve, soit précisément la pression que l'architecture de Firedancer a été conçue pour absorber.

Les deux équipes prévoient également une sécurité post-quantum. En avril 2026, Anza et l'équipe Firedancer ont opté séparément pour Falcon, un système de signature sélectionné par le NIST dont les signatures compactes conviennent à un réseau à haut débit sans altérer les performances.

Exigences matérielles pour Firedancer

Les premières couvertures affirmaient que Firedancer rendrait la validation moins coûteuse. C'est l'inverse qui s'est produit. Il récompense les machines dotées d'un grand nombre de cœurs et d'équipements réseau spécifiques, et la hausse des limites de calcul de Solana a placé la barre plus haut, et non plus bas.

Les guides opérateurs pour 2026 convergent vers un profil de production similaire :

• CPU : Une puce à 12 cœurs et 24 threads à 2,8 GHz constitue le minimum, mais les validateurs en production visent 24 cœurs et plus à 3,5 GHz et au-delà. Les processeurs AMD EPYC tels que les 9354 et 9355 dominent, dans des configurations à socket unique pour éviter la latence inter-socket.
• AVX-512 : Obligatoire pour la cryptographie accélérée. Sans cela, les gains de vérification des signatures disparaissent.
• RAM : Environ 384 Go à 512 Go de mémoire ECC, bien au-dessus des recommandations précédentes, pour des blocs plus volumineux et l'état des comptes.
• Stockage : Des disques NVMe Gen4 ou Gen5 d'entreprise, le système d'exploitation étant installé sur un disque séparé des données du ledger.
• Réseau : Une liaison symétrique de 10 Gbps et une carte réseau compatible XDP, dont la conception avec contournement du noyau (kernel-bypass) nécessite le bon fonctionnement.
• Réglage : Désactivez l'hyperthreading, isolez les cœurs du planificateur du noyau et définissez l'affinité du processeur (CPU affinity) afin que chaque module (tile) possède son propre cœur. Considérez tous ces éléments comme des exigences impératives.

Firedancer est une infrastructure de qualité professionnelle conçue pour du matériel performant. Elle ne rend pas l'exécution d'un nœud plus légère ou moins coûteuse.

Pourquoi Jump construit-il Firedancer ?

La motivation de Jump découle de son activité principale. Jump Trading Group a passé deux décennies à concevoir des systèmes à faible latence qui déplacent d'immenses volumes de données avec un délai minimal, et Firedancer applique cette culture à un validateur. Patel a décrit le client comme se comportant comme un véritable moteur de trading, et le scientifique en chef Kevin Bowers a dirigé les premières démonstrations de débit.

L'objectif affiché est la fiabilité et les performances pour Solana, un réseau dans lequel Jump a investi massivement. L'argent y joue également un rôle. Les validateurs gagnent de l'argent grâce à la valeur maximale extractible (MEV), le profit tiré du classement des transactions à l'intérieur des blocs, et le marché du MEV sur Solana est désormais un véritable secteur d'activité. Firedancer ne modifie pas directement l'économie du MEV, car celle-ci repose principalement sur des variantes telles que celle de Jito, mais un client plus rapide et plus stable renforce l'infrastructure sur laquelle comptent les opérateurs sensibles au MEV.

Risques et questions ouvertes

Firedancer représente une réalisation technique majeure, et son arrivée sur le mainnet soulève autant de questions qu'elle n'en résout. Gardez ces éléments à l'esprit.

• Benchmark vs débit en direct : Le chiffre de plus d'un million de TPS provient de démonstrations contrôlées. Le débit réel sur le mainnet est nettement inférieur, de l'ordre de quelques milliers, et les benchmarks ne disent pas grand-chose sur le comportement sous une charge contradictoire ou lors de partitions du réseau.
• Migration lente : Le changement de client demande un effort réel en matière de réglage matériel et d'opérations, et Agave bénéficie d'années d'historique sur le mainnet que Firedancer ne peut pas encore égaler. Les opérateurs prudents attendront, de sorte que le stake se déplace progressivement.
• Risque persistant lié à un client unique : Tant qu'une part suffisante du stake ne se sera pas déplacée vers des clients indépendants, un bug dans le logiciel dominant basé sur Agave pourrait toujours bloquer la chaîne. La diversité n'aide que lorsque la répartition est réellement équilibrée.
• Nouvelle base de code : Une réécriture complète en C et C++ comporte ses propres risques de mémoire et de concurrence, c'est pourquoi le lancement a été précédé d'un audit approfondi et d'un programme de primes aux bugs (bounty). Un historique de production encore mince laisse place à des imprévus.
• Pression de centralisation : Le profil matériel exigeant favorise les opérateurs professionnels et les grands centres de données, et les règles de concentration du stake dans le cadre du programme de délégation de la Fondation Solana pourraient orienter la validation vers un nombre plus restreint d'acteurs mieux financés.
• Pas d'investissement direct : Il n'y a pas de jeton Firedancer, l'exposition se fait donc par le biais du SOL, avec la volatilité crypto habituelle, indépendamment de toute mise à niveau spécifique.

Dernières réflexions

Firedancer redéfinit les enjeux du débat autour de Solana. Le réseau a toujours mis en avant sa vitesse, et celle-ci était bien réelle, mais elle reposait sur un point unique de défaillance logicielle qui a provoqué des pannes répétées et embarrassantes. Un second client indépendant constitue la solution structurelle, et il a fait son apparition sous une forme prête pour la production en décembre 2025.

Le chiffre d'un million de TPS continuera de faire les gros titres, pourtant c'est l'aspect le moins intéressant. Le véritable changement est que Solana dispose désormais d'une voie crédible vers une résilience multi-client, du genre de celle qui permet aux institutions de le traiter comme une infrastructure de production plutôt que comme une expérience rapide mais fragile.

L'exécution à grande échelle reste la grande inconnue. Le stake doit migrer, le nouveau code doit survivre à des années de conditions contradictoires, et les exigences matérielles ne doivent pas recentraliser discrètement l'ensemble des validateurs. Firedancer dote Solana de l'architecture dont il avait besoin ; la capacité du réseau à en tirer pleinement profit dépendra de son déploiement.