Alpenglow sur Solana : comment le consensus du réseau va évoluer

Lorsque l’on parle d’Alpenglow, la prochaine évolution du consensus de Solana, il est facile de se concentrer sur un chiffre : un objectif de finalité proche de 150 millisecondes.

C’est un chiffre marquant, mais il n’explique pas à lui seul l’ampleur du changement.

Alpenglow redessine la manière dont Solana atteint le consensus, coordonne les votes et propage les blocs à travers le réseau. Il introduit également de nouveaux composants, parmi lesquels Votor, les clés publiques BLS et le Validator Admission Ticket (VAT). Ces éléments font partie d’une transition progressive, et non d’une mise à jour unique et instantanée.

Plus qu’une amélioration isolée de la vitesse, Alpenglow prépare une nouvelle architecture pour un réseau qui opère déjà à grande échelle.

Alpenglow est le nouveau protocole de consensus que Solana prépare pour remplacer les mécanismes actuels de Proof of History et de TowerBFT.

Sa première phase se concentre sur Votor, un algorithme de vote conçu pour réduire la latence de finalité et simplifier la coordination entre validateurs. Dans le modèle actuel, les votes sont envoyés sous forme de transactions on-chain. Avec Votor, les validateurs échangeront directement des messages de vote et utiliseront des certificats cryptographiques agrégés pour prouver que le consensus a été atteint.

Le design prévoit deux chemins pour finaliser les blocs :

• un chemin rapide, où un bloc peut être finalisé en un tour lorsqu’il atteint le seuil de participation requis ;
• un second tour dans les cas où ce seuil n’est pas atteint dès le départ.

Solana vise une finalité d’environ 150 ms, contre une préconfirmation actuelle proche de 400 ms et une finalité TowerBFT d’environ 12,8 secondes.

Cela ne doit pas être interprété comme une performance déjà disponible sur mainnet. Il s’agit de l’objectif d’un changement de consensus encore en cours de déploiement et de validation.

Le changement central apporté par Alpenglow est Votor.

Au lieu de transformer chaque vote de validateur en transaction on-chain, Votor permet aux votes d’être transmis directement entre les participants. Ces votes sont ensuite agrégés dans des certificats qui reflètent l’état du consensus : notarisation, finalisation ou décision d’ignorer un bloc.

Cette approche vise à réduire une partie de la charge réseau associée aux transactions de vote et à permettre une finalité plus rapide.

Le protocole introduit également un modèle de résilience appelé 20+20. Il est conçu pour maintenir la liveness du réseau même si jusqu’à 20 % du stake se comporte de manière adversariale et que 20 % supplémentaires restent offline.

Il ne s’agit donc pas seulement de traiter les transactions plus rapidement. Il s’agit de revoir la manière dont un vaste réseau de validateurs se coordonne.

Alpenglow ne s’arrête pas au vote.

Une phase ultérieure, appelée Rotor, devrait remplacer progressivement Turbine, le système actuel de propagation des blocs de Solana. Rotor conservera l’utilisation de l’erasure coding, mais passera d’un modèle de distribution en arbre à une couche unique de relays.

L’objectif est de réduire la latence de distribution des données entre les nœuds.

Cette distinction est importante : Votor et Rotor suivent la même direction technique, mais ne seront pas déployés au même moment. La transition initiale se concentre sur la logique de vote et de finalité ; Rotor suivra dans une phase ultérieure.

Pour permettre à Votor d’agréger plusieurs signatures dans un même certificat, Solana a besoin d’un schéma de signature différent de celui actuellement utilisé dans les vote accounts.

C’est là qu’interviennent les clés publiques BLS.

Les signatures BLS permettent de combiner de nombreuses signatures sur un même message en une seule preuve vérifiable. Les certificats de consensus peuvent ainsi représenter la participation de nombreux validateurs sans devoir vérifier chaque signature individuellement.

