L’amendement très attendu XLS-30D pour le XRPL, qui devrait introduire un teneur de marché automatisé (AMM), ne sera pas lancé le 14 février, car de plus en plus de validateurs révoquent leur vote.
Cela est dû à un bug critique découvert dans le code AMM. RippleX, la branche de développement de Ripple, a identifié le problème lors d’un test prolongé, citant un obstacle potentiel pour plusieurs AMM transactions exécutées dans le même grand livre.
Le bug affecte principalement un cas limite où les frais de négociation sont fixés en dessous de 0,01 %. Dans ce cas, le bogue se produit lorsqu’il existe un cluster de transactions sur l’AMM, provoquant l’arrêt de certaines transactions pour un grand livre, entraînant un délai de trois à cinq secondes avant l’exécution.
1/ Lors de tests d’intégration étendus visant à garantir que l’AMM fonctionne comme prévu au fil du temps, nous avons identifié un problème qui pourrait empêcher plusieurs transmissions AMM de s’exécuter dans le même grand livre. Nous avons proposé et examinons un correctif : https://t.co/MPMKuI8dDK
– RippleX (@RippleXDev) 1er février 2024
Notamment, une fois l’AMM créé, les transactions doivent attendre la clôture d’un grand livre avant d’être exécutées. Après la clôture de ce grand livre, les transactions s’exécutent normalement, à l’exception de la transaction AMMvote.
Notamment, la première transaction AMMvote s’exécutera correctement, mais les transactions AMMvote qui suivront continueront d’attendre la clôture d’un grand livre dans les trois à cinq secondes avant l’exécution.
OndulationX a proposé un correctif et l’examine actuellement. Le correctif proposé résout le problème, garantissant une identification correcte des champs par défaut dans les objets internes AMM et renforçant la stabilité à la fois dans le grand livre principal et dans le code AMM.
Malgré l’impact relativement mineur du bug, les validateurs XRPL ont pris position en retirant leur vote sur l’amendement XLS-30D. Rappeler que l’amendement a atteint le consensus requis des validateurs le 1er février, avec une mise en œuvre ETA le 14 février.
Les validateurs XRPL révoquent les votes oui
Vet, un éminent validateur du XRPL, a exprimé son inquiétude quant à l’image négative potentielle que la mise en œuvre d’une fonctionnalité avec un bug pourrait jeter sur la réputation du XRPL.
Je retire mon vote pour le teneur de marché automatisé du grand livre XRP.
L’effet du cas limite AMM est très mineur et ne causera pas de problèmes d’après ce que nous savons actuellement, cela n’a pas changé et mon opinion à ce sujet n’a pas changé non plus.
En revanche, cela ne reflète pas l’image du…
– Vétérinaire 🏴☠️ (@Vet_X0) 7 février 2024
L’opérateur du validateur a réfléchi à une situation similaire avec l’amendement XLS-20D, soulignant l’importance d’un lancement sans faille pour une fonctionnalité aussi critique et a plaidé pour que le correctif soit mis en œuvre avant la mise en œuvre de l’AMM.
xSpectar, un autre validateur, a fait écho à ce sentiment, soulignant la nature critique de la fonctionnalité et la nécessité de résoudre les problèmes connus avant l’activation. Le projet NFT a plaidé pour que la communauté respecte les normes les plus élevées pour le XRPL.
Après un (ré)examen attentif, nous avons modifié notre vote sur l’amendement de l’AMM en faveur de Non.
C’est une fonctionnalité critique, il existe un problème connu, que nous devons d’abord résoudre avant de l’activer.
Voter autrement serait irresponsable et compromettrait notre intégrité et ce serait dangereux… https://t.co/K0WkCaKdGn
– xSPECTAR ™ (@xSPECTAR) 7 février 2024
L’officiel xSpectar Le compte a souligné qu’il est de la responsabilité des validateurs d’éviter de créer un dangereux précédent en permettant l’adoption d’amendements comportant des problèmes connus.
Daniel, CTO chez Eminence et opérateur du validateur Eminence, a pris une position de principe en retirant son vote sur l’amendement AMM proposé. Il a évoqué des inquiétudes quant à la compromission de l’intégrité des meilleures pratiques et à la création d’un dangereux précédent.
J’ai décidé de retirer mon vote sur l’amendement proposé à l’AMM. Après un examen attentif et des discussions au sein de notre communauté, la fonctionnalité proposée, dans sa forme actuelle, va à l’encontre des meilleures pratiques que nous nous efforçons de respecter.
Plus précisément, ma préoccupation réside dans la publication d’une fonctionnalité avec un…
– Daniel « Non » Keller (@daniel_wwf) 7 février 2024
Daniel a souligné l’importance de donner la priorité à la stabilité et à la fonctionnalité, même si cela impliquait de retarder la fonctionnalité. Il a suggéré de déprécier l’AMM actuel et d’introduire l’AMMv2 avec des correctifs à considérer.
Amendement XLS-30D en dessous de 80 % de consensus
Laboratoires XRPL, l’équipe de développement derrière Xaman, a également annulé son vote Oui. Au moment de mettre sous presse, le consensus des validateurs est tombé à 71,43 %, en dessous du consensus requis de 80 %. En conséquence, l’amendement ne sera pas adopté.
Pendant ce temps, la plupart des validateurs, dont Ripple, Bithomp, XRPScan, Alloy Networks, Bitrue et 20 autres, ont conservé leur soutien. XRPGoat, un autre validateur dUNL, suggéré que l’AMM pourrait être déployé puisque le bug est mineur, plaidant pour un correctif pendant l’exécution de la fonctionnalité.
