La finalité accélérée de Solana est en ligne : qu'est-ce que cela change pour les utilisateurs ?

Solana exécute Alpenglow sur le mainnet depuis le 21 octobre, remplaçant un système de vote qui pouvait prendre plusieurs secondes pour finaliser un bloc par un système conçu pour terminer en une fraction de seconde. La Fondation Solana consigne le basculement à l'epoch 1064, après que 446 des 654 validateurs ont certifié un bloc de genèse.

Un utilisateur envoyant du SOL pourrait voir un paiement apparaître presque immédiatement et se demander ce que la mise à niveau a amélioré. Un portefeuille peut afficher qu'une transaction a été traitée avant que le réseau ne l'ait rendue finale. Alpenglow compresse l'attente de l'assurance plus forte, mais l'application doit toujours soumettre le paiement, recevoir une réponse d'un nœud et décider quand modifier son propre affichage. Un échange peut imposer une attente supplémentaire avant de créditer un compte.

Le registre de mise à niveau de la Fondation indique que les formats de transaction, les programmes et les frais n'ont pas changé. Les développeurs qui se contentent de soumettre des paiements et de lire les soldes de comptes n'ont besoin d'aucun nouveau format de transaction. Ceux qui traitent des flux de blocs ont plus de travail, car le chemin d'un bloc proposé à un bloc convenu est différent. La question pratique est désormais de savoir quels services transmettent cette finalité plus rapide aux clients et lesquels continuent d'utiliser leurs anciens calendriers de confirmation.

Le basculement a eu lieu, mais 150 millisecondes est un objectif

Alpenglow a remplacé TowerBFT, l'ancien processus de consensus de Solana, le 21 octobre. Dans l'ancien système, les validateurs plaçaient des transactions de vote onchain et un bloc recueillait suffisamment de votes au fil des slots suivants pour devenir final. Votor, la partie active d'Alpenglow, transporte les votes directement entre les validateurs et les combine en certificats. Un bloc peut être finalisé en une ou deux rondes de vote.

La Fondation utilise 12,8 secondes comme référence pour l'ancienne finalité et environ 150 millisecondes comme nouvel objectif. Ces chiffres décrivent une comparaison de protocoles, et non deux mesures prises depuis le même portefeuille dans des conditions identiques. Le rapport de préparation du 21 octobre avertissait que les nœuds RPC non stakés pourraient être informés de la finalité plus tard que les validateurs participants, parfois après la production d'un autre bloc. La latence d'Internet et le nœud choisi par une application s'ajoutent à ce que voit l'utilisateur.

Une mesure externe publiée le 23 octobre a établi la finalité médiane à 404 millisecondes sur les 24 heures précédentes, avec un 90e percentile à 579 millisecondes et un 99e percentile à 765 millisecondes. Sa référence antérieure était d'environ sept secondes sous TowerBFT. Sur ces chiffres, la médiane s'est améliorée d'environ 17 fois, calculé en divisant sept secondes par 0,404 seconde. La méthodologie et le point d'observation diffèrent de la référence de 12,8 secondes et de l'objectif de conception de 150 millisecondes de la Fondation.

Le tableau de bord en direct de la Fondation affiche une lecture changeante de la dernière finalité observée et des tendances sur plusieurs fenêtres temporelles. Une dernière valeur ne doit pas être promue en expérience client typique. La série utile comprend la latence médiane et de queue, les pannes et le temps que mettent différents fournisseurs à signaler le même bloc finalisé. Un seul slot particulièrement rapide prouve que le protocole peut atteindre cette vitesse une fois ; cela dit peu de chose sur le paiement d'un commerçant pendant une heure de pointe.

La distinction entre cible et mesure était au cœur de la question de la préparation des validateurs avant l'activation. Le réseau principal a depuis fourni un certificat et plusieurs jours de blocs mesurables. Une question a trouvé sa réponse : les validateurs ont bien coordonné le basculement. Savoir si le client RPC typique observe quelque chose de proche de la cible annoncée est désormais une autre question, car la fondation et les moniteurs externes démarrent leurs chronomètres à des points différents. Rapporter les deux chiffres avec ces points de départ permet aux lecteurs de comparer les performances réelles sans considérer l'observation plus lente comme la preuve que la conception du consensus a échoué.

