Alpenglow : la grande refonte du consensus de Solana

Points clés exploitables 

• Le principal avantage d’Alpenglow pour Solana est une réduction par 100 du délai de finalité des transactions. Selon la situation géographique du validator, ce délai passera de 12,8 secondes à 100-150 ms, ce qui permettra à Solana de rivaliser avec des infrastructures Web2 plus centralisées et de prendre en charge des applications en temps réel.
• Alpenglow simplifie le consensus en éliminant plusieurs composants historiques de Solana, dont Proof of History, Tower BFT et la propagation des votes fondée sur le gossip. À la place de Proof of History, Alpenglow introduit une durée de bloc fixe de 400 ms, ce qui n’est pas équivalent à une horloge synchronisée à l’échelle mondiale, afin de coordonner la temporalité sur l’ensemble du réseau.
• Le protocole repose sur deux composants fondamentaux : Rotor, un protocole amélioré de propagation des blocs qui étend et perfectionne l’architecture Turbine existante de Solana, et Votor, un nouveau mécanisme de vote qui remplace Tower BFT, Proof of History et l’utilisation du gossip pour propager les votes.
• Toute l’activité de consensus passe hors chaîne : les certificats de vote resteront ancrés sur la chaîne et remplaceront les transactions de vote par slot par un système léger de certificats BLS. Ce changement élimine les frais de vote tels que nous les connaissons aujourd’hui. Historiquement, ils constituaient le principal coût opérationnel des validators. Cette évolution améliore donc considérablement leur économie pour les petits opérateurs. Le modèle économique exact est encore en cours de finalisation.
• Alpenglow offre un modèle de résilience « 20+20 » : il préserve la sécurité si des adversaires contrôlent jusqu’à 20 % du stake, ainsi que la vivacité si 20 % supplémentaires et distincts du stake sont hors ligne ou ne répondent pas. Le protocole peut ainsi tolérer des conditions réseau à la fois hostiles et instables.
• Votor emploie un système de vote simultané à deux niveaux pour le consensus. Dans le parcours Fast-Finalization, si un bloc obtient l’approbation d’au moins 80 % du stake au premier tour, il est immédiatement finalisé avec un Fast-Finalization Certificate. Dans le parcours Slow-Finalization, un second tour commence dès qu’un bloc obtient l’approbation d’au moins 60 % du stake. Si ce tour atteint au moins 60 % d’approbation, le bloc est finalisé avec un Finalized Certificate.
• Contrairement à Turbine, qui repose sur une arborescence multicouche avec un fanout de 200, Rotor utilise un modèle à saut unique dans lequel des nœuds relais assurent la diffusion des shreds. Chaque shred est transmis sous la forme d’un seul paquet avec code d’effacement, et la conception de Rotor est nativement compatible avec les systèmes multicast tels que DoubleZero. Notez que Rotor fera très probablement l’objet d’un SIMD distinct de celui de Votor.
• Le déploiement d’Alpenglow sur le mainnet de Solana est actuellement prévu pour le début de l’année prochaine. Une implémentation de référence du protocole est disponible sur Github.

Introduction

L’algorithme de consensus Alpenglow représente la refonte la plus importante du protocole central de Solana à ce jour. S’appuyant sur les dernières avancées de la recherche sur les blockchains, il repense en profondeur la manière dont le réseau parvient au consensus.

Alpenglow est le fruit du travail de la nouvelle division de recherche d’Anza, dirigée par le professeur Roger Wattenhofer de l’ETH Zurich, l’un des établissements d’informatique les mieux classés au monde. Autorité reconnue dans le domaine des systèmes distribués, le professeur Wattenhofer a précédemment coécrit l’article de 2024 Halting the Solana Blockchain with Epsilon Stake, qui a mis au jour de possibles vulnérabilités de vivacité dans le protocole de consensus actuel de Solana. Ses anciens doctorants, Kobi Sliwinski et Quentin Kniep, l’ont rejoint chez Anza.

L’équipe devait repenser l’algorithme de consensus de Solana pour améliorer ses performances et apporter des preuves formelles de sa correction, tout en préservant son architecture fondée sur Turbine. Alpenglow intègre de nombreuses avancées récentes de la recherche sur les systèmes distribués, en particulier pour gérer les comportements réseau adverses.

Le nom Alpenglow vient du mot allemand Alpenglühen, qui signifie « lueur des Alpes ». Il désigne la lumière saisissante qui éclaire les sommets au lever ou au coucher du soleil et fait référence aux origines suisses du protocole.

Quels sont les avantages d’Alpenglow ?

Voici une synthèse générale des principaux avantages attendus d’Alpenglow. Chacun sera étudié plus en détail dans la suite de l’article.

Une finalité plus rapide

Le principal avantage d’Alpenglow pour Solana est une réduction par 100 du délai de finalité des transactions, c’est-à-dire du temps nécessaire pour que les transactions des utilisateurs soient enracinées sur un réseau blockchain. Selon la situation géographique du validator, ce délai passera de 12,8 secondes à 100-150 ms, ce qui permettra à Solana de rivaliser avec des infrastructures Web2 plus centralisées et de prendre en charge des applications en temps réel.

• Finalité actuelle de Solana : 12,8 secondes 
• Confirmation optimiste actuelle de Solana : 500-600 millisecondes
• Finalité d’Alpenglow : 150 millisecondes (valeur médiane)*
• Finalité concurrente la plus rapide : 400 millisecondes (valeur autodéclarée)

*varie selon la géographie et la distribution du cluster.

Fin des transactions de vote

Avec Alpenglow, toute l’activité de consensus se déroule hors chaîne. Cela réduira la charge de l’unité de traitement des transactions (TPU) et du replay, qui n’auront plus à traiter les transactions de vote.

Alpenglow améliorera également considérablement l’économie des petits validators. Les frais liés aux transactions de vote constituent leur plus importante dépense opérationnelle. Leur suppression grâce au vote hors chaîne réduit fortement les coûts de participation, facilite l’activité des petits validators et abaisse la barrière à l’entrée pour contribuer à la sécurité du réseau.

Parmi les autres avantages figurent une logique d’engagement simplifiée et une croissance plus lente du registre, puisque les transactions de vote ne consomment plus d’espace de bloc et n’augmentent plus la taille du registre.

