L'amendement Batch V1.1 du XRP Ledger a progressé à un vote de validateur près du début de son processus d'activation de deux semaines, après que les développeurs ont corrigé 11 autres problèmes logiciels découverts lors des examens de sécurité.
Résumé
- Le Batch V1.1 du XRP Ledger a obtenu 27 des 35 votes de validateurs, ce qui le laisse à un vote du seuil d'activation de 80 %.
- Les développeurs ont corrigé 11 autres problèmes impliquant des signatures, des contrôles d'autorisation et des plantages potentiels de serveur avant le dernier vote.
- Batch permettrait aux utilisateurs de combiner jusqu'à huit transactions en une seule opération et exigerait que les paiements liés soient exécutés ensemble.
- La version actuelle a remplacé une proposition Batch antérieure après que des chercheurs ont découvert une grave faille d'autorisation avant qu'elle n'atteigne le mainnet.
RippleX a déclaré lundi que le dernier examen de Batch V1.1 avait identifié des problèmes impliquant des signatures de transaction, des contrôles d'autorisation et des plantages de serveur, les correctifs ayant été intégrés à la version actuellement examinée par les validateurs du XRP Ledger.
Le soutien s'élevait à 27 des 35 validateurs de confiance mardi, soit environ 77 %, laissant la proposition juste en dessous du niveau de 80 % requis pour entrer dans la période d'activation du réseau.
La mise à niveau Batch du XRP Ledger se rapproche des 80 % de soutien
Batch V1.1 permettrait de regrouper jusqu'à huit transactions en une seule opération, avec des règles d'exécution pouvant exiger que les transactions liées réussissent ensemble.
Pour un échange de jetons entre deux utilisateurs, la fonctionnalité pourrait rendre les deux transferts dépendants l'un de l'autre. Si un côté de l'échange échoue, l'autre transaction ne serait pas exécutée indépendamment.
Les portefeuilles et les places de marché pourraient utiliser la même structure pour traiter ensemble un paiement client et des frais de plateforme. RippleX a déclaré que des projets commerciaux utilisant Batch sont déjà sous contrat ou en développement, bien que l'équipe de développement n'ait pas publiquement identifié les entreprises concernées.
Le soutien des validateurs a augmenté rapidement au cours de la semaine dernière. Le 8 septembre, Batch V1.1 avait 24 votes sur les 35 validateurs de la liste de nœuds uniques par défaut, soit 68,57 %, selon un précédent rapport de crypto.news. Trois validateurs supplémentaires ont depuis soutenu l'amendement.
Selon les règles de gouvernance du XRP Ledger, un amendement doit maintenir au moins 80 % de soutien des validateurs pendant 14 jours consécutifs avant de pouvoir être activé. Avec 35 validateurs de confiance actuellement comptés, un vote de soutien supplémentaire porterait Batch V1.1 au-dessus du seuil et déclencherait cette période.
Le résultat ne serait pas verrouillé une fois le compte à rebours lancé. Les validateurs peuvent changer de position, et un soutien tombant en dessous de 80 % pendant la fenêtre de 14 jours interromprait le processus d'activation.
Un processus similaire s'est déroulé en juillet lorsque l'amendement fixCleanup3_2_0 a obtenu 85,71 % de soutien et est entré dans sa fenêtre d'activation. Le paquet a ensuite été activé le 29 juillet après avoir conservé suffisamment de soutien des validateurs pendant la période requise.
Batch V1.1 remplace une version antérieure présentant une grave faille
Le vote actuel fait suite au retrait de la conception originale de Batch après que des chercheurs ont découvert une vulnérabilité avant que la fonctionnalité n'atteigne le mainnet du XRP Ledger.
Dans certaines conditions, la faille aurait pu permettre à un attaquant de placer des transactions provenant du compte d'un autre utilisateur dans un lot sans obtenir l'autorisation requise. Aucun fonds d'utilisateur n'a été mis en danger car l'amendement concerné ne s'est jamais activé.
Les développeurs ont reconstruit la fonctionnalité après la découverte, Batch V1.1 étant ensuite inclus dans xrpld 3.3.0, publié le 6 août.
La version xrpld 3.3.0 a introduit l'implémentation corrigée de Batch aux côtés de plusieurs autres fonctionnalités de protocole proposées. Chaque amendement nécessite toujours une approbation distincte des validateurs avant de devenir actif sur le mainnet.
L'ingénieur logiciel de RippleX, Mayukha Vadari, a déclaré que le problème de signature original avait été découvert en février avant le déploiement sur le mainnet. Le travail ultérieur comprenait une correction de la cause racine, des examens par quatre ingénieurs seniors, un concours de sécurité Sherlock et des audits de Halborn et Common Prefix.
« Après que le bug de signature de la v1.0 a été détecté en février (avant le Mainnet, aucun fonds en danger), nous l'avons reconstruit », a écrit Vadari sur X le 14 septembre.
Le processus d'examen ne s'est pas arrêté à la vulnérabilité initiale. RippleX a déclaré que 11 autres problèmes avaient été découverts lors de l'examen de l'implémentation de remplacement.
Les examens de sécurité ont révélé 11 autres problèmes liés à Batch
Les conclusions supplémentaires couvraient la gestion des signatures, les contrôles d'autorisation et des conditions logicielles susceptibles de faire planter des serveurs.
Common Prefix a classé l'une des vulnérabilités comme critique. Selon l'examen de RippleX, le problème aurait pu permettre à un attaquant de réutiliser une autorisation qu'un utilisateur avait signée et d'effectuer plus de transactions que ce que l'utilisateur avait initialement l'intention d'autoriser.
D'autres conclusions concernaient la manière dont les transactions Batch vérifiaient les autorisations et traitaient les signatures. Les développeurs ont résolu les problèmes signalés avant que l'amendement n'atteigne son stade actuel de vote des validateurs.
RippleX a déclaré que quatre ingénieurs seniors ont examiné l'implémentation, tandis que Halborn et Common Prefix ont réalisé des audits externes. Le code a été soumis à des tests automatisés et à un concours de sécurité public conçu pour exposer les faiblesses avant l'activation.
Les tests de sécurité ont été utilisés dans d'autres propositions récentes du XRP Ledger. Un examen de sécurité de Common Prefix en juin a identifié des problèmes numériques et comportementaux dans des composants du XRPL, avec des correctifs déployés via la version 3.2.0. La société de sécurité a ensuite été chargée de la vérification formelle et de l'analyse d'autres parties du réseau.
Un concours Sherlock distinct couvrant les fonctionnalités proposées du XRP Ledger a trouvé des dizaines de vulnérabilités valides avant que les amendements concernés n'atteignent le mainnet, y compris des conclusions critiques et de haute gravité.
Batch fait partie de l'ensemble de fonctionnalités de xrpld 3.3.0
Batch est l'un des plusieurs changements de protocole introduits par le cycle logiciel 3.3.0, alors que les développeurs du XRP Ledger travaillent sur le règlement des transactions, la confidentialité, les autorisations et les fonctionnalités institutionnelles.
Avant la sortie du logiciel, les développeurs ont présenté cinq amendements XRPL proposés qui incluaient les transactions Batch, Confidential MPT, Sponsor, Dynamic MPT et Permission Delegation.
Batch est conçu autour du règlement atomique, où plusieurs opérations liées peuvent être traitées comme une transaction coordonnée au lieu d'être soumises séparément.
Permission Delegation permettrait à un compte d'accorder une autorité restreinte à un autre compte sans en céder le contrôle total. Confidential MPT est conçu pour dissimuler les soldes et les montants des transferts pour les Multi-Purpose Tokens tout en gardant les identités des comptes visibles sur le registre public.
Aucune des fonctionnalités ne devient active simplement parce que son code est inclus dans xrpld. Les validateurs décident séparément s'ils soutiennent les amendements, laissant chaque proposition suivre son propre calendrier de vote.
Le réseau a déjà connu différents taux d'adoption parmi les propositions de la 3.3.0. Ripple a voté en août pour l'amendement PermissionDelegationV1_1 lorsqu'il bénéficiait du soutien de sept des 35 validateurs de confiance.
Batch s'est depuis rapproché beaucoup plus du seuil d'activation. Ses 27 votes actuels laissent l'amendement à un validateur favorable du début de la période de 14 jours, à condition que les votes existants restent en place.
RippleX n'a pas nommé les projets commerciaux qu'il a dit être sous contrat ou en développement pour utiliser Batch. CoinDesk a déclaré avoir demandé à l'équipe de développement quelles entreprises se préparent à utiliser la fonctionnalité et si les 11 derniers correctifs ont fait l'objet d'un examen indépendant par rapport à la version actuellement examinée par les validateurs.