La production de blocs de Solana s'est accélérée grâce à un autre programme qui a réduit le temps de slot cible de 400 à 200 millisecondes en octobre. Cette mesure concerne la fréquence à laquelle un leader produit un bloc. La finalité concerne le moment où le réseau s'accorde sur le fait qu'un bloc particulier ne peut pas être inversé selon ses règles. Des slots plus rapides et une finalité plus rapide peuvent tous deux aider un utilisateur, mais les deux chiffres ne doivent pas être additionnés ni traités comme le même chronomètre.

Le chiffre annoncé dépend des participants qui reçoivent un bloc proposé à temps pour voter. Une route rapide peut certifier un bloc promptement, tandis qu'une route de secours accommodate une communication plus lente. Un tour lent n'implique pas en soi une mise à niveau échouée : le consensus doit encore s'accorder lorsqu'un validateur manque un message ou que la proposition d'un leader entre en concurrence avec une autre. La médiane peut s'améliorer considérablement tandis qu'un petit nombre de slots prend plus de temps. Les services traitant des transferts importants se soucieront de la queue lente autant que de la cible affichée.

Un observateur public devrait demander où commence le chronomètre de finalité. Démarrer lorsqu'un validateur reçoit un bloc proposé exclut le temps qu'un portefeuille a passé à diffuser sa transaction. Démarrer lorsqu'un commerçant appuie sur « débiter » inclut un humain et plusieurs systèmes logiciels. Démarrer lorsqu'un serveur RPC voit un certificat inclut le décalage entre les validateurs et le serveur. Chaque chronomètre répond à une question différente. La mesure externe du 23 octobre est utile parce que sa méthode et sa distribution peuvent être examinées séparément de l'affirmation de conception de la Fondation.

Un portefeuille a plus d'un chronomètre

Imaginez payer un café avec un portefeuille Solana. L'utilisateur approuve d'abord une transaction localement. Le portefeuille l'envoie via un service RPC, le réseau l'inclut dans un bloc candidat et les validateurs certifient ce bloc. Le système du commerçant reçoit une mise à jour de statut et décide s'il doit remettre le café. Alpenglow modifie l'étape de certification, pas le temps nécessaire pour ouvrir le portefeuille ni la politique propre du commerçant.

De nombreuses applications affichaient déjà un message de succès avant la finalité de TowerBFT. Elles utilisaient un niveau d'engagement moins définitif car la plupart des paiements de détail n'attendent pas la garantie de consensus la plus forte avant de changer l'écran. Un statut finalisé plus rapide pourrait permettre à une application d'offrir une assurance plus forte à peu près à la vitesse de son précédent statut précoce. L'amélioration ne sera visible que si le service met à jour sa règle d'attente et que son fournisseur livre le résultat rapidement.

Un dépôt sur un échange illustre la limite. Un transfert peut être final sur Solana tandis que l'échange vérifie encore l'expéditeur, associe l'adresse à un compte, effectue un contrôle des risques et applique une politique de crédit interne. Le nouveau temps de finalité de la chaîne ne peut pas contraindre l'échange à libérer immédiatement un solde. Un pont nécessite un relais de messages, une exécution sur la chaîne de destination et souvent ses propres garanties. Le règlement entre deux systèmes reste donc plus lent que la finalité de la chaîne source seule.

Le compte rendu du testnet de septembre exposait la distinction avant le lancement. Il décrivait un nouveau processus de vote, pas une nouvelle façon de signer des paiements ordinaires. Il existe désormais un enregistrement sur le réseau principal à vérifier. Les fournisseurs peuvent comparer le moment où un client soumet une transaction, le moment où un validateur la certifie et le moment où leur API signale la finalité. Sans ces horodatages séparés, une affirmation de paiement utilisateur en 150 millisecondes dissimule les parties qui n'ont pas été mesurées.

Le mot « instantané » restera tentant dans le marketing. Un client debout à un comptoir se soucie de savoir si le commerçant reçoit une acceptation fiable avant de se détourner, ce qui est une mesure de service de bout en bout. Un trader se soucie de savoir si une plateforme met à jour les soldes avant la prochaine opportunité de marché. Les deux peuvent en bénéficier même si le portefeuille n'affiche jamais un statut de finalité explicite. On ne devrait promettre à aucun des deux que chaque interaction se termine en 150 millisecondes.

Un opérateur de point de vente prend deux décisions indépendantes. Il choisit quand un paiement est suffisamment sûr pour remettre les marchandises, et il choisit comment gérer une connexion interrompue. Un certificat de consensus rapide améliore la première décision mais ne fait pas qu'un terminal hors ligne reçoive une réponse. Un processeur peut envoyer un message de succès provisoire et le réconcilier plus tard, ou attendre le statut finalisé. Ce qui compte au moment du paiement, c'est la politique réelle, y compris la façon dont les soumissions en double et les réponses retardées apparaissent à l'écran.

