XRPL corrige un défaut critique avant le lancement du réseau principal, mais les applications clientes restent à risque

Les validateurs du XRP Ledger (XRPL) ont mis BatchV1_1 sur une voie conditionnelle pour s'activer à 14h06:41 UTC le 29 septembre, transformant un quasi-échec de sécurité en un test en direct du processus d'amendement du réseau et de son logiciel environnant.

Le 22 septembre, xrpldashboard a montré que 30 des 35 validateurs de confiance soutenaient l'amendement, au-dessus du seuil de 28 votes affiché. La majorité est apparue pour la première fois sur le registre le 15 septembre.

Selon les règles d'amendement de XRPL, le soutien doit rester au-dessus de 80 % pendant deux semaines. Une chute à 80 % ou moins met fin à la période de majorité, donc la date d'activation reste conditionnelle.

Le 29 septembre est le premier test de production pour savoir si le processus de validation de XRPL, l'implémentation de référence et l'écosystème client ont transformé un défaut dangereux avant le lancement du réseau principal en une infrastructure de transaction atomique utilisable.

Le pare-feu des validateurs a fonctionné avant le réseau principal

L'amendement Batch original n'a jamais été activé sur le réseau principal du XRP Ledger. En février, des chercheurs ont trouvé un défaut d'autorisation critique alors que l'amendement était encore en phase de vote, et les validateurs ont été conseillés de voter contre.

La divulgation officielle de vulnérabilité de XRPL Labs indique qu'aucun fonds n'était en danger.

Le défaut se trouvait dans la boucle qui vérifiait les comptes autorisant un lot. Si le code rencontrait un signataire pour un compte nouvellement créé dont la clé correspondait à ce compte, il retournait immédiatement un succès au lieu de continuer avec les signataires restants.

Un attaquant pouvait placer ce signataire valide en premier, puis ajouter une entrée falsifiée prétendant autoriser un compte victime. Si l'amendement avait été mis en ligne, la transaction non vérifiée de la victime aurait pu s'exécuter sans les clés de la victime.

La réponse de XRPL s'est faite en deux étapes. La version 3.1.1 a marqué les amendements Batch et fixBatchInnerSigs comme non pris en charge, bloquant leur activation. BatchV1_1 les a ensuite remplacés par un chemin d'autorisation réécrit et des défenses supplémentaires.

Cet épisode a été un échec capturé à la frontière entre la publication de logiciels et l'activation de protocoles.

La spécification finale XLS-56 de la Fondation XRPL exige désormais qu'un lot multi-comptes contienne l'ensemble exact et complet des BatchSigners dont l'autorisation serait normalement nécessaire pour les transactions internes, à l'exception du compte dont la signature normale autorise la transaction externe.

Les entrées manquantes, supplémentaires, dupliquées ou mal ordonnées entraînent un rejet.

Chaque BatchSigner signe également plus qu'une simple collection lâche de transactions internes. La charge utile lie la signature au compte externe, son numéro de séquence ou son ticket, le mode de lot sélectionné, les hachages ordonnés de chaque transaction interne et le compte BatchSigner.

Une entrée multi-signée lie également chaque compte signataire imbriqué. Cela empêche une signature valide d'être transférée dans une autre transaction externe ou réaffectée à un autre participant.

L'implémentation de référence fusionnée ajoute des mesures d'application autour de ce design, y compris des vérifications d'ordre et d'unicité des signataires, des limites de nombre de transactions, le rejet des transactions internes soumises directement, et des protections contre la relecture du registre.

Ensemble, ces changements traitent à la fois le bug de succès prématuré divulgué et les manières adjacentes dont des données de lot malformées ou relues pourraient franchir les frontières d'autorisation.

Un lot contient de deux à huit transactions internes. Chaque transaction interne ne porte aucune signature ni frais et est marquée pour ne pas pouvoir être soumise indépendamment. Le lot externe sélectionne exactement un des quatre modes :

