Ripple : David Schwartz propose une parade contre le front-running sur XRP
David Schwartz, cofondateur du XRP Ledger et CTO Emeritus de Ripple, a proposé un mécanisme de réservation de transactions en deux composantes pour contrer les risques de front-running et d’attaques sandwich sur le DEX natif et l’AMM du XRPL.
Cette proposition, formulée en réponse aux inquiétudes soulevées par le compte d’analyse spécialisé XRPresso.io, introduit des garanties d’exécution prioritaire pour les utilisateurs prêts à payer des frais de réservation. Il s’agit d’une mesure d’intégrité du marché particulièrement pertinente alors que les flux institutionnels vers les produits XRP continuent de croître.
Le projet fait actuellement l’objet de discussions au sein de la communauté et n’a pas encore été formalisé en tant qu’amendement du réseau. Cette distinction est cruciale : sur le XRP Ledger, les modifications de protocole nécessitent le vote favorable d’une supermajorité de validateurs avant activation. Le design de Schwartz a certes du poids, mais il doit suivre un processus de gouvernance défini avant d’atteindre le mainnet.
Comment fonctionne réellement le mécanisme ReservedTxns de Ripple XRP
Le système introduit deux nouveaux composants au protocole. Le premier est un objet ledger nommé ReservedTxns, qui stocke un numéro de séquence cible du registre et une liste pouvant aller jusqu’à 32 identifiants de transactions.
Lorsque ce registre spécifique est exécuté, toutes les transactions listées présentes dans l’ensemble de consensus sont traitées en priorité, avant toutes les autres, après quoi l’objet est supprimé. Le second composant est un type de transaction TxnReserve, qui permet à un utilisateur de revendiquer un créneau prioritaire pour une ou plusieurs transactions futures en soumettant une réservation avant la clôture du registre cible.
Trois contraintes encadrent le TxnReserve : les frais de réservation doivent être au moins le double des frais de transaction standards ; le registre cible doit se situer dans les 16 prochains registres ; et la transaction réelle doit voir son LastLedgerSequence correspondre au registre réservé.
Ces règles ne sont pas fortuites : elles définissent à la fois le coût économique du système et la fenêtre temporelle étroite de son fonctionnement. Le plafond de 16 registres maintient les réservations liées à une exécution imminente, empêchant le mécanisme d’être détourné comme un outil de manipulation de file d’attente à usage général.
Une protection contre les attaques DoS est intégrée via une tarification dynamique : à mesure que les créneaux de réservation dépassent les 16 unités, les frais augmentent par paliers, atteignant plusieurs multiples de la réserve de base aux alentours de 30 créneaux. Schwartz a également précisé que le logiciel serveur XRPL conserverait les transactions réservées pour ne les libérer que lorsque les propositions du registre précédent sont connues, réduisant ainsi la fenêtre de visibilité pré-exécution.
« Cela garantit que vous pouvez exécuter votre transaction avant toute transaction formée après la divulgation de la vôtre », a déclaré Schwartz. « Vous utiliseriez cette approche chaque fois que vous voulez effectuer une transaction en étant certain qu’elle ne peut pas être victime d’un sandwich ou d’un front-run. »
Le problème de front-running spécifique au XRPL que Schwartz veut résoudre
L’inquiétude de XRPresso porte sur une caractéristique structurelle du XRP Ledger : les transactions en attente sont visibles dans une file d’attente publique avant la clôture d’un registre, offrant aux validateurs et aux nœuds bien connectés une vision anticipée des ordres entrants.
L’ordonnancement canonique des transactions sur le XRPL étant déterminé par une formule déterministe connue impliquant les hachages de transaction, un acteur sophistiqué peut soumettre des transactions similaires de manière répétée pour augmenter ses chances d’occuper un créneau favorable par rapport à une transaction cible. C’est la base mécanique d’une attaque sandwich sur le DEX ou l’AMM.
Schwartz a reconnu cette exposition mais a contesté la manière dont elle est présentée. Il a soutenu que tous les participants ont un accès égal à la file d’attente publique et que les validateurs n’obtiennent aucun avantage structurel d’ordonnancement, à moins d’une collusion entre plusieurs d’entre eux.
« Si plusieurs validateurs conspiraient, ou si un seul tentait de le faire, cela serait évident pour tout le monde », a-t-il affirmé, ajoutant qu’aucune tentative de ce type n’a été confirmée en dehors d’une preuve de concept.
Il a également souligné une contrainte de rentabilité pratique : extraire une valeur significative nécessite simultanément une liquidité élevée (pour générer un volume ciblable) et une liquidité faible (pour faire bouger les prix à un coût gérable), une combinaison rarement présente sur le XRPL.
Cet argument n’a pas totalement convaincu les détracteurs, mais il distingue le profil de risque actuel du XRPL de l’environnement MEV historiquement actif d’Ethereum.
Le débat sur le front-running en DeFi ne se limite pas à l’écosystème XRP. L’année dernière, le cofondateur de Binance, Changpeng Zhao, a proposé un DEX de perpétuels en « dark pool » utilisant la cryptographie zero-knowledge pour masquer les données d’ordres jusqu’à l’exécution. Cette approche a suscité des critiques de la part des défenseurs de la décentralisation, estimant qu’elle recrée les asymétries d’information que la crypto était censée éliminer.
XRPresso a avancé un argument similaire en réponse à Schwartz, affirmant qu’une confidentialité ciblée pour les détails des transactions en attente serait une solution à long terme plus propre qu’une couche de frais de réservation, soulignant que de telles implémentations existent déjà sur des chaînes concurrentes.
Pourquoi nous faire confiance
2M+
250+
8
70
Plus d'articles
in numbers
