Le nombre de transactions de Solana et, avec lui, son chiffre headliné de transactions par seconde (TPS) ont chuté lorsque le réseau a activé Alpenglow le 21 octobre. La documentation de mise à niveau de la Solana Foundation qualifie cette baisse de « changement comptable, et non de régression de débit ». Ce cadrage laisse néanmoins une question à quiconque lit un graphique Solana : l'activité a-t-elle réellement diminué, ou seulement le décompte ? La réponse dépasse le cadre d'un simple jour de mise à niveau, car le TPS figure parmi les indicateurs de débit les plus cités dans la couverture blockchain, et le décompte de Solana après le 21 octobre est établi selon une définition différente de tous les chiffres publiés auparavant.

Ce qu'Alpenglow a retiré de la liste des transactions

Sous TowerBFT, le système de consensus que Solana utilisait jusqu'au 21 octobre, les validateurs exprimaient leurs votes sous forme de transactions ordinaires. Les blocs en comptaient des centaines aux côtés des paiements, des swaps et d'autres trafics applicatifs, et tout décompte du total des transactions incluait ce trafic de votes. Comme ces votes provenaient des validateurs plutôt que des utilisateurs, une part de chaque chiffre de TPS d'avant la mise à niveau reflétait la machinerie de consensus du réseau plutôt que la demande pour ses applications.

Alpenglow remplace ce mécanisme par Votor, un protocole dans lequel les validateurs échangent directement leurs votes et les regroupent en certificats. Ces certificats figurent dans le pied de chaque bloc plutôt que dans sa liste de transactions, de sorte qu'un compteur tallyant les transactions cesse de voir les votes dès la bascule.

Ce que montrent les blocs de transition

Coindoo a examiné les blocs situés de part et d'autre de la bascule via le RPC public du mainnet de Solana, l'interface exposée par les nœuds pour lire les données de la chaîne, en utilisant sa méthode getBlock. Chaque bloc occupe un slot, une fenêtre d'environ 400 millisecondes. TowerBFT a fonctionné pendant les 5 000 premiers slots de l'époque avant qu'Alpenglow ne le remplace.

Le dernier bloc TowerBFT est arrivé à 13:54:00 UTC le 21 octobre, et le premier bloc Alpenglow a suivi à 13:54:03, sans qu'aucun bloc ne soit produit dans les huit slots qui les séparent. Environ trois transactions sur cinq dans le dernier bloc TowerBFT, soit 649 transactions au total, étaient des votes de validateurs ; un bloc plus tard, il n'y en avait plus aucune. Le bloc Alpenglow était néanmoins le plus grand des deux. Une simple paire de blocs ne peut pas indiquer si l'activité du réseau a augmenté ou diminué ; elle illustre le mécanisme. Mesurer une tendance exige des milliers de blocs.

Les votes ne sont pas le seul bruit dans le décompte

Les échecs ajoutent une deuxième couche. En lisant le champ d'erreur dans les métadonnées de chaque transaction, Coindoo a constaté que 844 des 1 701 transactions du premier bloc Alpenglow ont rencontré une erreur d'exécution, laissant 857 transactions réussies. Une transaction échouée est toujours facturée et demeure dans le bloc, mais elle n'a réalisé aucun paiement ni échange. Le cadrage de « changement comptable » ne couvre que la couche des votes, de sorte que même un décompte sans votes nécessite un filtre sur le champ d'erreur avant de décrire le travail réellement accompli.

Les transactions réussies ne correspondent pas non plus à des personnes. Un compte de trading automatisé peut envoyer des transactions en grand nombre, et une seule transaction peut contenir plusieurs instructions. Compter ce que les transactions ont réellement accompli, comme des swaps finalisés ou des transferts de tokens, se rapproche davantage de l'usage réel que tout total brut de transactions.

Où se trouvent les données de comparaison

La méthode getRecentPerformanceSamples de Solana indique, pour chaque échantillon, le nombre total de transactions, le nombre hors votes et la durée de l'échantillon en secondes. Diviser un décompte par la durée donne un taux moyen pour cette fenêtre.

La méthode renvoie au maximum 720 échantillons d'environ une minute chacun, soit environ les 12 dernières heures. Une requête effectuée plus d'une demi-journée après la transition ne remonte plus jusqu'à TowerBFT, de sorte que le côté antérieur à la mise à niveau de toute comparaison doit provenir d'échantillons stockés plus tôt ou de blocs historiques.

Trois filtres, appliqués de manière identique avant et après la bascule, rendent la comparaison significative :

1. Retirer les votes des validateurs. Alpenglow le fait côté nouveau ; l'ancien côté exige de le faire manuellement.
2. Retirer les transactions échouées en utilisant le champ d'erreur de chaque transaction. Le décompte hors votes de l'API les inclut toujours.
3. Comparer des fenêtres de temps équivalentes : des moyennes d'une minute contre des moyennes d'une minute, jamais un pic de tableau de bord contre un total quotidien.

Les outils lisent les votes doivent être réadaptés

Les transactions de vote faisaient plus que gonfler le TPS. Les outils de surveillance lisaient les instructions du programme de Vote dans la liste des transactions pour suivre quels validateurs participaient. Avec Alpenglow, cette entrée a disparu, et la Foundation dirige ces outils vers les certificats de vote dans les pieds de bloc. Un suiveur lisant encore l'ancienne source montrerait des validateurs devenus silencieux alors qu'ils continuent de voter.

Pour les chiffres d'usage de Solana, le nombre utile arrivera lorsque plusieurs jours de transactions hors votes réussies pourront être confrontés aux données antérieures à la mise à niveau couvrant les mêmes heures. D'ici là, tout graphique de TPS headliné englobant le 21 octobre mélange le changement comptable avec de véritables changements d'usage.

Source : Coindoo