Que se passe-t-il pour les validateurs Solana qui manquent la mise à jour Agave 4.4.1 ?

Anza a donné aux opérateurs de nœuds Solana jusqu'à l'epoch 1079 pour installer un correctif qui modifie la façon dont le réseau compte les données de compte chargées par une transaction. Une machine exécutant une version plus ancienne pourrait rester en ligne et néanmoins se désynchroniser de la chaîne acceptée, avec des conséquences différentes pour les validateurs qui perçoivent des récompenses de staking et pour les services sur lesquels les portefeuilles s'appuient pour obtenir des données à jour.

Anza a averti les validateurs avant l'epoch 1079 que les opérateurs exécutant un logiciel plus ancien risquaient d'être laissés de côté lorsque le réseau activerait une nouvelle règle. Les versions compatibles citées étaient Agave 4.4.1 et Firedancer v26.10.6.

Le suivi des feature gates d'Agave identifie le changement concerné comme une taille minimale de données chargées pour les comptes ProgramData de loader-v3. Son tableau des versions minimales sépare les versions utilisées par les réseaux de test de celles prévues pour le mainnet. La lecture du calendrier exige de vérifier ensemble le cluster, la fonctionnalité et l'epoch.

La date limite concernait aussi les nœuds qui ne votent pas. Ces machines peuvent fournir aux portefeuilles et aux échanges des soldes, des blockhashes et des données de confirmation. Un problème sur l'une d'elles peut atteindre des utilisateurs qui n'ont jamais délégué de SOL ni choisi de validateur.

Ce que fait le changement

Un programme Solana peut utiliser un compte pour stocker ses données exécutables. Lorsqu'une transaction doit charger un programme, le réseau tient compte des données associées à cette opération. Un minimum appliqué à un compte de données de programme modifie la façon dont les logiciels compatibles traitent la transaction concernée sous la nouvelle règle.

Le but d'un feature gate est de coordonner le moment où les participants commencent à utiliser une nouvelle règle. Les opérateurs peuvent installer une version à l'avance, tandis que le changement de règle effectif prend effet à un point convenu. Une version peut donc prendre en charge une fonctionnalité avant que celle-ci ne soit active sur le mainnet.

Une fois le gate activé, une version plus ancienne peut être en désaccord avec le logiciel mis à jour au sujet d'une transaction ou de l'état produit par un bloc. Un validateur peut alors cesser de suivre la chaîne reconnue par le reste du réseau, même si le serveur lui-même reste en ligne. C'est là le sens pratique de l'avertissement d'Anza concernant le risque d'être forké hors de la chaîne.

Pourquoi le stake derrière les nœuds compte

Cent petits validateurs et une poignée de grands opérateurs ne représentent pas nécessairement des montants comparables de stake votant. Pour le fonctionnement du réseau, la question pertinente est de savoir quelle quantité de stake suit les règles compatibles. Le suivi indique que les changements de version minimale sur le mainnet pour les versions mineures suivent normalement un seuil d'adoption par le stake et une période d'attente. Cette règle générale doit être distinguée de l'avertissement spécifique émis avant l'epoch 1079.

Une vérification de l'adoption devrait associer les informations de version au stake actif, puis comparer ces chiffres à la participation au vote après la limite. Un nœud signalant la bonne version peut encore être en train de rattraper son retard ou subir une panne distincte. Inversement, un agrégat stable peut masquer des problèmes chez un opérateur plus petit si la majeure partie du stake reste en ligne et vote normalement.

Cette différence compte pour les délégateurs. Leur expérience dépend du validateur auquel leur stake a été attribué, plutôt que du fait qu'une majorité de machines ait installé la version. Si un validateur cesse de voter efficacement, la participation manquée peut réduire les récompenses attribuables à ce stake. Les preuves pertinentes seraient les crédits de vote et les enregistrements de récompenses pour les epochs concernées.

Ce que les utilisateurs et les plateformes d'échange remarqueraient

