La mise à jour de XRPL du 27 mai montre comment les validateurs et les marchés décident d'une scission de la blockchain
La page des modifications connues de XRPL répertorie fixCleanup3_1__3 pour une activation le 27 mai et, de par sa conception, l'événement est une mise à niveau de maintenance.
La version 3.1.3 des correctifs des bundles ondulés pour les NFT, les domaines autorisés, les coffres-forts et le protocole de prêt, et le blog XRPL ont défini le vote par défaut sur Oui en raison de l'importance de ces correctifs.
Le processus de modification nécessite le soutien de plus de 80 % de validateurs de confiance pendant deux semaines avant que les nouvelles règles ne deviennent permanentes.
Ce qui rend l'épisode intéressant à examiner au-delà de la date limite, c'est ce que David Schwartz, co-créateur de XRPL, a dit à propos de ce qu'un véritable fork nécessiterait réellement, car sa réponse révèle comment la légitimité du protocole fonctionne sur n'importe quelle blockchain.
Le point central de Schwartz est que le nombre brut de nœuds est un mauvais indicateur du pouvoir de consensus. Un système dans lequel les nœuds votent proportionnellement à leur nombre crée une surface d'attaque où n'importe qui peut faire tourner des milliers de machines à faible coût.
Dans le modèle XRPL, chaque opérateur de serveur gère un ensemble organisé de validateurs auxquels le serveur fait confiance pour ne pas s'entendre, la liste de nœuds uniques, et l'UNL détermine les votes de validation que le serveur compte lors du consensus.
Le processus de modification du XRPL nécessite le soutien de plus de 80 % des validateurs de confiance pendant deux semaines avant que les nouvelles règles ne deviennent permanentes, bloquant les serveurs non mis à niveau.
Un serveur reçoit des messages de validation de nombreux nœuds à travers le réseau, et les validateurs sur son UNL déterminent lesquels de ces messages façonnent la vue 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 survit à une scission.
Pourquoi un vrai fork nécessite une campagne de coordination complète
Lors du vote XRPL du 27 mai, les serveurs bloqués par les amendements perdent la capacité de déterminer la validité du grand livre, de soumettre ou de traiter des transactions, de participer au consensus ou de voter sur les futurs amendements.
Cela rend la date limite opérationnellement importante pour tout échange, portefeuille, explorateur ou opérateur d'infrastructure exécutant encore un logiciel antérieur à 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 un amendement perd l’accès à la chaîne améliorée et ne dispose pas de l’infrastructure de coordination nécessaire pour ancrer un rival fonctionnel.
Pour produire un fork crédible, un groupe dissident aurait besoin de validateurs prêts à continuer à produire des registres selon les anciennes règles, et sans validateurs, il n'y a pas de flux de registres à suivre.
Ils auraient alors besoin d'une liste de nœuds uniques concurrente que les serveurs peuvent configurer ou que les logiciels peuvent utiliser par défaut, car sans une liste de validateurs de confiance, les nœuds ne disposent d'aucun mécanisme de coordination autour des anciennes règles.
En plus de cela, ils auraient besoin d'une distribution de code préservant les anciennes règles et livrés avec des valeurs par défaut pointant vers l'UNL rival, et ils auraient besoin d'un support d'infrastructure suffisant pour rendre le grand livre des anciennes règles accessible et échangeable.
Un fork XRPL crédible nécessite cinq couches au-delà des nœuds non mis à niveau : des validateurs d'anciennes règles, un UNL rival, un code d'anciennes règles, un support d'infrastructure et une reconnaissance du marché.
La documentation XRPL cite des recherches montrant que les UNL concurrents peuvent avoir besoin d'un chevauchement de 90 % dans le pire des cas pour éviter un fork, ce qui signifie que tout UNL rival devrait partager la quasi-totalité de l'ensemble de validateurs de confiance avec le validateur canonique pour maintenir la cohérence interne.
Un fork se formant autour d’un ensemble de validateurs radicalement différent risque de produire un grand livre qui ne peut pas maintenir son propre consensus, et encore moins attirer l’adoption du marché.
Ce que le processus d'amendement suit en réalité, c'est le soutien des validateurs, et le seuil de 80 % pour deux semaines garantit que les entités en qui le réseau a confiance ont conclu un accord durable avant que les nouvelles règles ne deviennent permanentes.
Une grande partie des nœuds non-validateurs non mis à niveau peuvent refléter un retard de l'infrastructure sans rien impliquer sur la trajectoire du grand livre canonique.
La distance entre le retard des infrastructures et une chaîne rivale
Dans le cas de l'ours, les bourses, les portefeuilles ou les opérateurs d'infrastructure qui sont en retard par rapport à l'activation du 27 mai seront bloqués par amendement et cesseront de fonctionner en tant que participants au grand livre.
Les utilisateurs passant 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 grand livre et des applications qui ne peuvent pas traiter les paiements.
Ce coût opérationnel incombe aux opérateurs qui ont dépriorisé la mise à niveau, et cela mérite d'être suivi, en particulier pour tout échange ou dépositaire majeur exécutant encore des nœuds antérieurs à 3.1.3 au moment de l'activation.
Un retard soutenu en matière d’infrastructure chez un nombre suffisant de fournisseurs créerait de véritables frictions entre les utilisateurs, même si le grand livre canonique se poursuit selon les nouvelles règles.
Dans le cas du taureau, fixCleanup3_1_3 s'active dans les délais avec la majorité qualifiée des validateurs intacte, les opérateurs d'infrastructure se mettent à jour sans incident majeur et l'épisode devient une activation de modification de routine.
Les correctifs des NFT, des domaines autorisés, des coffres-forts et des