• ALLORNOTHING : chaque transaction interne doit réussir ou aucun de leurs changements d'état ne s'engage.
• ONLYONE : la première transaction interne réussie est la seule appliquée.
• UNTILFAILURE : les transactions s'appliquent dans l'ordre jusqu'à ce qu'une échoue.
• INDEPENDENT : chaque transaction interne est tentée indépendamment des résultats des autres.

BatchV1_1 peut prendre en charge des flux atomiques tout ou rien, mais tous les lots ne sont pas atomiques dans ce sens étroit. Les développeurs peuvent également l'utiliser pour des solutions de secours ordonnées ou des paquets indépendants.

L'activation déplace le risque vers l'implémentation

Le piège d'intégration le plus immédiat est qu'un Batch externe peut renvoyer tesSUCCESS même lorsque une ou plusieurs transactions internes échouent. Les clients doivent inspecter les métadonnées et le code de résultat de chaque transaction interne pour déterminer ce qui s'est passé.

Cette distinction est importante en dehors du mode ALLORNOTHING, où l'exécution partielle ou indépendante est intentionnelle.

Le support de BatchV1_1 a été expédié dans xrpld 3.3.0 le 6 août. Une fois l'amendement activé, un serveur qui ne comprend pas les nouvelles règles devient bloqué par l'amendement. Il ne peut plus valider de manière fiable le registre ou participer au consensus jusqu'à ce qu'il soit mis à jour.

Un problème déposé contre xrpl.js a documenté que la version 5.0.0 construisait des signatures de Batch en utilisant l'ancienne charge utile, omettant le compte externe, la séquence et le lien des participants. Les nœuds activés pour BatchV1_1 ont rejeté ces signatures avec temBAD_SIGNATURE.

L'historique des versions de xrpl.js enregistre un support compatible dans la version 5.1.0.

L'amendement réparé de BatchV1_1 de XRPL approche d'un test d'activation conditionnelle après que les validateurs ont rejeté un précédent design de boucle de signataire.

Les lignes de portefeuille et d'indexeur reflètent les conseils d'intégration dans les règles détaillées XLS-56. Le protocole peut rejeter une signature malformée, mais il ne peut pas forcer un portefeuille à expliquer clairement un lot complexe ou un explorateur à présenter chaque résultat interne dans son contexte.

La spécification signale également que le front-running est un domaine encore sous enquête. Une autorisation plus forte empêche une partie de falsifier l'approbation d'un autre compte, mais elle n'élimine pas tous les risques créés par le regroupement de plusieurs actions orientées vers le marché en une seule soumission ordonnée.

Ce que prouvera le 29 septembre

Si la majorité se maintient, l'activation montrera que le processus de validation de XRPL peut arrêter un amendement dangereux, diriger les opérateurs vers une version désactivée et plus tard faire passer un remplacement réparé par la même machinerie de gouvernance.

Cela commencera également un test dans le monde réel pour savoir si les serveurs, bibliothèques de signature, portefeuilles et infrastructures de données s'accordent sur le nouveau format de transaction et ses résultats.

Cela ne prouvera pas que les applications ont adopté BatchV1_1, que les utilisateurs veulent cette fonctionnalité, ou que la demande de transactions sur le réseau augmentera. Le vote sur l'amendement et les versions logicielles établissent la disponibilité du protocole, mais ils ne fournissent pas de preuves d'achats supplémentaires de XRP.

Les signaux utiles viendront après l'activation : si des nœuds obsolètes deviennent bloqués, si les échecs de signature se regroupent autour des anciennes versions de clients, si les portefeuilles présentent des lots multi-comptes de manière intelligible, et si les explorateurs rapportent les résultats internes sans confondre le succès externe avec une exécution complète.

Les validateurs de XRPL ont réussi le premier test en empêchant le défaut de Batch original d'atteindre le mainnet. L'activation conditionnelle du 29 septembre demande si l'écosystème a suffisamment appris de cet incident pour faire fonctionner le remplacement en toute sécurité.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.