Cette évolution a aussi l’avantage de lever l’ambiguïté entourant les mesures de transactions par seconde (TPS) de Solana. Aujourd’hui, les TPS sont souvent présentés de deux manières : les TPS totaux, qui incluent les transactions de vote, et les TPS réels, qui ne comptabilisent que les transactions autres que les votes.

Un protocole plus rationalisé

Alpenglow rationalise le processus de consensus en supprimant plusieurs composants historiques de Solana, dont Proof of History, Tower BFT et l’utilisation du gossip pour propager les votes. Il intègre les avancées de pointe de la recherche moderne sur les blockchains sans introduire de complexité superflue.

Votor et Rotor d’Alpenglow jettent les bases de futures mises à niveau, comme l’exécution asynchrone et les leaders multiples simultanés (MCL). Solana est ainsi bien positionnée pour continuer à améliorer ses performances et faire évoluer son protocole.

Quel est le mécanisme de consensus actuel de Solana ?

Proof of History

Proof of History (PoH) n’est pas un algorithme de consensus. Il s’agit plutôt d’un outil qui aide à parvenir au consensus. La confusion vient probablement de son nom — « Proof of X » — qui laisse penser aux personnes connaissant Proof of Work et Proof of Stake qu’il s’agit d’un algorithme de consensus. Il est plus pertinent de le considérer comme un algorithme de « pré-consensus » qui rationalise le consensus grâce à un traitement efficace des transactions.

À un niveau général, PoH est une horloge décentralisée utilisée pour prouver le temps dans un réseau adverse. Plus formellement, PoH est une fonction cryptographique d’horodatage qui permet aux nœuds de s’accorder sur l’ordre des événements sans communiquer entre eux. Elle utilise une fonction de hachage séquentielle résistante aux préimages pour créer une chaîne de hachages. Les leaders horodatent les blocs à l’aide de ces hachages afin de prouver qu’un certain temps s’est écoulé. Tous les hachages étant chaînés, PoH fournit un historique prouvant que des données existaient à un instant précis. 

Cette approche diffère de celle d’autres chaînes, qui déterminent souvent l’ordre des blocs pendant le consensus avant d’y ajouter des horodatages. Sur Solana, une horloge vérifiable par cryptographie est d’abord créée, les transactions sont diffusées par rapport à cette horloge, puis le consensus vérifie le journal de transactions préordonné. Le chaînage des hachages rend l’ordre temporel incontestable. 

Tower BFT

Tower BFT intervient après la propagation des shreds (c’est-à-dire des blocs partiels) aux autres validators et leur replay par le réseau afin de déterminer si le bloc rejoint le registre. Sur le plan conceptuel, il s’agit d’un algorithme de consensus comparable à pBFT, conçu pour tirer parti de l’horloge de Proof of History à l’échelle du réseau. Au lieu d’exiger un tour de consensus synchrone pour chaque slot, les validators se préengagent sur de futurs slots à partir de la séquence Proof of History qu’ils ont déjà observée, ce qui permet une production continue de blocs.

Les validators émettent une transaction de vote par slot, signée par leur compte de vote. Les votes sur une branche donnée entraînent un verrouillage (c’est-à-dire un délai d’attente) pour cette branche. Un verrouillage correspond à une période définie de slots pendant laquelle un validator ne peut pas voter pour une autre branche. L’objectif est de contraindre les validators à s’engager sur une branche et d’allonger exponentiellement le verrouillage s’ils souhaitent en changer. Chaque vote comporte un compteur de verrouillage qui double chaque fois que le validator vote sur un slot descendant, formant ainsi une « tour de votes » d’engagements. Par conséquent, si un validator vote pour le bloc X, il ne peut voter pour aucune branche conflictuelle pendant un nombre exponentiellement croissant de slots futurs (par exemple, 1, 2, 4, 8…). Toute violation du verrouillage peut être prouvée et sanctionnée, même si le slashing n’a pas encore été déployé sur le mainnet.

Avec Tower BFT, Solana atteint deux niveaux de finalité : la confirmation optimiste et la finalité déterministe. 

Lorsqu’un nouveau bloc est produit et recueille les votes d’au moins 66 % du stake, il est reconnu comme faisant partie de la branche dominante, ou canonique. On parle de confirmation optimiste, car le bloc reçoit le niveau d’engagement « confirmed » dès qu’une supermajorité a voté pour lui. La confirmation optimiste a été introduite dans la version 1.3 du client Solana Labs (désormais Agave) pour améliorer l’UX en traitant un bloc comme finalisé avant sa finalisation formelle.

Depuis le bloc de genèse de Solana, aucun bloc confirmé de manière optimiste n’a jamais été annulé. Une telle annulation exigerait qu’au moins un tiers du stake total révèle une branche conflictuelle après que 66 % ont déjà voté honnêtement. De manière équivalente, une fois que le nombre de confirmations optimistes d’un bloc atteint ~87 % du stake, un adversaire aurait besoin qu’au moins 20 % de ce même stake signe deux fois, ce qui constitue un acte dont le caractère sanctionnable par slashing peut être formellement prouvé. Sans constituer une finalité absolue au sens strict de la théorie du consensus, la confirmation optimiste offre de solides garanties en pratique. Ces blocs peuvent être considérés comme finalisés pour presque tous les cas d’utilisation — c’est pourquoi la finalité de Solana est généralement donnée comme étant de 500 à 600 millisecondes dans la pratique.

La véritable finalité déterministe exige qu’un bloc atteigne le verrouillage maximal dans la tour de votes, soit 32 votes empilés le confirmant. Autrement dit, 32 blocs supplémentaires doivent être construits au-dessus de ce bloc pour qu’il soit considéré comme « finalisé » ou enraciné dans le réseau. Compte tenu des 32 slots requis et d’une durée de slot de ~0,4 seconde, un bloc atteint la finalité déterministe en ~12,8 secondes. Celle-ci est acquise lorsque la profondeur des votes verrouillés rend toute annulation impossible.

Quelles sont les limites du mécanisme de consensus actuel de Solana ?

Proof of History et Tower BFT ont permis à Solana d’atteindre un débit élevé et des confirmations optimistes rapides. Cette conception présente cependant plusieurs limites en matière de coût, de latence, de vivacité et d’exploitation des validators.

Frais et surcharge élevés liés aux votes

Chaque validator doit voter en permanence pour chaque slot afin de contribuer au consensus. Les votes sont des transactions qui interagissent avec le programme de vote, consomment des ressources réseau et entraînent des frais. 

