Technologie & IA
Solana : pourquoi les slots et la finalité ne mesurent pas la même vitesse
La documentation d’Alpenglow distingue des slots de 200 ms et une finalité visée autour de 150 ms. Comprendre ces indicateurs évite de comparer des durées qui ne décrivent pas la même étape.
Adrien VauclairNom de plume de la rédaction
Un créneau de production n’est pas une confirmation
Les annonces de performance d’une blockchain rassemblent souvent plusieurs durées sous le même mot : vitesse. Sur Solana, la documentation actualisée en octobre 2026 distingue pourtant le temps de slot, la production d’un bloc et sa finalité. Ces différentes mesures décrivent chacune une fonction particulière dans le fonctionnement du réseau et le traitement de ses opérations. Elles ne peuvent pas être échangées dans un titre sans modifier le sens de l’information.
02Le fonctionnement, pas à pas+
Un slot est une fenêtre pendant laquelle un producteur désigné dispose de son tour pour construire. Un bloc rassemble les transactions proposées. La finalité correspond à l’accord du réseau qui permet de considérer ce bloc comme définitivement retenu selon les règles du protocole. Le délai de production et celui de l’accord ne partent donc pas nécessairement du même point.
Deux évolutions distinctes sur le réseau
03Les points à retenir+
La Fondation Solana indique que la durée des slots a été réduite séparément de 400 à 200 millisecondes, par étapes achevées en octobre. Alpenglow concerne surtout le consensus : il vise une finalité autour de 150 millisecondes, contre environ 12,8 secondes avec TowerBFT. Le premier changement organise le calendrier de production ; le second modifie la manière dont les validateurs s’accordent.
Il n’y a donc pas de contradiction à voir une finalité annoncée plus courte qu’un slot. Les deux chiffres ne représentent pas la durée totale du parcours d’un utilisateur, depuis son clic jusqu’à l’affichage dans un portefeuille. Une interface, un fournisseur de données ou une application peut encore ajouter ses propres délais de traitement et de présentation.
Les statistiques doivent suivre ce qui est réellement compté
Avec Alpenglow, les votes de consensus sont échangés entre validateurs plutôt qu’inscrits comme des transactions ordinaires dans les blocs. Une série qui additionnait auparavant ces votes peut donc changer de niveau sans que cette variation décrive directement une baisse du nombre de paiements ou d’échanges effectués par les utilisateurs.
Pour comparer deux périodes, il faut conserver une définition cohérente des transactions suivies. La même précaution vaut pour un débit annoncé : un nombre d’opérations par seconde et un temps de finalité répondent à deux questions différentes. Une infrastructure peut recevoir davantage d’opérations sans que cette seule observation indique le temps nécessaire à chacune pour devenir définitive.
Lire les données avec leur méthode et leur date
La documentation demande aussi aux services d’indexation de tenir compte des blocs candidats et de leur identification. Elle déconseille d’assimiler systématiquement un slot à un bloc unique dans tous les traitements. Pour un lecteur, cette évolution rappelle que les indicateurs visibles dans un explorateur reposent sur des choix de classement et de calcul.
La conclusion utile n’est pas qu’un chiffre de vitesse suffirait à décrire toute l’expérience. Il faut préciser ce qui est chronométré, la source de la mesure et les conditions d’observation. Les objectifs du protocole, une mesure ponctuelle et le délai effectivement ressenti dans une application doivent rester identifiables séparément. Cette méthode permet d’expliquer les progrès annoncés sans promettre une durée identique pour chaque transaction ni déduire de la rapidité une garantie sur les jetons échangés.