Et si l’une des plus importantes mises à jour de l’histoire récente de Solana avait pu être livrée deux fois plus vite ? C’est précisément la question que pose Anatoly Yakovenko, co-fondateur du réseau, à la veille d’une migration majeure prévue pour le 21 octobre. Tandis que les transactions de vote des validateurs s’apprêtent à disparaître des blocs, le débat sur la complexité d’Alpenglow relance une discussion plus large : jusqu’où peut-on simplifier un consensus sans sacrifier la robustesse ?
Une critique qui arrive au moment critique
La veille d’un basculement technique aussi sensible, les mots d’un co-fondateur pèsent lourd. Anatoly Yakovenko a publié un commentaire sur X en citant un message qui célébrait la future suppression des votes on-chain. Il a ironisé sur la critique récurrente selon laquelle une grande partie des transactions par seconde affichées par Solana provenait simplement des votes des validateurs.
Sa phrase a fait le tour des discussions techniques : « Alpenglow would have shipped in half the time if they just changed the vote program to the ag state machine ». En français, il estime qu’un simple ajustement du programme de vote vers une machine d’état plus légère aurait permis de livrer Alpenglow en moitié moins de temps. Ce n’est pas une attaque frontale contre l’équipe, mais un rappel que les choix d’architecture ont un coût en délais et en complexité.
Cette remarque arrive alors que la migration principale est planifiée pour le 21 octobre. L’époque 1064 servira de déclencheur, avec un démarrage estimé autour de 13 h 20 UTC. Les opérateurs de nœuds et les services d’analyse se préparent depuis plusieurs semaines. Le moment choisi pour cette déclaration n’est donc pas anodin : il place la discussion au cœur de l’actualité technique du réseau.
Ce que change réellement la fin des votes dans les blocs
Jusqu’à présent, chaque validateur envoyait des transactions de vote qui apparaissaient dans les blocs. Ces votes occupaient une place importante dans les statistiques publiques de transactions par seconde. Une fois Alpenglow activé, ces messages disparaîtront des blocs eux-mêmes. Les explorateurs et les plateformes d’analytique devront donc recalibrer leurs compteurs.
Le résultat le plus visible sera une baisse des chiffres de TPS affichés. Pourtant, cette baisse ne signifie pas nécessairement une chute de l’activité réelle des utilisateurs. Les paiements, les échanges et les autres transactions non liées au consensus continueront d’exister. Seul le volume artificiellement gonflé par les votes disparaîtra des totaux.
Les services qui suivent la participation des validateurs devront aussi adapter leur logique. Au lieu de lire les instructions du programme de vote, ils devront s’appuyer sur les données de certificats placées dans les footers de blocs. Certains outils, comme le message gRPC de Yellowstone, ne transmettent pas encore ces certificats. Un travail d’adaptation reste donc nécessaire côté infrastructures.
Point clé : la disparition des votes on-chain va faire baisser les chiffres de TPS, mais l’activité utilisateur réelle n’en sera pas forcément affectée. Les outils d’analyse doivent se mettre à jour pour lire les certificats plutôt que les anciennes instructions de vote.
Alpenglow remplace TowerBFT par un système à deux chemins
Alpenglow n’est pas un simple correctif. Il s’agit d’un remplacement de TowerBFT, le mécanisme que les validateurs utilisaient jusqu’ici pour se mettre d’accord sur les blocs. Le nouveau design, documenté par Anza, introduit un système appelé Votor qui fait tourner deux chemins de vote en parallèle.
Le premier chemin finalise un bloc en un seul round dès qu’il obtient des réponses de 80 % de la stake. Le second chemin utilise deux rounds avec des seuils de 60 %. Cette double approche vise à combiner vitesse et résilience. Les votes deviennent des messages directs signés avec de la cryptographie BLS, ce qui permet d’agréger plusieurs signatures en un certificat compact.
Les validateurs s’appuient aussi sur leurs propres timers pour détecter un leader qui ne répond plus et voter pour le sauter. L’objectif affiché est une finalité autour de 150 millisecondes pour les nœuds admis dans l’ensemble de validateurs. C’est une promesse ambitieuse qui place Solana dans une catégorie de latence très compétitive face à d’autres réseaux.
Les votes deviennent des messages directs signés avec BLS, permettant d’agréger plusieurs signatures en un certificat compact.
Pourquoi Yakovenko parle d’un gain de temps potentiel
La remarque du co-fondateur porte sur la complexité choisie. Selon lui, une modification plus simple du programme de vote, orientée vers une machine d’état plus légère, aurait pu produire un résultat comparable en moitié moins de temps de développement. Cela ne signifie pas que le design actuel est mauvais. Cela souligne simplement qu’il existait des chemins plus directs.
Les documents techniques mentionnent d’ailleurs les alternatives étudiées pendant la conception. Une version sans finalité en un seul round offrait une opération plus simple et une tolérance aux fautes byzantines de 33 %. Ses auteurs reconnaissaient cependant une latence moins bonne et une résilience aux pannes inférieure. Une autre piste reposait sur un graphe orienté acyclique, potentiellement plus économe en bande passante, mais jugée moins efficace en latence et en utilisation complète de la capacité réseau.
Le choix final a privilégié la performance et la finalité rapide. Ce choix a un coût en temps de développement et en complexité opérationnelle. C’est précisément ce coût que Yakovenko met en lumière au moment où la migration devient concrète.
Les frais de vote changent de nature
Avec la suppression des votes on-chain, les frais individuels liés à chaque transaction de vote disparaissent. Les validateurs paieront désormais un forfait fixe de 0,8 SOL par époque. La totalité de ce montant est brûlée. Le paiement est prélevé sur le compte de vote et non plus sur le compte d’identité.
Ce forfait doit être réglé une époque à l’avance. La première charge, au début de l’époque 1064, couvre la participation à l’époque 1065. Un validateur qui ne peut pas payer perd le droit de voter ou de produire des blocs pour l’époque suivante. L’opérateur doit aussi veiller à conserver un solde supérieur au minimum d’exemption de loyer sur le compte concerné.
Ces changements préparent le terrain depuis plusieurs mois. L’enregistrement des clés publiques BLS était disponible sur le mainnet dès le 8 juillet, et la fonctionnalité d’admission a été activée le 22 juillet. Ces étapes préparatoires n’activaient pas encore le consensus Alpenglow lui-même, mais elles posaient les bases techniques nécessaires.
Résumé des nouveaux frais :
- 0,8 SOL brûlés par époque et par validateur
- Paiement anticipé d’une époque
- Source : compte de vote
- Conséquence en cas de non-paiement : exclusion de la participation
Le calendrier précis de la migration
La documentation de migration distingue l’activation de fonctionnalités et le transfert effectif du consensus. Le point de bascule intervient 5 000 slots après le déclenchement de l’époque 1064. Pendant une période transitoire, les blocs ne portent que des votes le temps que les validateurs terminent le passage.
Les opérateurs doivent utiliser la version 4,3,2 d’Agave, Jito-Solana ou Harmonic Salsa. Firedancer et Frankendancer ne sont pas supportés pendant cette phase de transition. Cette exigence de version unique vise à réduire les risques d’incompatibilité au moment le plus sensible.
Les développeurs avaient déjà pu observer le comportement modifié lorsque Alpenglow a atteint le devnet en septembre, après le passage sur testnet. Les explorateurs ont dû apprendre à conserver séparément les blocs candidats concurrents jusqu’à confirmation, en retenant uniquement le bloc sélectionné plutôt que de fusionner leurs transactions.
Finalité rapide, mais pas forcément pour tout le monde
L’objectif de 150 millisecondes de finalité concerne d’abord les nœuds admis dans l’ensemble de validateurs. Les nœuds situés en dehors de cet ensemble peuvent recevoir l’information plus tard. Par le chemin par défaut, ils apprennent la finalité via les certificats inclus dans un bloc ultérieur. Cela peut ajouter jusqu’à un intervalle de production de bloc, et davantage si des blocs sont sautés ou retardés.
Un validateur admis peut envoyer directement des messages de consensus à un nœud partenaire. Dans ce cas, la latence réseau entre les deux parties devient le principal délai supplémentaire. Si tous les partenaires configurés deviennent injoignables, le destinataire retombe sur l’apprentissage via les footers de blocs suivants.
Cette distinction entre nœuds admis et nœuds externes est importante pour les opérateurs de RPC et les services qui affichent l’état de confirmation. Une finalité consensus ultra-rapide ne se traduit pas automatiquement par une visibilité immédiate partout sur le réseau.
Une limite à 2 000 validateurs et des choix de gouvernance
Le design plafonne l’ensemble admis à 2 000 validateurs, en priorisant ceux qui détiennent le plus de stake. Cette limite vise à garder les certificats suffisamment petits pour tenir dans un seul message UDP. Les enregistrements de participation permettent ensuite de récompenser les validateurs qui votent activement.
La proposition a obtenu un large soutien lors du vote de gouvernance en septembre 2025 : 98,27 % des votes exprimés, avec une participation représentant 52 % de la stake totale. Ce résultat a ouvert la voie à l’implémentation. Le niveau de consensus politique interne était élevé, même si la participation n’était pas totale.
Ce plafond de 2 000 n’est pas anodin. Il reflète un arbitrage entre décentralisation et efficacité de communication. Plus le nombre de participants directs est élevé, plus les certificats deviennent volumineux et plus la latence risque d’augmenter. Les auteurs du design ont clairement privilégié la compacité et la rapidité.
Impact sur les explorateurs et les services d’analyse
Les équipes qui gèrent des explorateurs de blocs et des tableaux de bord de métriques doivent réinitialiser leurs baselines de comptage de transactions et de TPS. Continuer à utiliser les anciennes formules produirait des chiffres trompeurs. La documentation insiste sur ce point : les services doivent adapter leur lecture des footers de blocs.
Agave 4.3 propose une notification optionnelle de footer de bloc. Les services qui en ont besoin doivent l’activer et l’implémenter. Ces notifications conservent leur ordre par rapport aux notifications d’entrées, ce qui facilite le traitement séquentiel.
L’horloge de la chaîne conserve son format existant et sa précision à la seconde entière. Pendant l’exécution des transactions, l’horodatage estime le moment où le bloc parent s’est terminé. Les opérateurs sont invités à continuer de traiter cette valeur comme approximative. Rien de révolutionnaire de ce côté, mais une continuité utile pour les outils existants.
Ce que cette critique révèle sur la culture technique de Solana
La franchise de Yakovenko n’est pas nouvelle. Le réseau s’est construit autour d’une culture de discussion technique ouverte, parfois brutale. Dire publiquement qu’un projet aurait pu être livré plus vite avec une approche plus simple s’inscrit dans cette tradition. Cela force aussi à réfléchir aux compromis entre perfection architecturale et vitesse de livraison.
Dans un écosystème où la concurrence entre chaînes se joue aussi sur la capacité à itérer rapidement, ce type de remarque n’est pas anodin. Elle rappelle que chaque couche de sophistication ajoutée a un coût en temps d’ingénierie et en surface d’erreurs potentielles. Alpenglow a choisi la voie de la performance maximale. Yakovenko suggère qu’une voie intermédiaire aurait peut-être suffi pour une première version.
Cette discussion est saine. Elle évite de transformer chaque mise à jour en objet intouchable. Elle place aussi la responsabilité collective : les équipes d’implémentation, les validateurs, les opérateurs d’infrastructures et les développeurs d’outils doivent tous s’adapter en même temps.
Les implications concrètes pour les validateurs
Pour un opérateur de validateur, la migration impose plusieurs actions concrètes. Mettre à jour le logiciel vers une version supportée. S’assurer que le compte de vote dispose des fonds nécessaires pour le forfait de 0,8 SOL. Vérifier que les clés BLS sont correctement enregistrées. Surveiller le comportement pendant la fenêtre de transition de 5 000 slots.
Les validateurs qui ne respectent pas ces prérequis risquent de se retrouver exclus de la production de blocs pour une époque. Dans un environnement où les récompenses dépendent de la participation continue, une exclusion, même temporaire, a un coût économique. La préparation en amont devient donc critique.
Le passage à un forfait fixe change aussi la structure de coûts. Auparavant, chaque vote générait des frais individuels. Désormais, le coût est prévisible et constant par époque. Pour les petits opérateurs, cela peut simplifier la trésorerie. Pour les plus grands, l’impact reste limité, mais la prévisibilité est un avantage opérationnel.
Une baisse des TPS qui va faire parler
Il est presque certain que les prochains jours verront circuler des graphiques montrant une chute brutale des transactions par seconde. Certains y verront une preuve de ralentissement. D’autres rappelleront, à juste titre, que la composition des transactions a changé. La suppression des votes on-chain nettoie le signal, mais elle crée aussi un moment de confusion communicationnelle.
Les équipes de communication et les analystes indépendants devront expliquer clairement la distinction entre volume de consensus et volume d’activité utilisateur. Sans cette pédagogie, les chiffres bruts risquent d’être instrumentalisés. C’est un risque classique lors de toute modification profonde de la façon dont les métriques sont calculées.
À plus long terme, des compteurs plus propres devraient renforcer la crédibilité des statistiques. Les comparaisons avec d’autres réseaux deviendront plus pertinentes une fois que les votes ne gonfleront plus artificiellement les totaux. C’est l’un des bénéfices indirects de cette migration.
Les alternatives écartées et ce qu’elles disent du design
Le document SIMD-0326 détaille les pistes qui n’ont pas été retenues. L’absence de finalité en un seul round aurait simplifié l’opération et offert une tolérance aux fautes byzantines de 33 %. Mais la latence et la résilience aux pannes auraient souffert. L’approche basée sur un graphe orienté acyclique promettait des économies de bande passante, au prix d’une latence moins bonne et d’une difficulté à exploiter pleinement la capacité du réseau.
Ces alternatives montrent que l’équipe a explicitement pesé les compromis. La solution retenue privilégie la finalité ultra-rapide et la compacité des certificats. Elle assume un plafond de 2 000 validateurs et une double voie de vote. Ce n’est pas le design le plus simple possible, et c’est précisément ce que souligne Yakovenko.
Dans l’ingénierie des systèmes distribués, le chemin le plus simple n’est pas toujours celui qui est choisi. Parfois, la performance perçue et réelle justifie une complexité supplémentaire. Parfois, cette complexité retarde la livraison sans apport proportionnel. Le débat ouvert par le co-fondateur force à se poser cette question à chaud, juste avant le basculement.
Ce qui reste à surveiller après le 21 octobre
La migration elle-même n’est que le début. Dans les jours et semaines qui suivront, plusieurs indicateurs mériteront une attention particulière. Le comportement réel de la finalité en conditions de charge. La capacité des nœuds RPC à propager correctement les certificats. La stabilité des validateurs pendant et après la fenêtre de transition. L’adaptation des explorateurs et des outils d’analytique.
Il faudra aussi observer si la suppression des votes on-chain modifie en quoi que ce soit les patterns d’utilisation. Une métrique plus propre peut révéler des tendances qui étaient auparavant masquées. Les développeurs d’applications décentralisées, de leur côté, devraient constater peu de changements directs, car l’interface utilisateur et les appels de programmes restent largement identiques.
Enfin, la remarque de Yakovenko pourrait influencer les futures décisions d’architecture. Si une voie plus simple avait pu livrer une part substantielle des bénéfices plus tôt, les prochains projets gagneront peut-être à privilégier des itérations plus légères. Ou, au contraire, l’expérience d’Alpenglow démontrera que la complexité était justifiée. Seuls les résultats de production le diront.
Une étape technique, un signal culturel
Alpenglow représente bien plus qu’un changement de mécanisme de consensus. C’est un moment où le réseau assume une refonte profonde de la façon dont les validateurs s’accordent, de la façon dont les frais sont prélevés, et de la façon dont les statistiques publiques sont calculées. La critique de Yakovenko ajoute une couche de transparence rare : même un co-fondateur peut dire à voix haute qu’une autre route aurait peut-être été plus rapide.
Cette transparence ne diminue pas la portée de la mise à jour. Elle la situe simplement dans un continuum d’améliorations successives, où chaque choix d’architecture est discutable et perfectible. Pour les utilisateurs finaux, l’expérience devrait rester fluide. Pour les opérateurs et les équipes techniques, la période qui s’ouvre exige vigilance et adaptation.
Le 21 octobre marquera donc à la fois une bascule technique et un test de maturité. Si la migration se déroule sans incident majeur, Solana aura démontré sa capacité à faire évoluer son cœur de consensus tout en maintenant la continuité du service. Si des frictions apparaissent, la franchise des discussions techniques devrait aider à les identifier et à les corriger rapidement.
En attendant, la phrase de Yakovenko restera dans les mémoires comme un rappel utile : dans la course à la performance, la simplicité reste parfois le chemin le plus court. Même quand on choisit finalement une route plus ambitieuse.
