Alpenglow : La révolution qui va tout changer pour Solana (SOL)

Qu’est-ce qu’Alpenglow ?

Alpenglow est une nouvelle proposition de protocole de consensus pour Solana. Présentée officiellement à l’occasion de la conférence Solana Accelerate à New York ce lundi 19 mai, Alpenglow est développée par Anza, une entité spécialisée dans la R&D sur Solana.

Anza est notamment l’équipe derrière Agave, le principal client validateur de Solana, ainsi que plusieurs outils et améliorations techniques importantes de l’infrastructure du réseau au cours des dernières années.

→ Retrouvez la conférence de présentation de Alpenglow à Solana Accelerate, menée par Roger Wattenhofer, Head of Research à Anza.

Le but de Alpenglow est de proposer une alternative au consensus actuel de Solana (le Tower BFT et le Proof of History) afin d’améliorer les performances du réseau, diminuer la latence et la finalité des blocs, et plus généralement simplifier le protocole.

La proposition a été formalisée dans un whitepaper publié le 19 mai dernier, et elle s’inscrit dans une refonte plus large de la stack Solana autour de trois composants complémentaires, que nous présenterons dans la suite de cette recherche :

• Alpenglow (le nouveau consensus),
• Votor (le moteur de vote),
• Rotor (successeur de Turbine pour la propagation de blocs).

À travers Alpenglow, l’ambition de Anza est claire : faire de Solana non seulement le réseau le plus rapide, mais aussi l’un des plus robustes, même à très haute charge.

>“We believe that the release of Alpenglow will be a turning point for Solana. Alpenglow is not only a new consensus protocol, but the biggest change to Solana’s core protocol since, well, ever.”

---

Contexte technique actuel de Solana

Solana repose depuis son lancement sur un protocole de consensus basé sur deux mécanismes : Proof of History (PoH) et Tower BFT. Pour rappel, voici leurs rôles :

• Proof of History (PoH) est une fonction cryptographique (Verifiable Delay Function) qui permet (de manière simplifiée) de créer un système d’horodatage au sein de Solana : une séquence vérifiable de timestamps qui permet aux validateurs de se coordonner efficacement sans avoir à se synchroniser à chaque bloc.
• Tower BFT est un protocole de consensus qui utilise l’horloge créée par le PoH pour synchroniser les validateurs. Il repose sur une logique dans laquelle les validateurs “lock” leurs décisions au fil du temps afin de converger rapidement vers une unique décision.

Ce design permet à Solana d’atteindre un débit de traitement des transactions très élevé (plusieurs milliers de transactions par seconde en production), mais il introduit aussi des compromis importants :

• Une finalité “longue” : bien que les blocs soient produits rapidement (environ 400 ms), la finalité (le temps entre la création du bloc et sa finalité, autrement dit l’assurance que le bloc ne sera pas réorganisé) est d’environ 12 secondes.
• Une complexité : Tower BFT repose sur un système d’accumulation de votes des validateurs à travers les epochs, ce qui implique qu’ils doivent maintenir une mémoire précise de leur historique de votes dans le temps. Cela augmente la complexité du code et rend le comportement du protocole plus difficile à gérer.

Certes, cette architecture a fait de Solana l’un des layer 1 les plus performants en termes de débit brut (même si de nouveaux réseaux émergent récemment avec de meilleurs performances) mais au prix d’une certaine complexité opérationnelle et d’une finalité non déterministe (qu’on ne peut donc pas anticiper).

---

Ce que propose Alpenglow

Alpenglow est une refonte en profondeur du mécanisme de consensus de Solana. Il a pour objectif de réduire drastiquement la latence dans la finalité des blocs, tout en simplifiant l’architecture du protocole pour le rendre plus intuitif, plus sécurisé et plus robuste face aux pannes.

Cette proposition s’appuie sur une nouvelle approche du consensus et introduit deux composants clés : Votor et Rotor, qui remplacent respectivement Tower BFT et Turbine, le protocole utilisée jusqu’ici pour la propagation des blocs sur Solana.

Finalité en 1 ou 2 rounds

L’élément central d’Alpenglow est un mécanisme de finalité plus rapide et déterministe. Plutôt que de s’appuyer sur une accumulation de votes verrouillés dans le temps (comme avec Tower BFT), Alpenglow introduit une logique plus simple :

• Si un bloc obtient 40 % des votes, il est jugé sûr (même un fork ayant recueilli autant de votes sera forcément finalisé).
• S’il atteint 60 %, il est finalisé au round suivant.
• S’il atteint 80 %, il est finalisé immédiatement.

Ce mécanisme permet à chaque validateur de déterminer si un bloc est finalisé en se basant uniquement sur les votes qu’il a déjà reçus, sans avoir besoin d’attendre plusieurs cycles de vote ou de maintenir un historique complexe des votes passés à travers plusieurs blocs. Cela réduit considérablement la lourdeur du protocole.

Mais surtout, cela permet de réduire drastiquement la latence entre la création d’un bloc et sa finalité. Ce qui était de l’ordre de 12 secondes auparavant a été réduit à environ 150 ms (médiane), comme nous pouvons l’observer sur ces simulations proposées par Anza :

