David "JoelKatz" Schwartz a proposé un plan de réservation de transactions pour le XRP Ledger, après de nouvelles affirmations selon lesquelles les utilisateurs pourraient encore être exposés à des attaques de front-running et de sandwich sur les paiements, les croisements d'offres, les trades DEX et les swaps AMM.
Le débat a démarré après que XRPresso a déclaré que certains acteurs pourraient être en mesure de consulter les transactions en attente avant la clôture d'un registre et d'utiliser ces informations pour cibler des trades.
« Un sérieux problème de front-running persiste sur l'XRPL, qui désavantage les utilisateurs ordinaires. » XRPresso a indiqué que les validateurs et les nœuds bien connectés peuvent voir les transactions dans la file d'attente de pré-validation, puis soumettre leurs propres transactions afin d'obtenir une meilleure position dans l'ordre final du registre.
XRPresso a précisé que ce problème concerne avant tout les utilisateurs qui tradent via des portefeuilles et des dApps. Selon la publication, l'ordre final à l'intérieur de chaque registre suit un processus déterministe connu, et des soumissions répétées pourraient augmenter la probabilité de se positionner près d'un trade ciblé. Cela pourrait aggraver le slippage pour le trader d'origine lorsqu'une stratégie sandwich réussit.
« Pour les raisons que j'ai expliquées, je ne suis pas particulièrement préoccupé par ce problème. » Schwartz a néanmoins écrit que la préoccupation méritait une réponse concrète. Il a ensuite proposé un système de réservation de transactions qui permettrait à une transaction divulguée de s'exécuter avant toute transaction formée après qu'elle soit devenue visible.
Le plan ajouterait un nouvel objet de registre appelé ReservedTxns. Cet objet contiendrait un numéro de séquence de registre et un tableau d'identifications de transactions (TxID). Une nouvelle transaction TxnReserve permettrait à un utilisateur de réserver un créneau pour une transaction dans un futur registre, à condition que la demande respecte les règles de frais, de timing et d'exécution.
Schwartz a indiqué qu'une réservation devrait coûter au moins le double des frais de transaction normaux. Le registre cible devrait être supérieur au registre actuel et ne pas dépasser 16 registres à l'avance. Chaque objet réservé contiendrait moins de 32 identifications de transactions (TxID), à moins que la conception n'élargisse ultérieurement cette limite.
Selon la proposition, une transaction réservée serait diffusée à proximité du moment où les propositions du registre précédent sont connues. Schwartz a indiqué que le logiciel XRPL pourrait ajouter une fonctionnalité pour retenir ces transactions et ne les libérer que lorsque cette condition est remplie. La transaction devrait également définir son dernier registre valide comme étant le registre dans lequel elle est censée s'exécuter.
Lorsque ce registre s'exécute, le réseau vérifierait d'abord si un objet ReservedTxns existe pour le numéro de séquence du registre. S'il existe, le réseau exécuterait les transactions listées qui se trouvent dans l'ensemble de consensus avant les autres transactions. Il les retirerait ensuite de l'ensemble pour empêcher une exécution répétée et supprimerait l'objet de réservation.
La documentation de l'XRPL indique que l'ordonnancement canonique est conçu pour être déterministe, efficace et difficile à manipuler. Sa documentation DEX précise également que l'ordre des transactions est conçu pour décourager le front-running, car les trades s'exécutent lors de la clôture d'un nouveau registre. Cependant, la documentation sur le trading algorithmique de l'XRPL indique que le front-running est difficile, mais pas impossible.
Ce moment intervient alors que les développeurs XRPL continuent d'étendre la pile DeFi du réseau. La Fondation XRPL a récemment proposé les AMM Swappable Curves, une mise à niveau draft qui ajouterait des options StableSwap et de liquidité concentrée au market maker automatisé natif. L'XRPL prépare également des outils natifs de prêt et d'escrow programmable.
Ces mises à niveau pourraient apporter davantage d'activités de trading on-chain, de crédit et de règlement à l'XRPL. Une couverture récente a également mis en évidence des cas d'usage institutionnels, notamment un règlement de Trésorerie tokenisé impliquant Ripple et JPMorgan. À mesure que l'activité croît, l'ordonnancement des transactions et la visibilité des trades en attente pourraient attirer davantage l'attention des développeurs, des traders et des validateurs.
Schwartz a également abordé les risques potentiels de déni de service. Il a indiqué qu'un attaquant pourrait tenter de remplir des créneaux de réservation sur de nombreux registres, mais que la hausse des frais pourrait rendre cela coûteux. Dans un exemple, les frais augmenteraient une fois 16 créneaux remplis et pourraient atteindre plusieurs fois la réserve de base aux alentours de 30 créneaux. La proposition n'est pas encore un amendement formel, mais elle offre à la communauté XRPL une voie technique claire à examiner.