Environ trois quarts des transactions sur Solana sont des transactions de vote. Elles imposent une surcharge importante au réseau et représentent un coût réel pour les validators à chaque slot. Cette dépendance inutile envers des votes incessants introduit une surcharge et des coûts élevés, qui augmentent avec le nombre de slots traités et de validators dans le cluster. 

Latence de finalité

Si la confirmation optimiste est rapide, la finalité déterministe ne l’est pas. Un délai de ~12,8 secondes est lent par rapport aux protocoles de consensus plus récents, comme Mysticeti de Sui, qui annonce un délai de finalité de ~500 ms. Cela pose des problèmes aux applications qui exigent une certitude absolue pour leurs opérations, notamment les plateformes d’échange. En pratique, les utilisateurs font confiance aux blocs confirmés. Le réseau doit néanmoins conserver un long historique des branches en prévision d’éventuelles réorganisations mineures avant la finalisation. 

L’écart entre la confirmation optimiste et la latence déterministe correspond à un compromis : Tower BFT privilégie la vivacité avec une courte fenêtre pour gérer les branches éventuelles, au prix d’une finalité plus lente. Même sans attaque ni bug de consensus, une finalité de ~12,8 secondes fait pâle figure face aux chaînes à finalité rapide et aux infrastructures Web2 existantes.

Vivacité et tolérance au partitionnement du réseau

Tower BFT exige qu’une supermajorité de validators soit en ligne et réponde afin de confirmer et de finaliser les nouveaux blocs. Le consensus peut s’interrompre si plus d’un tiers du stake est hors ligne ou si le réseau est fortement partitionné. Solana peut continuer à produire des blocs en privilégiant la vivacité, mais le réseau peut ne pas atteindre le seuil de votes nécessaire à leur confirmation optimiste. Dans le pire des cas, comme lors des récentes interruptions de Solana, les validators bloqués dans l’attente de votes ou incapables de traiter la branche optimiste pourraient provoquer l’arrêt du réseau et nécessiter un redémarrage coordonné.

Il s’agit d’une limite classique du consensus BFT. Solana ne prévoit aucun mécanisme intégré permettant à une grande partie des validators de ne pas répondre temporairement. La vivacité de Solana a donc souffert dans des conditions extrêmes, car le protocole ne pouvait pas gérer correctement une chute sous le seuil de supermajorité requis pour le consensus. Tower BFT devait continuer à produire des blocs avec moins de 60 % du stake en ligne. Ces blocs ne pouvaient donc jamais atteindre la confirmation optimiste et risquaient d’être annulés.

Complexité opérationnelle pour les validators

Tower BFT impose de lourdes exigences aux validators : transactions de vote constantes, réseau robuste, mises à niveau du client, prévention des défaillances et conservation de « l’état de la tour ». Si un validator redémarre ou perd l’état le plus récent de sa tour, il risque d’émettre un vote contraire à un engagement de verrouillage antérieur, ce qui entraîne la perte de crédits de vote.

La dépendance du protocole envers le hachage continu de Proof of History et la propagation des votes par gossip oblige les validators à fournir d’importants efforts pour suivre le rythme des slots de ~400 ms de Solana. Les exigences matérielles élevées de Solana, même si elles diminuent avec le temps, restent également significatives. En outre, quel que soit leur stake, tous les validators doivent voter sur chaque slot pour maximiser leurs récompenses. Les petits validators paient donc, pour l’essentiel, les mêmes frais et supportent la même charge de travail que les plus grands. Comme les slots de leader sont attribués proportionnellement au stake, les validators qui en détiennent davantage produisent plus de blocs et perçoivent ainsi une plus grande part des frais de vote payés par les autres validators. Il en résulte un flux de valeur circulaire dans lequel les frais de vote redistribuent effectivement le capital au profit des validators disposant du stake le plus élevé.

De plus, le mécanisme de consensus actuel de Solana rend le replay de blocs dupliqués extrêmement complexe, car les clients doivent gérer plusieurs candidats pour un même slot. Le système de certificats de Votor garantit que chaque slot engage soit un seul hachage, soit un saut explicite, ce qui simplifie considérablement le replay des blocs dupliqués.

Il devient évident que la conception de Tower BFT, bien qu’innovante, entraîne une complexité opérationnelle considérable pour les validators.

Comment fonctionne Alpenglow ?

Alpenglow s’articule autour de deux composants principaux :

• Rotor : un protocole amélioré de propagation des blocs, fondé sur l’architecture Turbine existante et venant la perfectionner.
• Votor : un nouveau protocole de vote qui remplace Tower BFT, la propagation des votes fondée sur le gossip et Proof of History pour la participation au consensus.

Dans les sections suivantes, nous étudierons ces composants en détail.

Rotor : nouvelle couche de diffusion des données

Rotor est un protocole amélioré de propagation des blocs qui s’appuie sur la conception Turbine existante de Solana, avec des améliorations majeures en matière d’efficacité et de simplicité. Contrairement à Turbine, qui utilise une arborescence multicouche avec un fanout de 200, Rotor emploie un modèle à saut unique (2δ). 

Les blocs sont divisés en tranches, puis chaque tranche est encodée en plusieurs shreds au moyen de codes d’effacement Reed-Solomon. Pour garantir l’authenticité des shreds, le leader crée un arbre de Merkle à partir de leurs hachages et signe la racine. Chaque shred contient son chemin dans cet arbre ainsi que la signature du leader.

Chaque shred est envoyé directement à un nœud relais. Les relais diffusent ensuite leur shred à tous les nœuds du réseau, en commençant par le prochain leader. Cette approche à une seule couche réduit la latence et simplifie le chemin de propagation. Elle est également étonnamment rapide :

Le leader et les relais de shreds sont sélectionnés par échantillonnage pondéré selon le stake, ce qui signifie que chaque nœud doit transmettre une quantité de données proportionnelle à son stake. Grâce au code d’effacement, les nœuds n’ont besoin de recevoir qu’un sous-ensemble des shreds pour reconstruire la tranche de bloc d’origine.

Une différence notable avec Turbine tient au fait que Rotor ne transmet qu’une seule version de chaque shred encodée avec un code d’effacement. Il n’est donc plus nécessaire d’envoyer séparément des shreds de données et de récupération comme le fait Turbine. Si la redondance, c’est-à-dire le taux d’expansion des données, reste identique, cette conception élimine les comportements étranges liés au transfert des shreds de données et garantit la simplicité du protocole.