Dans l’infographie, il est important de comprendre que :

• Les barres bleu clair correspondent à la latence du réseau. Actuellement, la majorité des noeuds de Solana a une latence de 50 ms, mais certains dépassent 200 ms. Néanmoins, c’est toujours le noeud le plus rapide qui impose la latence totale du réseau, d’où l’augmentation de la courbe bleu clair lorsque le % de validateurs atteints augmente.
• Les barres rose montrent le temps nécessaire pour qu’un noeud reçoivent les votes de plus de 60 % des validateurs.
• Les barres bleu foncé correspondent au délai de fonctionnement de Rotor (dont nous parlons dans la section suivante).
• Enfin, les barres violet correspondent au temps de finalisation du bloc (ce que certains confondent régulièrement avec le temps de finalité du bloc).

Ces améliorations sont primordiales pour plein de raisons. En boostant les performances du réseau et surtout, en offrant des garanties claires sur la finalité des transactions aux développeurs, Alpenglow ouvre la voie à tout un tas de nouvelles applications qui nécessitent justement ce genre de performances.

Votor : la nouvelle logique de finalisation

Votor est le nouveau moteur de vote introduit par Alpenglow. Il remplace le mécanisme de Tower BFT, qui gérait jusqu’ici la finalisation des blocs sur Solana. L’objectif est de simplifier en profondeur la manière dont les validateurs convergent vers un bloc finalisé en instaurant une structure de vote moins complexe qu’auparavant.

Votor simplifie radicalement le processus de Tower BFT en instaurant une structure de vote explicite et stateless. Il s’inspire du protocole Streamlet, un algorithme de consensus byzantin moderne conçu pour la finalité rapide avec peu de complexité.

Voici les principes clés du fonctionnement de Votor :

• Le consensus avance par rounds, c’est-à-dire des cycles de votes entre validateurs, chacun visant à finaliser un bloc candidat (au lieu d’accumuler les votes dans le temps, ils sont envoyés par les validateurs à chaque round).
• À chaque round, chaque validateur émet un vote explicite pour un bloc donné, basé uniquement sur l’état courant du réseau (et non sur un historique de locks).
• Un bloc est finalisé si, à l’issue du round : il obtient 80 % des votes (finalité immédiate en 1 round), il obtient 60 % des votes (finalité en 2 rounds) ou il dépasse 40 % des votes (diffusé mais pas encore finalisé).

Cette logique permet aux validateurs de raisonner localement, c’est-à-dire de prendre une décision sur le bloc à voter ou finaliser à partir des votes visibles en temps réel, sans avoir besoin de maintenir des locks persistants ou de calculer un historique complexe.

En résumé, Votor apporte trois bénéfices majeurs :

• Finalité rapide et déterministe, en 1 ou 2 rounds, avec des garanties claires.
• Réduction de la complexité logicielle, en éliminant les dépendances à l’historique.
• Meilleure résilience en cas de forks ou d’événements imprévus, grâce à un protocole plus intuitif et vérifiable.

Rotor : une propagation plus robuste et déterministe

Rotor est le nouveau protocole de diffusion des blocs introduit par Alpenglow. Il succède à Turbine, le mécanisme de propagation utilisé depuis les débuts de Solana. L’objectif de Rotor est d’améliorer l’efficacité de la diffusion des blocs en rendant le comportement du réseau plus prédictible.

Turbine fonctionnait sur une logique inspirée du gossip, où les blocs étaient diffusés en fragments à travers des couches successives de nœuds, sélectionnée de manière aléatoire. Ce système était efficace pour minimiser la bande passante requise, mais posait quand même quelques risques (incohérences en cas de pertes de certains fragments, etc.).

Rotor remplace la distribution non déterministe (autrement dit, la distribution aléatoire des fragments) par une diffusion dont l’arborescence est explicite, c’est-à-dire que chaque bloc est propagé selon un schéma défini à l’avance. Ce dernier est dérivé d’un arbre de diffusion (dissemination tree) dans lequel chaque nœud connaît ses pairs cibles et relaie les blocs selon un ordre établi.

Voici les principes clés du fonctionnement de Rotor :

• La structure de propagation est définie de manière déterministe, ce qui permet d’anticiper et de contrôler la diffusion des blocs.
• Chaque bloc est encapsulé dans un vote émis par un validateur, ce qui garantit que la propagation et la validation sont connectées.
• Le protocole supporte l’exécution asynchrone, permettant de gérer plusieurs rounds en simultané et de réduire les délais de confirmation même en cas de problèmes sur le réseau.

→ Pour aller plus loin, retrouvez l’article de blog de présentation de Alpenglow

---

Étude comparative de Solana avec Alpenglow

---

Perspectives et perception par la communauté

L’annonce d’Alpenglow a suscité un accueil globalement très positif, notamment de la part des figures clés de l’écosystème Solana. Anatoly Yakovenko, cofondateur de Solana Labs, a salué l’élégance et la simplicité du nouveau modèle de consensus, estimant qu’il répondait enfin aux deux exigences fondamentales pour un système performant :

