Testnet Alpenglow de Solana : que change la finalité à 150 ms ?

SOL
finalité des transactionsmise à niveau du consensusAlpenglowTowerBFTtestnetSolanaVotor
il y a 1 heureSource: crypto.news
Testnet Alpenglow de Solana : que change la finalité à 150 ms ?

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 visant à réduire la finalité des transactions d'environ 13 secondes à environ 150 millisecondes.

Résumé

  • La mise à niveau Alpenglow de Solana passe au testnet public avec pour objectif de réduire la finalité des transactions d'environ 13 secondes à environ 150 millisecondes.
  • Alpenglow remplace TowerBFT par Votor, permettant aux validateurs de parvenir à un accord via un ou deux tours de vote directs.
  • Agave 4.3 est requis pour le test, tandis que Firedancer et Frankendancer ne prennent pas encore en charge Alpenglow.
  • Le 28 septembre est indiqué pour l'activation provisoire des fonctionnalités d'Agave 4.3 sur le mainnet, mais il ne s'agit pas d'une date de lancement confirmée d'Alpenglow.

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 ponts 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 onchain 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 des votes directement.

Selon la nouvelle conception, les validateurs peuvent parvenir à un accord après un ou deux tours de vote. Ce changement supprime la longue séquence de votes de consensus onchain requise sous TowerBFT, tout en laissant l'exécution des transactions largement inchangée pour les applications et les utilisateurs.

Solana Alpenglow passe au testnet public

Alpenglow a déjà passé plus de quatre mois à fonctionner sur un plus petit cluster communautaire 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 jetons sans valeur monétaire, permettant 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 fait passer Alpenglow aux tests de validateurs communautaires en mai, décrivant la mise à niveau comme le plus grand changement de consensus de l'histoire de Solana. Comme crypto.news l'a précédemment rapporté, le cluster communautaire a permis aux opérateurs de validateurs de tester la nouvelle conception de consensus avant son déploiement sur l'infrastructure de test existante de Solana.

Votor est conçu pour atteindre la finalité via l'un des deux chemins de vote selon la participation des validateurs. Les spécifications antérieures indiquaient qu'un bloc pouvait être réglé après un tour lorsque suffisamment de stake participait, tandis qu'un second tour offrait une autre voie vers la finalité en cas de participation plus faible.

Le résultat attendu est une forte réduction du temps de finalité actuel de Solana. Anza a estimé la finalité médiane à environ 150 millisecondes, avec des simulations antérieures la situant aussi bas que 100 millisecondes dans des conditions favorables.

Les développeurs n'ont pas modifié la façon dont les applications exécutent les transactions dans le cadre de la mise à niveau. Les utilisateurs de portefeuilles continueront d'envoyer des transactions via les mêmes interfaces, tandis que les principaux changements concernent la manière dont les validateurs communiquent et s'accordent sur l'état permanent de la blockchain.

Agave 4.3 porte le code d'Alpenglow

Les validateurs participant au test d'Alpenglow doivent exécuter Agave 4.3, la dernière branche du logiciel de validateur principal 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 avait auparavant progressé par étapes contrôlées, demandant d'abord aux opérateurs responsables de 10 % du stake du mainnet de mettre à niveau avant d'étendre la recommandation à 25 %.

Le développement d'Alpenglow est lié aux versions d'Agave depuis des mois. En août, l'objectif de finalité de 150 millisecondes était attendu via Agave 4.3 après que le code sous-jacent d'Alpenglow avait déjà été inclus pour les tests dans la branche logicielle précédente.

La date du 28 septembre indiquée dans le calendrier Agave 4.3 d’Anza fait référence à la reprise provisoire de l’activation des fonctionnalités du mainnet. Anza déclare que ses dates de publication sont susceptibles de changer, tandis que son outil de suivi des feature gates indiquait encore l’activation du testnet Alpenglow comme en attente mercredi matin.

Le 28 septembre ne représente donc pas une date confirmée pour le début de l’exploitation d’Alpenglow sur le mainnet Solana.

Cette distinction intervient alors que plusieurs améliorations de performance de Solana ont suivi des calendriers d’activation distincts. La finalité des transactions, la production de slots et la capacité de transactions sont contrôlées par différents changements de réseau, même si chacun peut affecter la rapidité avec laquelle les applications interagissent avec Solana.

Solana a déjà réduit les temps de slot à 250 ms

Solana a récemment réduit son temps de slot cible de 300 millisecondes à 250 millisecondes dans le cadre de SIMD-0525, amenant le réseau à un objectif de quatre slots par seconde.

La mise à niveau des slots à 250 millisecondes a réduit la fenêtre de quatre slots de leader de chaque validateur de 1,2 seconde à une seconde. Les limites de traitement du réseau ont été ajustées en même temps que les slots plus courts, ce qui signifie que le changement n’a pas augmenté la capacité de traitement globale dans la même proportion.

Une étape finale dans le cadre de SIMD-0525 vise des slots de 200 millisecondes, ce qui amènerait le réseau à cinq slots cibles par seconde. Les développeurs n’ont pas fixé de date d’activation confirmée sur le mainnet pour cette étape.

Le temps de slot et la finalité mesurent différentes parties 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 à un accord sur le caractère irréversible d’un bloc.

Solana a commencé la séquence actuelle de réductions de slots en août, lorsque sa cible est tombée à 350 millisecondes par rapport au réglage de 400 millisecondes utilisé depuis le lancement du réseau. SIMD-0525 a défini des cibles successives de 350, 300, 250 et finalement 200 millisecondes.

Alpenglow suit un chemin distinct via SIMD-0326 et remplace TowerBFT par Votor au lieu de modifier la durée des slots individuels.

Firedancer reste en dehors du premier test Alpenglow

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épendante d’Agave.

La diversité des clients donne aux validateurs Solana différentes implémentations logicielles pour participer au même réseau. Si des clients distincts sont disponibles, un défaut logiciel 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 que les audits de sécurité se poursuivaient, le client construit indépendamment étant destiné à réduire la dépendance aux implémentations de validateurs existantes de Solana.

Frankendancer sert d’implémentation hybride qui combine des composants de Firedancer avec le logiciel Solana existant. Aucune des deux implémentations n’est répertoriée comme prenant en charge la fonctionnalité Alpenglow SIMD-0326 en attente sur l’outil de suivi actuel des feature gates d’Anza.

Agave 4.3 est donc le client pris en charge pour la première migration publique vers le testnet. L’outil de suivi d’Anza répertorie Alpenglow comme une activation de testnet en attente sous SIMD-0326, tandis que les champs de prise en charge pour Firedancer et Frankendancer restent marqués comme indisponibles.