David \u201eJoelKatz\u201c Schwartz, fr\u00fcherer Chief Technology Officer von Ripple und eine der pr\u00e4genden technischen Stimmen im XRPL-\u00d6kosystem, hat einen konkreten Vorschlag gegen Front-Running und Sandwich-Angriffe auf dem XRP Ledger skizziert. In einem X-Beitrag reagierte Schwartz auf Kritik von XRPresso.io, wonach gut angebundene Akteure Transaktionen vor der Validierung sehen und daraus Vorteile beim Handel auf DEX- und AMM-Funktionen des XRPL ziehen k\u00f6nnen.<\/p>\n
XRPresso.io hatte die Debatte mit deutlichen Worten neu angesto\u00dfen. Das XRPL-nahe Portal schrieb auf X: \u201eEin ernstes Front-Running-Problem besteht weiterhin auf dem XRPL und benachteiligt normale Nutzer. Validatoren und gut vernetzte Nodes k\u00f6nnen Transaktionen in der Pre-Validation-Queue sehen, bevor ein Ledger geschlossen wird.\u201c Dadurch k\u00f6nnten anspruchsvollere Akteure ausstehende Trades analysieren und eigene Transaktionen so platzieren, dass sie von der finalen Reihenfolge im Ledger profitieren.<\/p>\n
Im Zentrum der Kritik steht die kanonische Sortierung von Transaktionen innerhalb eines Ledgers. XRPresso.io formulierte es so: \u201eWeil die endg\u00fcltige Reihenfolge innerhalb jedes Ledgers auf einer bekannten, deterministischen Formel mit Transaktions-Hashes basiert, erh\u00f6ht das Einreichen mehrerer Transaktionen die Chance, relativ zum Ziel-Trade auf einem g\u00fcnstigen Platz zu landen. Das erlaubt es fortgeschrittenen Akteuren, zuverl\u00e4ssig Wert aus den Trades anderer Nutzer abzusch\u00f6pfen \u2013 insbesondere auf der DEX und dem AMM \u2013 h\u00e4ufig durch Sandwich-Angriffe, die die Slippage f\u00fcr den urspr\u00fcnglichen Trader verschlechtern.\u201c<\/p>\n
Schwartz erkl\u00e4rte in seiner Antwort, er sei aus den von ihm zuvor genannten Gr\u00fcnden \u201enicht so besorgt\u201c \u00fcber das Thema, legte aber dennoch einen technischen Mechanismus vor, der die Angriffsm\u00f6glichkeit ausr\u00e4umen soll. \u201eIch habe einen Vorschlag f\u00fcr ein ziemlich einfaches Schema, das diesen Angriff eliminieren w\u00fcrde\u201c, schrieb er. \u201eEs ist ein Transaktionsreservierungssystem, das sicherstellen kann, dass eine Transaktion vor jeder Transaktion ausgef\u00fchrt wird, die erst gebildet wurde, nachdem sie offengelegt wurde. Dieses Schema beseitigt Bedenken hinsichtlich Front-Running oder Sandwich-Angriffen.\u201c<\/p>\n
Der Vorschlag sieht ein neues Ledger-Objekt namens Schwartz beschreibt die Ausf\u00fchrung so, dass reservierte Transaktionen vor allen \u00fcbrigen Transaktionen des Konsens-Sets verarbeitet werden. \u201eWenn ein Ledger ausgef\u00fchrt wird, wird zun\u00e4chst das Ledger-Objekt mit den reservierten Transaktionen f\u00fcr diese Ledger-Sequenznummer abgerufen. Gibt es keines, werden die weiteren Schritte \u00fcbersprungen und die Transaktionen normal ausgef\u00fchrt.\u201c Anschlie\u00dfend werde jede reservierte Transaktion ausgef\u00fchrt, sofern sie im Konsens-Set enthalten ist, und aus diesem Set entfernt, damit sie nicht ein zweites Mal ausgef\u00fchrt wird. Danach werde das Reservierungsobjekt f\u00fcr die entsprechende Ledger-Sequenznummer gel\u00f6scht.<\/p>\n Auch die Verbreitung der reservierten Transaktionen ist Teil des Vorschlags. Schwartz schrieb: \u201eWenn eine Transaktion einen reservierten Slot in Ledger X hat, sollte die Transaktion ausgesendet werden, sobald bekannt ist, dass die initialen Vorschl\u00e4ge f\u00fcr Ledger X-1 vollst\u00e4ndig eingegangen sind oder das finale Konsens-Transaktionsset bekannt ist.\u201c<\/p>\n Die XRPL-Software solle daf\u00fcr eine Funktion erhalten, die diesen Zeitpunkt offenlegt und optional Transaktionen bis genau zu diesem Moment zur\u00fcckh\u00e4lt. Zudem solle eine reservierte Transaktion erneut verbreitet werden, wenn sie nicht k\u00fcrzlich ausgesendet wurde, selbst dann, wenn ein Server davon ausgeht, dass sie scheitern wird. Die Begr\u00fcndung: \u201eIhre Weiterleitung wurde bereits durch die verdoppelte Geb\u00fchr f\u00fcr die Reservierungstransaktion bezahlt, also ist das kein Angriff.\u201c<\/p>\n Schwartz adressiert auch einen m\u00f6glichen Denial-of-Service-Vektor, bei dem ein Angreifer viele Reservierungsslots blockiert. Als Gegenma\u00dfnahme schl\u00e4gt er steigende Geb\u00fchren vor, sobald sich ein Reservierungsobjekt f\u00fcllt: Ab 16 reservierten Slots k\u00f6nnten die Kosten linear steigen, bei 30 Slots bis auf das Dreifache der Basisreserve. \u201eEin Angreifer m\u00fcsste alle f\u00fcnf Sekunden ein Mehrfaches dessen zahlen, was irgendjemand bereit w\u00e4re zu zahlen, um seine Transaktion zu sch\u00fctzen\u201c, schrieb Schwartz. Der Vorschlag ist damit noch keine implementierte \u00c4nderung am XRPL, aber ein konkreter technischer Ansatz f\u00fcr eine Debatte, die im \u00d6kosystem seit Jahren mit Blick auf Fairness, Transaktionssichtbarkeit und Nutzervertrauen gef\u00fchrt wird.<\/p>\n KI-Transparenzhinweis: Dieser Artikel wurde mit Unterst\u00fctzung eines KI-Systems auf Basis der angegebenen Quellen vorbereitet und vor der Ver\u00f6ffentlichung redaktionell durch einen menschlichen Editor gepr\u00fcft, bearbeitet und freigegeben. Alle Zitate, Daten und Tatsachenbehauptungen sollen aus den genannten Quellen stammen; dennoch k\u00f6nnen Fehler nicht vollst\u00e4ndig ausgeschlossen werden.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" David Schwartz schl\u00e4gt ein Reservierungssystem f\u00fcr XRPL-Transaktionen vor, das Front Running und Sandwich-Angriffe durch feste Ausf\u00fchrungspl\u00e4tze eind\u00e4mmen soll.<\/p>\n","protected":false},"author":2,"featured_media":2506,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[72],"tags":[88,89],"class_list":{"0":"post-2503","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-news","8":"tag-ripple","9":"tag-xrp"},"yoast_head":"\nReservedTxns<\/code> vor. Dieses Objekt enth\u00e4lt eine Ledger-Sequenznummer sowie ein Array von Transaktions-IDs und wird \u00fcber einen Index gespeichert, der aus dem Hash eines festen Strings und der jeweiligen Ledger-Sequenznummer gebildet wird. Zus\u00e4tzlich schl\u00e4gt Schwartz eine neue Transaktion namens TxnReserve<\/code> vor, mit der Nutzer einen Ausf\u00fchrungsplatz f\u00fcr eine bestimmte Transaktion reservieren k\u00f6nnen. Daf\u00fcr m\u00fcssten sie mindestens die doppelte normale Transaktionsgeb\u00fchr zahlen, alle \u00fcblichen Ausf\u00fchrungsanforderungen erf\u00fcllen und einen Ledger angeben, der gr\u00f6\u00dfer als der aktuelle, aber h\u00f6chstens 16 Ledger in der Zukunft liegt.<\/p>\n