Solana se prépare à tester sur son testnet public un objectif de finalité considérablement plus rapide. Anza, le studio de développement derrière le client validateur Agave, a placé Alpenglow sous « Pending Testnet Activation » dans son traqueur officiel de feature gates, mis à jour le 22 septembre. Cette inscription signifie que la fonctionnalité attend désormais une activation sur le testnet public, aucun epoch d'activation n'ayant été publié à ce jour.

L'entrée identifie la fonctionnalité comme « SIMD-0326: Alpenglow: new consensus algorithm » et l'assigne à Agave v4.3.0. Les champs correspondant à l'epoch d'activation sur le testnet et à la date d'activation restent vides. Agave v4.3.0 est également indiquée comme le prochain plancher de version attendu sur le testnet — c'est-à-dire la plus ancienne version logicielle que les validateurs peuvent exécuter tout en restant compatibles avec ce réseau. Anza décrit son calendrier comme provisoire ; l'inscription ne constitue donc pas une date d'activation garantie.

Ce que l'objectif de 150 ms mesure réellement

Selon la documentation officielle des mises à niveau de Solana, Alpenglow vise à réduire la finalité d'environ 12,8 secondes à environ 150 millisecondes. Si cet objectif est atteint, la finalité serait environ 85 fois plus rapide.

La finalité est le point auquel les validateurs sont parvenus à un consensus suffisant pour qu'un bloc soit considéré comme irréversible. Ce n'est pas simplement le moment où une transaction apparaît pour la première fois sur le réseau. Aujourd'hui, une application peut voir une transaction Solana comme « confirmée » avant qu'elle ne reçoive le statut plus fort de « finalisée » du réseau. Alpenglow est conçu pour faire converger ces deux étapes, car un certificat de finalisation pourrait arriver dans un délai proche de celui actuellement associé à une confirmation initiale.

Trois horloges peuvent régir un seul paiement

• Exécution : la transaction s'exécute et apparaît initialement dans un bloc.
• Finalité du protocole : les validateurs établissent que le bloc ne doit plus être annulé.
• Libération par le service : un exchange, un bridge ou un commerçant décide du moment où il crédite le dépôt, libère les actifs ou finalise la commande.

Alpenglow raccourcirait la deuxième horloge. Chaque entreprise continuerait de contrôler la troisième, ce qui signifie qu'un objectif protocolaire de 150 ms ne garantirait pas que chaque paiement destiné au client se termine en 150 millisecondes.

Comment Alpenglow modifie le consensus de Solana

La première étape d'Alpenglow introduit Votor, un remplacement du processus de vote utilisé par le système de consensus TowerBFT actuel de Solana. Actuellement, les validateurs soumettent leurs votes sous forme de transactions et construisent la finalité sur une séquence de slots. Avec Votor, ils échangeraient directement leurs votes et les combineraient en certificats montrant qu'une part suffisante du stake a approuvé un bloc.

Un bloc pourrait être finalisé après un seul tour de vote lorsque la participation arrive rapidement. Un second tour serait disponible lorsque les conditions du réseau empêchent la voie la plus rapide.

🚨 Testnet operators: Alpenglow activation on testnet only runs on Agave. If you're on Firedancer or Frankendancer today, switch over to an Agave node before the migration window so your stake counts toward activation. Details in the thread below 👇

— Anza (@anza_xyz) September 22, 2026

La mise à niveau ne modifie ni l'exécution des contrats intelligents, ni le calcul des soldes, ni la manière dont les utilisateurs soumettent des transactions ordinaires. Elle change la façon dont les validateurs conviennent que le bloc résultant est final.

Solana a également modifié ce que les transactions peuvent contenir. Sa récente augmentation de la taille maximale des transactions a créé davantage d'espace pour les signatures, les instructions et les preuves. Cette mise à niveau change ce qui peut tenir dans une transaction ; Alpenglow change la vitesse à laquelle le réseau peut la considérer comme irréversible.

