Ripple-CTO schlägt ReservedTxns gegen Front-Running auf XRPL DEX vor
Wie ReservedTxns funktioniert
Das Konzept besteht aus zwei neuen Protokollkomponenten. Die erste ist ein ReservedTxns-Ledger-Objekt, das eine Ziel-Ledger-Sequenznummer sowie ein Array mit bis zu 32 Transaktions-IDs speichert. Sobald das entsprechende Ledger ausgeführt wird, werden alle dort gelisteten Transaktionen zuerst verarbeitet, noch vor allen anderen, und das Objekt wird anschließend gelöscht. Die zweite Komponente ist der Transaktionstyp TxnReserve, mit dem ein Nutzer einen Prioritätsslot für eine oder mehrere zukünftige Transaktionen reservieren kann, bevor das Ziel-Ledger geschlossen wird.
Drei Bedingungen regeln die Nutzung von TxnReserve: Die Reservierungsgebühr muss mindestens doppelt so hoch sein wie die Standardtransaktionsgebühr. Das Ziel-Ledger darf höchstens 16 Ledger vom aktuellen Stand entfernt liegen. Und die eigentliche Transaktion muss ihre LastLedgerSequence auf das reservierte Ledger setzen. Das 16-Ledger-Limit stellt sicher, dass Reservierungen eng an die unmittelbar bevorstehende Ausführung gekoppelt bleiben und nicht als allgemeines Werkzeug zur Manipulation der Warteschlange missbraucht werden können.
Schutz vor Missbrauch und DoS-Angriffen
Zum Schutz vor Denial-of-Service-Angriffen sieht der Entwurf eine dynamische Gebührenskalierung vor: Sobald die Zahl der belegten Reservierungsslots 16 übersteigt, steigen die Gebühren stufenweise an und erreichen bei rund 30 belegten Slots ein Vielfaches der Basisgebühr. Darüber hinaus soll die XRPL-Server-Software reservierte Transaktionen zurückhalten und erst kurz vor dem Zeitpunkt freigeben, zu dem die Vorschläge des vorherigen Ledgers bekannt sind. Damit wird das Zeitfenster, in dem die Transaktion öffentlich einsehbar ist, stark verkürzt.
Schwartz formulierte das Ziel des Mechanismus klar: „Das garantiert, dass Sie Ihre Transaktion vor jeder Transaktion ausführen können, die gebildet wurde, nachdem Ihre Transaktion offengelegt wurde. Sie würden diesen Ansatz jederzeit verwenden, wenn Sie eine Transaktion durchführen möchten, die nicht sandwiched oder front-runned werden kann.“
Das strukturelle Problem auf dem XRPL
Der Kern des von XRPresso angesprochenen Problems liegt in einem Strukturmerkmal des XRP Ledger: Ausstehende Transaktionen sind in einer öffentlich sichtbaren Warteschlange einsehbar, bevor ein Ledger geschlossen wird. Da die kanonische Transaktionsreihenfolge auf dem XRPL durch eine deterministische Formel auf Basis von Transaktions-Hashes bestimmt wird, kann ein versierter Akteur ähnliche Transaktionen wiederholt einreichen, um die Wahrscheinlichkeit zu erhöhen, eine günstige Position relativ zu einem Zieltrade zu belegen, was die mechanistische Grundlage einer Sandwich-Attacke darstellt.
Schwartz räumte das Risiko ein, stellte jedoch die Schwere in Frage. Er argumentierte, dass alle Teilnehmer gleichen Zugang zur öffentlichen Warteschlange haben und Validatoren keinen strukturellen Vorteil bei der Reihenfolge genießen, sofern nicht mehrere gemeinsam handeln. Er wies auch auf eine praktische Profitabilitätsschranke hin: Sinnvolle Gewinne durch solche Angriffe erfordern gleichzeitig hohe Liquidität und niedrige Liquidität, eine Kombination, die auf dem XRPL selten vorkommt.
Kritik und breiterer Kontext
XRPresso argumentierte, dass gezielte Vertraulichkeit für ausstehende Transaktionsdetails die sauberere Langzeitlösung wäre, und verwies auf Implementierungen, die bereits auf konkurrierenden Chains im Einsatz sind. Das Thema Front-Running ist kein XRPL-spezifisches Phänomen. Binance-Mitgründer Changpeng Zhao schlug im Vorjahr einen Dark-Pool-Perpetuals-DEX vor, der Zero-Knowledge-Kryptografie nutzt, um Auftragsdaten bis zur Ausführung zu verbergen. Dieser Ansatz wurde seinerseits kritisiert, weil er Informationsasymmetrien reproduziere. Der Vorschlag von Schwartz muss vor einer möglichen Aktivierung auf dem Mainnet einen formalen Governance-Prozess durchlaufen, der eine Supermehrheit der XRPL-Validatoren erfordert.
