Solana Alpenglow expliqué : Votor, Rotor et l’objectif des 150 ms

Dans l’écosystème Solana, Alpenglow est souvent résumé à son chiffre le plus spectaculaire : 150 ms de finalité. Mais le sujet n’est pas un simple correctif de performance. Formalisé dans la proposition SIMD-0326, Alpenglow est une réécriture de la couche de consensus qui remplacerait Proof of History et Tower BFT par une architecture centrée sur Votor pour les votes et la finalisation, et Rotor pour la diffusion des données de blocs .

La cible affichée est de faire passer la finalité de 12,8 secondes sous Tower BFT à environ 100 à 150 millisecondes . Le vote de gouvernance est passé, mais l’activation sur le réseau principal reste conditionnée aux tests, à l’implémentation et à la préparation des clients .

Pourquoi Solana touche à son consensus

Le fonctionnement actuel de Solana repose sur deux briques clés. Proof of History sert de mécanisme d’ordonnancement cryptographique du temps : les nœuds leaders horodatent les blocs avec des preuves qu’un certain intervalle s’est écoulé, et les validateurs peuvent ensuite vérifier ces preuves . Tower BFT construit le consensus en empilant des votes de validateurs assortis de périodes de verrouillage : chaque vote confirme une branche et allonge le verrouillage des votes précédents .

Ce système a permis des confirmations optimistes rapides, mais Alpenglow vise une notion plus stricte. Anza décrit Solana aujourd’hui comme offrant une finalité optimiste de l’ordre d’une seconde, tandis que SIMD-0326 compare la finalité de Tower BFT à 12,8 secondes avec les 100 à 150 ms visés par Alpenglow . Pour l’utilisateur, la nuance est importante : une confirmation optimiste peut donner une impression de rapidité ; la finalité correspond au moment où une transaction est considérée comme réglée par le consensus.

Votor : accélérer le vote sans empiler une longue tour

Votor est la partie d’Alpenglow qui reprend la logique de vote et de finalisation des blocs . Dans SIMD-0326, il est décrit comme un protocole léger à votes directs, capable de finaliser un bloc via un processus en un seul tour ou en deux tours selon les conditions du réseau .

Le changement est structurel. Tower BFT s’appuie sur une tour de votes et de verrouillages ; Votor cherche à atteindre la finalité en un ou deux échanges lorsque suffisamment de stake participe. Certaines synthèses techniques parlent de seuils de stake autour de 60 % à 80 %, mais l’élément le plus solidement documenté reste le modèle de finalisation en un ou deux tours décrit par SIMD-0326 .

Anza indique aussi qu’Alpenglow s’appuie sur des primitives cryptographiques BLS pour réduire fortement la latence de finalisation tout en préservant la sûreté . Autrement dit, la promesse n’est pas seulement un message de confirmation plus rapide : c’est un chemin plus court vers une finalité déterministe.

Rotor : faire circuler les blocs assez vite

Rotor est le protocole de diffusion des données d’Alpenglow. Anza le présente comme une évolution qui reprend et affine l’approche de Turbine, le système actuel de distribution des blocs de Solana . Son rôle est très concret : Votor ne peut finaliser rapidement que si les validateurs reçoivent les données du bloc assez tôt pour les vérifier et voter.

Des analyses tierces décrivent Rotor comme un système de relais plus structuré et pondéré par le stake, avec des objectifs de propagation sous les 100 ms et une estimation de 18 ms dans des conditions réseau typiques . Ces chiffres ne sont pas encore des mesures établies sur le mainnet ; ils éclairent surtout la logique d’ensemble : accélérer la diffusion des blocs pour rendre crédible une finalité à très faible latence.

Ce que cela pourrait changer

Domaine	Effet attendu	Réserve à garder en tête
Finalité	Baisse visée de 12,8 s sous Tower BFT à environ 100 à 150 ms avec Alpenglow .	Solana dispose déjà d’une finalité optimiste de l’ordre d’une seconde ; le saut porte surtout sur la finalité forte du consensus .
Propagation des blocs	Rotor doit rendre la distribution des blocs plus rapide et plus prévisible ; des estimations tierces évoquent des objectifs sous 100 ms, voire 18 ms dans des conditions typiques .	Ce ne sont pas encore des mesures établies sur le réseau principal.
Débit et capacité des blocs	Alchemy indique que les votes de validateurs consomment aujourd’hui environ 75 % de l’espace de bloc de Solana et que déplacer ces votes hors chaîne pourrait libérer une grande partie de cette capacité pour les transactions des utilisateurs .	Alpenglow reste d’abord une mise à niveau du consensus et de la finalité ; les gains de débit sont donc indirects, pas une garantie mécanique de hausse du TPS brut .
Coûts des validateurs	Si moins de votes de consensus doivent être publiés comme transactions on-chain, les validateurs devraient subir moins de pression liée aux frais de vote récurrents ; une synthèse mentionne aussi un modèle de « Validator Admission Ticket » comme changement lié aux coûts .	Les économies exactes dépendront de l’implémentation finale, des frais et de l’économie du réseau.
Surcharge réseau	Certaines synthèses techniques avancent une réduction de la communication entre validateurs, avec une estimation d’environ 40 % .	Cela reste une projection tant que le déploiement n’a pas été mesuré en production.

En clair, Alpenglow promet surtout une finalité à plus faible latence. Les bénéfices sur le débit et les coûts viendraient surtout de la réduction du trafic de consensus, notamment des votes, plutôt que d’une refonte de toute l’exécution des transactions.

Le calendrier : gouvernance validée, mainnet encore à confirmer

Alpenglow a d’abord été présenté par Anza comme un nouveau protocole de consensus et comme la plus grande modification du protocole central de Solana . La proposition formelle SIMD-0326 a été publiée en août 2025, en la décrivant comme une refonte majeure du consensus . Le vote a commencé le 27 août, de l’époque 840 à l’époque 842 .

Le vote de gouvernance a abouti début septembre 2025. Les rapports ne donnent pas exactement le même pourcentage : Alchemy mentionne 98,27 % d’approbation, tandis que Blockworks cite 98,94 % des participants en faveur ; les deux indiquent environ 52 % de participation du stake . Le point commun est sans ambiguïté : la proposition a franchi la gouvernance avec un très large soutien des validateurs.

Pour le mainnet, la prudence s’impose. Une feuille de route d’Anza évoquait une arrivée au début 2026, tandis qu’un récapitulatif d’Alchemy publié en avril 2026 indiquait des tests en cluster privé et une attente de mainnet en fin 2026 . Anza a aussi écrit que l’objectif 2026 était de faire sortir Alpenglow des clusters de développement vers un déploiement plus large .

La lecture la plus prudente est donc la suivante : proposition et gouvernance au troisième trimestre 2025, développement et tests privés en 2026, puis possible déploiement mainnet en 2026 — avec fin 2026 comme hypothèse plus conservatrice si les tests restent le facteur bloquant .

À retenir

Si Alpenglow arrive tel que proposé, ce serait le changement de consensus le plus important de Solana à ce jour. Votor vise à condenser le vote et la finalité en un ou deux tours rapides ; Rotor vise à transporter les données de blocs assez vite pour soutenir ce nouveau chemin de consensus .

L’objectif de 100 à 150 ms est spectaculaire, mais il doit encore être lu comme une cible d’ingénierie tant qu’il n’a pas été prouvé sur le réseau principal. La dynamique de gouvernance est là ; l’activation finale dépendra des tests, de la préparation des clients et de la capacité du réseau à confirmer, en conditions réelles, les réductions attendues de surcharge de vote et de coûts pour les validateurs .