XRPL v3.2.0 dépasse le seuil UNL, mais adoption lente
La préparation des validateurs est déjà au-dessus de la barre d'activation de 80 %, tandis que fixCleanup3_2_0 reste un catalyseur séparé et plus lent.
La version 3.2.0 du serveur XRP Ledger a atteint environ 89 % d'adoption parmi les validateurs UNL par défaut, franchissant le seuil requis pour l'activation si cela se maintient pendant deux semaines consécutives. La base de nœuds plus large est encore biaisée vers la version 3.1.3, et un amendement distinct axé sur la sécurité lié à la version est en dessous du taux de mise à niveau du logiciel.
Points clés
- Le logiciel serveur XRPL v3.2.0 a été lancé le 15 juin avec des objectifs déclarés de réduction des coûts d'exploitation, d'amélioration de la stabilité et d'attrait institutionnel renforcé.
- L'instantané d'XRPSCAN a montré environ 833 nœuds XRPL actifs, avec environ 43 % sur v3.2.0 contre environ 51 % fonctionnant encore sur v3.1.3.
- Les validateurs UNL par défaut sont plus avancés que la base de nœuds : 31 des 35 validateurs étaient sur v3.2.0, soit environ 89 %.
- L'amendement fixCleanup3_2_0 sur le registre, qui regroupe des corrections de sécurité et des améliorations pour les nouvelles fonctionnalités XRPL, est resté sous vote et a été décrit comme étant largement en dessous du déploiement du logiciel.
La version 3.2.0 franchit la barre UNL par défaut, en attente de la fenêtre de deux semaines
Le logiciel serveur XRPL v3.2.0 a été déployé le 15 juin avec un argument opérationnel : moins cher à exécuter, plus stable et plus attrayant pour un usage institutionnel. D'ici le 8 juillet, la mise à niveau avait déjà franchi le seuil clé de la couche des validateurs sur la liste Unique Node par défaut.
Les mécanismes d'activation de XRPL sont binaires et soumis à des délais. "Pour qu'une nouvelle version de logiciel ou un amendement s'active, il doit bénéficier d'un soutien soutenu de plus de 80 % des validateurs sur cette liste pendant deux semaines consécutives." Sur les 35 validateurs de l'UNL par défaut, 31 exécutaient v3.2.0, soit environ 89 %, ce qui est supérieur à l'exigence de >80 %. La question ouverte est la durée, puisque la condition de deux semaines n'est pas confirmée comme remplie.
Pour les traders, cette répartition est importante car elle cadre le déploiement comme étant plus proche de l'achèvement au niveau du consensus que ne l'implique la distribution plus large du réseau.
FixCleanup3_2_0 : L'amendement de sécurité sur une voie séparée et plus lente
Le risque matériel se trouve principalement dans la deuxième voie. Parallèlement à la publication du logiciel, XRPL a un amendement sur le registre, fixCleanup3_2_0, toujours en vote formel au 8 juillet.
L'amendement regroupe des corrections de sécurité et des améliorations liées aux nouvelles fonctionnalités de XRPL, y compris le mode unique-actifcoffres, autoriséséchanges décentralisés, des jetons multi-usages (MPT), et le protocole de prêt. Il ajoute également des vérifications internes destinées à empêcher les comptes supprimés de laisser des données résiduelles.
De manière critique, l'amendement ne progresse pas en synchronisation avec la mise à niveau du logiciel. Il a été décrit comme ayant un taux d'adoption bien inférieur à celui de la v3.2.0, renforçant l'idée que « mettre à niveau un validateur et voter pour l'amendement sont deux étapes distinctes. » Ripple a voté en faveur de fixCleanup3_2_0.
Opérationnellement, l'amendement introduit une limite stricte pour les retardataires. "Les validateurs qui ne parviennent pas à mettre à jour avant l'activation de l'amendement risquent d'être coupés du registre dans ce que le registre appelle un état bloqué par amendement." Cela transforme le retard de version d'une scission cosmétique en un événement de connectivité potentiel si le vote finit par être validé.
Signaux qui pourraient resserrer ou prolonger le calendrier de mise à niveau
Le premier minuteur est le soutien à la persistance des validateurs. Le seuil qui compte est de savoir si le soutien par défaut de l'UNL pour v3.2.0 reste au-dessus de 80 % pendant les deux semaines requises, car c'est la condition d'activation.
Le deuxième minuteur est le nettoyage de la distribution. Le mélange de nœuds d'XRPSCAN est encore biaisé vers v3.1.3, donc les traders vont surveiller si la part de v3.2.0 augmente vers, puis au-delà, de la part d'environ 51 % de l'ancienne version alors que les opérateurs rattrapent leur retard.
Le troisième minuteur est l'amendement lui-même. Le décompte des votes pour le fixCleanup3_2_0 n'a pas été spécifié, seulement qu'il est bien en dessous de l'adoption du logiciel, donc tout pourcentage publié ou toute accélération visible dans le vote devient le prochain catalyseur concret.
Les communications des opérateurs qui font explicitement référence à l'évitement d'un état bloqué par amendement seraient également un indice que l'urgence de la mise à niveau passe de facultative à obligatoire.
Répartition de l'adoption : les validateurs ont été mis à niveau, la base de nœuds plus large ne l'a pas été.
XRPSCAN a montré environ 833 nœuds actifs au moment de l'instantané, avec environ 43 % sur v3.2.0 et environ 51 % toujours sur v3.1.3. C'est un déploiement qui semble lent si le seul critère est le nombre brut de nœuds.
Mais la couche de validateurs raconte une histoire différente. Sur l'UNL par défaut, 31 des 35 validateurs étaient déjà sur v3.2.0, soit environ 89 %. Dans la structure du marché de XRPL, c'est la métrique la plus exploitable car elle détermine si les mises à niveau et les amendements peuvent réellement passer à un état actif.
C'est pourquoi les traders ont tendance à privilégier la préparation de l'UNL par rapport à la distribution large des nœuds. Un réseau peut sembler « en retard » en nombre de nœuds tout en étant encore proche d'une transition de couche de consensus, et ces transitions sont là où le risque opérationnel et la volatilité ont tendance à se concentrer.
Le risque d'activation à deux voies est le véritable signal de trading ici.
Je considère cela comme deux catalyseurs distincts qui peuvent agir à des moments différents. v3.2.0 est déjà au-dessus du seuil UNL par défaut, donc le véritable test est de savoir si ce soutien reste fixé pendant toute la fenêtre de deux semaines, car c'est ce qui transforme "déployé" en "activé."
L'incertitude plus grande concerne fixCleanup3_2_0. Si cet amendement atteint finalement l'activation alors que le vote est encore en retard, la configuration commence à sembler structurelle plutôt que guidée par le récit, car le risque bloqué par l'amendement oblige les opérateurs tardifs à agir.
Cela ressemble plus à un catalyseur de sentiment qu'à un changement fondamental jusqu'à ce que le vote sur l'amendement se resserre et que la longue traîne de nœuds du réseau comble l'écart de version d'une manière qui réduit le risque de temps d'arrêt inattendu.
