La prochaine refonte majeure du consensus de Solana, Alpenglow, doit commencer son déploiement sur le mainnet le 21 octobre 2026 — et elle pourrait produire un effet secondaire auquel peu d'observateurs occasionnels s'attendent : une chute brutale, purement statistique, du nombre de transactions rapporté du réseau.

Selon la documentation Alpenglow de la Solana Foundation, l'epoch 1064 devrait débuter vers 15h00 UTC le 21 octobre. Le calendrier des epochs pouvant dériver, cette heure n'est qu'une estimation et non un moment d'activation fixe. Les epochs sont de longues séquences de slots qui structurent le registre de Solana ; leurs limites évoluent donc avec la production effective de blocs — un point utile à connaître pour quiconque suit le déploiement en temps réel. TowerBFT restera en place pendant les 5 000 premiers slots de l'epoch — environ 18 minutes — après quoi le consensus Alpenglow prendra le relais au slot 459 653 000.

La version mainnet s'articule autour de Votor, le nouveau protocole de vote et de finalité d'Alpenglow, qui vise une finalité des blocs d'environ 150 millisecondes — contre environ 12,8 secondes avec le système TowerBFT actuel. Rotor, un composant distinct d'Alpenglow conçu pour remplacer le système de propagation de blocs Turbine de Solana, est prévu pour une version ultérieure et n'a pas encore de date mainnet. Cette approche par étapes limite l'activation d'octobre aux seuls changements de consensus.

Une mise à niveau différente selon le point de vue

La distinction est importante. Alpenglow est conçu pour laisser intacte l'expérience ordinaire des portefeuilles, tandis que l'infrastructure qui produit, diffuse et interprète les données de Solana changera de manière substantielle. Les utilisateurs quotidiens ne devraient pas modifier leur façon de soumettre des transactions ; le travail d'adaptation incombe aux opérateurs de validateurs, aux fournisseurs d'infrastructure et aux plateformes de données.

Votor remplace votes on-chain par des certificats de validateurs

Le consensus est le processus par lequel les validateurs d'une blockchain s'accordent sur les blocs valides. Avec le consensus TowerBFT actuel de Solana, les validateurs émettent leurs votes sous forme de transactions on-chain. Ces votes s'accumulent sur 32 slots avant qu'un bloc n'atteigne la finalité, d'où l'attente d'environ 12,8 secondes pour la garantie de règlement la plus forte.

Votor retire ces votes du bloc lui-même. Les validateurs se les envoient directement entre eux et les agrègent en certificats, permettant à un bloc d'atteindre la finalité en une ou deux rondes de vote.

L'objectif de 150 millisecondes désigne le temps nécessaire pour qu'une transaction devienne finale — c'est-à-dire irréversible. Cela ne signifie pas que Solana produira un nouveau bloc toutes les 150 millisecondes ; la durée des slots a été réduite séparément à 200 millisecondes en octobre.

Pour les services qui attendent la finalité avant de créditer un dépôt, de livrer des biens ou de finaliser un transfert, ce changement pourrait éliminer une grande partie du délai créé par le propre processus de consensus de Solana. Il n'élimine pas les délais imposés par les contrôles de risque des plateformes d'échange, les bridges, les prestataires de paiement ou d'autres chaînes. Le bénéfice importe surtout dans les flux de travail où une partie attend une garantie de règlement plus forte avant de finaliser l'autre versant d'une transaction. L'outil d'escrow livraison contre paiement de Solana est un exemple d'infrastructure pouvant bénéficier d'une finalité plus rapide sans que les utilisateurs aient à changer leur façon de soumettre des transactions.

La suppression des votes transformera les données de transaction de Solana du jour au lendemain