L’architecture de Rotor est également compatible avec les systèmes multicast tels que DoubleZero, ce qui offre une certaine flexibilité dans la livraison des blocs. Comme leur propagation consomme une bande passante importante — les grands validators approchent actuellement les 150 000 paquets sortants par seconde — Rotor introduit un modèle qui récompense les relais pour la distribution des données, alignant ainsi les incitations sur les performances du réseau.

Le livre blanc d’Alpenglow ne définit aucun mécanisme concret de calcul ou de distribution des récompenses. Il précise toutefois que les récompenses de Rotor doivent tenir compte de la bande passante consommée, les nœuds relayant davantage de données étant censés recevoir une plus grande part des récompenses.

Qu’est-ce que Blokstor ?

Blokstor permet aux nœuds de stocker et de gérer les données de bloc reçues de Rotor. Plus formellement, Blokstor est une structure de données qui gère le stockage des tranches. Lorsqu’un shred est reçu, son contenu est ajouté à Blokstor si certaines conditions sont remplies, notamment :

• Blokstor ne contient pas déjà de shred pour ces indices
• Une signature de leader valide
• Un chemin d’arbre de Merkle valide

Blokstor émet un événement "Block(slot(b), hash(b) hash(parent(b)))" lorsqu’il reçoit le premier bloc b complet pour slot(b). Blokstor peut également exécuter des procédures de réparation afin de collecter et de stocker d’autres blocs pour le même slot. Lorsqu’un bloc est finalisé, Blokstor ne doit conserver que ce bloc dans le slot concerné.

Votor : nouveau moteur de vote et de finalisation

Votor est le nouveau moteur de vote et de finalisation d’Aplenglow. Il remplace Tower BFT pour la notarisation et la finalisation des blocs. Il s’inspire des travaux de recherche Simplex afin d’améliorer l’efficacité et la simplicité, et les applique à un contexte de Proof of Stake. 

Simplex démontre qu’un accord byzantin efficace peut être atteint dans un système Proof of Stake à leader tournant avec des messages extrêmement courts, à condition de disposer d’une limite supérieure stricte pour le délai réseau. À partir de ces résultats, Votor parvient au consensus en un ou deux tours.

À un niveau général, Votor garantit que chaque slot possède soit un Skip Certificate indiquant que le slot a été sauté, soit un bloc notarié construit sur la chaîne canonique de blocs notariés. Pour être notarié, un bloc doit disposer d’un certificat valide. Au lieu d’inonder le gossip de votes, les validators diffusent de légers messages de vote à un ensemble de pairs pondéré selon le stake, sous la forme d’un maillage d’« envoi direct » plutôt que par le gossip traditionnel de Solana. Une fois le quorum atteint, n’importe quel nœud peut agréger ces signatures en certificat au moyen du schéma de signature Boneh–Lynn–Shacham (BLS). Les transactions de vote par slot ne sont ainsi plus nécessaires, car seul l’en-tête du certificat agrégé est ancré sur la chaîne.

Comment fonctionne le mécanisme de vote de Votor ?

Votor utilise un mécanisme de vote simultané à plusieurs niveaux, réparti en deux parcours :

• Fast-Finalization : si le bloc proposé obtient l’approbation d’au moins 80 % du stake au premier tour de vote, il est immédiatement finalisé et un Fast-Finalization Certificate est produit. Cette finalisation en un seul tour est possible parce que 80 % du stake dépasse largement le seuil de supermajorité, rendant inutile un second tour de vote.
• Slow-Finalization : si le premier tour recueille l’approbation de <80 % du stake, mais d’au moins 60 %, Votor lance immédiatement un second tour. Dès que celui-ci obtient l’approbation d’au moins 60 % du stake, un Finalized Certificate est produit.

Les deux parcours s’exécutent simultanément, et le premier qui atteint son seuil finalise le bloc. Dès qu’un leader termine l’ingestion du bloc parent, il peut commencer à transmettre le bloc suivant pendant que les votes continuent de s’accumuler. Un bloc est ainsi produit toutes les ~400 ms, comme le garantissait l’ancien consensus de Solana. Cette conception assure que, si le premier tour n’obtient pas l’approbation d’au moins 80 % du stake, Votor se rabat sur le second tour. Elle garantit également que deux blocs conflictuels ne peuvent pas tous deux atteindre la finalité en raison du chevauchement du stake.

Qu’est-ce que la structure de données Pool de Votor ?

Le Pool est une structure de données tenue par chaque nœud qui fait office de registre local de l’activité de vote et de la génération de certificats. Il mémorise les votes reçus pour chaque slot et chaque nœud. Lorsqu’un nombre suffisant de votes est reçu, le certificat correspondant est généré. Lorsqu’un certificat nouvellement reçu ou créé par le nœud est ajouté au Pool, il est diffusé à tous les autres nœuds. 

Même si plusieurs validators peuvent créer des certificats presque simultanément, tout certificat qui atteint le seuil de quorum est fonctionnellement équivalent pour le consensus, quels que soient les validators inclus dans l’ensemble des signatures. Le Finalized Certificate constitue la seule exception, car jusqu’à trois certifications distinctes peuvent devoir circuler. Il n’existe jamais plus de quatre certificats uniques, tous types confondus, pour un même slot, et chacun n’est diffusé qu’une fois. Cette approche empêche le spam de votes tout en permettant à n’importe quel nœud honnête de créer et de partager le certificat dès que le Pool indique un quorum.

Points clés

Les votes sont diffusés sous forme de paquets UDP uniques à tous les validators, qui mémorisent ceux reçus pour chaque slot et chaque nœud. Avec Votor, la notarisation et la finalité d’un bloc donné sont déterminées par les trois conditions suivantes :

• Approbation d’au moins 80 % du stake au premier tour de vote.
• Approbation d’au moins 60 % du stake aux premier et second tours de vote.
• Le validator reçoit d’un autre validator un certificat valide indiquant que le bloc a été finalisé.

Fin de Proof of History

Puisque Rotor propage les données de bloc en un seul saut et que Votor vise une latence maximale de ~150 ms — un point que nous approfondirons dans la section suivante — Solana n’a plus besoin d’une horloge décentralisée. De simples horloges locales suffisent. Alpenglow remplace Proof of History par des minuteurs d’expiration locaux.

