Le XRPL Dashboard a enregistré 30 votes pour parmi les 35 validateurs de confiance qu'il suit lors d'une vérification à 04:43 UTC le 26 septembre. Ce décompte ouvre une nouvelle fenêtre d'approbation pour l'amendement BatchV1_1 — il ne complète pas, en soi, le processus d'activation.

À retenir :

• BatchV1_1 a regagné 30 des 35 votes des validateurs.
• L'horloge d'approbation précédente de deux semaines a été réinitialisée.
• Au moins 29 votes doivent désormais se maintenir.
• Le 9 octobre est une date au plus tôt, conditionnelle.
• L'activation sur le ledger confirme la mise à niveau.

La date a été réinitialisée même si le nombre de votes s'est rétabli

BatchV1_1 avait atteint 30 validateurs favorables le 15 septembre. Selon le calendrier initial, cela situait l'activation vers le 29 septembre. La majorité a ensuite été retirée le 25 septembre et s'est reformée plus tard dans la journée, repoussant l'estimation d'environ 10 jours.

Le tableau de bord identifie les flag ledgers auxquels la majorité précédente a été retirée et la nouvelle a été enregistrée. Il ne révèle pas pourquoi ce changement temporaire s'est produit ni le raisonnement d'un validateur en particulier. Le développement confirmé est la réinitialisation elle-même : un amendement nécessite un soutien ininterrompu pendant toute la fenêtre, même lorsque son nombre de votes revient ensuite au même niveau.

Cela fait du 9 octobre une estimation conditionnelle dérivée du registre actuel de la majorité sur le ledger. Elle peut encore évoluer avant l'activation.

Trente votes pour laissent un vote au-dessus de la ligne

Le seuil du XRPL est souvent résumé à « 80 % de soutien », mais la règle est plus stricte : un amendement nécessite plus de 80 % de soutien des validateurs de confiance. Avec 35 validateurs dans l'ensemble surveillé par le tableau de bord, 28 votes équivalent exactement à 80 %. BatchV1_1 a besoin de 29 votes pour pour établir ou préserver sa majorité.

Le total actuel de 30 équivaut à environ 85,7 %. Il se situe un vote au-dessus de l'exigence de 29 votes. Un passage de 30 à 29 laisserait le compte à rebours intact ; un passage à 28 déclencherait une autre réinitialisation au flag ledger concerné.

Le processus d'amendement du XRPL vérifie les votes autour des flag ledgers, généralement environ toutes les 15 minutes. Ces flag ledgers servent de points de contrôle récurrents où le soutien est mesuré, et l'horloge de deux semaines ne tourne que lorsque le total reste au-dessus du seuil. Une fois qu'un amendement a maintenu plus de 80 % de soutien pendant deux semaines, le changement s'applique définitivement aux versions ultérieures du ledger.

Le code serveur et les règles du Mainnet sont des étapes distinctes

Coind a précédemment expliqué comment BatchV1_1 peut coordonner des instructions de paiement connectées. Cette utilité n'est pas la question soulevée par la réinitialisation. La question actuelle est de savoir si l'amendement corrigé peut compléter le processus de validation requis pour que ces règles de transaction prennent effet sur le Mainnet.

La disponibilité dans le logiciel serveur rend un amendement éligible au vote des validateurs, tandis que le comportement du Mainnet ne change qu'après activation par le réseau. C'est cette séparation qui fait qu'une date du tableau de bord doit être lue comme une estimation en direct de la progression de la gouvernance plutôt que comme une annonce de sortie de produit.

Pourquoi le retrait de sécurité antérieur importe maintenant

BatchV1_1 est le successeur corrigé d'un amendement Batch antérieur qui avait été retiré avant l'activation sur le Mainnet après qu'un chercheur a découvert une faille d'autorisation. La version originale n'est jamais devenue active, et le problème n'a donc pas exposé les fonds des utilisateurs du Mainnet.

Selon la divulgation de vulnérabilité du XRPL, le remplacement a apporté des modifications aux vérifications de signature et d'autorisation et a fait l'objet d'un examen supplémentaire avant de revenir au vote. Cet épisode montre comment le processus fonctionne comme prévu : un code disponible dans le logiciel serveur peut encore être stoppé avant de modifier les règles du Mainnet. La nouvelle fenêtre de 14 jours est le test de gouvernance actuel pour cette implémentation révisée.

La confirmation à surveiller se trouve sur le ledger

Le 9 octobre n'a d'importance que si la majorité se maintient pendant toute la fenêtre. La confirmation viendra d'une pseudo-transaction EnableAmendment enregistrée par le ledger, après quoi BatchV1_1 deviendra une règle active du Mainnet pour les ledgers suivants.

En attendant cet événement, l'information pertinente est la continuité de la majorité des validateurs. Le tableau de bord offre une vue utile du compte à rebours actuel, mais c'est le registre d'activation du ledger qui déterminera si l'amendement Batch corrigé a réellement franchi le seuil de l'infrastructure XRPL en production.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d'investissement. Le soutien des validateurs et le statut de l'amendement peuvent changer.