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 autorisés, les coffres-forts et le protocole de prêt, et le blog XRPL a fixé le vote par défaut sur Oui en raison de l'importance de ces correctifs.
Le processus d'amendement nécessite un soutien de plus de 80 % des validateurs fiables maintenu pendant deux semaines avant que les nouvelles règles ne deviennent permanentes.
Ce qui rend cet épisode méritant d'être examiné au-delà de la date limite, c'est ce qu'a dit le co-créateur de XRPL, David Schwartz, à propos de ce qu'exigerait réellement un véritable fork, car sa réponse révèle comment fonctionne la légitimité du protocole sur n'importe quelle 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ù n'importe qui peut mettre en marche des milliers de machines à faible coût.
Dans le modèle XRPL, chaque opérateur de serveur maintient un ensemble soigneusement sélectionné de validateurs auxquels le serveur fait confiance pour ne pas se concerter, la Liste Unique de Nœuds (UNL), et l'UNL détermine quels votes de validation le serveur prend en compte lors du consensus.
Le processus d'amendement XRPL nécessite le soutien de plus de 80 % des validateurs fiables maintenu pendant deux semaines avant que les nouvelles règles ne deviennent permanentes, bloquant ainsi les serveurs non mis à jour.
Un serveur reçoit des messages de validation provenant de nombreux nœuds à travers le réseau, et les validateurs de son UNL déterminent lesquels de ces messages façonnent la vision du serveur sur le grand livre.
Schwartz a expliqué que la légitimité du consensus sur XRPL passe par les listes de confiance et la coordination des validateurs, produisant un système dans lequel l'alignement de l'UNL et l'adoption économique déterminent quel grand livre survivra à une scission.
Pourquoi un vrai fork nécessite une campagne complète de coordination
Pour le vote XRPL du 27 mai, les serveurs bloqués par l'amendement perdent la capacité de déterminer la validité du grand livre, de soumettre ou traiter des transactions, de participer au consensus ou de voter sur de futurs amendements.
Cela rend la date limite opérationnellement importante pour tout échange, portefeuille, explorateur ou opérateur d'infrastructure encore sous logiciel pré-3.1.3, car ces serveurs deviennent non participants au grand livre canonique jusqu'à ce que l'opérateur mette à jour.
L'infrastructure bloquée par l'amendement perd l'accès à la chaîne mise à jour 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 à produire des grands livres selon les anciennes règles, et sans validateurs, il n'y a aucun flux de grand livre à suivre.
Il leur faudrait ensuite une Liste Unique de Nœuds concurrente que les serveurs peuvent configurer ou que le logiciel peut utiliser par défaut, car sans une liste de validateurs fiables, les nœuds n'ont aucun mécanisme pour se coordonner autour des anciennes règles.
En outre, ils auraient besoin d'une distribution de code qui préserve les anciennes règles et qui soit livrée avec des paramètres par défaut pointant vers l'UNL rivale, et ils auraient besoin d'un support d'infrastructure de la part des portefeuilles, des échanges, des explorateurs et des applications suffisant pour rendre le grand livre selon les anciennes règles accessible et négociable.
Un fork XRPL crédible nécessite cinq niveaux au-delà des nœuds non mis à jour : des validateurs selon les anciennes règles, une UNL rivale, un code selon les anciennes règles, un support d'infrastructure et une reconnaissance du marché.
La documentation XRPL cite des recherches montrant que des UNL concurrentes peuvent avoir besoin d'un chevauchement de 90 % dans le pire des cas pour éviter un fork, ce qui signifie que toute UNL rivale devrait partager presque tout l'ensemble de validateurs fiables avec la chaîne canonique pour maintenir une cohérence interne.
Un fork formé autour d'un ensemble de validateurs radicalement différent risque de produire un grand livre incapable de maintenir son propre consensus, sans parler d'attirer l'adoption du marché adoption.
Ce que le processus d'amendement suit en réalité, c'est le soutien des validateurs, et le seuil de 80 % pendant deux semaines garantit que les entités auxquelles le réseau fait confiance ont atteint un accord durable avant que les nouvelles règles ne deviennent permanentes.
Une grande partie des nœuds non validateurs non mis à jour peut refléter un retard d'infrastructure sans rien dire sur la trajectoire du grand livre canonique.
La distance entre le retard d'infrastructure et une chaîne rivale
Dans le scénario baissier, les échanges, portefeuilles ou opérateurs d'infrastructure qui sont en retard par rapport à l'activation du 27 mai deviennent bloqués par l'amendement et cessent de fonctionner comme participants au grand livre.
Les utilisateurs qui passent par ces fournisseurs rencontrent des interruptions de service, telles que des transactions impossibles à soumettre, des explorateurs incapables de confirmer la validité du grand livre et des applications incapables de traiter les paiements.
Cet coût opérationnel pèse sur les opérateurs qui ont dépriorisé la mise à jour, et il vaut la peine d'être suivi, particulièrement pour tout grand échange ou gardien encore sous nœuds pré-3.1.3 à l'activation.
Un retard d'infrastructure persistant chez suffisamment de fournisseurs créerait une friction réelle pour les utilisateurs même si le grand livre canonique continue sous les nouvelles règles.
Dans le scénario haussier, fixCleanup3_1_3 s'active selon le calendrier avec la supermajorité de validateurs intacte, les opérateurs d'infrastructure se mettent à jour sans incident majeur, et l'épisode devient une activation d'amendement ordinaire.
Les correctifs pour les NFT, les domaines autorisés, les coffres-forts et le protocole de prêt prennent effet, et le réseau avance. Le débat sur la gouvernance que l'upgrade met en lumière survit à chaque résultat, car l'explication de Schwartz sur ce qu'exigerait une vraie scission s'applique à tout futur amendement.
Maintenir les anciennes règles nécessite un groupe dissident exécutant l'ancien logiciel, recrutant des validateurs autour d'une UNL concurrente et convainquant les portefeuilles, les échanges et les marchés de reconnaître leur grand livre comme le grand livre canonique XRP, contre une configuration par défaut orientant tout le monde vers la chaîne mise à jour.
Toute blockchain possède une couche de gouvernance
Schwartz a fait une comparaison avec Stellar, dont la mise à jour Protocol 24 est elle-même un correctif de stabilité pour un bug d'archivage d'état dans Stellar Core, qui était un événement de maintenance nécessitant le même type d'adoption coordonnée par les validateurs.
La couche de légitimité équivalente de Bitcoin passe par les mineurs, les nœuds économiques, les implémentations de clients et les listes d'échanges. Celle d'Ethereum passe par les validateurs, l'infrastructure de staking, la diversité des clients, les développeurs principaux et l'adoption par la couche des applications.
Ce que XRPL rend explicite grâce aux UNL, d'autres réseaux l'intègrent dans la distribution de la puissance minière, l'économie du 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 aux décisions humaines coordonnées pour rendre permanents les changements de règles traverse les trois.
Au travers de XRPL, Bitcoin, Ethereum et Stellar, les changements de règles deviennent permanents grâce à des décisions coordonnées de validateurs, mineurs, développeurs et marchés plutôt qu'à partir du nombre brut de nœuds.
L'activation du 27 mai illustre comment la couche de gouvernance de XRPL convertit l'accord des validateurs en permanence du grand livre, la configuration de l'UNL déterminant quels accords comptent.
Un opérateur qui n'est pas d'accord avec fixCleanup3_1_3 a la liberté technique de faire tourner l'ancien logiciel et de configurer une UNL rivale.
Que tout échange liste le jeton résultant, que tout portefeuille le prenne en charge ou que tout créateur de marché offre de la liquidité est une question que le protocole ne peut pas répondre pour eux.
Cette déconnexion de coordination explique pourquoi les mises à jour de protocole sur des réseaux bien adoptés produisent rarement des forks durables : l'économie de suivre la chaîne canonique l'emporte presque toujours sur l'économie de construire une chaîne parallèle à partir de zéro, et la chaîne canonique est celle que le marché décide être réelle.
Le post La mise à jour du 27 mai de XRPL montre comment les validateurs et les marchés décident d'une scission blockchain est apparu en premier sur CryptoSlate.