Schwartz schlägt XRPL-Lösung vor, während Bedenken über Front-Running zurückkehren

David „JoelKatz" Schwartz hat einen Transaktionsreservierungsplan für das XRP Ledger vorgeschlagen, nachdem erneute Behauptungen aufkamen, dass Nutzer weiterhin Front-Running- und Sandwich-Angriffe auf Zahlungen, Angebotskreuzungen, DEX-Trades und Marktmacher-Swaps erleiden könnten. 

Die Debatte begann, nachdem XRPresso erklärte, dass einige Akteure in der Lage sein könnten, ausstehende Transaktionen einzusehen, bevor ein Ledger geschlossen wird, und diese Informationen nutzen könnten, um Trades gezielt anzugehen.

„Ein ernstes Front-Running-Problem besteht weiterhin auf dem XRPL, das reguläre Nutzer benachteiligt." XRPresso sagte, Validatoren und gut vernetzte Nodes könnten Transaktionen in der Vorvalidierungs-Warteschlange einsehen und dann eigene Transaktionen einreichen, um eine bessere Position in der endgültigen Ledger-Reihenfolge zu erlangen.

XRPresso sagte, das Problem betreffe vor allem Nutzer, die über Wallets und dApps handeln. Laut dem Beitrag folgt die endgültige Reihenfolge innerhalb jedes Ledgers einem bekannten deterministischen Prozess, und wiederholte Einreichungen könnten die Chance erhöhen, in der Nähe eines Zieltrades zu landen. Das könnte den Slippage für den ursprünglichen Händler verschlechtern, wenn eine Sandwich-Strategie erfolgreich ist.

Schwartz legt ein Reservierungsschema vor

„Aus den Gründen, die ich erläutert habe, mache ich mir über dieses Problem nicht allzu viele Sorgen." Schwartz schrieb, dass das Anliegen dennoch eine praktische Antwort verdiene. Er schlug daraufhin ein Transaktionsreservierungsschema vor, das es ermöglichen könnte, dass eine offengelegte Transaktion vor jeder Transaktion ausgeführt wird, die nach ihrer Sichtbarkeit gebildet wurde.

Der Plan würde ein neues Ledger-Objekt namens ReservedTxns hinzufügen. Dieses Objekt würde eine Ledger-Sequenznummer und ein Array von Transaktion-IDs (TxIDs) enthalten. Eine neue TxnReserve-Transaktion würde es einem Nutzer ermöglichen, einen Slot für eine Transaktion in einem zukünftigen Ledger zu reservieren, sofern die Anfrage die Gebühren-, Timing- und Ausführungsregeln erfüllt.

Schwartz sagte, eine Reservierung sollte mindestens das Doppelte der normalen Transaktionsgebühr kosten. Das Ziel-Ledger müsste größer als das aktuelle Ledger und nicht mehr als 16 Ledger voraus sein. Jedes reservierte Objekt würde weniger als 32 Transaktion-IDs enthalten, es sei denn, das Design erweitert die Obergrenze später.

Reservierte Transaktionen würden zuerst ausgeführt

Gemäß dem Vorschlag würde eine reservierte Transaktion kurz vor dem Zeitpunkt übertragen, an dem die Vorschläge des vorherigen Ledgers bekannt sind. Schwartz sagte, die XRPL-Software könnte eine Funktion hinzufügen, um solche Transaktionen zurückzuhalten und sie erst freizugeben, wenn diese Bedingung erfüllt ist. Die Transaktion sollte außerdem ihr letztes gültiges Ledger auf das Ledger setzen, in dem sie ausgeführt werden soll.

Wenn dieses Ledger ausgeführt wird, würde das Netzwerk zunächst prüfen, ob ein ReservedTxns-Objekt für die Ledger-Sequenznummer existiert. Falls es existiert, würde das Netzwerk die aufgelisteten Transaktionen, die im Konsenssatz enthalten sind, vor anderen Transaktionen ausführen. Anschließend würde es sie aus dem Satz entfernen, um eine wiederholte Ausführung zu verhindern, und das Reservierungsobjekt löschen.

Die XRPL-Dokumentation besagt, dass die kanonische Reihenfolge deterministisch, effizient und schwer zu manipulieren ist. Die DEX-Dokumentation besagt zudem, dass die Transaktionsreihenfolge darauf ausgelegt ist, Front-Running zu erschweren, da Trades beim Schließen eines neuen Ledgers ausgeführt werden. Die Dokumentation zum algorithmischen Handel des XRPL besagt jedoch, dass Front-Running schwierig, aber nicht unmöglich ist.

DeFi-Upgrades erhöhen den Einsatz

Der Zeitpunkt fällt zusammen mit der kontinuierlichen Erweiterung des DeFi-Stacks des Netzwerks durch XRPL-Entwickler. Die XRPL Foundation schlug kürzlich AMM Swappable Curves vor, ein Entwurf für ein Upgrade, das StableSwap und konzentrierte Liquiditätsoptionen zum nativen automatisierten Marktmacher hinzufügen würde. XRPL bereitet außerdem native Kreditvergabe- und programmierbare Treuhandwerkzeuge vor.

Diese Upgrades könnten mehr On-Chain-Handel, Kredit- und Abrechnungsaktivitäten zum XRPL bringen. Jüngste Berichte zeigten auch institutionelle Anwendungsfälle, darunter eine tokenisierte Treasury-Abrechnung unter Beteiligung von Ripple und JPMorgan. Mit zunehmendem Aktivitätsniveau könnten die Transaktionsreihenfolge und die Sichtbarkeit ausstehender Trades mehr Aufmerksamkeit von Entwicklern, Händlern und Validatoren auf sich ziehen.

Schwartz sprach auch mögliche Denial-of-Service-Risiken an. Er sagte, ein Angreifer könnte versuchen, Reservierungsslots über viele Ledger hinweg zu füllen, aber steigende Gebühren könnten dies kostspielig machen. In einem Beispiel würden die Gebühren steigen, sobald 16 Slots gefüllt sind, und könnten bei etwa 30 Slots das Mehrfache der Basisreserve erreichen. Der Vorschlag ist noch keine formelle Änderung, gibt der XRPL-Community jedoch einen klaren technischen Weg zur Überprüfung vor.