Comment fonctionne le mécanisme d’expiration de Votor ?

En pratique, le système d’expiration fonctionne comme suit :

• Fenêtre du leader : le leader prend en charge une fenêtre de quatre slots, avec Δblock ≈ 400 ms par slot.
• Arrivée des données ou expiration : dès que le bloc parent d’un leader est notarié, chaque validator déclenche ses délais d’expiration et prédéfinit quatre échéances — une par slot — à t = now + Δtimeout + slotIndex * Δblock, où Δblock ≈ 400 ms. Notez que ces minuteurs ne sont jamais réinitialisés et servent de limites supérieures. Si les shreds d’un bloc arrivent à temps, le validator vote pour ce slot avec un message NotarVote, et l’expiration en attente devient une opération nulle. En revanche, si le délai expire avant l’arrivée de tout shred, le validator considère que le leader est malhonnête ou défaillant et émet un SkipVote.
• Certification : un Fast-Finalization Certificate ou un Finalized Certificate est produit pour les blocs notariés, comme décrit ci-dessus. Un Skip Certificate peut également être produit pour les slots sautés.

Alpenglow introduit un système dans lequel chaque validator mesure les délais d’expiration localement et de manière indépendante. Solana n’a donc pas besoin d’une horloge unique pilotée par hachage comme Proof of History. Comme chaque message tient dans un seul paquet UDP et que Rotor n’effectue qu’un seul saut, la limite de 400 ms est réaliste sans hachage. Les validators n’auront plus à calculer continuellement des hachages, pourront voter contre des blocs sans subir de verrouillage et les clients alternatifs, comme Firedancer, ne seront pas contraints de reproduire l’implémentation de Proof of History du client Agave.

Saut de slots

Les validators peuvent également sauter un slot en envoyant un message SkipVote. Si au moins 60 % du stake émet un message SkipVote, un Skip Certificate est produit et le slot est officiellement sauté. Les votes de saut ont le même poids de récompense que les votes de notarisation. Un validator n’a donc aucune raison de rester silencieux si le leader se comporte mal. Notez que cela pourrait changer une fois le modèle économique d’Alpenglow finalisé.

Les validators envoient un SkipVote pour un slot dès qu’ils déterminent qu’ils ne peuvent pas finaliser de bloc pour celui-ci. Cela peut être dû à une expiration, à l’absence d’un bloc ou à la production d’un bloc invalide ou mal formé. Si le premier slot de la fenêtre de quatre slots d’un leader remplit l’une de ces conditions, les validators marquent toute la fenêtre comme défaillante. Ils parcourent alors les slots restants et émettent des SkipVotes pour chacun de ceux sur lesquels ils n’ont pas encore voté. Toute la fenêtre de quatre slots peut ainsi se réduire à un seul tour de saut. Chacun de ces votes ne concerne toujours qu’un seul slot, mais comme la plupart des validators émettent la même rafale, les trois slots en attente atteignent le seuil de 60 % à peu près simultanément. Cela évite que le cluster reste inactif pendant trois autres slots vides en attendant l’expiration d’un leader hors ligne.

Cela laisse évidemment des interruptions dans la production des blocs. Le rythme des slots se poursuit toutefois sans interruption grâce à ces certificats de saut rapides. Cela simplifie le choix de la branche et améliore la cohérence, car un Skip Certificate agit comme un « bloc nul » canonique pour ce slot : tous les nœuds honnêtes adoptent donc le saut comme résultat. Il n’existe ainsi aucune branche concurrente, et les sauts n’entraînent pas de branches persistantes, ce qui permet de maintenir une cadence régulière de production des blocs.

Récompenses des validators

Avec Votor, les récompenses des validators reposent sur leur participation aux votes et à la génération des certificats. Les nœuds qui contribuent au consensus en votant pour (NotarVote) ou contre (SkipVote) un bloc reçoivent les mêmes récompenses. Cela encourage une participation honnête et garantit que les nœuds votent selon leur propre état plutôt que d’essayer de prévoir ou de suivre la majorité.

Aucune implémentation précise des récompenses n’a été spécifiée à ce jour.

Benchmarks de performance et résultats de simulation d’Alpenglow

Les simulations d’Anza montrent qu’Alpenglow finalise un bloc en environ 100 à 150 ms, selon que le bloc est notarié par le chemin de finalisation rapide ou celui de secours (c’est-à-dire la finalisation lente). Le chemin de finalisation rapide vise une latence de ~100 ms, tandis que celui de finalisation lente vise une latence de ~150 ms.

Histogramme de latence

La latence réseau impose une limite inférieure fondamentale aux communications de tout système distribué. Par exemple, si le leader se trouve à New York et que la majorité du stake est en Europe, la latence médiane à sens unique nécessaire à un nœud pour envoyer des informations aux autres nœuds du réseau peut atteindre environ 200 millisecondes. La latence est plus faible entre les nœuds géographiquement proches (par exemple, au sein d’un même centre de données ou d’une même région) et nettement plus élevée pour ceux situés dans les pays du Sud ou dans d’autres zones éloignées.

• Réseau : latence réseau nécessaire pour envoyer 1 bit aux autres nœuds via Internet
• Rotor : surcoût de Rotor par rapport à cette limite inférieure
• Notarisation : temps nécessaire pour recevoir les votes notariés de 60 % du stake (un tour de vote supplémentaire est également possible ; une fois les votes reçus, la finalisation peut commencer)
• Finalité : temps de finalisation

La finalité globale d’Alpenglow est deux fois supérieure à la limite inférieure. Autrement dit, la surcharge du consensus multiplie par deux la latence réseau brute minimale. Ainsi, si le trajet à sens unique le plus long entre le leader et la supermajorité du stake est, par exemple, de ~70 ms (soit un RTT de ~140 ms), la finalité par le chemin rapide devrait se situer entre 120 et 150 ms.

L’histogramme de latence issu des simulations d’Anza montre que 65 % du stake atteint la finalité dans les 50 ms suivant la latence réseau brute. Cela signifie que la plupart des validateurs votent presque dès l’arrivée des données.

Avec Alpenglow, les engagements déterministes restent nettement plus rapides que ceux de toute L1 concurrente, rapprochant bien davantage l’expérience on-chain de Solana de celle des services Web2 traditionnels.

Analyse de la sécurité et de la tolérance aux pannes d’Alpenglow