Le changement le plus visible pour les analystes ne sera peut-être pas la finalité. Les transactions de vote n'apparaîtront plus dans les blocs Solana avec Votor. Ces votes étant enregistrés dans les blocs comme n'importe quelle autre transaction, les tableaux de bord qui totalisent tout le contenu d'un bloc les ont longtemps comptés dans le débit global — et comme ils représentaient une grande part des transactions comptabilisées, le nombre total de transactions et les chiffres de TPS peuvent fortement ch après l'activation.

Ce serait un changement de comptabilisation, et non la preuve que Solana a soudainement perdu des utilisateurs ou de la demande applicative. Un tableau de bord qui continue de comparer les totaux post-Alpenglow aux chiffres d'avant la mise à niveau sans ajuster sa référence pourrait signaler à tort un effondrement de l'activité du réseau.

Avant de conclure que « les transactions Solana ont baissé, donc l'utilisation de Solana a baissé » après le 21 octobre, vérifiez si le tableau de bord inclut les votes de validateurs antérieurs à la mise à niveau dans sa référence historique. Si c'est le cas, le nombre de transactions global n'est plus directement comparable. Les recommandations de Solana elle-même invitent les indexeurs et les tableaux de bord de débit à recalibrer leurs données, et les outils qui mesuraient la participation en analysant les instructions du Vote Program doivent passer aux certificats portés dans le pied de bloc d'Alpenglow.

Utiliser un panier de métriques d'activité après la mise à niveau

Aucune métrique unique ne peut décrire la demande du réseau. Une fois les transactions de vote disparues, la lecture la plus fiable combinera plusieurs mesures plutôt que de considérer le TPS total comme un verdict à lui seul :

• Transactions hors vote : mesure directe des transactions générées en dehors du vote des validateurs.
• Payeurs de frais actifs : meilleur indicateur de l'ampleur de la participation que les simples totaux de transactions.
• Nombre et valeur des transferts de stablecoins : utiles pour suivre l'activité de paiement et de règlement.
• Volume DEX et traders uniques : ensemble, ils apportent plus de contexte que le volume seul.
• Revenus de frais : complémentaire aux métriques utilisateurs, bien qu'ils puissent aussi varier selon les conditions de frais et l'intensité des échanges.

Cette approche rend les comparaisons post-mise à niveau plus honnêtes. Si le TPS total baisse alors que les transactions hors vote, les payeurs de frais actifs et le volume applicatif restent stables, le réseau a modifié sa comptabilisation — pas nécessairement sa demande.

Qu'est-ce qui montrera si le déploiement a réussi ?

Le premier test est la finalité réalisée. Le réseau devra démontrer que les blocs atteignent la finalité proche de l'objectif annoncé, sans instabilité significative ni hausse des slots ignorés.

Le deuxième est la préparation opérationnelle. Les validateurs doivent migrer vers des clients Agave compatibles ; Firedancer et Frankendancer ne sont pas pris en charge pendant la transition. Les utilisateurs d'indexeurs et de RPC/Geyser doivent également gérer le nouveau champ bank_id, car un slot peut contenir plusieurs blocs candidats.

Le troisième est la continuité des données. Les explorateurs, les plateformes d'analyse et les médias devront distinguer la baisse du nombre de votes de validateurs d'une demande applicative plus faible avant de tirer des conclusions des graphiques de transactions post-mise à niveau de Solana.

Finalité plus rapide, TPS obsolète

La promesse immédiate d'Alpenglow est une finalité bien plus rapide sans changer la façon dont les utilisateurs ordinaires envoient des transactions. Sa conséquence moins évidente est que les statistiques d'activité habituelles de Solana devront être réinitialisées une fois les votes de validateurs disparus des blocs. Après le 21 octobre, une baisse du nombre de transactions global doit d'abord être traitée comme une question de mesure. Seul un déclin simultané de l'activité hors vote, des payeurs de frais actifs et de l'usage au niveau des applications soutiendrait la conclusion que la demande elle-même s'est affaiblie.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d'investissement. Le calendrier d'activation du mainnet et les performances dépendent des conditions du réseau et de la préparation de l'implémentation.

Source : Coindoo