Alpenglow, la refonte du consensus de Solana, progresse sur les réseaux de test, mais le réseau principal utilise toujours son consensus actuel. Le changement proposé modifierait la manière dont les validateurs déterminent qu’un bloc est final. Son objectif de finalité à 150 millisecondes reste une cible conditionnelle, et non une garantie de délai pour chaque paiement utilisateur.
Le suivi des fonctionnalités d’Anza classe toujours SIMD-0326, Alpenglow, parmi les activations en attente sur le mainnet. Il indique des positions d’activation sur testnet et devnet et associe Agave 4.3.0 à la fonctionnalité. Dans le même relevé, la version minimale du mainnet était 4.2.2, tandis que 4.3.0 apparaissait comme prochain minimum attendu. Une version logicielle prévue et l’activation effective d’un nouveau consensus constituent cependant deux étapes différentes.
Le 28 septembre ne constituait pas une date de lancement
Une entrée du calendrier indiquait que les activations de fonctionnalités sur le mainnet reprendraient le 28 septembre. Elle n’annonçait pas qu’Alpenglow serait activé ce jour-là. Le suivi d’Anza continue de présenter la fonctionnalité comme en attente. Une correction publiée le 29 septembre a retracé cette confusion et indiqué qu’Anza avait rejeté la date de lancement qui circulait.
Cette distinction est importante pour les validateurs et les utilisateurs. Un opérateur peut installer une version contenant du code encore inactif sans que la fonctionnalité correspondante soit appliquée au réseau. Le minimum de version peut également évoluer après l’atteinte d’un seuil de participation et le passage d’époques, tandis qu’une porte d’activation séparée déclenche ensuite le nouveau comportement.
Votor change le consensus tandis que Turbine reste en place
SIMD-0326 organise la première transition principalement autour de Votor, le nouveau mécanisme de consensus. Rotor, qui doit remplacer le système de diffusion des données, est réservé à une modification distincte. Dans un premier temps, Solana conserverait donc Turbine pour la propagation des données.
Cette séparation permet de distinguer plusieurs fonctions. Le consensus détermine quand suffisamment de validateurs se sont accordés sur un bloc pour qu’il soit considéré comme final. La propagation concerne la manière dont ce bloc atteint les validateurs. L’exécution détermine si une transaction s’est correctement déroulée, tandis qu’une application attend également que son fournisseur RPC transmette le résultat.
L’objectif de 150 millisecondes doit ainsi être compris comme une cible de finalité au niveau du consensus dans des conditions favorables. Il ne représente pas le temps total entre l’action d’un utilisateur et le résultat visible. Un portefeuille doit signer et envoyer la transaction, celle-ci doit atteindre un leader, être incluse et exécutée, puis son résultat doit revenir par un service RPC.
Une mesure unique pourrait masquer l’expérience réelle
Une évaluation utile devrait séparer la finalité du protocole et le parcours complet d’une transaction. La première mesure partirait de la proposition d’un bloc jusqu’à la formation d’un certificat de finalisation. La seconde couvrirait la soumission, l’exécution, l’inclusion, la finalité et la réponse RPC reçue par l’utilisateur.
L’exemple fourni illustre cette différence. Si la finalisation prend 150 millisecondes après la proposition, mais que l’inclusion attend un créneau de 350 millisecondes et que la réponse RPC ajoute 100 millisecondes, l’utilisateur observe au moins 600 millisecondes avant même d’ajouter la signature ou d’éventuelles nouvelles tentatives. Ces valeurs sont hypothétiques et ne constituent pas des mesures d’Alpenglow en production.
Les médianes peuvent aussi masquer les situations les plus difficiles. Une mauvaise route réseau, une partition temporaire, un vote manquant ou une charge de replay importante peuvent produire des délais plus longs. Des résultats crédibles devraient donc inclure les percentiles, le comportement de récupération et les conséquences des défaillances de leaders.
Les validateurs doivent tester les scénarios de défaillance
Un réseau candidat au mainnet doit fonctionner lorsque des validateurs arrivent tardivement, lorsque les messages sont retardés entre régions, lors de redémarrages logiciels, de défaillances de leaders ou de visions contradictoires de la chaîne. Le plan de migration Alpenglow traite également le passage de l’ancien état de vote vers le nouveau.
Le mélange de clients constitue aussi un élément du test. Dans l’instantané observé, le suivi d’Anza indiquait Firedancer et Frankendancer comme non pris en charge pour Alpenglow. Ce statut concerne un calendrier précis et ne constitue pas une affirmation permanente sur ces clients. Une migration en production devra néanmoins tenir compte du stake utilisant chaque implémentation.
Le chemin rapide ne représente pas toutes les conditions
SIMD-0326 prévoit une finalisation rapide lorsque des validateurs représentant 80 % du stake notarient un bloc en un seul tour. Une voie plus lente utilise deux tours impliquant 60 % du stake et des certificats de notarisation et de finalisation. Si un leader ne fournit pas de bloc valide à temps, les validateurs peuvent voter pour ignorer le créneau concerné.
Mesurer uniquement la voie rapide à 80 % laisserait donc de côté les circonstances où les mécanismes de repli deviennent importants. Une évaluation pratique devrait comptabiliser la part des créneaux finalisés rapidement, celle utilisant le chemin plus lent et celle qui est ignorée, puis publier séparément les médianes et les 95e et 99e percentiles.
Le modèle de sécurité décrit également une approche « 20 plus 20 », capable de tolérer une part adversariale et une part distincte de stake qui ne répond pas sous les hypothèses indiquées. Les auteurs précisent qu’un vote en un tour n’offre pas le même seuil byzantin de 33 % qu’un modèle à deux tours. Cette différence accompagne directement la recherche d’une finalité plus rapide.
La migration nécessite un point de départ commun
Le passage au nouveau consensus impose aux validateurs de s’accorder sur le dernier bloc de l’ancien système qui deviendra le parent du premier bloc Alpenglow. Le document de migration appelle ce point commun le bloc de genèse Alpenglow. Sans accord sur celui-ci, les certificats ultérieurs pourraient se référer à des historiques incompatibles.
Le transfert proposé commence après un créneau d’activation, mais la limite utilisée pour la migration se situe 5 000 créneaux plus tard afin d’éviter le début d’une époque. Le processus attend ensuite un bloc répondant à une condition forte de confirmation optimiste, avec des votes représentant au moins 82 % du stake selon la structure prévue.
Les validateurs signent alors un vote de genèse pour un bloc ancêtre commun. Un certificat de genèse à 82 % leur fournit la preuve nécessaire pour basculer. Ces seuils appartiennent à la migration et sont distincts des 80 % utilisés par la voie rapide de Votor après le changement.
Le coût des validateurs fait partie du test
Alpenglow comporte également une dimension économique. Dans le système actuel, les opérateurs envoient des transactions de vote et paient les frais correspondants. SIMD-0326 propose à la place un ticket d’admission des validateurs, ou VAT.
Le document donne une estimation initiale d’environ 0,8 SOL par jour, soit 1,6 SOL par époque, et prévoit que l’intégralité du paiement soit brûlée. Ce chiffre constitue un paramètre initial de la proposition, pas une facture déjà appliquée à tous les validateurs.
Un coût fixe peut peser différemment sur les petits opérateurs disposant de peu de stake délégué. L’évaluation devrait donc comparer les frais de vote avant la transition avec le VAT et les coûts opérationnels après celle-ci, tout en suivant le nombre d’opérateurs actifs, la distribution du stake et la diversité géographique.
Une transaction finale peut rester invisible pour un service
Un dépôt sur une plateforme illustre l’écart entre finalité et expérience utilisateur. La transaction est d’abord signée et soumise, atteint un leader, entre dans un bloc, puis les validateurs votent jusqu’à la formation du certificat. Un service RPC observe ensuite ce certificat avant que le système de dépôt applique ses propres contrôles et crédite le compte.
Le changement de consensus réduit principalement une partie de cette séquence. Une plateforme peut volontairement attendre davantage, comparer plusieurs fournisseurs RPC ou retarder un crédit pendant un incident. À l’inverse, une application peut afficher rapidement un succès après avoir vu un bloc, avant que le certificat de finalisation le plus fort soit disponible.
La finalité ne garantit pas non plus qu’une transaction produise le résultat économique souhaité. Une opération peut échouer selon les règles d’une application, payer des frais ou être exécutée à un prix inattendu dans les paramètres soumis. Le consensus garantit la décision du registre, pas la sécurité d’un smart contract ou l’exactitude d’un oracle.
Le mainnet exige encore plusieurs étapes distinctes
La préparation du mainnet comporte plusieurs portes. Il faut d’abord une adoption logicielle suffisante par le stake, puis une vérification du protocole sur testnet et devnet dans des conditions normales et défavorables. Les plateformes, fournisseurs RPC, explorateurs et portefeuilles doivent ensuite savoir interpréter le nouveau signal de finalité avant l’activation programmée.
Le suivi d’Anza indique qu’un minimum de version mainnet peut augmenter après l’adoption d’une nouvelle version mineure par 95 % du stake et le passage de deux époques complètes. Cette règle concerne la version minimale prise en charge. Elle ne signifie pas qu’Alpenglow s’active automatiquement lorsque le seuil de 95 % est atteint.
Les éléments publics manquent encore d’un plan final d’activation daté et d’une série comparable de mesures de finalité sous différentes charges. Les résultats devraient préciser les versions logicielles, le stake participant, les types de clients, les conditions de messages, l’inclusion des transactions et les latences par percentile.
La preuve la plus déterminante viendra après le basculement, avec des observations répétées sur le mainnet de la finalité et du règlement visible dans les applications, accompagnées de données sur les éventuels événements de récupération. Pour l’instant, les tests montrent qu’Alpenglow est effectivement exercé sur les réseaux prévus. Ils ne démontrent pas encore que chaque utilisateur bénéficiera d’un règlement en 150 millisecondes.
