La page des amendements connus de XRPL liste fixCleanup3_1__3 pour une activation le 27 mai, et par conception, cet événement est une mise à jour de maintenance.
La version 3.1.3 de rippled inclut des correctifs pour les NFT, les domaines avec autorisation, les coffres et le protocole de prêt, et le blog XRPL a fixé le vote par défaut à Oui en raison de l'importance de ces correctifs.
Le processus de modification exige plus de 80 % de soutien des validateurs de confiance maintenu pendant deux semaines avant que les nouvelles règles ne deviennent permanentes.
Ce qui rend cet épisode intéressant à examiner au-delà de la date limite, c'est ce que le cofondateur de XRPL David Schwartz a déclaré sur ce qu'exigerait véritablement un fork, car sa réponse révèle comment la légitimité du protocole fonctionne sur toute blockchain.
Le point central de Schwartz est que le nombre brut de nœuds est un mauvais indicateur de la puissance de consensus. Un système où les nœuds votent proportionnellement à leur nombre crée une surface d'attaque où quiconque peut lancer des milliers de machines à faible coût.
Dans le modèle XRPL, chaque opérateur de serveur maintient un ensemble sélectionné de validateurs que le serveur considère comme non collusifs, la Unique Node List, et la UNL détermine les votes de validation que le serveur prend en compte lors de la concorde.
Un serveur reçoit des messages de validation provenant de nombreux nœuds à travers le réseau, et les validateurs de sa UNL déterminent lesquels de ces messages façonnent la vision du serveur sur le registre.
Schwartz a expliqué que la légitimité du consensus sur XRPL passe par des listes de confiance et la coordination des validateurs, créant un système dans lequel l'alignement UNL et l'adoption économique déterminent quel registre survit à une séparation.
Pourquoi un vrai fork nécessite une campagne de coordination complète
Pour le vote sur XRPL le 27 mai, les serveurs qui deviennent bloqués par un amendement perdent la capacité de déterminer la validité du ledger, de soumettre ou de traiter des transactions, de participer à la concorde ou de voter sur de futurs amendements.
Cela rend la date limite opérationnellement cruciale pour toute plateforme d'échange, wallet, Explorateur ou opérateur d'infrastructure encore en cours d'utilisation avec une version antérieure à 3.1.3, car ces serveurs deviennent non participants du registre canonique jusqu'à ce que l'opérateur effectue la mise à jour.
L'infrastructure bloquée par amendement perd l'accès à la chaîne mise à niveau et manque d'infrastructure de coordination pour ancrer une rivale fonctionnelle.
Pour produire un fork crédible, un groupe dissident aurait besoin de validateurs prêts à continuer de produire des registres selon les anciennes règles, et sans validateurs, il n’y a pas de flux de registre à suivre.
Ils auraient ensuite besoin d'une liste de nœuds uniques concurrente que les serveurs peuvent configurer ou que le logiciel peut utiliser par défaut, car sans une liste de validateurs de confiance, les nœuds n'ont aucun mécanisme pour se coordonner autour des anciennes règles.
En plus de cela, ils auraient besoin d'une distribution de code qui préserve les anciennes règles et qui inclut des valeurs par défaut pointant vers le UNL concurrent, ainsi qu'un support infrastructurel suffisant de la part des wallets, des plateformes d'échange, des Explorateurs et des applications pour rendre le ledger des anciennes règles accessible et négociable.
La documentation XRPL cite des recherches montrant que, dans le pire des cas, des UNL concurrents peuvent nécessiter un chevauchement de 90 % pour éviter un fork, ce qui signifie que tout UNL concurrent devrait partager presque l'intégralité de l'ensemble de validateurs de confiance avec celui canonique pour maintenir sa cohérence interne.
Une fork formée autour d'un ensemble de validateurs radicalement différent risque de produire un registre incapable de maintenir son propre consensus, encore moins d'attirer l'adoption du marché.
Ce que le processus de modification suit réellement, c'est le soutien des validateurs, et le seuil de 80 % pendant deux semaines garantit que les entités que le réseau fait confiance ont atteint un accord durable avant que de nouvelles règles ne deviennent permanentes.
Une grande partie des nœuds non mis à jour non validateurs peut refléter un retard infrastructurel sans impliquer quoi que ce soit sur la trajectoire du registre canonique.
La distance entre le retard d'infrastructure et une chaîne rivale
Dans le scénario baissier, les plateformes d'échange, les wallets ou les opérateurs d'infrastructure qui retiennent l'activation du 27 mai deviennent bloqués par amendement et cessent de fonctionner comme participants du registre.
Les utilisateurs qui passent par ces fournisseurs rencontrent des interruptions de service, telles que des transactions qui ne peuvent pas être soumises, des explorateurs qui ne peuvent pas confirmer la validité du registre, et des applications qui ne peuvent pas traiter les paiements.
Ce coût opérationnel incombe aux opérateurs qui ont mis à l'arrière-plan la mise à niveau, et il vaut la peine de le suivre, particulièrement pour toute grande plateforme d'échange ou tout custodian encore en fonctionnement avec des nœuds pré-3.1.3 à l'activation.
Un retard soutenu de l'infrastructure sur un nombre suffisant de fournisseurs créerait une friction réelle pour les utilisateurs, même si le registre canonique continue selon les nouvelles règles.
Dans le scénario haussier, fixCleanup3_1_3 s'active selon le calendrier avec la supermajorité des validateurs intacte, les opérateurs d'infrastructure mettent à jour sans incident majeur, et l'épisode devient une activation de modification routinière.
Les correctifs pour les NFT, les domaines avec autorisation, les coffres et le protocole de prêt entrent en vigueur, et le réseau passe à la suite. Le débat de gouvernance soulevé par la mise à niveau subsiste quel que soit le résultat, car l'explication de Schwartz sur ce qu'exigerait une véritable séparation s'applique à toute future modification.
Maintenir les anciennes règles exige un groupe dissident utilisant un logiciel ancien, recrutant des validateurs autour d'une UNL concurrente, et convainquant les wallets, les plateformes d'échange et les market makers de reconnaître leur registre comme le registre canonique XRP, contre une configuration par défaut orientant tout le monde vers la chaîne mise à jour.
Chaque blockchain possède une couche de gouvernance
Schwartz a établi une comparaison avec Stellar, dont la mise à jour du Protocole 24 est elle-même une correction de stabilité pour un bogue d'archivage d'état dans Stellar Core, ce qui a nécessité un événement de maintenance exigeant le même type d'adoption coordonnée par les validateurs.
La couche de légitimité équivalente du bitcoin passe par les mineurs, les nœuds économiques, les implémentations client et les listages sur les plateformes d'échange. Celle d'ethereum passe par les validateurs, l'infrastructure de staking, la diversité des clients, les développeurs principaux et l'adoption au niveau des applications.
Ce que XRPL rend explicite à travers les UNL, d'autres réseaux intègrent dans la répartition du pouvoir minier, l'économie de staking ou le consensus social autour duquel les développeurs de logiciels clients font confiance.
Les mécanismes diffèrent entre bitcoin, ethereum et XRPL, tandis que la dépendance à des décisions humaines coordonnées pour rendre les modifications de règles permanentes traverse les trois.
L'activation du 27 mai illustre comment la couche de gouvernance de XRPL convertit l'accord des validateurs en permanence du registre, la configuration UNL déterminant quels accords sont pris en compte.
Un opérateur qui ne partage pas l'accord avec fixCleanup3_1_3 a la liberté technique d'exécuter un logiciel ancien et de configurer une UNL rivale.
Que toute plateforme d'échange liste le token résultant, que tout wallet le prenne en charge, ou que tout market maker fournisse de la liquidité est une question que le protocole ne peut pas répondre pour eux.
Ce décalage de coordination explique pourquoi les mises à jour de protocole sur les réseaux largement adoptés produisent rarement des forks durables : les économies associées à la poursuite de la chaîne canonique pèsent presque toujours plus lourd que celles de construire une chaîne parallèle depuis le début, et la chaîne canonique est celle que le marché décide comme étant réelle.
Le post XRPL’s May 27 upgrade shows how validators and markets decide a blockchain split est apparu pour la première fois sur CryptoSlate.