Alpenglow : un changement majeur à venir pour Solana

La mise à jour la plus importante du protocole Solana, Alpenglow, vient tout juste d’être annoncée lors de l’événement Accelerate 2025. Organisé par la Solana Foundation du 18 au 23 mai 2025 à New-York, il a regroupé de nombreuses personnalités de la fintech et de l’industrie crypto.

Roger Wattenhofer, fondateur d’Anza Research et professeur à l’Université de Zurich, a introduit ce nouveau mécanisme de consensus, élaboré avec deux de ses étudiants, Quentin Kniep et Kobi Sliwinski. Alpenglow permettra à Solana d’améliorer considérablement sa scalabilité et ses performances globales.

Solana se débarrasse de la preuve d’histoire et de Tower BFT

Solana a grandement innové dans l’univers des blockchains avec son système d’horodatage, appelé la preuve d’histoire, et son mécanisme de consensus, Tower BFT. Pour rappel, la preuve d’histoire, conceptualisée par Anatoly Yakovenko, permet au réseau de s’accorder sur l’écoulement du temps entre deux événements. Tower BFT, quant à lui, est l’algorithme de consensus actuel de Solana, qui tire parti de la proof of history.

La combinaison de ces éléments et d’autres innovations comme Turbine, Sealevel ou Gulf Stream permettent à Solana d’assurer un haut débit de transactions. Malgré des débuts difficiles, marqués par des arrêts intempestifs de la blockchain, ces technologies ont assuré son succès. La plateforme, rapide et peu coûteuse, est désormais largement utilisée dans la finance décentralisée. De plus, elle est désormais la plus utilisée pour émettre les fameux memecoins.

En fondant Anza Research, Roger Wattenhofer et son équipe souhaitent améliorer considérablement les performances de Solana, mais aussi sa sécurité. Ils se sont tout d’abord attelés au design d’un tout nouveau mécanisme de consensus pour les réseaux en preuve d’enjeu.

Alpenglow, le nouveau mécanisme de consensus de Solana

Avec Alpenglow, Solana dit adieu à un grand nombre des composants originels du protocole. Il est voué à remplacer Tower BFT, basé sur la preuve d’histoire. Turbine, l’algorithme de dissémination des informations au sein du réseau, sera également remplacé par Rotor, une version améliorée.

Ces changements permettront à Solana de bénéficier d’une scalabilité rivalisant avec les plateformes du Web2 en termes de réactivité. La latence moyenne entre la création d’un bloc et sa finalisation devrait passer de 12,8 secondes à 150 millisecondes.

Alpenglow s’appuie sur des recherches de pointe. Il combine la distribution de données par codage d’effacement aux dernières avancées en matière de consensus. Il introduit des innovations majeures :

• Un système de vote à un ou deux tours se traduisant par un délai de finalisation sans précédent ;
• Sa résilience dite « 20+20 » qui permet au protocole de fonctionner efficacement, même dans des conditions réseau difficiles ;
• Une stratégie d’échantillonnage à faible variance.

Vue d’ensemble d’Alpenglow

Alpenglow est un nouveau protocole blockchain en preuve d’enjeu qui repose sur deux composants principaux, Rotor et Votor.

Rotor est la version optimisée de Turbine, le protocole de dissémination des données actuel de Solana. Il a pour particularité d’utiliser la totalité de la bande-passante disponible fournie par les nœuds. C’est ce qui permet d’atteindre un débit asymptotiquement optimal. 

Sur Solana, le temps est divisé en slots. Un nœud appelé leader choisi par une fonction aléatoire est chargé de construire des blocs pour un nombre fixé de slots consécutifs. C’est donc lui qui reçoit les nouvelles transactions, qu’elles soient envoyées par les utilisateurs ou par d’autres nœuds.

L’idée de l’algorithme Rotor est de disséminer les blocs en petits morceaux en utilisant la bande-passante de tous les nœuds. Une fois un bloc construit, un nouveau leader commence à produire un nouveau bloc. Dans le même temps, chaque nœud finit par recevoir le bloc précédent et vote quant à sa validité.

Si le bloc arrive dans les temps et qu’il est correct, le nœud vote pour le bloc. S’il arrive en retard, il est ignoré (cela signifie que le leader n’est pas digne de confiance ou que le réseau est instable). Si un bloc est élu à la super-majorité (80 % du stake total du réseau), le protocole produit un certificat de notarisation. Le bloc sera alors immédiatement finalisé. Dans le cas contraire, il faudra à nouveau choisir entre notariser le vote ou ignorer le bloc.

Fonctionnement détaillé d’Alpenglow

Structure des blocs : Shred, Slice, Block

Chaque tranche (slice) possède un hash racine, qui constitue à son tour les nœuds feuilles du deuxième arbre de Merkle, dont la racine correspond au hash de bloc.

Rotor

Rotor est le protocole de diffusion de blocs d’Alpenglow. Le leader souhaite diffuser des données (un bloc) à tous les autres nœuds. Cette procédure doit présenter une faible latence, utiliser la bande passante du réseau de manière équilibrée et être résiliente aux pannes de transmission. Le bloc doit être produit et transmis en continu, c’est-à-dire que le leader n’a pas besoin d’attendre que le bloc soit entièrement construit.