Un utilisateur qui envoie des SOL se soucie de savoir si le transfert est accepté et atteint le niveau de confirmation prévu. Cela peut être vérifié au moyen des données de la transaction et du réseau. L'affirmation selon laquelle plusieurs opérateurs auraient manqué une mise à jour n'établit pas en soi des confirmations plus lentes, un arrêt ou une panne généralisée.

Une plateforme d'échange peut également suspendre les dépôts ou les retraits pendant qu'elle surveille une mise à niveau, même lorsque les transferts se poursuivent onchain. Les soldes de ses clients dépendent de sa propre infrastructure et de ses politiques de crédit. Une transaction qui apparaît onchain peut donc rester en attente sur le compte d'échange d'un client jusqu'à ce que cette plateforme reprenne un traitement normal.

La comparaison utile après la mise à niveau consisterait à vérifier trois choses séparément. Premièrement, les blocs ont-ils continué à être produits et confirmés ? Deuxièmement, la quantité de mise votante a-t-elle effectivement changé ? Troisièmement, une plateforme d'échange nommée a-t-elle suspendu ou repris des transferts autour de la limite ? Chaque réponse nécessite un enregistrement différent.

Pourquoi la date limite de mise à niveau s'appliquait aussi à l'infrastructure

Les notes de version Agave d'Anza identifient le changement de comptabilité ProgramData comme un backport. La version Firedancer inclut la prise en charge de la même fonctionnalité. Lorsque deux clients traitent la même transaction après l'activation, ils doivent s'accorder sur la quantité de données de compte qu'elle charge. La règle partagée est ce qui compte à la limite.

Un nœud RPC non staké peut servir une application sans contribuer de stake aux votes. Cela permet facilement à un utilisateur de portefeuille de rencontrer un problème local même si les validateurs votants continuent de produire des blocs. Une application qui lit depuis un point de terminaison en retard peut afficher un état ancien ou renvoyer une erreur. Comparer sa réponse avec la même requête via un autre point de terminaison aide à identifier où la perturbation s'est produite.

La migration Alpenglow d'octobre de Solana offre un contexte sur la manière dont les opérateurs se préparent à un changement coordonné. Cette migration concernait le protocole de consensus. Le correctif de novembre concernait le chargement des comptes. Les deux donnent aux opérateurs une version à vérifier, mais les effets doivent être évalués par rapport à la règle spécifique qui a changé.

Ce qui rendait la date limite différente d'une date de publication

Anza a publié Agave 4.4.1 le 5 novembre. Son avertissement ultérieur aux opérateurs indiquait que le changement était prévu pour l'epoch 1079, dont le début était estimé à environ 13h30 UTC le 6 novembre. La version identifiait le logiciel dont les opérateurs avaient besoin, tandis que l'epoch identifiait le moment où le réseau prévoyait de commencer à appliquer la règle.

Une limite d'epoch dépend de la progression de la chaîne. L'heure indiquée dans l'avertissement donnait aux opérateurs une estimation pratique, mais la transition de la chaîne vers le nouvel epoch était l'événement important. Les opérateurs ne pouvaient pas considérer une heure locale ultérieure ou une fenêtre de maintenance de routine comme une prolongation du calendrier.

Une version peut inclure du code qui ne change pas encore la manière dont le réseau traite les transactions. Les opérateurs installent d'abord le logiciel, puis le réseau active la fonctionnalité au moment prévu. Cette séquence permet aux opérateurs de se préparer sans que les nœuds appliquent immédiatement des règles différentes au même bloc.

La fenêtre était courte même pour les opérateurs qui étaient déjà passés à Agave 4.4.0. Le numéro de correctif a changé de un, mais la version précédente ne disposait pas de la prise en charge nécessaire pour la nouvelle règle. Une installation récente ne remplaçait donc pas la vérification de la build exacte.

