La transition de Solana vers Alpenglow, prévue le 21 octobre 2026, s’accompagne d’une remarque critique de son cofondateur Anatoly Yakovenko sur la complexité du développement. Selon lui, une modification du programme de vote aurait permis de livrer Alpenglow environ deux fois plus rapidement. Cette déclaration intervient alors que le réseau prépare le remplacement de son mécanisme de consensus et la disparition des transactions de vote des validateurs dans les blocs. Le changement aura des conséquences visibles sur les statistiques de transactions, les frais de participation des validateurs et la manière dont certains services techniques récupèrent les informations de finalité.
Yakovenko remet en question le temps consacré au développement
Dans une publication sur X datée du 21 octobre, Yakovenko a commenté un message saluant la suppression programmée des votes inscrits sur la chaîne. Le message faisait également référence aux critiques récurrentes selon lesquelles une grande partie des transactions par seconde affichées par Solana correspond aux votes des validateurs. Le cofondateur a estimé qu’un simple changement du programme de vote vers la machine à états « ag » aurait permis de réduire de moitié le délai de livraison. Cette appréciation porte sur la méthode de développement, sans remettre en cause, dans les informations rapportées, la date pour la migration.
Alpenglow remplace TowerBFT, le système utilisé jusqu’ici par les validateurs pour s’accorder sur les blocs. La conception publiée par Anza prévoit des votes directs et des certificats compacts, plutôt que le maintien du fonctionnement antérieur. La Solana Foundation situe le déclenchement de la migration à l’époque 1064, dont le début était estimé vers 13 h 20 UTC le 21 octobre. Sa documentation distingue toutefois l’activation de fonctionnalités du basculement effectif du consensus. Celui-ci intervient 5 000 slots plus tard, à une frontière de migration durant laquelle les blocs transportent temporairement uniquement des votes pendant la transition des validateurs.
La disparition des votes modifiera les indicateurs TPS
L’un des changements les plus visibles concerne les chiffres de transactions par seconde, souvent désignés par l’acronyme TPS. Les votes des validateurs ne seront plus enregistrés comme transactions dans les blocs, ce qui réduira mécaniquement les totaux qui les comptabilisaient. Cette baisse statistique ne signifie pas nécessairement que les paiements, les échanges ou les autres opérations réalisées par les utilisateurs auront diminué. La Solana Foundation demande donc aux explorateurs et aux plateformes d’analyse de recalibrer leurs références de volumes et de TPS afin de ne pas interpréter incorrectement la rupture entre les séries anciennes et nouvelles.
La comparaison des volumes avant et après la migration exige donc de séparer les opérations des utilisateurs des messages de consensus. Une série historique additionnant ces catégories ne peut être prolongée directement avec des données excluant les votes. Le changement touche la présentation des mesures, pas seulement leur collecte.
Les services qui suivent la participation des validateurs devront également adapter leurs sources de données. Au lieu de lire les instructions du programme Vote, ils devront exploiter les certificats placés dans les pieds de bloc. La Foundation précise que le message de pied de bloc transmis par Yellowstone gRPC ne relaie pas encore ces certificats. Les développeurs disposaient déjà d’un environnement pour observer ces changements lorsque Alpenglow est arrivé sur devnet en septembre, après son passage sur testnet. Les explorateurs doivent notamment conserver séparément les blocs candidats concurrents jusqu’à confirmation, puis retenir le bloc sélectionné sans fusionner artificiellement leurs transactions.
La documentation d’Anza décrit une notification facultative de pied de bloc disponible dans Agave 4.3. Les services ayant besoin de ces métadonnées doivent l’activer et prévoir leur traitement. L’ordre des notifications de pied de bloc reste cohérent avec celui des notifications d’entrées. Parallèlement, l’horloge de la chaîne conserve son format et sa précision à la seconde entière. Lors de l’exécution d’une transaction, son horodatage estime la fin du bloc parent ; les opérateurs sont donc invités à continuer de considérer cette valeur comme approximative, plutôt que comme une mesure temporelle exacte.
Des frais de vote remplacés par une contribution par époque
La migration transforme également les coûts liés au vote des validateurs. Avec la suppression des votes inscrits sur la chaîne, les frais facturés pour chaque transaction de vote disparaissent. Ils sont remplacés par une contribution forfaitaire de 0,8 SOL par époque, entièrement détruite, selon la documentation de la Solana Foundation. Cette somme est prélevée sur le compte de vote, qui remplace ainsi le compte d’identité comme source des paiements liés à la participation au consensus. Les opérateurs doivent conserver suffisamment de fonds pour régler la contribution tout en respectant le minimum nécessaire à l’exemption de loyer du compte.
Le paiement est effectué une époque à l’avance. Ainsi, la première contribution prélevée au début de l’époque 1064 finance l’admission à l’époque 1065. Un validateur incapable de payer perd l’autorisation de voter ou de produire des blocs pendant l’époque suivante. Plusieurs préparatifs avaient été engagés avant le basculement : l’enregistrement des clés publiques BLS était disponible sur le réseau principal depuis le 8 juillet, tandis que la fonctionnalité d’admission avait été activée le 22 juillet. Ces étapes préalables ne constituaient pas, à elles seules, l’activation du consensus Alpenglow.
Pour participer à la migration, la liste de vérification de la Foundation impose la version 4.3.2 d’Agave, de Jito-Solana ou de Harmonic Salsa. Les instructions destinées aux opérateurs indiquent que Firedancer et Frankendancer ne sont pas pris en charge pendant ce basculement. Il s’agit de conditions techniques propres à la période de transition, distinctes des règles de facturation par époque. Les validateurs doivent donc examiner à la fois leur version logicielle, la disponibilité des fonds sur le compte de vote et le calendrier de changement de consensus pour comprendre les exigences publiées.
Votor introduit deux voies de finalisation parallèles
Dans l’architecture présentée par Anza, le composant Votor exécute deux voies de vote simultanément. La première permet de finaliser un bloc en un seul tour lorsque les réponses représentent 80 % des participations pondérées. La seconde repose sur deux tours, avec des seuils de 60 %. Les votes prennent la forme de messages directs signés au moyen de la cryptographie BLS. Plusieurs signatures peuvent ensuite être regroupées dans un certificat compact. Anza explique également que les validateurs utilisent leurs propres minuteries pour détecter un leader qui ne répond pas et voter afin de le passer.
La proposition SIMD-0326 expose les architectures envisagées pendant la conception. Une option dépourvue de finalité en un seul tour aurait offert un fonctionnement plus simple et une tolérance de 33 % aux fautes byzantines. Ses auteurs lui attribuaient toutefois une latence moins favorable et une résistance inférieure aux pannes. Une autre solution, fondée sur un graphe orienté acyclique, présentait des économies potentielles de bande passante, mais soulevait des difficultés de latence et d’utilisation complète de cette bande passante. Ces comparaisons éclairent les arbitrages documentés, sans établir qu’une solution écartée aurait nécessairement donné de meilleurs résultats en production.
La proposition limite à 2 000 le nombre de validateurs admis, en privilégiant ceux qui disposent des participations les plus élevées. Selon les auteurs, cette limite aide à conserver des certificats suffisamment petits pour tenir dans un seul message UDP. Les enregistrements de participation servent également à attribuer des récompenses aux validateurs qui votent effectivement. L’implémentation a été précédée d’un vote de gouvernance : en septembre 2025, la proposition Alpenglow a obtenu 98,27 % de soutien parmi les suffrages exprimés, tandis que la participation représentait 52 % du total des mises.
La finalité visée en 150 millisecondes ne sera pas uniforme
Alpenglow affiche un objectif de finalité d’environ 150 millisecondes, mais Anza souligne que tous les nœuds ne recevront pas nécessairement cette information aussi vite. Les nœuds RPC situés hors de l’ensemble des validateurs admis peuvent apprendre qu’un bloc est finalisé avec un délai supplémentaire. Dans le parcours par défaut, ils obtiennent les certificats lorsqu’ils apparaissent dans un bloc ultérieur. Ce fonctionnement peut ajouter jusqu’à un intervalle de production de bloc, voire davantage lorsque des blocs sont retardés ou sautés. La rapidité du consensus doit donc être distinguée du moment où un service extérieur reçoit sa confirmation.
Cette distinction a des conséquences pour les outils qui affichent un statut de confirmation aux applications. Deux services peuvent suivre le même consensus tout en recevant les certificats à des moments différents, selon leur connexion aux validateurs admis. Les indications de performance doivent donc préciser si elles concernent la finalisation du protocole ou la réception effective de cette information.
Un validateur admis peut transmettre directement ses messages de consensus à un nœud partenaire. Dans ce cas, la latence du réseau entre les deux partenaires constitue le principal délai supplémentaire décrit par Anza. Si tous les partenaires configurés deviennent inaccessibles, le destinataire revient au mécanisme ordinaire et attend les certificats présents dans les pieds des blocs suivants. Les développeurs de services RPC doivent ainsi tenir compte de leur mode de réception des informations, plutôt que d’appliquer automatiquement l’objectif de 150 millisecondes à chaque interface.
Une migration qui change les mesures et les procédures
Les informations publiées sur Alpenglow décrivent simultanément un nouveau mécanisme de consensus, une modification des frais des validateurs et une évolution des données accessibles aux services d’observation. La suppression des transactions de vote pourra faire baisser les TPS affichés sans baisse correspondante de l’activité des utilisateurs. Les certificats remplaceront certaines données auparavant obtenues dans les transactions, tandis que les opérateurs devront gérer une contribution de 0,8 SOL par époque. Enfin, la finalité rapide visée par le protocole n’exclut pas des délais supplémentaires pour certains nœuds RPC. Ces différences seront essentielles pour interpréter les mesures après le basculement annoncé.