“I got nearly everything wrong about consensus, except the important parts: 1) it can’t be in the way of block producers utilizing 100% of the bandwidth 100% of the time. 2)users need some deterministic finality in one round (2-delta)”

Ce sentiment est partagé par plusieurs développeurs de Solana, pour qui la clarté conceptuelle du nouveau protocole est vue comme un tournant pour l’avenir de l’écosystème, comme le rapport Anatoly :

“There are no words in human languages to express how core engineering feels about dealing with no more than 2 blocks of state transitions at a time instead of up to an epoch of full of unconfirmed blocks.”

En parallèle, certaines critiques ont émergé autour du calendrier de déploiement, qui devrait s’étendre jusqu’à la fin de l’année 2025. Ce débat fait écho à des précédents bien connus dans la communauté Ethereum, où il a fallu plus de deux ans de préparation pour finaliser The Merge, puis plusieurs mois de travail pour préparer Pectra.

Tout comme pour ces étapes majeures d’Ethereum, Alpenglow n’est pas une simple à jour : c’est une refonte complète de certains des composants les plus critiques du protocole. Il est donc normal que cela prenne du temps.

Par ailleurs, il faut également noter que la résilience du réseau ne dépend pas uniquement du consensus, mais aussi de la diversité des clients validateurs. À ce jour, Solana repose essentiellement sur un seul client principal, Agave, développé justement par Anza. Sur ce point, l’arrivée de Firedancer, un client validateur alternatif développé par Jump Crypto, est donc de plus en plus attendue.

Note : Certains craignent que cette nouveauté (apportée par Anza) ne retarde le développement du client validateur Firedancer. D’après Anatoly, cela ne devrait pas être le cas.

→ Retrouvez notre article d’introduction à Firedancer :

---

Vers la fin des vote fees et une nouvelle économie pour Solana ?

Parmi les nombreuses implications d’Alpenglow, l’une des plus structurantes pour l’écosystème Solana est la suppression des “vote fees”. Jusqu’ici, chaque bloc validé sur Solana nécessitait que chaque validateur envoie une transaction de vote pour attester sa participation au consensus.

Ces transactions associées aux votes des validateurs représentaient une charge significative qui pesait particulièrement sur les petits validateurs : jusqu’à 1,1 SOL par jour, soit plus de 400 SOL par an simplement pour pouvoir voter.

C’est d’ailleurs la raison pour laquelle la barrière a l’entrée pour devenir validateur sur Solana était aussi élevée. On estime que le seuil de rentabilité est d’environ 4850 SOL, soit environ 825 000 dollars.

Avec Alpenglow, cette mécanique de vote fees disparaît. Désormais, le vote est géré via des signatures BLS agrégées et sont donc nativement intégré au sein de la couche du protocole. Autrement dit, les validateurs n’auront plus besoin d’envoyer une transaction de vote à chaque bloc.

Cela représente une baisse estimée de 80 % des coûts d’exploitation des validateurs, selon les premières estimations. Concrètement, le seuil de rentabilité pour opérer un validateur pourrait chuter de 4 850 SOL à environ 450 SOL, rendant économiquement viable l’entrée de nouveaux validateurs indépendants.

Mais surtout, ce changement transforme profondément l’économie des validateurs sur Solana. Auparavant, les petits validateurs étaient largement dépendants de l’inflation du SOL et des récompenses associées pour couvrir leurs frais (et particulièrement les votes fees). En supprimant ces frais, Solana réduit sa dépendance à l’inflation et la soutenabilité du réseau à long terme.

Par ailleurs, cela pourrait relancer certaines perspectives explorées ces dernières semaines par les équipes de Solana. Pour rappel, en mars 2025, la proposition SIMD-228 (qui prévoyait de modifier l’inflation du SOL et réduire les émissions) avait été refusée. Alors que la majorité des gros validateurs avaient voté “pour”, ce sont surtout les petits validateurs qui ont voté “contre”, de peur de voir leur rentabilité énormément chuter.

→ Retrouvez notre article sur la proposition SIMD-228 :

---

Que retenir ?

Avec Alpenglow, Solana engage une refonte complète de son mécanisme de consensus. En résumé, l’objectif est double : améliorer drastiquement les performances et simplifier l’architecture du réseau.

Pour faire simple, l’amélioration la plus marquante est que le temps entre la création du bloc et sa finalité va passer d’environ 12 secondes à moins de 250 ms, pour une médiane autour de 150 ms et dans le meilleur des cas, des performances à 100 ms d’après les simulations internes d’Anza.

Cela signifie que, au-delà d’être désormais la blockchain avec la latence la plus faible, Solana peut surtout se comparer avec les meilleures infrastructures Web2. Ainsi, on pourrait imaginer une toute nouvelle vague d’applications qui demandent des performances quasi instantanée ; dans la finance, le gaming, etc.

Finalement, la vraie révolution d’Alpenglow est donc faire de Solana non seulement une blockchain rapide, mais une plateforme capable de rivaliser avec les standards du Web2, sans compromis sur la décentralisation et la sécurité.