Le consensus d’Alpenglow améliore le consensus BFT traditionnel, qui résiste aux adversaires contrôlant jusqu’à 33 % du stake du réseau. Cette limite est désignée par « 3f + 1 ». Alpenglow l’abaisse à 20 % du stake du réseau en s’appuyant sur la limite 5f + 1 introduite par Martin et Alvisi dans Fast Byzantine Consensus. Il utilise un modèle de résilience « 20+20 », dans lequel la sécurité est divisée en deux volets :

• Pannes byzantines ≤ 20 % : la sûreté est assurée si moins de 20 % du stake total est contrôlé par des validateurs malveillants. Cela représente une somme considérable, chiffrée en milliards de dollars, et ces validateurs seraient faciles à identifier et à sanctionner. Un attaquant risquerait donc de perdre l’intégralité de son stake, ce qui rendrait de telles attaques économiquement non viables.
• Phénomènes non malveillants ≤ 20 % : la vivacité est assurée si, au maximum, 20 % du stake total, indépendamment du stake malveillant, est hors ligne, en panne ou ne participe pas au consensus pour une autre raison. Cela inclut les pannes réseau, les erreurs de configuration et les bugs logiciels. Le réseau peut donc continuer à finaliser des blocs même si une minorité importante de validateurs ne répond pas.

Sûreté

La sûreté est garantie à condition que le stake malveillant total soit ≤20 % et qu’il ne puisse pas empêcher au moins 60 % de participation honnête sur un fork. Ces conditions garantissent que tout seuil de votes considéré comme final par le protocole (c’est-à-dire un tour pour le chemin rapide, deux tours pour le chemin lent) est suffisamment élevé pour empêcher l’obtention d’un seuil contradictoire sur un autre fork. Si des validateurs malveillants tentent de voter de manière équivoque (c’est-à-dire de voter pour deux forks différents ou de produire deux blocs différents dans le même slot), les nœuds honnêtes finiront par recevoir leurs signatures contradictoires. Ce comportement est facile à identifier et devrait idéalement, à l’avenir, constituer une infraction passible de sanctions telles que le slashing. 

De plus, si un leader tentait de produire un bloc non valide, les validateurs honnêtes refuseraient simplement de voter pour celui-ci. Le modèle de communication directe d’Alpenglow pour le vote empêche un acteur malveillant d’isoler ou d’éclipser facilement un nœud honnête disposant de stake, car les votes de la majorité honnête finiront par le démasquer. Dans le meilleur des cas pour lui, un leader malveillant pourrait forcer le consensus à emprunter son chemin plus lent ou provoquer un retard d’un slot, mais il ne pourrait pas bloquer ou faire diverger durablement la chaîne.

Vivacité

La vivacité est garantie dans des conditions de synchronie partielle tant que les seuils de panne sont respectés. Cela signifie qu’après un certain délai réseau, les validateurs honnêtes pourront communiquer et réunir ≥60 % du stake sur un même bloc. Si exactement 20 % du stake total est hors ligne, le chemin rapide peut encore aboutir si tous les nœuds honnêtes restants votent. Si un peu plus de 20 % du stake total est hors ligne, le réseau utilisera systématiquement le chemin de finalisation lente pour un second tour de vote. La finalité reste garantie, bien qu’elle soit plus lente. Les défaillances bénignes affectent donc principalement les performances, et non la sûreté.

Haute résilience aux pannes

Alpenglow est explicitement conçu pour offrir une haute résilience aux pannes et fonctionner dans des conditions réseau difficiles. Autrement dit, Alpenglow restera sûr et opérationnel même avec 20 % de stake malveillant et 20 % de stake qui ne répond pas. 

Ce n’est toutefois pas une solution universelle à toutes les défaillances imaginables. Alpenglow représente une amélioration majeure pour Solana, mais n’élimine pas entièrement le risque d’arrêt ou de panne du réseau si ses hypothèses ne sont pas respectées. La production de nouveaux blocs nécessite ≥60 % du stake, tandis que ≥20 % du stake agissant de manière malveillante pourrait empêcher le consensus ou provoquer une panne. Néanmoins, dans les limites définies, Alpenglow garantit la sûreté et la vivacité en un ou deux tours de vote.

La suppression de la preuve d’historique affaiblit-elle la sécurité ?

Bien qu’elle soit fondamentale pour le fonctionnement actuel de Solana, la suppression de la preuve d’historique n’affaiblit pas la sécurité de manière significative. Comme indiqué précédemment, la limite universelle de 400 ms remplace l’horloge de hachage de la preuve d’historique. Même si le réseau subit des retards importants, le chevauchement du stake de Votor (c’est-à-dire ≥80 % en un tour et ≥60 % + ≥60 % en deux tours) empêche les validateurs honnêtes d’approuver deux forks différents.

Elle modifie toutefois les garanties de vivacité, car celle-ci dépend du message de synchronie : la vivacité est assurée tant que les messages honnêtes arrivent dans ce délai. La diffusion des données en un seul saut de Rotor et les votes tenant dans un seul paquet maintiennent la latence largement dans l’enveloppe des 400 ms, même sous forte charge.

Dans l’ensemble, la suppression de la preuve d’historique éliminera la dépendance au calcul continu de hachages, supprimant ainsi tout vecteur d’attaque fondé sur le blocage du hachage. Comme indiqué ci-dessus, elle modifie également les garanties de vivacité. Mais elle n’affaiblit pas la sécurité de manière significative.

Points clés

Alpenglow échange une légère réduction de la tolérance byzantine contre une finalité déterministe inférieure à une seconde, une gestion souple des grandes pannes bénignes et une identification plus facile des validateurs malveillants. Les principaux enseignements sont les suivants :

• Deux blocs contradictoires ne peuvent pas tous deux être finalisés à moins que ≥20 % du stake ne les signent tous les deux, une action facile à prouver et à sanctionner.
• Solana continuera à finaliser des blocs tant que ≥60 % du stake peut communiquer, même si le reste est hors ligne.
• Dans le pire des cas, la finalité repasse à un second tour de vote avec un objectif de latence de ~150 ms, de sorte que les attaques dégradent la vitesse de la chaîne avant d’en menacer la sûreté.
• Le coût d’un dépassement de la limite byzantine de 20 % est prohibitif, tandis que les infractions moins graves sont détectables et peuvent faire l’objet de sanctions sociales et économiques une fois le slashing activé sur le mainnet.