Les applications financières ont d'autres raisons de distinguer la vitesse de la politique. Une application de prêt peut enregistrer une garantie lorsqu'un transfert est traité mais n'autoriser l'emprunt qu'après la finalisation. Une plateforme centralisée peut surveiller les soldes finalisés tout en appliquant sa propre retenue sur les retraits. Un pont doit gérer le risque de la chaîne réceptrice en plus de celui de Solana. Un certificat plus rapide crée l'opportunité de raccourcir la portion dépendante de la chaîne de chaque flux de travail. Publier les temps de service avant et après montrerait où les fournisseurs saisissent cette opportunité.

Moins de transactions sur le graphique peut signifier la même quantité d'utilisation

Sous TowerBFT, le vote des validateurs faisait partie du flux de transactions onchain. Les validateurs d'Alpenglow communiquent directement et placent les informations de certification dans les pieds de bloc, de sorte que ces transactions de vote n'apparaissent plus dans le décompte ordinaire des transactions par bloc. Un tableau de bord qui affichait toutes les transactions par seconde peut chuter après le basculement sans baisse des transferts, swaps ou paiements effectués par les utilisateurs.

Le cofondateur de Solana, Anatoly Yakovenko, a discuté de la suppression des transactions de vote peu avant l'activation, lorsque le changement du TPS principal attirait l'attention. Les analystes comparant le trafic du 20 octobre avec celui d'après le 21 octobre devraient isoler les transactions non-vote des deux côtés. Sinon, un changement comptable ressemble à une demande perdue. L'erreur inverse serait de prétendre que la baisse du trafic de vote crée elle-même un nombre égal de transactions utilisateur utiles supplémentaires ; la capacité disponible et l'utilisation réelle sont deux choses différentes.

L'arithmétique peut être vérifiée sans inventer une nouvelle estimation de débit. Si un décompte d'avant la mise à niveau combine les transactions utilisateur U et les votes des validateurs V, son total est U + V. Après que les votes quittent le bloc, un graphique similaire peut afficher approximativement U même lorsque les clients soumettent autant de transferts. La différence V est un changement dans ce que le graphique compte. Calculer la croissance réelle nécessite des séries comparables uniquement utilisateur, et non les totaux principaux avant et après.

Cela compte aussi pour les commentaires sur les frais et les revenus. Les frais de transaction de vote disparaissent, tandis que les validateurs paient plutôt un Ticket d'Admission Validateur. La mécanique des frais de transaction utilisateur reste en place. Un changement dans les revenus totaux de frais lié à la catégorie de vote perdue ne peut pas simplement être présenté comme un changement dans la volonté des consommateurs de transiger. Une comparaison minutieuse sépare les dépenses liées au vote, les frais d'admission et les frais que les utilisateurs paient pour envoyer ou prioriser leurs propres transactions.

Les explorateurs de blocs et les fournisseurs de données font face à une tâche connexe. La participation autrefois lue à partir des instructions du programme de vote doit maintenant être lue à partir des certificats et des données de pied de bloc. Un fournisseur continuant à analyser l'ancien champ peut afficher des votes de validateurs manquants même lorsque le réseau finalise normalement les blocs. La documentation de Solana avertit que certaines interfaces de streaming ne transmettent pas encore chaque élément des métadonnées de certificat, ce qui fait de la documentation des fournisseurs une partie de toute comparaison sérieuse de performance.

Un graphique des transactions par seconde est vulnérable lors d'un changement de protocole car il agrège souvent différentes catégories. Une plateforme affirmant que l'activité des utilisateurs a chuté immédiatement après l'activation a besoin du décompte uniquement utilisateur aux deux dates, idéalement ventilé en transferts réussis, swaps et tentatives échouées. Les transactions ne sont pas des personnes uniques ni des achats complétés. Un bot peut générer de nombreuses instructions, et une instruction infructueuse peut encore apparaître dans une série de transactions soumises. Une réduction du vote des validateurs ne dit rien en soi sur les marchands acceptant Solana.

