Les développeurs de Solana ont programmé la mise à niveau de consensus Alpenglow pour le 21 octobre, visant une finalité d'environ 150 millisecondes tout en demandant aux validateurs et aux opérateurs d'applications de se préparer aux changements lors du passage sur le mainnet.
Résumé
- La mise à niveau Alpenglow de Solana est prévue pour le 21 octobre, visant une finalité des transactions d'environ 150 millisecondes.
- Quicknode avertit d'une brève pause des transactions et de possibles interruptions des flux de données pendant le passage.
- Les validateurs doivent utiliser un logiciel compatible et alimenter les comptes de vote pour les frais d'admission de 0,8 SOL.
- Certains nœuds RPC peuvent recevoir les informations de finalité plus tard que les validateurs participant directement au consensus.
L'avis de maintenance de Quicknode identifie mercredi comme jour d'activation prévu, mais sa dernière mise à jour avertit que l'estimation initiale de 14h50 UTC pourrait être avancée à 13h20 UTC à mesure que la production de blocs progresse. Le fournisseur demande aux opérateurs d'être prêts à partir de 13h00 UTC, le passage de consensus suivant l'activation d'environ 20 minutes.
La page actuelle de mise à niveau de la Solana Foundation situe le changement à l'époque 1064 et indique le mainnet comme pas encore activé. Son estimation mise à jour place le début de l'époque près de 13h20 UTC, faisant de la frontière d'époque le déclencheur pertinent plutôt qu'un rendez-vous fixe à l'horloge murale.
Solana Alpenglow vise la finalité, pas une exécution plus rapide
Selon la conception d'Anza, Votor remplace la logique de vote et de finalité de TowerBFT. La cible est d'environ 150 millisecondes dans des conditions réseau normales, et non une garantie que chaque portefeuille, exchange ou application de trading affichera une transaction terminée dans ce délai.
La Fondation indique que l'exécution des transactions, le comportement des programmes et les mécanismes de frais restent inchangés. Les utilisateurs ordinaires n'ont pas besoin de modifier leur façon de signer ou d'approuver les transactions, tandis que la mise à niveau distincte de distribution de données Rotor est réservée à une version ultérieure. Sa documentation sépare le déploiement du consensus des réductions antérieures de la durée des slots, qui régissent la fréquence à laquelle le réseau produit des blocs.
L'aperçu technique de Quicknode décrit deux voies de vote fonctionnant simultanément. L'une peut finaliser un bloc en un seul tour lorsque 80 % des validateurs participent, tandis que l'autre utilise un second tour lorsque la participation atteint 60 %.
Le fournisseur distingue ce processus des confirmations précoces que les utilisateurs voient déjà. Son aperçu indique que les applications affichent couramment des confirmations en deux à trois secondes avec des paramètres optimistes, avant que l'ancien système n'atteigne la pleine finalité autour de 13 secondes.
Le déploiement d'octobre fait suite à une feuille de route antérieure qui liait Alpenglow à Agave 4.3. Un rapport du 14 août documentait que le code d'Alpenglow était présent dans Agave 4.2 pour les tests, sans autoriser l'activation sur le mainnet dans cette version.
Au 26 septembre, la mise à niveau avait atteint le devnet après la transition du testnet la veille, comme précédemment couvert par crypto.news. Les équipes d'applications pouvaient alors vérifier le nouveau comportement de consensus avant de déployer sur le réseau gérant les fonds des utilisateurs.
Les traders font face à une brève interruption pendant le passage
Quicknode avertit que les nouvelles transactions cesseront brièvement d'entrer dans les blocs pendant que le réseau change de systèmes de consensus. Son avis décrit une pause de quelques secondes, avec une interruption plus longue possible si la transition prend plus de temps.
Les soumissions de transactions peuvent temporairement renvoyer une erreur de prévol « node unhealthy », indique le fournisseur. Les flux de données Yellowstone peuvent se déconnecter une fois, tandis que les abonnements utilisant l'engagement traité le plus précoce peuvent afficher des slots qui n'atteignent jamais la confirmation.
L'avis de maintenance recommande un engagement confirmé ou finalisé pour les données qui ne doivent pas être annulées. Quicknode indique que ses points de terminaison Solana existants resteront en place et que son équipe surveillera le réseau tout au long du changement.
Dans l'aperçu technique du fournisseur, un règlement irréversible plus rapide est pertinent pour les applications financières, les transferts de trésorerie d'entreprise et les services en temps réel. Le document présente ces usages comme des capacités de l'architecture de consensus proposée, sans établir que les plateformes de trading individuelles adopteront de nouvelles politiques de règlement le jour de l'activation.
La préparation des validateurs comprend les logiciels et le financement des comptes
La liste de contrôle actuelle de la Solana Foundation demande aux validateurs d'exécuter la version 4.3.2 d'Agave, Jito-Solana ou Harmonic Salsa avant l'epoch 1064. Firedancer et Frankendancer ne sont pas pris en charge pendant la migration, selon les mêmes directives.
Les opérateurs doivent maintenir au moins 0,8 SOL au-dessus du minimum exonéré de loyer dans leurs comptes de vote pour couvrir le Validator Admission Ticket. Le premier prélèvement paie la participation à l'epoch 1065, et des frais impayés empêchent un validateur de voter ou de produire des blocs lors de l'epoch suivante.
L'approbation de la gouvernance précède ces exigences opérationnelles. La proposition a été adoptée en septembre 2025 avec 98,27 % des votes en sa faveur, selon la couverture du scrutin achevé. La participation représentait 52 % de l'enjeu, de sorte que le pourcentage d'approbation décrit les votes exprimés plutôt que l'ensemble de la population des validateurs.
Ce vote antérieur a approuvé le SIMD-0326, la proposition à l'origine de la refonte du consensus. Le rapport de l'époque enregistrait 1,05 % contre et 0,69 % d'abstention, la petite différence d'arrondi étant conservée dans les chiffres publiés.
La livraison RPC peut être en retard sur l'objectif de 150 ms
La documentation destinée aux opérateurs d'Anza explique que les messages de consensus circulent normalement entre les validateurs admis. Un nœud non staké utilisant le chemin de livraison par défaut apprend la finalité à partir des certificats transportés dans les blocs ultérieurs, ce qui ajoute généralement jusqu'à un intervalle de bloc produit.
Des blocs sautés ou retardés peuvent allonger cette attente. Un nœud associé à un validateur admis peut recevoir les messages directement, bien que la latence réseau entre les deux fasse toujours partie du temps de livraison.
La couverture du devnet de septembre documentait des changements distincts pour les indexeurs et les explorateurs. Les blocs candidats doivent rester séparés jusqu'à la confirmation, et les données de participation des validateurs s'éloignent des transactions de vote ordinaires au profit de certificats attachés aux données des blocs.
Selon ce rapport, la suppression des transactions de vote modifie les totaux des tableaux de bord même lorsque le nombre de paiements et de transactions des utilisateurs reste constant. Les services comptant les deux catégories doivent réinitialiser leurs comparaisons, tandis que les systèmes suivant les votes des validateurs doivent lire les données de certificat de remplacement.