La version Firedancer 26.10.6 prenait en charge la même fonctionnalité. Les opérateurs pouvaient utiliser différentes implémentations de client, mais les deux devaient compter les mêmes données de compte lors de l'exécution d'une transaction selon les règles actives.

La distinction entre logiciel et activation était déjà apparue dans la couverture de crypto.news du déploiement sur testnet d'Alpenglow. Alpenglow changeait le consensus, tandis que le correctif de novembre concernait le traitement des transactions. Dans les deux cas, la disponibilité d'une build constituait un jalon distinct de l'exigence par le réseau de son comportement.

Où ProgramData entre dans la transaction

Une transaction liste les comptes dont ses instructions ont besoin. Un validateur charge les données associées à ces comptes pour exécuter les instructions. Le réseau limite la quantité de données de compte qu'une transaction peut charger, ce qui donne aux validateurs une borne sur une catégorie de travail qu'ils effectuent avant ou pendant l'exécution.

Le loader upgradable de Solana utilise un compte de programme et un compte ProgramData distinct. Ce dernier stocke les données du programme exécutable et les informations associées pour le loader. Un utilisateur invoque le programme sans tenir compte manuellement de la taille de ces données exécutables. Le runtime du validateur gère cette partie.

Le correctif fixe un plancher pour la quantité attribuée à un compte ProgramData de loader-v3 lorsqu'il est chargé. Si l'ancienne comptabilité attribuait moins que le plancher, la nouvelle règle compte au moins le minimum contre la limite de données chargées de la transaction. Une transaction bien en dessous de la limite peut produire le même résultat après le changement.

La différence compte à la frontière. Une transaction qui combine plusieurs instructions ou utilise plusieurs programmes peut déjà charger des données de compte substantielles. Si le nouveau minimum place le montant combiné au-dessus de la limite, les anciennes et nouvelles règles peuvent produire des résultats différents même avec les mêmes instructions et le même signataire.

La limite de données chargées est distincte du budget de calcul. Le calcul mesure le travail d'exécution. Une transaction peut disposer de suffisamment de calcul pour exécuter les instructions et échouer néanmoins à une limite qui régit les comptes qu'elle peut charger. Augmenter seule l'allocation de calcul ne change pas la quantité comptée contre la limite de données chargées.

La règle laisse également en place les instructions déployées d'une application. Le programme peut rester à la même adresse et avoir le même code tandis que le validateur facture différemment son compte ProgramData. Les équipes applicatives ont une raison de revérifier les transactions proches de la limite même si elles n'ont effectué aucun déploiement de leur propre chef.

Comment deux nœuds peuvent être en désaccord sur le même bloc

Les validateurs exécutent les transactions pour vérifier l'état produit par un bloc. Si deux nœuds partent du même état et appliquent des règles différentes à l'une de ces transactions, ils peuvent atteindre des résultats différents. Ils ne peuvent pas tous deux considérer le même état résultant comme valide à moins que la différence ne soit résolue.

Cela explique l'avertissement d'Anza concernant les nœuds plus anciens qui sortent du rythme. Un ancien nœud peut rester en ligne et continuer à répondre aux requêtes tout en échouant à suivre la chaîne acceptée par les validateurs compatibles. Le fait que son processus soit actif est un test plus faible que celui de savoir s'il est à jour et en accord avec le cluster.

Un opérateur peut comparer le slot rapporté par le nœud avec une référence indépendante. Un validateur votant doit également vérifier que ses votes sont comptés sur la chaîne acceptée. Les journaux d'erreurs peuvent identifier un problème lors du rejeu de blocs qui serait invisible dans une vérification de disponibilité.

L'avertissement décrivait la conséquence de l'incompatibilité. Une évaluation après la date limite doit encore montrer quels opérateurs exécutaient des versions obsolètes et ce qui est arrivé à leurs nœuds. Un instantané de version collecté après qu'un opérateur s'est rétabli pourrait manquer une brève période pendant laquelle ce validateur était désynchronisé.

