La mise à niveau Alpenglow de Solana a atteint son réseau public de développeurs, permettant aux équipes d'applications de tester un système conçu pour réduire la finalité des transactions d'environ 12,8 secondes à environ 150 millisecondes.
Résumé
- Alpenglow est actif sur le devnet et le testnet de Solana, tandis que le mainnet utilise encore le système de consensus actuel.
- La mise à niveau remplace les transactions de vote des validateurs onchain par des votes directs qui peuvent finaliser un bloc en une ou deux tours.
- Les applications qui envoient uniquement des transactions et lisent les soldes n'ont besoin d'aucune migration, mais les services de données de blocs doivent mettre à jour leurs systèmes.
- Anza n'a annoncé aucune date ferme pour l'activation d'Alpenglow sur le mainnet.
Selon la page de mise à niveau de la Solana Foundation, Alpenglow est désormais actif sur le devnet et le testnet mais n'a pas été activé sur le mainnet. Anza, qui développe le logiciel de validateur principal de Solana, a annoncé le passage au devnet le 25 septembre, un jour après que le testnet a achevé sa transition.
Les deux réseaux servent différentes parties du déploiement. Les équipes d'applications peuvent utiliser le devnet pour vérifier le comportement de leur logiciel avec des jetons sans valeur réelle, tandis que le testnet offre aux validateurs et aux opérateurs d'infrastructure un espace pour tester le logiciel réseau dans des conditions plus exigeantes.
Pour les développeurs, la nouvelle étape du devnet signifie qu'ils peuvent tester les applications avec Alpenglow sans attendre que le système atteigne la blockchain qui gère les fonds des utilisateurs. Le mainnet de Solana continue d'utiliser TowerBFT, de sorte que le chiffre de 150 millisecondes reste un objectif pour la mise à niveau prévue plutôt qu'un temps de finalité disponible pour les utilisateurs aujourd'hui.
Alpenglow de Solana change la façon dont les validateurs finalisent les blocs
Sous TowerBFT, les validateurs soumettent des votes sous forme de transactions qui apparaissent dans les blocs. Un nombre suffisant de votes doit s'accumuler sur 32 slots avant qu'un bloc ne devienne final, ce qui prend actuellement environ 12,8 secondes, selon la Foundation.
La première phase d'Alpenglow, appelée Votor, fait plutôt envoyer les votes directement entre validateurs. La Foundation indique qu'un bloc peut atteindre la finalité après un tour de vote si les validateurs représentant au moins 80 % de l'enjeu votent pour l'accepter. Un second tour offre une autre voie lorsque le premier n'atteint pas ce seuil.
La finalité est le point auquel le réseau s'est suffisamment mis d'accord sur une transaction pour qu'elle ne puisse plus être annulée selon ses règles de consensus. Un résultat plus rapide pourrait compter pour une bourse américaine décidant quand créditer un dépôt Solana ou pour un fournisseur de paiement décidant quand considérer la vente d'un marchand comme terminée. Chaque service peut encore appliquer ses propres vérifications avant de libérer des fonds ou de confirmer un paiement à un client.
La Foundation distingue la finalité du temps nécessaire pour produire un bloc. En septembre, Solana a réduit son temps de slot cible de 300 millisecondes à 250 millisecondes, avec une réduction supplémentaire à 200 millisecondes prévue dans le cadre d'une mise à niveau distincte. Des slots plus courts changent la fréquence à laquelle le réseau peut les produire ; Alpenglow change la façon dont les validateurs s'accordent sur le fait qu'un bloc est final.
Un précédent rapport de crypto.news couvrait les préparatifs du testnet le 23 septembre, lorsque les développeurs préparaient Agave 4.3 pour le test public. Le passage au devnet donne désormais aux équipes d'applications accès au système de consensus mis à niveau dans le réseau qu'elles utilisent couramment pour le développement.
Les services de données de blocs font face à des changements avant le mainnet
Pour une application qui envoie des transactions et lit les soldes des comptes, la Foundation indique qu'Alpenglow ne nécessite aucune migration. L'exécution des transactions, les frais et les formats utilisés pour envoyer des transactions restent les mêmes sous la mise à niveau du consensus.
Les services qui construisent des historiques de transactions ont plus de travail à faire. Alpenglow peut exposer des blocs candidats concurrents pour le même slot avant que le réseau n'en sélectionne un. La Foundation demande aux fournisseurs de données de garder ces candidats séparés, puis de conserver le bloc qui atteint la confirmation. Combiner des transactions de différents candidats pourrait laisser un explorateur ou un autre service avec un enregistrement incorrect.
Les votes des validateurs disparaîtront également des blocs car ils ne seront plus soumis comme transactions. Par conséquent, un graphique qui compte à la fois les transactions des utilisateurs et les votes des validateurs affichera un total de transactions plus faible après l'activation, même si les utilisateurs effectuent le même nombre de paiements et d'échanges. La Foundation a demandé aux fournisseurs de données de réinitialiser les comparaisons et les alertes construites sur les anciens chiffres.
Certains services lisent également la participation des validateurs à partir des transactions de vote. Avec Alpenglow, la Fondation indique que ces informations sont transférées vers des certificats attachés aux données de bloc, ce qui oblige ces services à modifier l'endroit où ils les obtiennent. Les opérateurs utilisant les flux de données Geyser ou gRPC de Solana doivent également tenir compte des identifiants qui distinguent les blocs candidats au sein d'un slot.
Ces changements rendent les tests sur le devnet pertinents pour les exchanges, les explorateurs et d'autres entreprises qui dépendent des enregistrements de transactions, y compris les services américains connectés à Solana. Leurs règles de dépôt restent leur propre décision opérationnelle ; la mise à niveau du réseau ne modifie pas automatiquement le moment où une plateforme rend les fonds disponibles.
L'activation sur le mainnet n'a toujours pas de date ferme
La feuille de route antérieure d'Alpenglow sur Solana liait le déploiement proposé sur le mainnet à Agave 4.3 et à un objectif en octobre. Ni la transition vers le testnet ni l'activation sur le devnet ne fixent de date confirmée pour le basculement vers le réseau réel.
Le calendrier logiciel d'Anza permet provisoirement la reprise des activations de fonctionnalités sur le mainnet le 28 septembre. Le calendrier n'identifie pas ce jour comme la date d'activation d'Alpenglow, et la page de statut de la Fondation répertorie toujours la mise à niveau comme inactive sur le mainnet.
La Fondation décrit Votor comme la première phase d'Alpenglow. Une phase ultérieure, Rotor, est prévue pour remplacer le système utilisé pour diffuser les blocs à travers le réseau. Le déploiement actuel concerne les changements de vote et de finalité, tandis que l'objectif d'environ 150 millisecondes provient de tests et de simulations plutôt que de transactions réglées dans des conditions de marché réelles.