Là où une finalité plus rapide pourrait faire la différence

• Exchanges : une plateforme pourrait créditer un dépôt Solana plus tôt, bien que les vérifications d'identité, le filtrage des portefeuilles et les contrôles de risque internes puissent encore retarder l'accès aux fonds.
• Bridges : un bridge pourrait vérifier plus tôt le côté Solana d'un transfert, mais ses relayers et la blockchain de destination continueraient d'opérer selon des calendriers distincts.
• Commerçants : si la finalité blockchain est le maillon le plus lent du paiement, un processeur de paiement pourrait confirmer plus tôt un paiement irréversible et commencer à traiter la commande.

L'amélioration serait plus visible là où un service attend actuellement la garantie de règlement la plus forte de Solana. Elle aurait moins d'effet lorsque des contrôles de conformité, une autre blockchain ou un système de paiement hors chaîne provoquent déjà le plus grand délai.

L'activation suivie ne prend actuellement en charge qu'Agave

Solana peut être exploité via des clients validateurs développés de manière indépendante. Agave est maintenu par Anza, tandis que Firedancer et Frankendancer offrent des implémentations alternatives. L'entrée actuelle d'Alpenglow assigne la fonctionnal à Agave v4.3.0 et marque Firedancer et Frankendancer comme non pris en charge.

L'entrée décrit la feature gate en attente sur le testnet ; elle n'établit pas quels clients prendront en charge Alpenglow au moment où une activation sur le mainnet sera envisagée. Aucune date d'ajout de prise en charge pour l'un ou l'autre des clients alternatifs n'apparaît dans le traqueur. Leur préparation demeure donc une question de déploiement ouverte plutôt que la preuve qu'ils ont été définitivement écartés.

Ce que l'activation sur le testnet devra prouver

• Migration : les validateurs peuvent-ils changer de système de consensus sans interrompre la production de blocs ?
• Vitesse observée : la finalité mesurée s'approche-t-elle de 150 ms plutôt que de simplement atteindre l'objectif dans des tests contrôlés ?
• Retards du réseau : la finalité reste-t-elle fiable lorsque les validateurs ou les connexions Internet répondent lentement ?
• Distribution de l'infrastructure : les fournisseurs RPC et les indexeurs reçoivent-ils les nouvelles données de finalité rapidement et de manière cohérente ?
• Préparation des clients : quand des implémentations supplémentaires de validateurs pourront-elles prendre en charge le nouveau système de consensus ?

Le chiffre de 150 ms est une attente, pas une constante. La documentation de Solana indique que la finalité peut varier selon la distribution du stake et selon qu'un bloc nécessite un ou deux tours de vote. Certaines infrastructures peuvent également apprendre qu'un bloc a été finalisé plus tard que les validateurs produisant directement le certificat.

Même un résultat réussi sur le testnet ne garantirait pas des performances identiques sur le mainnet. La participation des validateurs, la distribution du stake et le trafic réseau peuvent différer entre les deux environnements.

Un epoch d'activation lancera le véritable test

La prochaine étape vérifiable sera la publication d'un epoch d'activation ou une annonce officielle indiquant que la feature gate s'est ouverte. Les données publiques du testnet pourront alors montrer à quel point Alpenglow se rapproche de son objectif et à quelle vitesse le signal de finalité qui en résulte atteint les portefeuilles et les infrastructures.

Pour les entreprises de paiement, un accord plus rapide entre validateurs n'est utile que si elles reçoivent cette information suffisamment vite pour modifier le moment de la libération des fonds. L'epoch d'activation lancera ce test ; il ne tranchera pas la question à lui seul.

Cet article est fourni à titre d'information uniquement. Les calendriers du réseau, la prise en charge par les clients validateurs et la finalité mesurée peuvent évoluer à mesure que les tests progressent.

Source : Solana Prepares to Test 150ms Finality — Coindoo