La date d'activation et le moment où un observateur remarque un problème peuvent également différer. Une règle étroite n'affecte que les transactions qui l'exercent. Une période sans divergence visible immédiatement après la frontière ne montrerait pas si un nœud pouvait traiter une transaction proche de la limite affectée.

Pourquoi un décompte de validateurs ne raconte qu'une partie de l'histoire

L'importance d'un validateur votant dépend en partie de la quantité de stake qu'il représente. Une poignée de grands opérateurs peut représenter plus de poids de vote que de nombreux petits. Un décompte des machines affectées répond donc à une question différente du pourcentage de stake actif qui a continué à participer.

Les nœuds non stakés ont un rôle distinct. Ils peuvent fournir des données aux applications, aux exchanges et aux portefeuilles ou relayer des transactions signées. Une panne chez un service populaire peut affecter de nombreux utilisateurs même si le service n'apporte aucun stake au consensus.

Les mesures pertinentes peuvent évoluer indépendamment. La production de blocs peut continuer tandis qu'un fournisseur RPC particulier sert des données obsolètes. Un validateur peut manquer des votes tandis que son site web public reste disponible. Un exchange peut suspendre les dépôts Solana tandis que la chaîne continue de confirmer les transferts.

Une couverture antérieure de la date limite d'Alpenglow de Solana décrivait une transition nécessitant une préparation coordonnée des validateurs et des applications. L'objectif y était une finalité plus rapide. La barrière ProgramData a un effet technique plus étroit, mais les opérateurs doivent toujours juger de leur préparation en fonction de leur propre place dans le réseau.

Ce que les délégateurs peuvent établir à partir des registres de votes et de récompenses

Les délégateurs ont une question économique même lorsque le réseau reste disponible. Ils veulent savoir si le validateur qui perçoit des récompenses en leur nom a continué de participer. Un correctif manqué ne déplace pas en soi les SOL délégués hors du compte de staking, mais une interruption du vote peut réduire les récompenses gagnées au cours de la période concernée.

Le premier endroit à consulter est le compte de vote du validateur. Comparer les crédits de vote sur les époques autour de la limite peut établir si sa participation a changé. Les registres de récompenses offrent une vérification distincte de l'effet pour des comptes de staking particuliers.

Une récompense plus faible n'identifie pas en soi la mise à niveau comme la cause. La commission, la performance antérieure du validateur et le statut du compte de staking peuvent tous affecter le montant enregistré. La preuve que les votes se sont arrêtés à la limite et ont repris après un changement de client donnerait une explication plus solide qu'une seule récompense plus faible.

Un jeton de staking liquide ajoute une couche supplémentaire. Un pool peut répartir son stake entre plusieurs validateurs. Un problème chez un opérateur peut ne contribuer qu'à une partie de la variation des récompenses du pool, selon sa part de la délégation et la comptabilité du pool.

Le staking via une plateforme d'échange ajoute une relation de service. La plateforme peut exploiter ses propres validateurs ou recourir à un autre fournisseur, puis créditer les clients selon ses conditions. Un utilisateur aurait besoin des registres de la plateforme pour relier un changement onchain des votes à la récompense créditée à un compte individuel.

Ce qu'un point de terminaison RPC obsolète peut faire à un portefeuille

De nombreux portefeuilles obtiennent les soldes, les blockhashes et les résultats de transactions via un point de terminaison RPC. Un nœud qui prend du retard peut signaler un solde antérieur ou ne pas renvoyer une transaction récente. Les utilisateurs peuvent rencontrer ces symptômes même si d'autres nœuds traitent le réseau normalement.

Un blockhash peut affecter la transaction avant que le réseau ne l'exécute. Un portefeuille qui obtient un blockhash obsolète peut construire une transaction qui n'est plus valide au moment où elle atteint un nœud sain. Le symptôme est une soumission échouée, mais la raison peut être une information obsolète plutôt qu'un changement du solde ou des instructions.