La distinction compte aussi pour l'économie du réseau. La disparition des frais de vote réduit un type de paiement onchain par les validateurs. Le ticket d'admission est brûlé depuis un autre compte selon un calendrier différent. Les frais utilisateur dépendent de ce que les clients soumettent et de la priorité qu'ils paient. Combiner les trois en une seule tendance de revenus obscurcirait si la demande a changé ou si la comptabilité a bougé. Des catégories cohérentes de part et d'autre du 21 octobre offrent une base plus solide pour interpréter un graphique de frais.

Les services de données doivent suivre le bloc gagnant

Une décision de vote rapide ne fait pas de chaque bloc proposé le gagnant. Les flux de données mis à jour de Solana peuvent exposer plus d'une banque candidate pour un slot, et Agave 4.3 étiquette les événements avec un bank_id afin que les clients puissent séparer les candidats. Un indexeur regroupant toutes les données sous un numéro de slot peut accidentellement mélanger des transactions de candidats concurrents dans un enregistrement d'un bloc qui n'a jamais existé sous cette forme.

La Fondation demande aux consommateurs de streaming de mettre en tampon par la paire d'identifiant de slot et de banque et de conserver la banque qui atteint la confirmation. S'ils fusionnent des flux de différents fournisseurs, l'identifiant n'a de sens qu'au sein de chaque connexion ; le hash de bloc est la référence inter-fournisseurs. Une partie du comportement plus fréquent de banques multiples est attendue dans Agave 4.4, il y a donc le temps de s'adapter avant que cela ne devienne courant, mais les applications traitant les flux de blocs actuels devraient se préparer dès maintenant.

La plupart des utilisateurs de portefeuille ne verront jamais un identifiant bancaire. Une application de portefeuille ou un échange qui reconstruit les dépôts à partir d'un flux défectueux pourrait afficher un paiement trop tôt, en manquer un ou rattacher un transfert au mauvais candidat de bloc. Un système de trading qui réagit aux premiers événements du flux doit savoir s'ils appartenaient au bloc final. Le protocole peut finaliser rapidement tandis que les erreurs d'un indexeur retardent ou déforment encore ce que les gens voient.

Les notes de migration du mainnet de la Fondation indiquent que les niveaux d'engagement confirmé et finalisé décrivent désormais le même état, bien que le premier reste disponible pour le moment et sera supprimé dans une version ultérieure. Il est conseillé aux développeurs d'orienter les nouveaux travaux vers le niveau finalisé et de revoir les paramètres de délai d'attente ou de nouvelle tentative réglés sur l'ancienne attente. Un service qui attend 12 secondes par habitude peut rester lent malgré une chaîne beaucoup plus rapide.

Les flux de données connaissent d'autres changements. La Preuve d'Histoire ne rythme plus la production de blocs de la même manière, de sorte que les entrées de tick quittent le flux de shreds. Un programme lisant l'horodatage de l'Horloge peut voir une source différente de celle d'avant. Ces détails ne sont pas des signes que les transactions des utilisateurs ont changé de format. Ce sont des endroits où les logiciels construits autour de l'ancien rythme du registre peuvent avoir besoin de travail avant que la nouvelle vitesse du réseau n'atteigne l'écran.

Pour un indexeur, le problème est plus qu'un nouveau nom de champ. Il peut recevoir le même slot via deux connexions et traiter les transactions dans l'ordre d'arrivée. Si les flux transportent des événements de banques concurrentes et que sa base de données n'indexe les enregistrements que par slot, les enregistrements ultérieurs peuvent écraser les précédents ou créer un mélange impossible. La clé slot-et-banque des conseils de migration empêche cela au sein d'un flux ; le hash du bloc gagnant final réconcilie les fournisseurs. Les clients ne remarquent ce travail que lorsqu'un solde ou un historique de transactions devient plus fiable.

La logique de nouvelle tentative mérite un autre regard. Un client qui interroge une fois par seconde peut manquer la majeure partie du bénéfice d'une amélioration du consensus de quelques centaines de millisecondes. Un autre peut soumettre à nouveau le même paiement parce qu'une réponse arrive après son délai d'attente. Des clients bien conçus distinguent une réponse lente d'une transaction non traitée et préservent les identifiants à travers les nouvelles tentatives. Les opérateurs doivent tester ces comportements avec le nouveau flux d'engagement avant de promettre un délai de paiement fixe.

Les validateurs ont une nouvelle facture récurrente

La suppression des transactions de vote onchain modifie les coûts des validateurs. La Fondation Solana indique que le vote coûtait auparavant environ 1 SOL par époque en frais de transaction, payés depuis le compte d'identité d'un validateur. Le nouveau Ticket d'Admission de Validateur brûle 0,8 SOL par époque depuis son compte de vote, en plus du minimum exonéré de loyer. Le ticket acheté au début d'une époque admet le validateur pour la suivante.

