Solana sait déjà produire des blocs rapidement. Ce qu'elle ne fait pas aussi vite aujourd'hui, c'est déclarer définitivement qu'un bloc ne sera plus réorganisé.

Avec TowerBFT, la finalité complète arrive après l'accumulation de votes sur 32 slots, soit environ 12,8 secondes dans le fonctionnement actuel décrit par la Fondation Solana. Alpenglow vise environ 150 millisecondes.

Le chiffre est spectaculaire : un peu plus de 98 % de réduction. Il faut cependant préciser ce qu'il mesure. Les 150 ms concernent la finalité, pas la durée d'un slot. Solana travaille séparément à faire passer les slots de 400 à 200 ms.

Votor sort les votes des transactions

La première phase d'Alpenglow s'appelle Votor. C'est elle qui doit arriver avec Agave 4.3.

Aujourd'hui, les validateurs votent notamment au moyen de transactions inscrites dans les blocs. Votor change ce mécanisme : les votes sont envoyés directement entre validateurs puis agrégés sous forme de certificats. Selon les conditions, un bloc peut être finalisé en un ou deux tours.

Conséquence assez concrète : les transactions de vote disparaissent des blocs. Les tableaux de bord qui comptaient naïvement toutes les transactions pour calculer un TPS devront recalibrer leurs métriques, même si l'activité utilisateur n'a pas chuté.

Le protocole est conçu autour d'un modèle dit 20+20. Solana indique qu'il doit continuer à parvenir au consensus avec jusqu'à 20 % de stake adversarial et 20 % supplémentaire hors ligne, sous les hypothèses prévues par Alpenglow.

150 ms ne veut pas dire que tout Solana change

L'exécution reste séparée de cette migration. La Solana Virtual Machine, les programmes, le format des transactions, les comptes et le mécanisme de frais ne sont pas remplacés par Alpenglow.

C'est le consensus qui bouge : comment les validateurs choisissent un bloc et à quel moment ils le considèrent final.

Rotor, la seconde grande composante d'Alpenglow, doit ensuite remplacer Turbine pour la propagation des blocs. Au lieu de l'organisation actuelle en arbre, Rotor prévoit une couche de relais unique afin de réduire la latence. Cette partie n'est pas prévue dans l'activation initiale de Votor et n'a pas encore de calendrier définitif.

Les indexeurs vont devoir oublier l'idée d'un seul bloc par slot

Pour les applications qui se contentent de signer et d'envoyer des transactions, la migration doit être largement transparente. Les infrastructures qui consomment directement les flux de validateurs ont davantage de travail.

Agave 4.3 ajoute notamment un bank_id aux événements diffusés par Geyser et gRPC. La raison est structurelle : avec l'évolution d'Alpenglow et le fast leader handoff prévu ensuite, plusieurs banques candidates pourront apparaître pour un même slot avant qu'une seule soit retenue.

Les indexeurs ne doivent donc plus utiliser uniquement le numéro de slot comme clé. Solana recommande de bufferiser les événements par couple slot et bank_id, puis de promouvoir la banque qui atteint l'état confirmé.

Petit piège supplémentaire : bank_id est local au nœud. Deux fournisseurs RPC peuvent attribuer des valeurs différentes à la même banque. Les infrastructures multi-provider doivent les réconcilier par blockhash, pas par bank_id.

Confirmed et finalized finiront par vouloir dire la même chose

Alpenglow modifie aussi un vocabulaire que beaucoup d'applications Solana ont intégré dans leur logique.

Une fois le nouveau consensus actif, les niveaux confirmed et finalized doivent converger. Solana recommande toutefois de ne pas passer prématurément les applications sur finalized : tant que TowerBFT est encore utilisé, cette valeur implique toujours l'attente actuelle d'environ 12,8 secondes.

Les timeouts, interfaces de paiement et mécanismes de retry calibrés autour de cette latence devront donc être revus au moment réel de la migration du cluster, pas sur une simple date inscrite dans un calendrier.

Agave 4.3 ajoute aussi de la cryptographie que les programmes faisaient mal eux-mêmes

Le changement de consensus partage la feuille de route avec une évolution plus discrète mais très intéressante pour les développeurs de protocoles ZK.

Solana prépare des syscalls natifs pour des opérations sur BN254 G2 et BLS12-381. Aujourd'hui, lorsqu'une primitive de courbe elliptique n'est pas fournie par le runtime, un programme doit l'implémenter en BPF. C'est possible, mais coûteux en compute units.

SIMD-0302 étend les opérations natives existantes sur BN254 avec l'addition, la soustraction et la multiplication scalaire sur les points G2. La Fondation Solana estime un gain de l'ordre de 10 à 20 fois en compute par rapport aux implémentations purement BPF.

Ce n'est pas un micro-benchmark sans usage évident. Le G2 natif facilite notamment la vérification groupée de preuves Groth16 et certaines constructions basées sur des engagements polynomiaux KZG.

BLS12-381 apporte une seconde famille de courbes

SIMD-0388 va plus loin en introduisant des syscalls pour BLS12-381 : opérations G1 et G2, validation de points, pairings et décompression.

BLS12-381 est largement utilisée dans des systèmes cryptographiques modernes et vise environ 128 bits de sécurité. L'intégrer au runtime évite à chaque protocole de payer le coût exorbitant d'une réimplémentation complète à l'intérieur de son programme.

Pour des applications ZK, des ponts ou des protocoles utilisant des signatures BLS, la différence peut être assez brutale : une primitive qui occupait une part problématique du budget de calcul devient une opération native exécutée directement par le validateur.

La vraie mise à niveau est dans les hypothèses du réseau

Alpenglow est souvent présenté comme le passage de 12,8 secondes à 150 ms. C'est l'accroche facile, et elle n'est pas fausse.

Mais le changement le plus profond est ailleurs. Les votes ne sont plus des transactions ordinaires, les certificats deviennent une partie centrale du consensus, les indexeurs doivent gérer plusieurs banques candidates et le runtime gagne de nouvelles primitives cryptographiques dédiées aux systèmes ZK modernes.

La feuille de route actuelle place Agave 4.3 en octobre 2026. Alpenglow reste indiqué comme en développement, et les nouvelles primitives cryptographiques sont elles aussi annoncées pour le quatrième trimestre. Tant que l'activation mainnet n'a pas eu lieu, 150 ms reste donc une cible de protocole, pas une performance garantie à chaque transaction sur le réseau public.