Quel est l’impact d’Alpenglow sur les validateurs ?

Les coûts de vote constituent le principal obstacle à l’exploitation d’un validateur Solana. Aucun montant minimal strict de SOL n’est requis pour exploiter un validateur. Cependant, l’envoi de transactions de vote à chaque slot, nécessaire pour participer au consensus, peut coûter jusqu’à ~1 SOL par jour.

Alpenglow vise à remplacer les transactions de vote par slot par un système compact de certificats qui supprime, dans les faits, les frais de vote tels que nous les connaissons aujourd’hui. Chaque validateur diffuserait des messages de vote légers à tous les autres nœuds. Une fois le quorum atteint, n’importe quel nœud peut agréger ces signatures dans un certificat au moyen du schéma de signature BLS. Les votes étant désormais agrégés avec BLS, seul l’en-tête du certificat est ancré on-chain. En pratique, cela supprimerait le coût quotidien de ~1 SOL par validateur. 

Comme indiqué précédemment, avec Alpenglow, chaque proposition de bloc est évaluée par deux chemins de vote simultanés :

• Finalisation rapide (un tour)
  • Se déclenche lorsque le total des votes notariés pour un bloc donné atteint ≥80 % du stake au premier tour de vote
  • Produit un certificat de finalisation rapide 
  • Vise une latence de ~100 ms
• Finalisation lente (deux tours)
  • Se déclenche lorsque le total des votes notariés pour un bloc donné atteint ≥60 % du stake au premier tour de vote
  • Produit un certificat de finalisation une fois que le total des votes notariés du second tour atteint ≥60 % du stake
  • Vise une latence de ~150 ms

Votor exécute les deux chemins simultanément. Les deux décomptes sont donc mis à jour à partir du même flux de votes du premier tour, et le premier certificat à franchir son seuil finalise le bloc. Le chevauchement des ensembles de stake (c’est-à-dire ≥60 %) garantit que deux blocs contradictoires ne peuvent jamais tous deux atteindre la finalité.

Les conséquences opérationnelles de cette nouvelle conception sont positives pour les validateurs :

Réduction des coûts opérationnels 

La suppression des frais de vote réduit considérablement l’obstacle à l’entrée pour les futurs validateurs. Ces frais rendaient par ailleurs les petits validateurs plus dépendants des récompenses liées à l’inflation pendant les marchés baissiers. Leur suppression pourrait justifier de futures discussions sur l’inflation de Solana, compte tenu du vote controversé sur SIMD-228. Selon l’implémentation d’Alpenglow actuellement à l’étude, une telle réduction ferait passer le montant minimal de SOL nécessaire pour être rentable de ~4 850 SOL (~800 000 USD) à ~450 SOL (~75 000 USD), d’après les calculs effectués avec le calculateur de rentabilité des validateurs de Cogent Crypto.

Gestion simplifiée des clés 

Les validateurs Solana n’ont plus besoin de signer un vote à chaque slot. La clé d’identité du validateur peut ainsi être conservée dans un module de sécurité matériel (HSM) sans risque pour les performances, ce qui réduit le risque lié aux hot wallets.

Réduction de la charge réseau pendant les slots du leader

L’agrégation d’un certificat par bloc remplace des milliers de transactions de vote individuelles par epoch, ce qui réduit la charge réseau pendant les slots du leader. 

Suppression du calcul des verrouillages

La table de verrouillage exponentiel de type Tower de Solana est supprimée. Les validateurs doivent désormais uniquement conserver en mémoire la chaîne de certificats la plus récente, ce qui raccourcit les temps de redémarrage.

Quel est l’impact d’Alpenglow sur les fournisseurs RPC ?

Les conséquences opérationnelles de cette nouvelle conception sont majoritairement positives pour les fournisseurs RPC, malgré quelques problèmes potentiels de scalabilité :

Simplification des niveaux d’engagement 

Ce nouveau niveau de finalité supprimerait l’écart historique entre les niveaux d’engagement confirmed (c’est-à-dire optimiste) et finalized (c’est-à-dire enraciné). Par exemple, toute logique UX qui attend deux niveaux de confirmation (notamment en affichant un indicateur de chargement jusqu’à la finalisation) pourrait être réduite à une seule vérification de certificat.

Réduction de la taille du registre

Compte tenu de la demande actuelle sur Solana, la croissance du registre diminuerait d’environ trois quarts en raison de la suppression des transactions de vote. Cela réduirait également la taille des snapshots et des archives. Cependant, compte tenu des objectifs prévus d’augmentation de la limite de CU par bloc, il reste à déterminer comment cela se traduira en pratique.

Goulot d’étranglement de la distribution WebSocket

Avec Alpenglow, interroger régulièrement l’état des transactions n’a plus de sens, puisque la finalité arrive en ~100 à 150 ms et est encodée dans un certificat unique. Il serait plus logique de recevoir les informations de finalité via un canal push restant ouvert pendant toute la durée de vie de l’application, du navigateur ou du bot, et diffusant chaque nouveau certificat à tous les clients abonnés. Les difficultés ne concernent plus des millions de petites requêtes HTTP, mais des centaines de milliers de sockets en temps réel.

Actualisation des caches en temps réel

Tout cache conservant les données d’un compte pendant plus d’un quart de seconde pourrait afficher des données obsolètes, puisque les certificats règlent un bloc en 100 à 150 ms. Les caches edge, les CDN et les proxys de couche 7 devront utiliser des TTL extrêmement courts ou des hooks de purge tenant compte des certificats.

Quel est le calendrier de développement d’Alpenglow ?

Alpenglow a été officiellement dévoilé lors de la conférence Accelerate de New York, fin mai. La prochaine phase consiste à publier un Solana Improvement Document (SIMD) officiel, qui ouvrira la proposition aux commentaires de la communauté sur GitHub, les forums de gouvernance de Solana et le Discord Solana Tech.

Après la période d’examen par la communauté, la proposition fera l’objet d’un vote de gouvernance on-chain par la communauté des validateurs. En parallèle, la nouvelle conception sera soumise à des tests approfondis pour en garantir les performances et la sécurité.

Si toutes les étapes se déroulent comme prévu, le déploiement sur le mainnet de Solana devrait avoir lieu au début de l’année prochaine.

Risques et questions ouvertes concernant Alpenglow