Un validateur qui ne parvient pas à conserver suffisamment de SOL dans le bon compte ne peut ni voter ni produire de blocs lors de l'époque suivante et perd l'opportunité d'y gagner ses récompenses. Envoyer le montant à l'ancien compte d'identité ne paiera pas les nouveaux frais. Les opérateurs peuvent acheminer les revenus de blocs vers le compte de vote, bien que la Fondation indique que ce changement prend deux époques et que les revenus de commission peuvent être insuffisants à une limite donnée.

La comparaison entre environ 1 SOL et 0,8 SOL n'est pas une économie nette universelle. Les revenus, la mise, les coûts logiciels, les commissions et le calendrier de chaque prélèvement diffèrent selon les validateurs. Le fait fiable est quel compte paie, quel est le montant des frais d'admission forfaitaires et ce qui se passe s'ils sont manqués. La concentration à long terme dépendra de la capacité des petits opérateurs à soutenir les exigences opérationnelles et financières tout en restant compétitifs.

Le lancement nécessitait Agave 4.3.2 ou des clients compatibles Jito-Solana ou Harmonic Salsa. Firedancer et Frankendancer n'étaient pas pris en charge pour la migration, selon la page opérateur de la Fondation. L'activation d'Alpenglow prouve que le réseau pouvait basculer avec les validateurs participants ; elle ne montre pas que chaque client validateur alternatif était prêt pour le même jour. La diversité des clients reste une question de résilience distincte.

L'approbation de la gouvernance est venue avant la migration.Le plan de déploiement antérieur décrivait le code dans Agave 4.2 pendant les tests, mais l'installation seule n'a jamais été le basculement du mainnet. Le certificat de genèse et le début du consensus au slot 459 653 000 sont la preuve de l'activation. Les 446 signataires du premier certificat représentaient un événement de coordination concret, non une promesse sur la présence ou la performance de tous les 654 validateurs chaque heure par la suite.

Le ticket forfaitaire modifie l'économie des validateurs différemment selon leur taille. Un grand opérateur et un petit paient les mêmes 0,8 SOL pour l'entrée, de sorte que les frais consomment une plus grande fraction des récompenses brutes d'un petit opérateur. Savoir si cela pousse quelqu'un à partir dépend de la mise déléguée, de la commission, des coûts d'exploitation et des autres revenus. Les conseils aux opérateurs établissent les mécanismes de paiement ; ils ne prévoient pas combien de validateurs partiront. Un suivi utile consisterait à comparer les opérateurs indépendants actifs et la concentration de la mise sur plusieurs époques.

Le changement de compte peut créer une interruption évitable même pour une opération saine. Le ticket provient du compte de vote à l'avance, alors que les opérateurs finançaient les anciens frais de vote depuis le compte d'identité au fur et à mesure de l'envoi des votes. Un validateur disposant globalement de suffisamment de SOL mais avec une mauvaise répartition entre les comptes peut manquer l'admission. Les rapports de disponibilité devraient distinguer ce problème de migration d'une défaillance du nouveau protocole de vote. Ce sont des défaillances opérationnelles distinctes avec des remèdes différents.

La mise à niveau résout un problème plus étroit que ne le font les applications de paiement

L'argument de Solana en faveur d'Alpenglow est puissant : si la finalité arrive beaucoup plus tôt, les services qui nécessitent un règlement irréversible peuvent cesser d'attendre pendant plusieurs secondes d'incertitude. Les mesures externes du 23 octobre soutiennent une amélioration substantielle sur le mainnet, même si leur médiane de 404 millisecondes était plus lente que l'objectif de conception. Les commerçants et les plateformes d'échange peuvent choisir de s'appuyer sur ce statut plus fort et plus rapide.

Un service peut néanmoins conserver une marge de sécurité. Il pourrait utiliser plusieurs fournisseurs RPC, exiger un filtrage antifraude ou créditer un client seulement après que son propre registre a réconcilié les dépôts. Un paiement de faible valeur pourrait être libéré sur un statut traité, rendant Alpenglow presque invisible dans son interface actuelle. Un transfert important pourrait utiliser le statut finalisé et gagner plusieurs secondes. La mise à niveau ne rend pas un service prudent irrationnel ; elle lui donne un signal réseau plus rapide à intégrer dans sa décision.