La simulation dépend de la même relation. Un nœud exécutant d'anciennes règles peut signaler qu'une transaction respecte la limite de données chargées alors que les nœuds appliquant la nouvelle règle aboutissent à un résultat différent. Une simulation sur un nœud compatible peut encore différer de l'exécution finale si l'état change entre la simulation et l'inclusion.

Les applications disposant de plusieurs nœuds derrière un seul point de terminaison font face à une autre possibilité. Les requêtes peuvent réussir ou échouer selon la machine qui les reçoit. Un fournisseur doit vérifier que l'ensemble du pool est à jour avant d'attribuer un problème intermittent à la chaîne.

Une comparaison entre des points de terminaison indépendants aide à distinguer ces problèmes. Si plusieurs points de terminaison à jour concordent et qu'un service diffère, l'écart peut être local à ce service. Si des observateurs indépendants signalent également un changement dans la production de blocs ou les confirmations, il existe des preuves plus solides d'un problème de réseau.

La transition de consensus d'octobre a eu ses propres changements d'infrastructure. Crypto.news a rapporté qu'Alpenglow a supprimé les précédentes transactions de vote onchain. Les équipes applicatives ont dû distinguer le changement dans ce qu'elles observaient de la capacité des validateurs à suivre le nouveau système. La règle de chargement des comptes de novembre fait à nouveau dépendre la réponse du rôle de l'observateur.

Pourquoi le crédit sur une plateforme d'échange peut être en retard par rapport à la chaîne

Une plateforme d'échange ne peut créditer un dépôt qu'après que ses systèmes ont reconnu le transfert et appliqué sa politique de confirmation. Une transaction onchain réussie ne détermine donc pas le moment où le solde interne d'un client sur la plateforme change.

Une plateforme peut suspendre les dépôts ou les retraits pendant qu'elle met à jour son infrastructure. Elle peut également continuer à recevoir des transferts onchain pendant que sa file de dépôts attend la confirmation d'un nœud sain. Un avis de plateforme et un explorateur de blocs peuvent tous deux être exacts même si l'un indique une interruption de service et l'autre un transfert réussi.

Pour les retraits, un délai peut survenir avant que l'échange ne signe ou ne diffuse la transaction. L'absence d'enregistrement onchain pendant cette période ne dit pas grand-chose sur la question de savoir si le réseau accepterait la transaction une fois soumise. Le statut de traitement de la plateforme concerne cette partie de la chronologie.

Un rapport indiquant que plusieurs échanges ont suspendu leurs opérations devrait encore préciser quels services ont été affectés et quelle raison chacun a donnée. Un avis de maintenance de routine ou une file d'attente causée par un autre problème peut tomber dans la même fenêtre qu'une mise à niveau. La coïncidence est une raison de comparer les enregistrements, pas une mesure de la participation au réseau.

Ce qui montrerait si les opérateurs ont manqué le correctif

Le suivi des feature gates d'Anza sépare le seuil de version minimale des activations individuelles. Des articles antérieurs de crypto.news sur le déploiement d'Alpenglow et le seuil du mainnet décrivaient la même distinction. Une version peut atteindre le seuil à un moment donné et ne pas inclure un changement prévu pour une époque ultérieure.

L'enregistrement post-activation le plus utile comparerait la fonctionnalité active, la distribution logicielle et la participation des opérateurs sur la même fenêtre. L'enregistrement de la fonctionnalité identifie le moment où la règle a commencé à s'appliquer. L'enregistrement logiciel identifie quelles versions étaient en service. Les votes et les blocs montrent si le réseau et les opérateurs individuels se sont comportés différemment.

Les slots sautés sont une observation possible. Ils peuvent aussi augmenter pour des raisons sans rapport avec le correctif, y compris la performance ordinaire des validateurs désignés pour diriger. Comparer plusieurs fenêtres et associer les sauts à leurs leaders donne du contexte à l'observation.

