L’upgrade Alpenglow de Solana, qui vise à réduire le temps de finalisation des transactions d’environ 12,8 secondes à près de 150 millisecondes, est désormais actif sur le devnet et le testnet publics. Anza a annoncé cette étape le 25 septembre 2026, un jour après la transition du testnet séparé, marquant un jalon technique important pour l’écosystème.
🔑 En bref
- Alpenglow actif sur le devnet et le testnet publics depuis le 25 septembre 2026
- Finalité ciblée : ~150 ms contre 12,8 s actuellement avec TowerBFT
- Protocole Votor : un seul tour de vote si 80 % des enjeux se prononcent
- Modèle de résilience « 20+20 » : 20 % d’adversaires + 20 % hors ligne tolérés
- Calendrier mainnet indicatif : feuille de route Solana vise octobre 2026
Comment Votor remplace TowerBFT
Le mécanisme TowerBFT actuel exige des validateurs qu’ils votent sur les blocs à travers 32 slots consécutifs (intervalles fixes de production de blocs) avant d’atteindre la finalité complète, un processus qui dure environ 12,8 secondes avec un slot de 400 millisecondes. Alpenglow introduit Votor, un nouveau protocole qui permet aux validateurs d’échanger leurs votes directement et de les agréger en certificats cryptographiques.
Dans des conditions favorables, Votor peut finaliser un bloc après un seul tour de vote. Si le seuil de 80 % des enjeux participants n’est pas atteint au premier tour, le protocole recourt à un second tour avec un seuil plus bas. C’est cette architecture qui produit l’objectif de 150 millisecondes, un chiffre dérivé de simulations plutôt qu’une garantie pour chaque bloc.
Le modèle de résilience « 20+20 » diffère des systèmes byzantins traditionnels au tiers. Il maintient le réseau fonctionnel même si jusqu’à 20 % des enjeux sont adverses et 20 % supplémentaires hors ligne. Les développeurs justifient ce compromis par une finalisation en un tour beaucoup plus rapide tout en préservant des garanties de sécurité solides.
Déploiement progressif et statut des clients
Anza, l’entreprise qui développe le logiciel principal de Solana, a recommandé Agave 4.3 à tous les validateurs du mainnet le 21 septembre 2026. La version avait d’abord été déployée auprès d’opérateurs représentant 10 %, puis 25 % des SOL utilisés pour sécuriser le réseau. Le calendrier logiciel mentionne de manière provisoire la date du 28 septembre pour la reprise des activations de fonctionnalités sur le réseau principal, sans confirmation qu’il s’agisse du lancement d’Alpenglow.
La feuille de route officielle cible Agave 4.3 et Alpenglow pour octobre 2026, sans date ferme. Le déploiement actuel concerne uniquement Votor ; Rotor, le système redesigné de distribution des blocs destiné à remplacer Turbine, est prévu pour une phase ultérieure.
Les clients alternatifs Firedancer et Frankendancer, développés par Jump Crypto pour renforcer la diversité logicielle, ne participent pas encore au test initial. La première migration fonctionnera donc entièrement via Agave, ce qui interroge sur la diversité des clients au moment même où elle représente un objectif de fiabilité à long terme.
Positionnement face à la concurrence
Une finalité de 150 millisecondes placerait Solana parmi les réseaux généralistes les plus rapides. À titre de comparaison :
| Blockchain | Finalité indicative | Type de réseau |
|---|---|---|
| Solana (Alpenglow) | ~150 ms (cible) | L1 généraliste |
| Sui | ~480 ms (tests) | L1 généraliste |
| Avalanche C-Chain | <1 s | L1 partagé |
| Avalanche L1 dédié | <100 ms | Sous-réseau |
| Ethereum | >12 s (slot) | L1 généraliste |
L’avantage distinctif de Solana réside dans la combinaison de cette finalité sub-seconde avec l’un des écosystèmes de smart contracts publics les plus établis, supportant déjà des DEX majeurs, des stablecoins, des memecoins et des applications de paiement.
Implications concrètes pour l’écosystème
La réduction du temps de finalité profite principalement aux systèmes qui ne peuvent pas se fier à une confirmation optimiste. Un exchange crypto recevant un dépôt peut créditer les fonds plus rapidement lorsqu’il sait que la transaction est définitive. Les ponts cross-chain, qui doivent s’assurer qu’un actif a été verrouillé ou brûlé sur un réseau avant d’en libérer sur un autre, bénéficient également de cette certitude accélérée. Les plateformes de trading institutionnel traitant des titres tokenisés, des stablecoins ou des garanties partagent ce même besoin de finalité.
« Les votes des validateurs ne seront plus enregistrés comme des transactions dans les blocs, ce qui réduira le nombre total de transactions rapportées, même si l’activité utilisateur reste inchangée. »
Solana Foundation, communication aux fournisseurs de données
Les fournisseurs de données et les services construisant des historiques de transactions doivent adapter leurs comparaisons et maintenir les blocs candidats rivaux séparés tant que le réseau n’en a pas choisi un, car mélanger leur contenu produirait un enregistrement incorrect. Les applications qui se contentent d’envoyer des transactions et de lire des soldes ne nécessitent pas de migration.
Alpenglow n’augmente pas directement la vitesse d’exécution des transactions ni le TPS (transactions par seconde). Le Solana Virtual Machine, les programmes, les transactions et le système de frais restent essentiellement inchangés. Seule la manière dont les validateurs s’accordent sur le caractère final d’un bloc évolue. Le traitement par les wallets et les contrôles de dépôt propres aux exchanges peuvent en outre ajouter un temps d’attente supplémentaire au-delà des 150 millisecondes théoriques.
Slots plus courts en complément
Solana réduit également les temps de slot de 400 millisecondes à 200 millisecondes via Agave 4.2, dans le cadre d’un déploiement gradualiste. Les temps de slot sur le mainnet ont déjà diminué vers 250 millisecondes, avec 200 ms comme objectif final. La combinaison de slots plus courts et d’une finalité nettement plus rapide rend le réseau globalement plus réactif, sans modifier la capacité de traitement brute.
Conclusion
Le passage d’Alpenglow sur le second testnet public marque une étape technique majeure pour Solana, mais son calendrier de mise en service sur le mainnet demeure flou. Trois scénarios se dessinent : un lancement réussi dès octobre 2026 selon la feuille de route, un décalage si les tests révèlent des instabilités, ou une migration phasée qui activerait Votor avant Rotor. Dans tous les cas, la diversité de clients reste un angle mort tant que Firedancer n’intègre pas le test, et les fournisseurs de données devront adapter leurs outils avant qu’une finalité sub-seconde ne devienne une réalité quotidienne.
Sources
Cet article est publié à titre informatif et éducatif. Il ne constitue en aucun cas un conseil en investissement. Faites vos propres recherches (DYOR) avant toute décision.