Un nouvel algorithme de consensus

La transition vers un nouveau protocole de consensus représente une entreprise majeure, mais il existe un précédent significatif. The Merge d’Ethereum en 2022 a démontré qu’un grand réseau en production pouvait changer avec succès son mécanisme de consensus central, en passant de la preuve de travail à la preuve d’enjeu sans perturber ses opérations. Autrement dit, les risques restent nombreux, mais le terrain n’est pas totalement inexploré.

Une telle transition nécessiterait également des guides de migration afin que les applications, SDKs, wallets et bots ne cessent pas silencieusement de fonctionner lorsqu’Alpenglow fusionnera les niveaux d’engagement confirmed et finalized en une seule vérification de certification. Tout code qui interroge explicitement deux niveaux d’engagement ou utilise par défaut le niveau confirmed cessera de fonctionner. Avant la mise en service d’Alpenglow, un effort coordonné de l’écosystème est nécessaire concernant la documentation, les avertissements des linters, les méthodes RPC et l’architecture générale du code. 

Gouvernance

Le risque lié à la gouvernance est un autre facteur à prendre en compte. Le récent vote sur SIMD-228 montre que Solana fonctionne comme un réseau véritablement décentralisé, où l’adoption des propositions n’est pas garantie, même lorsqu’elles sont soutenues par les développeurs principaux et des membres influents de la communauté. Toutefois, les changements à venir introduits par Alpenglow, notamment la réduction des coûts de vote, sont globalement favorables aux validateurs, en particulier aux plus petits opérateurs. Nous estimons donc que la probabilité d’une opposition au niveau de la gouvernance est relativement faible.

Récompenses

Le livre blanc d’Alpenglow et les documents connexes publiés jusqu’à présent ne précisent pas les mécanismes exacts destinés à récompenser l’activité de vote des validateurs ou à indemniser les relais Rotor pour leur utilisation de la bande passante. Le livre blanc indique aussi clairement que le vote équivoque est passible de sanctions, mais ne précise pas qui soumet effectivement la pénalité, quel est son montant ni si la sanction est automatique ou décidée par la gouvernance. Ces omissions laissent des aspects clés de l’économie des validateurs sans définition et pourraient susciter des débats conflictuels au sein de l’écosystème.

MEV

Alpenglow restructurera également en profondeur le paysage actuel de la MEV sur Solana. La latence reste un facteur déterminant pour la MEV, car certaines stratégies rentables reposent sur la réplication du trafic TPU ou sur l’annulation massive et le remplacement de transactions dans un ordre précis avant qu’elles ne soient confirmées de manière optimiste. Tout cela se produit dans la fenêtre actuelle de ~500 à 600 ms, qu’Alpenglow cherche à réduire à ~150 ms. À première vue, les leaders, en particulier les validateurs qui hébergent déjà une infrastructure personnalisée de construction de blocs, pourraient capter une part plus importante de la MEV. Les arbitragistes indépendants spécialisés dans la latence pourraient quant à eux perdre leur avantage, à moins de continuer à développer des systèmes de trading encore plus rapides et granulaires.

Plusieurs leaders simultanés

La conception d’Alpenglow est bien plus adaptée à l’adoption d’un cadre multi-leaders, appelé Multiple Concurrent Leaders (MCL), que l’architecture de consensus actuelle de Solana. Comme l’a indiqué Anatoly Yakovenko, un premier prototype de MCL pourrait consister à lancer deux instances d’Alpenglow partageant le même ensemble Rotor et diffusant tous les shreds simultanément. Rotor distribuerait les flux parallèles et Votor notarierait chaque voie. Plusieurs questions relatives à la couche d’exécution se posent toutefois. Plus précisément :

• Comment partitionner les ensembles d’écritures afin que les blocs de deux leaders ne verrouillent jamais le même compte ou, si cela se produit, que la résolution du conflit soit à la fois déterministe et peu coûteuse ?
• Comment fusionner les certificats de chaque voie en une racine d’état canonique sans doubler le coût de réexécution ?
• Quelle logique de marché des frais appliquer lorsque les voies sont en concurrence pour les mêmes actifs ?
• Quel type de stratégies MEV inter-voies cela permettrait-il ?
• Un validateur disposant d’un stake élevé pourrait-il dominer les slots simultanés en l’absence de limites par voie ? 

Bien que la conception d’Alpenglow contribue à faire de MCL un élément réaliste de la feuille de route en supprimant les obstacles au niveau du consensus, cela reste une initiative prometteuse pour l’avenir tant que ces questions ouvertes n’auront pas trouvé de réponse.

Conclusion

Ce rapport a étudié les composants fondamentaux d’Alpenglow et examiné la manière dont ils remodèlent le modèle de consensus de Solana. Nous avons également analysé les améliorations techniques, l’évolution de l’économie des validateurs, les effets au niveau du réseau ainsi que les avantages en matière de performances, de simplicité et de scalabilité.

Le livre blanc d’Alpenglow marque un tournant pour Solana, non seulement dans la conception du protocole, mais aussi dans la philosophie de développement. Pour la première fois, Solana a publié des preuves formelles de validité pour son algorithme de consensus, marquant le passage de son approche traditionnellement empirique et axée sur l’ingénierie à des fondations plus rigoureuses, étayées par la recherche. Cette évolution reflète la maturation d’un écosystème qui continue de privilégier les performances, mais y ajoute désormais la rigueur de la vérification formelle.

L’abandon de la preuve d’historique (PoH) représente une évolution tout aussi symbolique de l’identité du réseau. Bien que l’importance pratique de PoH ait souvent été exagérée, cette technologie a longtemps constitué l’innovation emblématique de Solana, occupant une place de choix dans les présentations techniques et devenant synonyme de la marque. Sa suppression marque la fin d’une époque et le début d’une nouvelle. Solana arrive à maturité.

Ressources supplémentaires

• Diapositives de la présentation Accelerate sur Alpenglow - Roger Wattenhofer
• Alpenglow : un nouveau consensus pour Solana - Blog d’Anza
• Implémentation de référence d’Alpenglow - GitHub
• Livre blanc d’Alpenglow - Quentin Kniep, Jakub Sliwinski, Roger Wattenhofer
• Le consensus sur Solana - Blog de Helius
• Scale or Die à Accelerate 2025 : présentation d’Alpenglow, le nouveau consensus de Solana - Vidéo YouTube