L'enjeu délinquant offre une vue différente. Le montant peut évoluer lorsqu'un grand validateur cesse de participer, même si le nombre total de nœuds délinquants change à peine. La comparaison doit tenir compte des opérateurs qui étaient déjà délinquants avant la mise à niveau.

Les effets sur les RPC et les échanges doivent être documentés séparément. Ces fournisseurs peuvent servir un grand nombre d'utilisateurs sans apparaître dans la comparaison des enjeux. Leurs avis, leurs métriques de service et les enregistrements du moment où les nœuds sont revenus aux slots actuels décriraient des perturbations que les données de vote ne peuvent pas capturer.

Pourquoi un déploiement progressif nécessite encore un test d'activation

Une version stable d'un client peut être déployée progressivement avant qu'une nouvelle fonctionnalité ne soit active. Cela permet aux opérateurs de voir si le logiciel démarre correctement, se synchronise et traite les transactions selon les règles en vigueur. Cela aide aussi à révéler les problèmes de déploiement avant que davantage de nœuds ne l'utilisent.

Un déploiement réussi avant l'activation ne peut pas exercer toutes les conséquences de la fonctionnalité active. Une transaction proche de la limite de données de compte chargées doit être testée selon les deux ensembles de règles pour montrer exactement où le résultat change. C'est un test différent de celui qui consiste à observer si le binaire reste en ligne.

Crypto.news a précédemment rapporté qu'Alpenglow visait une approche différente de la finalité. Ses critères de réussite incluaient ce qui arrivait à la vitesse de confirmation. Le correctif ProgramData est mieux évalué en examinant si les clients s'accordent sur les transactions qui rencontrent la nouvelle limite et si l'infrastructure reste disponible après l'activation du gate.

Un retour en arrière change aussi de sens au moment de l'activation. Avant la limite, une version plus ancienne encore prise en charge peut toujours traiter les règles déjà en vigueur. Après, revenir à une version dépourvue de la fonctionnalité peut réintroduire exactement l'incompatibilité que l'opérateur cherchait à résoudre. Une solution de repli doit conserver la prise en charge du gate actif.

Un opérateur disposant de capacité excédentaire peut démarrer un nœud corrigé et le valider avant d'y affecter du trafic. Un opérateur plus petit peut devoir redémarrer son unique nœud et attendre qu'il se synchronise. L'échéance est partagée, mais le temps que les utilisateurs passent à attendre peut dépendre de la redondance du fournisseur.

Pourquoi le prix du SOL ne peut pas mesurer l'effet de la mise à niveau

Le SOL peut baisser ou augmenter pendant les mêmes heures où les opérateurs installent un correctif. Il s'échange contre bon nombre des mêmes devises et pools de capitaux que d'autres actifs crypto. Les taux, les mouvements du Bitcoin et les changements de levier peuvent affecter le prix au cours de la même fenêtre.

Un problème technique peut avoir de l'importance pour le trading s'il interrompt les transferts ou rend une application indisponible. Les preuves de cette explication incluraient des avis des plateformes, des changements dans les dépôts ou retraits, ou des données d'exécution onchain liées aux comptes concernés. Le prix d'un token seul n'identifie pas ce canal.

L'échec d'une transaction individuelle se distingue également de la perte de contrôle d'un compte. Un portefeuille peut avoir construit une transaction avec des informations obsolètes ou l'avoir soumise via un nœud obsolète. L'utilisateur peut toujours contrôler le compte tandis que l'application a du mal à atteindre le réseau actuel.

Le test le plus direct après l'échéance se situe donc au niveau du service. Un nœud de vote devrait être à jour et enregistrer des votes. Un service RPC devrait répondre aux requêtes de la chaîne acceptée. Un échange devrait être en mesure de rendre compte si et quand il a traité les transferts soumis autour du basculement.

