Qu'est-ce que Firedancer, tant attendu lors de la conférence Breakpoint ?
TechFlow SélectionTechFlow Sélection
Qu'est-ce que Firedancer, tant attendu lors de la conférence Breakpoint ?
Comment se comporte le client validateur Solana Firedancer et comment l'exécuter ?
Dédié à des analyses Web3 approfondiesRédaction : Karen, Foresight News
Lors de la conférence Solana Breakpoint la semaine dernière, l'ambiance était animée, les annonces de produits de l'écosystème se succédaient, et diverses activités annexes ont ajouté encore plus d'éclat à cet événement. Un point fort particulièrement remarquable a été le déploiement en version préliminaire du client validateur Firedancer sur le réseau principal de Solana. Cette réalisation historique a suscité une attention particulière, marquant un bond qualitatif dans les performances du réseau Solana tout en réduisant le risque d'arrêt du réseau causé par un échec du seul client validateur existant jusqu'alors.
Le développement de Firedancer remonte à la période 2021-2022. Conçu comme un deuxième client validateur pour Solana sous l'impulsion de Jump Trading Group (le client initial Agave ayant été développé par Anza), son objectif premier est d'éliminer les points uniques de défaillance afin de renforcer la solidité et la résilience globale du réseau. Contrairement au validateur initial basé sur Rust, Firedancer est entièrement écrit en langage C, sans aucune ligne de code Rust. Ce choix technologique réduit considérablement l'impact potentiel des vulnérabilités sur l'ensemble du réseau, ajoutant ainsi une couche supplémentaire de sécurité à Solana.
Quelles sont les performances de Firedancer ?
Selon la démonstration présentée par Kevin Bowers, directeur scientifique chez Jump Crypto lors de la conférence Solana Breakpoint, Firedancer a montré sa capacité à traiter plus d'un million de transactions par seconde, un chiffre largement supérieur à la limite théorique actuelle de quelques dizaines de milliers de TPS sur Solana. Kevin Bowers a comparé cette avancée à la transformation d'une « route de campagne » en une « autoroute interétat », annonçant une optimisation simultanée de la capacité et des coûts du réseau.
Liam Heeger, ingénieur principal chez Jump Trading, a partagé les progrès réalisés par Firedancer sur le testnet : le client a déjà produit avec succès plus de 20 000 blocs et atteint un taux de mise en gage (staking) de 1 %.
Un autre ingénieur, Aryaman Jain, a présenté davantage de détails sur les performances de Firedancer dans des conditions spécifiques : dans un environnement composé de 10 validateurs, il peut atteindre un niveau de TPS de l'ordre du million, traiter plus de 1,2 milliard d'unités de calcul par seconde, démontrer une capacité Blockspace de 3,5 Gbps et atteindre une efficacité d'exécution VM de 500 000 TPS.
Comment fonctionne Firedancer ?
Firedancer repose sur trois composants principaux : une pile logicielle haute performance pour le calcul et le réseau, un Runtime, ainsi qu’un mécanisme de consensus. La capacité de Firedancer à porter les performances du réseau Solana à un million de TPS – alors que la limite imposée par le protocole actuel se situe autour de 81 000 TPS – tient essentiellement à son architecture innovante et à l’optimisation du flux de données.
Ce validateur adopte un modèle concurrentiel utilisant un petit nombre de threads exécutant diverses tâches spécialisées, chacun étant dédié à une fonction précise telle que le traitement des paquets réseau, la validation des transactions ou l’empaquetage des blocs. Cette conception permet une utilisation maximisée des ressources et une amélioration significative de la vitesse de traitement des transactions.
Plus précisément, chaque thread exécute l’une des 11 tâches différentes. Certaines tâches ne nécessitent qu’un seul thread, tandis que d’autres exigent plusieurs threads travaillant en parallèle. Chaque thread dispose d’un cœur CPU dédié, dont il a la propriété exclusive : il ne dort jamais ni n’est utilisé par le système d’exploitation à d’autres fins.
Firedancer introduit également une architecture appelée « tiles » (dalles). Chaque tile représente une tâche spécifique, le thread qui l’exécute et le cœur CPU qui lui est alloué. Cette combinaison rend le réglage des performances flexible et efficace. Par exemple, les tiles net et quic peuvent chacune traiter plus d’un million de TPS, tandis que les tiles verify et bank se concentrent respectivement sur la vérification des transactions et l’exécution des blocs. Bien que leur vitesse soit relativement plus faible, elle reste suffisante pour répondre aux exigences des scénarios à forte concurrence.
Le document officiel de Firedancer liste 11 types de tiles :
-
net : envoie et reçoit des paquets réseau depuis les équipements (chaque tile peut traiter >1 million de TPS) ;
-
quic : reçoit les transactions des clients, gère toutes les connexions et traite les paquets pour implémenter le protocole QUIC (chaque tile peut traiter >1 million de TPS) ;
-
verify : vérifie les signatures cryptographiques des transactions entrantes et filtre celles qui sont invalides (chaque tile peut traiter 20 000 à 400 000 TPS) ;
-
dedup : détecte et filtre les transactions entrantes en double ;
-
pack : lorsqu’il devient leader, empaquette les transactions entrantes et planifie intelligemment leur exécution ;
-
bank : exécute les transactions planifiées (chaque ensemble de tiles peut traiter 20 000 à 400 000 TPS) ;
-
poh : mécanisme continu d’opérations de hachage en arrière-plan, qui mélange les valeurs de hachage générées avec les transactions exécutées afin de prouver l’ordre et la temporalité ;
-
shred : lorsqu’il est leader, diffuse les données de blocs sur le réseau ; sinon, reçoit et relaie ces données (le débit dépend principalement de la taille du cluster. Dans les tests, un seul tile peut traiter >1 million de TPS si le cluster est petit) ;
-
store : reçoit les données de blocs lorsqu’il est leader, ou les récupère depuis d'autres nœuds quand ceux-ci sont leaders, puis les stocke dans une base de données locale sur disque ;
-
metric : collecte des informations de surveillance provenant des autres tiles et les expose via un point de terminaison HTTP ;
-
sign : détient la clé privée du validateur, et reçoit ainsi que répond aux demandes de signature provenant des autres tiles.
À noter que, avant même que Firedancer ne soit pleinement mature, une version transitoire appelée Frankendancer a déjà intégré le réseau principal Solana. Frankendancer est un hybride combinant certaines parties du code de Firedancer avec celles d’Agave, tirant parti des forces de Firedancer en matière de pile réseau et de production de blocs, tout en conservant les fonctions d’exécution et de consensus d’Agave. En revanche, Firedancer est entièrement reconstruit depuis zéro, sans inclure aucune ligne de code provenant d’Agave.
Quels impacts pour Firedancer ?
Sans aucun doute, le lancement de Firedancer aura un impact majeur sur l’écosystème Solana. Il enrichira considérablement la diversité des validateurs, atténuant ainsi davantage les risques liés aux pannes ponctuelles et renforçant encore la fiabilité du réseau Solana.
De plus, Firedancer maintient une compatibilité ascendante avec les protocoles existants, garantissant une transition en douceur pour l’écosystème, sans nécessiter de changements majeurs de la part des développeurs d’applications DApp ou des utilisateurs.
Bien que Firedancer fonctionne actuellement en mode non-votant et doive encore subir des optimisations et audits continus, cela dessine néanmoins un avenir bien plus prometteur pour le réseau Solana.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Foresight News