Un leader utilise plusieurs rondes du protocole Rotor pour diffuser un bloc. Chaque ronde prend en compte la transmission indépendante d’un fragment (shred) du bloc. Le leader transmet chaque fragment dès qu’il est prêt (pipelining de la production et de la transmission des blocs).

Pour chaque tranche, le leader génère Γ fragments de codage Reed-Solomon et construit un arbre de Merkle sur leurs hachages, puis signe la racine. Les fragments de codage incluent le chemin de Merkle ainsi que la signature de la racine. Chaque fragment contient autant de données et de métadonnées correspondantes que peut contenir un datagramme UDP.

Le codage d’effacement

Les codes correcteurs permettent de reconstruire des données incomplètes à partir d’un certain nombre de fragments. L’utilisation du codage d’effacement Reed-Solomon garantit qu’au prix d’un envoi supplémentaire de données, la réception de γ fragments suffit à reconstruire la tranche. Ensuite, pour une vérification de validité supplémentaire, un récepteur génère les fragments manquants (jusqu’à Γ − γ). Pour chaque tranche, le leader envoie chaque fragment directement au nœud correspondant, sélectionné comme relais de fragment.

Chaque relai diffuse ensuite son fragment à tous les nœuds qui en ont encore besoin, c’est-à-dire à tous les nœuds sauf au leader et à lui-même, par ordre d’enjeu décroissant. À titre d’optimisation mineure, tous les relais de fragment envoient d’abord leur fragment au leader suivant. Cela améliore légèrement la latence pour le leader suivant, qui a le plus besoin du bloc.

Pour permettre aux récepteurs de vérifier à moindre coût l’authenticité de chaque fragment individuellement, le leader construit un arbre de Merkle sur tous les fragments d’une tranche. Chaque fragment inclut ensuite son chemin dans l’arbre et la signature du leader de la racine de l’arbre.

Lors de la réception du premier fragment d’une tranche, un nœud vérifie la validité du chemin de Merkle et de la signature du leader, puis stocke la racine vérifiée. Pour tout fragment ultérieur, le nœud récepteur vérifie uniquement la validité du chemin Merkle par rapport à la racine stockée.

Blokstor

Blokstor est le système qui collecte et stocke le premier bloc reçu via Rotor pour chaque emplacement temporel (slot). Il peut aussi exécuter la procédure de réparation, pour récupérer un autre bloc et le stocker. Si un bloc est finalisé, Blokstor doit collecter et stocker uniquement ce bloc dans l’emplacement donné.

Votes et certificats

Si un leader obtient au moins 80 % des votes pour son bloc, celui-ci est immédiatement finalisé après un tour. On parle alors de finalisation rapide. Cependant, dès qu’un nœud constate que 60 % des votes pour un bloc sont positifs, il procède à un second tour de vote. Si le second vote réunit à nouveau le quorum de 60 % pour un bloc, celui-ci est finalisé. En revanche, si un nombre suffisant de votes considère le bloc en retard, la proposition d’initiation du bloc est ignorée (saut).

Le Pool

Chaque nœud gère une structure de données appelée Pool. Dans ce Pool, chaque nœud mémorise tous les votes et certificats de chaque période temporelle (slot).

Votor : notarier et finaliser les blocs sur Alpenglow

L’algorithme Votor a pour but de notarier et de finaliser les blocs. Les blocs finalisés constituent une chaîne unique de références parentes. Le protocole garantit que, pour chaque emplacement :

• Soit un certificat de saut est créé ;
• Soit un bloc b est notarié (ou un bloc b de secours), de sorte que tous les ancêtres de b soient également notariés.

Des seuils de condition garantissent qu’un leader malveillant ne puisse empêcher la création des certificats. Si de nombreux nœuds corrects ont produit des votes de notarisation pour le même bloc b, tous les autres nœuds corrects effectueront des votes de secours pour b. Sinon, tous les nœuds corrects diffuseront des votes de secours.

Un nœud peut finaliser un bloc dès qu’il observe suffisamment de votes de notarisation (80 %) produits par d’autres nœuds immédiatement après la réception d’un bloc. Cependant, un seuil de participation inférieur est requis (60 %) pour créer un certificat de notarisation. Le nœud enverra alors le vote de finalisation. Par conséquent, les blocs sont finalisés après un tour de vote parmi les nœuds détenant 80 % de la participation, ou deux tours de vote parmi les nœuds détenant 60 % de la participation.

En conclusion

Alpenglow présente des performances bien supérieures à Tower BFT en termes de gestion de la bande passante et de latence. Les résultats des tests menés par Anza Research à Zurich sont disponibles dans son whitepaper.

En passant sous la barrière des 200 millisecondes pour la finalisation des blocs, les développeurs pourront imaginer de nouvelles applications sur Solana. L’idée est de se rapprocher de l’exécution en temps réel.

Pour l’instant, les dates d’implémentation d’Alpenglow n’ont pas été annoncées. L’équipe prévoit un déploiement en fin d’année 2025 si les tests se passent bien. Les anglophones peuvent visionner la présentation d’Alpenglow lors de la conférence Scale or Die – Accelerate 2025 sur Youtube :