Qu’est-ce que le très attendu Firedancer at Breakpoint ?

Lors de la conférence Solana Breakpoint de la semaine dernière, l’atmosphère était animée par des lancements de produits et divers événements parallèles intéressants. L’un des faits marquants a été le lancement officiel sur le réseau principal de la première version du client validateur de Solana, Firedancer.

Cette étape importante a fait l’objet d’une attention particulière, car elle a permis au réseau Solana d’améliorer considérablement ses performances tout en réduisant le risque d’interruption du réseau dû à la défaillance d’un seul client.

Le développement de Firedancer remonte à 2021-2022, sous l’impulsion de Jump Trading Group, en tant que deuxième client validateur de Solana (le premier client, Agave, ayant été développé par Anza). Son objectif principal était d’éliminer les points de défaillance uniques, en améliorant la robustesse et la résilience globales du réseau.

Contrairement au validateur original basé sur Rust, Firedancer est écrit en C, à l’exclusion du code Rust. Ce choix réduit considérablement l’impact potentiel des vulnérabilités sur le réseau, ajoutant une solide couche de sécurité à Solana.

Quelles sont les performances de Firedancer ?

Lors d’une présentation au Solana Breakpoint, Kevin Bowers, Chief Scientist de Jump Crypto, a présenté la capacité de Firedancer à traiter plus d’un million de transactions par seconde (TPS), dépassant de loin la limite théorique actuelle de Solana, qui est de quelques dizaines de milliers de TPS. Il a comparé métaphoriquement cette réalisation à l’élargissement d’une « route de campagne » en une « autoroute inter-États », ce qui indique une double optimisation des coûts et de la capacité du réseau.

L’ingénieur principal Liam Heeger a fait part des progrès réalisés sur le réseau de test, en indiquant que Firedancer avait réussi à produire plus de 20 000 blocs avec un ratio de mise de 1 %. Un autre ingénieur, Aryaman Jain, a démontré les performances de Firedancer dans des conditions spécifiques, révélant un TPS allant jusqu’à un million dans un environnement à 10 validateurs, avec plus de 1,2 milliard de calculs par seconde et une capacité d’espace de blocs de 3,5 Gbps.

Comment fonctionne Firedancer ?

Firedancer s’articule autour de trois éléments principaux : une pile de calcul à haute performance, une pile de réseau et les mécanismes d’exécution et de consensus. Sa capacité à porter les performances de Solana à 1 million de TPS (les limites actuelles du protocole se situent autour de 81 000 TPS) repose sur son architecture innovante et l’optimisation du flux de données.

Le validateur utilise un modèle de concurrence qui exécute diverses tâches sur quelques threads, chaque thread se concentrant sur des tâches spécifiques telles que le traitement des paquets réseau, la validation des transactions et l’empaquetage des blocs. Cette conception maximise l’utilisation des ressources et accélère considérablement le traitement des transactions.

Plus précisément, chaque thread exécute l’une des 11 tâches différentes. Certaines tâches ne requièrent qu’un seul thread, tandis que d’autres nécessitent plusieurs threads travaillant en parallèle. Chaque thread fonctionne sur un cœur de processeur dédié, ce qui garantit qu’il ne dort jamais et qu’il n’est jamais réaffecté par le système d’exploitation.

Firedancer introduit également une architecture appelée « tuiles », où chaque tuile représente un travail, son fil d’exécution et un cœur de processeur alloué. Cette combinaison permet un réglage des performances flexible et efficace. Par exemple, les tuiles net et quic peuvent gérer plus d’un million de TPS, tandis que les tuiles verify et bank se concentrent sur la validation des transactions et l’exécution des blocs, ce qui est suffisant pour les scénarios à haute teneur en liquidités.

La documentation officielle de Firedancer répertorie les 11 tuiles suivantes :

• net : Envoie et reçoit des paquets réseau (chaque tuile peut gérer >1 million de TPS) ;
• quic : Reçoit les transactions des clients, gère la connexion et le traitement des paquets pour le protocole QUIC (chaque tuile peut traiter >1 million de TPS) ;
• vérifier : Valide les signatures cryptographiques des transactions entrantes, en filtrant celles qui ne sont pas valides (chaque tuile peut traiter 20 à 40 000 TPS) ;
• déduire : Vérifie et filtre les transactions entrantes en double ;
• paquet : Il conditionne les transactions entrantes lorsqu’il agit en tant que chef de file, en planifiant intelligemment leur exécution ;
• banque : Exécute les transactions programmées (chaque tuile peut gérer 20 à 40 000 TPS) ;
• poh : Hachage continu en arrière-plan, mélangeant les hachages générés avec les transactions exécutées afin de prouver l’ordre et le moment de l’exécution ;
• déchiqueter : distribue les données de bloc au réseau lorsqu’il agit en tant que leader ; dans le cas contraire, il reçoit et retransmet les données de bloc (le débit dépend principalement de la taille du cluster, avec des références indiquant >1 million de TPS pour les petits clusters) ;
• magasin : Reçoit des données de bloc lorsqu’il agit en tant que chef de file ou d’autres nœuds lorsqu’ils sont chefs de file, et les stocke dans une base de données sur disque local ;
• métrique : collecte des informations de surveillance sur d’autres tuiles et les fournit aux points d’extrémité HTTP ;
• signe : détient la clé privée du validateur et répond aux demandes de signature des autres tuiles.

Notamment, avant que Firedancer n’arrive à maturité, sa version transitoire, Frankendancer, est déjà entrée dans le Solana mainnet. Frankendancer est un hybride du code de Firedancer et d’Agave, qui tire parti des avantages de Firedancer en matière de pile réseau et de production de blocs, tout en conservant les fonctionnalités d’exécution et de consensus d’Agave. En revanche, Firedancer est entièrement construit à partir de zéro, sans aucun code Agave.

Quel est l’impact de Firedancer ?

Il ne fait aucun doute que le lancement de Firedancer a des conséquences importantes pour l’écosystème Solana, en améliorant considérablement la diversité des validateurs et en réduisant encore le risque de points de défaillance uniques, renforçant ainsi la fiabilité du réseau.

De plus, Firedancer maintient une compatibilité ascendante avec les protocoles existants, assurant une transition en douceur pour l’écosystème sans nécessiter d’ajustements substantiels de la part des développeurs et des utilisateurs de DApps.

Bien que Firedancer soit actuellement sans droit de vote et fasse l’objet d’une optimisation et d’un audit continus, il donne une image encourageante du développement futur du réseau Solana.