La gestion des clés publiques BLS est déjà active sur mainnet. Chaque validateur a besoin d’une clé BLS supplémentaire pour se préparer au nouveau modèle. Elle ne remplace pas l’identité ed25519 actuelle du vote account, mais ajoute une couche cryptographique spécifique à Alpenglow.

C’est un prérequis technique important, mais l’enregistrement d’une clé publique BLS n’active pas Alpenglow à lui seul.

Le Validator Admission Ticket, ou VAT, est un feature gate distinct qui définit quels validateurs peuvent rejoindre le set admis à participer au consensus.

Une fois actif sur mainnet, le VAT imposera deux conditions principales :

• disposer d’une clé publique BLS enregistrée ;
• figurer parmi les 2 000 validateurs ayant le plus de stake à chaque epoch.

Un validateur qui ne remplit pas ces conditions est exclu du set admis, cesse de voter et ne perçoit plus de récompenses d’inflation tant qu’il reste en dehors de ce set.

Le VAT ne doit pas être confondu avec le slashing. Il ne s’agit pas d’une pénalité pour comportement malveillant ou incident opérationnel. C’est un mécanisme d’admission qui prépare le réseau au modèle de consensus d’Alpenglow.

Il est également essentiel de distinguer le VAT de l’activation complète de Votor :

BLS prépare les clés. VAT contrôle l’admission. Alpenglow transforme le consensus.

Le changement de consensus modifie également la structure de certains coûts opérationnels du réseau.

Avec TowerBFT, les validateurs envoient des transactions de vote on-chain. Solana estime ces coûts à environ 2 SOL par epoch pour un validateur qui participe activement.

Avec Alpenglow, les votes ne seront plus publiés sous forme de transactions on-chain. Les validateurs admis paieront à la place une commission fixe de 1,6 SOL par epoch via le VAT.

Cette commission sera brûlée, plutôt que redistribuée comme rémunération aux block producers.

L’intention initiale est de maintenir une barrière économique comparable aux coûts actuels de vote, dans une architecture différente. Cela ne signifie pas que les récompenses évolueront automatiquement dans une direction précise. L’économie finale de chaque opération dépendra toujours du stake, des récompenses du réseau, des commissions, des coûts d’infrastructure et de la performance effective.

Un changement de consensus modifie aussi les métriques à suivre et la manière de les interpréter.

Jusqu’à présent, une part importante de la visibilité sur les validateurs Solana provient des transactions de vote on-chain, des crédits de vote et de l’activité associée. Avec Votor, les votes ne suivront plus exactement le même flux.

Les certificats et agrégats continueront de fournir des preuves d’activité de consensus, mais les outils de monitoring devront intégrer ce nouveau contexte pour que les métriques restent utiles et comparables.

Chez Stakely, nous travaillons déjà à rendre les opérations sur Solana plus visibles grâce au Solana TVC Live Tracker, un outil open source qui suit l’état des votes, les crédits et l’activité des validateurs dans le modèle actuel.

Alpenglow renforce l’importance de cette observabilité : il ne suffit pas qu’un réseau soit rapide. Son fonctionnement doit aussi pouvoir être compris.

Alpenglow sera déployé en plusieurs phases. Les clés publiques BLS préparent déjà les validateurs au nouveau modèle, le VAT établira les conditions d’admission et Votor modifiera la manière dont Solana atteint la finalité. Rotor étendra ensuite cette évolution à la propagation des blocs.

L’essentiel n’est pas d’anticiper une date fixe ni de tenir pour acquis un résultat de performance avant que le déploiement soit terminé.

Alpenglow représente un changement profond dans la manière dont Solana coordonne le consensus : moins de dépendance aux transactions de vote on-chain, des certificats cryptographiques agrégés, un objectif de finalité beaucoup plus rapide et une nouvelle structure d’admission et de coûts pour le réseau.

Chez Stakely, nous continuerons à suivre cette transition à travers notre expérience d’opérateur d’infrastructure sur Solana. Vous pouvez staker vos SOL avec Stakely directement depuis votre propre wallet tout en gardant le contrôle de vos actifs.