Le bogue aurait pu permettre à une configuration de signataire mal formée de passer la validation sans nécessiter les clés privées de tous les autres comptes impliqués.
L'amendement Batch V1.1 du XRP Ledger est à un vote du validateur d'atteindre le seuil de 80 % nécessaire pour commencer son compte à rebours d'activation de 14 jours, après une reconstruction de sécurité qui a suivi une faille critique dans la version originale.
Le code révisé a fait l'objet d'un examen technique de haut niveau, de tests contradictoires, de deux examens de sécurité externes et d'une analyse assistée par l'IA avant son vote actuel du validateur.
Le lot V1.1 atteint le vote final avant le compte à rebours d'activation
Le développeur de RippleX, Mayukha Vadari, a déclaré que l'amendement était livré avec xrpld 3.3.0 et qu'il était maintenant soumis au vote. La mise à jour remplace Batch V1.0, dont le bug de validation de signature a été découvert en février alors que la modification était encore pré-mainnet, ce qui signifie qu'aucun fonds n'était en danger.
La faille originale impliquait un retour anticipé dans la fonction checkBatchSign. Si un compte de signataire n’existait pas encore dans le grand livre, la validation pourrait aboutir sans vérifier les signataires restants. Cela aurait pu permettre d'exécuter des transactions pour le compte d'autres comptes sans leurs clés privées.
Batch V1.1 a supprimé cette faille et a également résolu plusieurs autres problèmes détectés lors de la reconstruction. Le processus comprenait un examen par quatre ingénieurs senior, un Sherlock Batch Attackathon, une réévaluation Halborn, un audit Common Prefix, une analyse Cantina AI et des tests de régression Devnet et testnet.
Vadari a également déclaré que l'équipe avait corrigé des bugs supplémentaires découverts grâce à son nouveau travail d'équipe rouge sur l'IA. Les modifications incluent des correctifs pour les contournements de validation MPT, les pannes de nœuds, la validation de la taille du chemin, la vérification de la signature, l'ordre des signataires et le hachage des transactions.
Le sentiment des validateurs est proche du seuil requis, avec un compte, FrancisBovineSwift, décrivant le vote par lots comme « presque atteint », avec l'instantané le plus récent montrant que 27 validateurs de confiance ont voté pour l'amendement et huit contre, ce qui place le soutien à environ 77 % par rapport au seuil de 80 % requis pour approuver les changements, avec juste un vote supplémentaire nécessaire pour atteindre ce seuil.
Vous aimerez peut-être aussi :
Pourquoi l'amendement par lots est important pour les développeurs XRPL
Batch, également connu sous le nom de XLS-56, permet à plusieurs transactions provenant de différents comptes de s'exécuter de manière atomique en une seule clôture de grand livre. Si une transaction dans un lot tout ou rien échoue, l’ensemble de l’opération est annulé. La conception ne nécessite pas de contrats intelligents.
Cette fonctionnalité est destinée aux échanges atomiques, aux règlements coordonnés et à d'autres transactions dans lesquelles plusieurs parties doivent agir ensemble. Cela pourrait également réduire le nombre d’étapes nécessaires à la création et aux transferts de NFT.
La reconstruction de la sécurité fait suite à un autre examen récent du XRPL, après que le réseau a retiré son amendement de délégation d'autorisation lorsqu'un bogue de haute gravité a été découvert avant le déploiement du réseau principal, la V1.1 faisant l'objet d'un examen supplémentaire.
En outre, un tableau de bord de test XRPL lancé ce mois-ci a également rendu les tests de modification plus visibles en suivant les types de transactions, les champs et les codes de résultat qui ont été exercés sur Devnet.