La mise à niveau à venir du registre XRP Ledger en version 3.1.3 a relancé un débat après que le CTO émérite de Ripple, David Schwartz, a expliqué pourquoi l’XRPL observe davantage d’événements qui ressemblent à des « hard forks techniques ».
Résumé
* David Schwartz a déclaré que l’XRPL connaît plus de « hard forks techniques » que la plupart des registres publics établis.
* La version 3.1.3 de l’XRPL inclut fixCleanup3_1_3 pour les NFT, les Permissioned Domains, les Vaults et le Lending Protocol.
* Les nœuds qui manquent la date limite du 27 mai pour la mise à jour pourraient se retrouver confrontés à un blocage via amendement et à des perturbations de service.
Le XRP Ledger se dirige vers l’activation de la version 3.1.3, qui inclut l’amendement fixCleanup3_1_3. Le communiqué officiel de l’XRPL indique que l’amendement contient des correctifs pour les NFT, les Permissioned Domains, les Vaults et le Lending Protocol. En raison de la nature de ces correctifs, son vote par défaut a été fixé à yes.
Comme l’avait déjà rapporté crypto.news, l’amendement est entré dans une période d’activation de deux semaines et devrait être activé le 27 mai. Il a également précisé que les opérateurs doivent effectuer une mise à jour afin que leurs nœuds puissent suivre les nouvelles règles du réseau.
La date limite a suscité des inquiétudes chez certains membres de la communauté, car des nœuds plus anciens pourraient perdre l’accès normal une fois l’amendement activé. Cela a mené à un débat sur la question de savoir si la procédure de mise à niveau doit être considérée comme une maintenance de routine ou comme un risque de hard fork.
David Schwartz explique les hard forks de l’XRPL
-------------------------------------------
Schwartz a abordé le débat sur X et a déclaré que l’XRPL compte plus d’événements qui sont « techniquement des hard forks » que beaucoup d’autres blockchains publiques établies. Il a relié ce schéma à la conception de l’XRPL et à son recours à des smart transactors.
Il a également repoussé l’idée d’un simple modèle « un nœud, un vote ». Schwartz a déclaré : « Je ne pense pas que quiconque voudrait un système “un nœud, un vote”, » ajoutant qu’une personne pourrait créer de nombreux nœuds pour truquer un tel système.
Ses commentaires portaient surtout sur la façon dont l’XRPL gère la coordination. Selon lui, le simple nombre brut de nœuds ne détermine pas à lui seul quelle chaîne devient le registre principal en cas de scission.
Scission de validateurs de l’XRPL et débat sur l’UNL
---------------------------------------
Schwartz a déclaré qu’une scission de validateurs ne décide pas, à elle seule, du résultat. Il a écrit que chaque camp aurait besoin de validateurs en quantité suffisante pour créer une Unique Node List, ou UNL, fonctionnelle, avec des validateurs qui s’accordent sur un flux de ledger.
Ce point est crucial car le consensus de l’XRPL dépend de listes de validateurs considérées comme fiables plutôt que du poids issu du minage ou du staking. Si deux groupes suivent des règles différentes, chacun d’eux aurait aussi besoin de listes de validateurs correspondantes et de répartitions de code pour continuer à produire des ledgers.
Ce débat ne signifie pas qu’une scission de chaîne s’est produite. Il montre plutôt comment le modèle de mise à niveau de l’XRPL repose sur des mises à jour logicielles, l’alignement des validateurs et le choix des utilisateurs sur les règles qu’ils suivent.
Les correctifs de l’amendement XRPL restent au centre
----------------------------------------------
La mise à niveau actuelle se concentre sur des corrections de bugs plutôt que sur une nouvelle fonctionnalité de marché. La version officielle de l’XRPL indique que fixCleanup3_1_3 couvre le nettoyage des NFT, les correctifs des Permissioned Domains, des Vaults et du Lending Protocol.
Cela rend la date limite du 27 mai importante pour les exchanges, les entreprises d’infrastructure, les validateurs et les projets qui utilisent des services de l’XRPL. Les nœuds qui ne procèdent pas à la mise à niveau pourraient se retrouver désynchronisés par rapport aux règles actives du réseau.