Le premier changement mesurable pourrait être la fiabilité de la promesse derrière une confirmation plutôt qu'une animation spectaculaire dans un portefeuille. Les utilisateurs qui voyaient déjà une confirmation rapide ne savaient pas nécessairement si elle était réversible. Les fournisseurs peuvent désormais décider d'afficher ou d'exiger une finalité plus forte dans cette même fenêtre. Publier le temps entre l'approbation du client et l'acceptation du commerçant établirait plus clairement l'affirmation destinée à l'utilisateur que la seule publicité du chiffre de consensus.

La deuxième partie d'Alpenglow, Rotor, est encore prévue pour une version ultérieure sans date d'activation. Votor a modifié le vote et la finalité ; la distribution des blocs utilise toujours l'ancienne approche Turbine. Le nom du package peut donner l'impression que tous les composants proposés sont arrivés ensemble. Le tableau de statut actuel de la Fondation rend la séparation claire. Tout gain de performance attribué à Rotor dans les données actuelles du mainnet se tromperait de chronologie.

La distribution des blocs reste pertinente lorsque les données circulent de manière inégale à travers le réseau. Un vote plus rapide ne peut pas aider un validateur à certifier une proposition qu'il n'a pas reçue. Le composant Rotor prévu concernerait une étape différente de celle des certificats de Votor. Pour l'instant, les observations lentes peuvent refléter la propagation, le vote, la livraison par RPC public ou plusieurs à la fois. Enregistrer chaque étape indiquerait à un opérateur si sa prochaine amélioration relève du logiciel de validateur, de la distribution des données ou de l'infrastructure client.

Le lancement initial est un court échantillon de performance. Les versions des clients, le travail de migration des fournisseurs et la participation des validateurs définissent les conditions actuelles. Les versions ultérieures peuvent modifier la régularité avec laquelle les services externes entendent parler des certificats, même sans autre changement de consensus. Une semaine glissante d'observations auprès de plusieurs fournisseurs RPC indépendants, y compris les périodes de pointe, serait plus précieuse pour un commerçant qu'une seule démonstration rapide.

Ce qui reste à mesurer

Il n'existe pas de chiffre de finalité unique qui capture l'attente de chaque utilisateur. Les certificats de validateur, les observations RPC publiques, le statut du portefeuille et les délais de crédit des plateformes d'échange mesurent des étapes différentes. Le tableau de bord de la Fondation fournit des lectures réseau en direct, tandis que les moniteurs externes observent depuis leurs propres nœuds. Une concordance entre méthodes et fournisseurs sur plusieurs jours montrerait si les résultats rapides tiennent au-delà de la semaine de lancement et à quelle fréquence la queue lente apparaît.

Le bilan du mainnet est déjà plus solide qu'une promesse de testnet. Alpenglow est actif, les transactions de vote ont quitté les blocs et les développeurs ont publié les changements d'intégration. Il est encore trop tôt pour attribuer à la mise à niveau du consensus plus d'utilisateurs d'applications, des prix de jetons plus élevés ou une amélioration donnée à chaque paiement. De telles affirmations nécessitent des cohortes de transactions, des mesures de service avant et après et des données comparables portant uniquement sur les utilisateurs.

Pour un portefeuille ou un fournisseur de paiement, la prochaine décision est concrète : utiliser rapidement le signal finalisé, publier lorsque l'utilisateur le voit et conserver les vérifications supplémentaires que son produit exige. La chaîne a modifié une étape. Les gens le remarqueront lorsque les logiciels qui l'entourent modifieront le reste du parcours.

Ce qu'il faut surveiller

• Finalité observée : Comparez les lectures de la médiane mobile et du centile le plus lent sur le tableau de bord de la Fondation et sur des nœuds indépendants, en précisant les points d'observation.
• Délais des portefeuilles et des plateformes d'échange : Mesurez l'intervalle entre l'approbation du client et la confirmation visible ou le crédit du solde, et pas seulement le certificat du validateur.
• Trafic comparable : Suivez les transactions des utilisateurs hors votes avant et après le 21 octobre afin que les transactions de vote supprimées ne faussent pas la tendance.
• Erreurs de streaming : Vérifiez si les fournisseurs RPC et d'indexeur prennent en charge la reconstruction de blocs compatible avec les banques et un statut finalisé en temps opportun.
• Admission des validateurs : Surveillez le financement des comptes de vote, les validateurs actifs et la diversité des clients pris en charge, étant donné que les frais de 0,8 SOL se répètent à chaque époque.

FAQ