Ces preuves peuvent étayer une évaluation même si le prix évolue pour des raisons sans rapport. Elles donnent aussi aux délégateurs un moyen d'évaluer la performance de leur propre validateur sans traiter une exigence de version à l'échelle du réseau comme une déclaration sur les résultats de chaque opérateur.

Ce qui se passe lorsqu'un opérateur revient en ligne

L'installation du logiciel corrigé est une étape dans la restauration d'un nœud. L'opérateur doit ensuite voir si le processus rattrape la chaîne acceptée et la suit selon les règles actuelles. Un serveur peut redémarrer avec succès tout en rejouant encore des blocs ou en renvoyant des données en retard par rapport à la tête de chaîne.

Un nœud de vote doit aussi montrer que sa participation a repris. Son opérateur peut comparer les votes actuels avec le moment où le nœud s'est rétabli. Un délégateur lisant plus tard les données de récompense peut alors distinguer le point de rétablissement du moment où le correctif a été installé.

Un fournisseur de services peut retirer un nœud corrigé de la rotation jusqu'à ce qu'il ait rattrapé son retard et passé les vérifications. L'opérateur peut comparer le slot, le résultat d'une transaction récente et le résultat d'une simulation avec une référence séparée. Un fournisseur qui remet le nœud en trafic avant ces vérifications peut donner l'impression qu'une mise à niveau logicielle est terminée alors que les clients rencontrent encore des données obsolètes.

La chronologie compte lors de l'évaluation de l'impact. Un nœud qui a divergé et est revenu dans la même époque peut apparaître sain dans un annuaire ultérieur. Sa participation manquée peut néanmoins compter pour l'opérateur ou les délégateurs. Une chronologie publique d'incident devrait contenir suffisamment de détails pour montrer quand le service s'est arrêté et quand l'activité normale a repris.

Les équipes applicatives peuvent aussi examiner les transactions qui ont échoué uniquement via un backend particulier. Si la resoumission via un nœud actuel résout le problème sans modification des instructions, le point de terminaison antérieur devient une source probable de l'échec. Si la même transaction échoue systématiquement sur les nœuds actuels près de la limite de données du compte, la transaction elle-même peut devoir être reconstruite.

Une telle reconstruction peut impliquer de réduire les données chargées par la transaction ou de séparer les instructions là où l'application peut tolérer plusieurs transactions. Diviser une transaction peut modifier ses garanties, car des instructions censées réussir ou échouer ensemble peuvent ne plus le faire. Le changement relève donc de la conception propre à l'application, aux côtés de ses exigences de chargement de compte.

Les conséquences pour un utilisateur dépendent de l'endroit où l'incompatibilité s'est produite. Un opérateur peut manquer de participation, un RPC peut renvoyer des informations obsolètes et une application peut construire une transaction qui ne tient plus. Les deux premiers peuvent être traités en restaurant une infrastructure compatible, tandis que le troisième dépend de la transaction et de la règle active.

Une vérification du rétablissement de Solana devrait garder ces observations séparées. Elle devrait comparer les enregistrements de vote des opérateurs, les enregistrements de service des fournisseurs et les résultats d'exécution des applications concernées. Cela permet d'identifier un effet étroit même si le réseau a continué à produire des blocs tout au long.

L'échéance de novembre a donné aux opérateurs une version nommée et une frontière d'époque. La trace durable de son impact proviendra de ce que les nœuds ont fait autour de cette frontière et du service qu'ils ont pu fournir après.

Points à surveiller

• Versions compatibles : Le calendrier d’Anza et les notes de version peuvent établir le seuil du réseau principal et ses équivalents entre les clients.
• Participation au vote : L’enjeu actif et les crédits de vote peuvent montrer si la participation au vote a changé autour de la limite.
• Confirmations du réseau : Les enregistrements de blocs et de confirmations peuvent montrer si le réseau a continué à traiter des transactions autour du changement.
• Opérations des plateformes d’échange : Les avis des plateformes peuvent établir si une plateforme d’échange a suspendu ses propres dépôts ou retraits Solana.

FAQ