L'amendement Batch V1.1 du XRP Ledger n'est plus qu'à un vote de validateur de lancer son processus d'activation de deux semaines, après que les développeurs aient corrigé 11 autres problèmes logiciels découverts lors des audits de sécurité.
RippleX a déclaré lundi que la dernière révision de Batch V1.1 avait identifié des problèmes concernant les signatures de transactions, les vérifications d'autorisation et les plantages de serveurs, les correctifs étant intégrés dans 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 %, ce qui laissait la proposition juste en dessous du niveau de 80 % requis pour entrer dans la période d'activation du réseau.
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, cette fonctionnalité pourrait rendre les deux transferts interdépendants. Si l'une des parties de l'échange échoue, l'autre transaction ne serait pas effectuée indépendamment.
Les portefeuilles et les marchés 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 identifié publiquement les entreprises impliquées.
Le soutien des validateurs a rapidement augmenté 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 %, comme crypto.news l'avait précédemment rapporté. 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 s'activer. Avec 35 validateurs de confiance actuellement comptés, un vote de soutien supplémentaire ferait passer Batch V1.1 au-dessus du seuil et lancerait cette période.
Le résultat ne serait pas figé une fois le compte à rebours lancé. Les validateurs peuvent changer leur 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 s'est ensuite activé le 29 juillet après avoir conservé un soutien suffisant des validateurs pendant la période requise.
Le vote actuel fait suite au retrait de la conception originale de Batch après que des chercheurs aient 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 depuis le compte d'un autre utilisateur à l'intérieur d'un lot (batch) sans obtenir l'autorisation requise. Aucun fonds d'utilisateur n'a été mis en péril car l'amendement affecté n'a jamais été activé.
Les développeurs ont reconstruit la fonctionnalité suite à cette découverte, et Batch V1.1 a ensuite été 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 ainsi que 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.
Mayukha Vadari, ingénieure logicielle chez RippleX, a déclaré que le problème de signature original avait été découvert en février avant le déploiement sur le mainnet. Les travaux ultérieurs ont inclus une correction de la cause première, des révisions 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 v1.0 ait é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é trouvés pendant l'examen de l'implémentation de remplacement.
Les découvertes supplémentaires couvraient la gestion des signatures, les vérifications d'autorisation et les conditions logicielles capables de faire planter les 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 permission qu'un utilisateur avait signée et d'effectuer plus de transactions que l'utilisateur n'avait initialement l'intention d'autoriser.
D'autres découvertes concernaient la manière dont les transactions Batch vérifiaient les permissions 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 avaient examiné l'implémentation, tandis que Halborn et Common Prefix avaient effectué des audits externes. Le code a fait l'objet de tests automatisés et d'un concours de sécurité public conçu pour exposer les faiblesses avant l'activation.
Des tests de sécurité ont été utilisés pour d'autres propositions récentes du XRP Ledger. Un audit de sécurité de Common Prefix en juin a identifié des problèmes numériques et comportementaux dans les composants de l'XRPL, avec des correctifs déployés via la version 3.2.0. La firme 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 découvertes critiques et de haute gravité.
Batch est l'un des nombreux changements de protocole introduits via le cycle logiciel 3.3.0, alors que les développeurs du XRP Ledger travaillent sur le règlement des transactions, la confidentialité, les permissions et les fonctionnalités institutionnelles.
Avant la publication 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.
La Délégation de Permission permettrait à un compte d'accorder une autorité restreinte à un autre compte sans céder le contrôle total. Confidential MPT est conçu pour masquer les soldes et les montants de transfert pour les Jetons Polyvalents (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 de soutenir ou non les amendements, laissant chaque proposition suivre son propre calendrier de vote.
Le réseau a déjà connu des taux d'adoption différents pour les propositions 3.3.0. Ripple a voté en août pour l'amendement PermissionDelegationV1_1 alors qu'il avait le soutien de sept des 35 validateurs de confiance.
Batch s'est depuis rapproché considérablement du seuil d'activation. Ses 27 votes actuels laissent l'amendement à un validateur de soutien 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'elle 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 cette fonctionnalité et si les 11 dernières corrections avaient fait l'objet d'un examen indépendant par rapport à la version actuellement examinée par les validateurs.
XRP
