Solana a fait progresser sa mise à niveau de consensus Alpenglow vers un déploiement sur le testnet public, alors que les développeurs se préparent à tester une conception destinée à réduire la finalité des transactions d’environ 13 secondes à près de 150 millisecondes.
Selon GitHub, l’étape du testnet permettra aux développeurs de tester la migration dans l’environnement de test établi de Solana avant que le système de consensus puisse être envisagé pour le réseau principal.
La finalité désigne le moment où une transaction devient irréversible selon les règles de consensus du réseau. Les exchanges attendent généralement la finalité avant de créditer les dépôts, tandis que les bridges blockchain l’utilisent avant de libérer des actifs sur un autre réseau.
Solana s’appuie actuellement sur TowerBFT pour le consensus, les validateurs enregistrant leurs votes on-chain et accumulant suffisamment de votes sur 32 slots avant qu’un bloc n’atteigne la finalité. Alpenglow remplace ce processus par un protocole appelé Votor, qui permet aux validateurs d’échanger directement leurs votes.
Dans cette nouvelle architecture, les validateurs peuvent parvenir à un accord après un ou deux tours de vote. Ce changement supprime la séquence plus longue de votes de consensus on-chain requise par TowerBFT, tout en laissant l’exécution des transactions largement inchangée pour les applications et les utilisateurs.
Alpenglow fonctionne déjà depuis plus de quatre mois sur un cluster communautaire plus restreint, créé spécifiquement pour tester le système de consensus. Le passage de la mise à niveau au testnet public établi de Solana l’expose à un groupe plus large de validateurs, de fournisseurs d’infrastructure et de services déjà connectés au réseau.
Le testnet public utilise des tokens sans valeur monétaire, ce qui permet aux développeurs de redémarrer le réseau, de tester les procédures de migration et d’enquêter sur les problèmes sans mettre en danger les fonds du mainnet.
Anza a d’abord déployé Alpenglow dans les tests communautaires de validateurs en mai, qualifiant cette mise à niveau de plus grand changement de consensus de l’histoire de Solana. Comme crypto.news l’avait précédemment rapporté, le cluster communautaire a permis aux opérateurs de validateurs de tester la nouvelle architecture de consensus avant son déploiement dans l’infrastructure de test existante de Solana.
Votor est conçu pour atteindre la finalité via l’un de deux chemins de vote, selon la participation des validateurs. Des spécifications antérieures indiquaient qu’un bloc pouvait être finalisé après un seul tour lorsqu’une quantité suffisante de stake participe, tandis qu’un second tour offre une autre voie vers la finalité en cas de participation plus faible.
Le résultat attendu est une forte réduction par rapport au temps de finalité actuel de Solana. Anza a estimé la finalité médiane à environ 150 millisecondes, des simulations antérieures la situant même à 100 millisecondes dans des conditions favorables.
Les développeurs n’ont pas modifié la manière dont les applications exécutent les transactions dans le cadre de cette mise à niveau. Les utilisateurs de wallets continueront à envoyer des transactions via les mêmes interfaces, tandis que les principaux changements concernent la façon dont les validateurs communiquent et s’accordent sur l’état permanent de la blockchain.
Les validateurs participant au test d’Alpenglow doivent exécuter Agave 4.3, la dernière branche du logiciel principal de validation maintenu par Anza.
Anza a recommandé Agave 4.3 pour une adoption générale parmi les validateurs du mainnet le 21 septembre. Le déploiement était auparavant passé par des étapes contrôlées, demandant d’abord aux opérateurs représentant 10 % du stake du mainnet d’effectuer la mise à niveau, avant d’étendre la recommandation à 25 %.
Le développement d’Alpenglow est lié depuis des mois aux versions d’Agave. En août, l’objectif de finalité à 150 millisecondes devait être atteint via Agave 4.3, après que le code sous-jacent d’Alpenglow eut déjà été inclus pour les tests dans la branche logicielle précédente.
La date du 28 septembre indiquée dans le calendrier d’Agave 4.3 d’Anza fait référence à la reprise provisoire de l’activation des fonctionnalités sur le mainnet. Anza précise que ses dates de publication sont susceptibles de changer, tandis que son feature gate tracker indiquait encore tôt mercredi que l’activation d’Alpenglow sur le testnet était en attente.
Le 28 septembre ne constitue donc pas une date confirmée pour le début du fonctionnement d’Alpenglow sur le mainnet de Solana.
Cette distinction intervient alors que plusieurs mises à niveau de performance de Solana suivent des calendriers d’activation distincts. La finalité des transactions, la production des slots et la capacité transactionnelle sont contrôlées par différents changements du réseau, même si chacun peut affecter la rapidité avec laquelle les applications interagissent avec Solana.
Solana a récemment réduit son temps de slot cible de 300 millisecondes à 250 millisecondes dans le cadre de SIMD-0525, portant le réseau à un objectif de quatre slots par seconde.
La mise à niveau vers des slots de 250 millisecondes a réduit la fenêtre de leadership de quatre slots de chaque validateur de 1,2 seconde à une seconde. Les limites de traitement du réseau ont été ajustées parallèlement au raccourcissement des slots, ce qui signifie que ce changement n’a pas augmenté la capacité globale de traitement dans la même proportion.
Une étape finale dans le cadre de SIMD-0525 vise des slots de 200 millisecondes, ce qui porterait le réseau à cinq slots cibles par seconde. Les développeurs n’ont pas fixé de date confirmée d’activation sur le mainnet pour cette étape.
Le temps de slot et la finalité mesurent des aspects différents du réseau. Le temps de slot détermine la fréquence à laquelle Solana peut produire de nouveaux slots, tandis qu’Alpenglow modifie la manière dont les validateurs parviennent à s’accorder sur le fait qu’un bloc est irréversible.
Solana a entamé la séquence actuelle de réduction des slots en août, lorsque son objectif est passé à 350 millisecondes contre 400 millisecondes depuis le lancement du réseau. SIMD-0525 a défini des objectifs successifs de 350, 300, 250 et, à terme, 200 millisecondes.
Alpenglow suit une trajectoire distincte via SIMD-0326 et remplace TowerBFT par Votor au lieu de modifier la durée des slots individuels.
Firedancer et Frankendancer, des clients validateurs développés par Jump Crypto, ne prennent actuellement pas en charge le test Alpenglow, laissant la migration initiale dépendre d’Agave.
La diversité des clients offre aux validateurs de Solana différentes implémentations logicielles pour participer au même réseau. Si plusieurs clients distincts sont disponibles, une défaillance logicielle affectant une implémentation n’affecte pas nécessairement tous les validateurs.
Firedancer a commencé à produire des blocs sur le mainnet plus tôt cette année après des années de développement par Jump Crypto. L’équipe a initialement recommandé un déploiement progressif pendant la poursuite des audits de sécurité, ce client développé indépendamment étant destiné à réduire la dépendance aux implémentations de validateurs existantes de Solana.
Frankendancer sert d’implémentation hybride combinant des composants de Firedancer avec le logiciel Solana existant. Aucune de ces deux implémentations n’est indiquée comme prenant en charge la fonctionnalité Alpenglow en attente sous SIMD-0326 dans le feature gate tracker actuel d’Anza.
Agave 4.3 est donc le client pris en charge pour la première migration sur le testnet public. Le tracker d’Anza répertorie Alpenglow comme une activation testnet en attente sous SIMD-0326, tandis que les champs de prise en charge pour Firedancer et Frankendancer restent indiqués comme indisponibles.
ETH
SOL
