Transaktionssimulation vs. Flashloan-Attacken: Warum Rabby vor Ultra-kurzfristigen Exploits nicht schützt

Ein Nutzer verbindet Rabby Wallet mit einer DeFi-Anwendung auf Ethereum, um Token in einen Liquiditäts-Pool einzuzahlen. Die Transaktionssimulation zeigt eine erwartete Rendite von 2,5 Prozent über sieben Tage an, und die Sicherheitswarnungen des Wallets signalisieren grünes Licht. Der Nutzer unterzeichnet die Transaktion. Doch zwischen dem Augenblick der Simulation und der tatsächlichen Ausführung im nächsten Block passiert etwas, das keine statische Vorschau erfassen kann: Ein Flashloan-Angreifer hat den Liquiditätspreis manipuliert, und die echte Rendite beträgt minus 40 Prozent. Die Simulation war technisch korrekt – nur für einen anderen Zustand des Systems.

Diese Szene offenbart eine grundlegende Grenze von Transaktionssimulation als Sicherheitsmechanismus. Rabby Wallet ist bekannt für seine robusten Schutzmaßnahmen gegen Phishing und bösartige Smart Contracts: Die Wallet führt Transaktionen vor dem Signieren durch, warnt vor verdächtigen Zielzielen und verschlüsselt private Keys lokal. Doch diese Werkzeuge schützen gegen statische Risiken – Code-Fehler, Betrugsadressen, falsche Netzwerke – nicht gegen dynamische Attacken, die das Blockchain-Ökosystem zwischen Simulation und Ausführung verändern. Flashloans, MEV-Manipulation und Just-in-Time Liquidität sind keine Wallet-Probleme. Sie sind Protokoll-Probleme, die jede DeFi-Wallet teilt.

Wie Transaktionssimulation funktioniert und was sie nicht tut

Rabby Wallet nutzt Transaktionssimulation durch Tenderly oder ähnliche Infrastruktur, um Transaktionen auszuführen, bevor der Nutzer sie unterzeichnet. Der Simulator nimmt den aktuellen Zustand des Systems – alle Smart-Contract-Zustände, Kontostände, Preise in Oracles – und führt die Transaktion aus, ohne sie tatsächlich in die Blockchain zu schreiben. Das Ergebnis ist vorhersagbar: Wenn ein Token-Transfer fehlschlägt, oder ein Smart Contract nicht genug Guthaben hat, wird die Simulation das zeigen. Wenn ein Zielvertrag einen ungültigen Opcode enthält, wird es auch dabei auffallen.

Diese Simulation schützt gegen breite Kategorien von Fehlern und betrügerischen Verträgen. Ein Scammer kann nicht einfach einen Vertrag schreiben, der beliebig viele Token stiehlt, ohne dass die Simulation vor dem Signieren einen Fehler zeigt – sofern der Diebstahl direkt im Code codiert ist. Ebenso können einfache Fehler wie eine falsche Adresse, eine falsche Dezimalzahl oder ein fehlender Genehmigung erfasst werden. Für diese statischen Gefahren ist Transaktionssimulation ein ernsthafter Schutz.

Die Simulation hat jedoch einen entscheidenden Zeitstempel: Sie spiegelt den Zustand des Ledgers zum Zeitpunkt der Simulation wider, nicht zum Zeitpunkt der Ausführung. Das ist nicht nur eine technische Besonderheit. Das ist der Punkt, an dem jede MEV-Attacke, jeder Flashloan-Exploit und jeder Just-in-Time-Liquiditätsangriff die Lücke ausnutzt. Zwischen Simulation und Ausführung können Minuten, Stunden oder – bei überlasteten Netzwerken wie Ethereum L1 – sogar bis zu mehrere Blöcke vergehen. In diesem Zeitraum können andere Transaktionen die Preise ändern, Liquiditätspools leeren oder Positionen liquidieren.

Ein konkretes Beispiel verdeutlicht dies: Ein Nutzer möchte 100 ETH in einen Curve-Pool einzahlen und sieht in der Simulation einen erwarteten Token-Output von 99,8 ETH-Äquivalent (unter Berücksichtigung von Gebühren). Die Simulation ist korrekt für die gerade gescannten Kurven und Liquiditäten. Doch zwei Sekunden später erscheint eine andere Transaktion im selben Block, die den Curve-Pool drained und den Preis um 15 Prozent verschiebt. Der echte Output des Nutzers fällt auf 84,8 ETH-Äquivalent – aber die Wallet-Simulation warnte nicht, weil sie nicht die Zukunft sehen kann.

Flashloans: Atomare Geldraubzüge über Grenzen

Ein Flashloan ist ein Smart-Contract-Primitiv, das es jedem beliebigen Nutzer ermöglicht, beliebig große Kreditmengen aufzunehmen, solange die Schuld innerhalb derselben Transaktion zurückgezahlt wird. Das Konzept existiert nur auf Smart-Contract-Blockchains wie Ethereum und benötigt nicht einmal Sicherheiten, weil die Atomar des Contracts garantiert, dass Nichterstattung zum Rollback der gesamten Transaktion führt. Der Exploit besteht darin, dass während dieses Flashloans die Preise manipuliert werden können.

Ein klassisches Schema: Der Angreifer nimmt einen großen Flashloan aus Aave, nutzt das Geld, um den Preis in Uniswap zu beeinflussen (indem er große Mengen eines Tokens kauft), nutzt diesen künstlich hohen Preis, um ein anderes DeFi-Protokoll auszunutzen, das auf dem Uniswap-Preis-Oracle vertraut, verkauft dann alles zurück und zahlt den Flashloan zurück – zusammen mit Gebühren, die deutlich unter dem Gewinn liegen. Die gesamte Attacke verläuft in einer atomaren Transaktion: von Block zu Block sieht die Blockchain einen normalen Zustand.

Transaktionssimulation in Rabby Wallet oder jeder anderen DeFi-Wallet schützt nicht vor diesem Szenario, weil die Simulation den Angreiffer-Block nicht enthält. Der Nutzer und der Angreifer befinden sich in unterschiedlichen Blöcken. Die Simulation des Nutzers zeigt den Zustand vor dem Angriff. Die tatsächliche Transaktionsausführung erfolgt nach dem Angriff – und der Preis ist anders. Die Wallet kann dies nur erfassen, wenn sie die **nächsten Blöcke in die Zukunft sieht**, was unmöglich ist.

Besonders tückisch sind Attacken durch professionelle MEV-Bots, die privat einen Transaktion-Pool überwachen. Ein Nutzer sendet eine Transaktionsanfrage an das Netzwerk. Ein Bot sieht diese Anfrage in den Mempool, platziert seine eigene, bösartige Transaktion davor (Front-Running), ändert Preise, und platziert eine weitere Transaktion dahinter (Back-Running), um Gewinne zu sichern. Der Nutzer in der Mitte verliert. Die Rabby-Simulation hätte diese Bot-Aktivität nicht vorhergesehen, weil sie vor dem Mempool-Scan stattfindet.

Warum Slippage-Schutz unzureichend ist

Rabby Wallet und die meisten anderen DeFi-Wallets bieten Slippage-Schutz: Der Nutzer legt einen minimalen erwarteten Output fest, und die Transaktion wird zurückgerollt, wenn der echte Output darunter liegt. Das ist wertvoll, aber es ist eine reaktive, nicht präventive Verteidigung. Slippage-Schutz sagt: „Wenn der Preis um mehr als fünf Prozent fällt, breche ab.” Das verhindert die Katastrophe, aber es bedeutet auch, dass die Transaktion fehlschlagen könnte – möglicherweise mehrmals in Folge – in einem volatilen Markt.

Ein Nutzer, der eine Limit-Order um Mitternacht platziert, kann aufwachen und feststellen, dass die Transaktion dreimal fehlgeschlagen ist, weil der Slippage außerhalb des Toleranzbereichs lag. Das ist besser als zu verlieren, aber es ist auch frustrierend. Und in großen Transaktionen oder bei Protokollen ohne eingebauten Slippage-Schutz kann es sein, dass der Nutzer die Slippage-Toleranz manuell setzen muss – worauf hin viele Nutzer eine zu hohe Toleranz wählen und wieder anfällig sind.

Flashloan-basierte Attacken sind oft so aggressiv, dass selbst ein kluger Slippage-Schutz nicht hilft. Wenn ein Angreifer den Preis um 50 Prozent verschiebt, und der Nutzer auf ein Slippage-Limit von 15 Prozent hoffen kann, endet die Transaktion mit einem Fehler. Das ist besser als der volle Vermögensverlust, aber der Nutzer hat auch keine Token erhalten. Der Fehler ist dann nicht eine böse Absicht des Wallets, sondern das Scheitern des Preismechanismus selbst.

MEV-Architektur und die Unmöglichkeit von lokaler Simulation

MEV (Maximal Extractable Value) ist nicht ein Angriff, sondern ein strukturelles Merkmal aller Blockchains mit Smart Contracts. Validatoren, Sequenzer und Blockersteller können die Reihenfolge von Transaktionen wählen. Diese Macht lässt sich monetisieren. Ein MEV-Bot sieht die anstehenden Transaktionen und reordnet, sperrt oder manipuliert sie für Gewinn. Das System als Ganzes wird zu einem Auktionierungsprozess, bei dem die höchste Gebote gewinnen – aber die Gebote sind versteckt, privat und nicht vollständig nachvollziehbar für einen einzelnen Wallet-Nutzer.

Rabby Wallet ist im rabby ökosystem ein non-custodial Wallet, das heißt, es speichert private Keys lokal und hat keine zentralisierte Kontrolle über die Reihenfolge von Transaktionen. Das ist gut für die Sicherheit des Wallets selbst – die Keys können nicht gestohlen werden, weil Rabby sie nicht hat. Das ist aber auch ein Nachteil gegen MEV: Das Wallet kann nicht viel tun, um die Transaktion durch den Mempool zu priorisieren oder deren Reihenfolge gegen MEV-Bots zu sichern. Die Wallet kann die Transaktion konstruieren und signieren, aber nicht kontrollieren, wo sie in der Blöcke-Warteschlange landet.

Einige Wallets und Protokolle versuchen, MEV zu mindern, indem sie private Mempools verwenden (wie Flashbots Protect), auf separaten Sequenzern laufen (wie auf Arbitrum mit sequencer-managed Transaktionen) oder Encrypted Mempools nutzen (wie Shutter Network). Aber auch diese Lösungen sind nicht vollständig. Sie verschieben das Problem, anstatt es zu lösen. Und sie erfordern, dass der Nutzer explizit diese Kanäle nutzt – die Standard-Transaktion über Rabby geht immer noch durch den öffentlichen Mempool.

Intelligente Limits, Verzögerungen und Beobachtung

Was kann ein Nutzer tun, um sich selbst vor Flashloan-Attacken und MEV zu schützen? Die erste Strategie ist, die Transaktionsgröße zu reduzieren und sie in mehreren Schritten durchzuführen. Ein großer Trade ist ein besser Ziel für einen Flashloan-Angreifer als zehn kleine Trades. Der Nachteil ist Gebühreneffizienz und Aufwand. Auf Ethereum Mainnet ist dies oft nicht praktikabel; auf Arbitrum oder Polygon, wo Gas-Kosten niedrig sind, funktioniert es besser.

Die zweite Strategie ist, eine Verzögerung einzuführen. Statt die Transaktion sofort zu senden, speichert der Nutzer sie, wartet eine Stunde, und sendet sie dann. Das erhöht die Chancen, dass der Bot nicht mehr im selben Block sitzt. Das ist kein garantierter Schutz, funktioniert aber in der Praxis gegen automatisierte, opportunistische Bots, die auf Minuten-Zeitskalen arbeiten.

Die dritte Strategie ist, den Transaktion-Preis-Ort zu beobachten. Statt zu einer beliebigen Zeit zu kaufen, wartet der Nutzer, bis der Kurs unter einen bestimmten Schwelle fällt, bei dem ein Trade wahrscheinlich profitabel ist – oder bis Liquidität besonders groß ist. Das ist nicht präventiv, aber es reduziert das Angreifer-Fenster. Ein sehr großer Trade bei niedriger Liquidität ist ein attraktiveres Ziel als ein mittelmäßiger Trade bei hoher Liquidität.

Dezentralisierte Sequenzer und Intent-basierte Architekturen

Die längerfristigen Lösungen auf Protokoll-Ebene sind dezentralisierte Sequenzer und Intent-basierte Architektur. Ein dezentralisierter Sequenzer (wie auf Arbitrum oder kommend auf anderen Layer-2s) bedeutet, dass keine einzelne Entität die Transaktion-Reihenfolge kontrolliert. Das macht MEV-Bots ineffektiver, weil der Angreifer nicht wissen kann, welcher Validator die nächste Reihenfolge baut. Intent-basierte Architektur (wie Anoma oder kommende Solver-Märkte auf Ethereum) bedeutet, dass der Nutzer nicht eine Transaktion mit expliziter Reihenfolge sendet, sondern nur eine „Absicht” – z.B. „Ich will 1 ETH gegen mindestens 1500 USDC tauschen”. Spezialisierte Solver konkurrieren dann, um diese Absicht auszuführen, ohne den Nutzer der Reihenfolge-Manipultion auszusetzen.

Rabby Wallet wird diese Systeme unterstützen, sobald sie reif sind. Aber heute, 2024, sind sie nicht standardisiert. Die meisten Nutzer verwenden immer noch Standard-EVM-Blockchains mit öffentlichen Mempools und Validator/Sequenzer-basierten Reihenfolge. Für diese Nutzer gilt: Transaktionssimulation schützt vor statischen Risiken, nicht vor dynamischen.

Warnsignale und realistische Erwartungen setzen

Rabby Wallet zeigt Sicherheitswarnungen an, wenn eine Transaktion verdächtig aussieht. Das ist wertvoll, aber der Nutzer sollte verstehen, was diese Warnungen schützen und was nicht. Eine Warnung „Dieses Protokoll hat einen bekannten Audit-Fehler” ist nützlich. Eine Warnung „Dieser Vertrag könnte beliebig viele Token nehmen” ist nützlich. Eine Warnung „Ihr Slippage liegt über 10 Prozent” ist nützlich. Aber es gibt keine Warnung, die sagt: „In diesem Block könnten MEV-Bots eingreifen und den Preis um 20 Prozent ändern.”

Das liegt nicht daran, dass Rabby schlecht ist. Das liegt daran, dass das Problem nicht in der Wallet, sondern in der Blockchain-Architektur liegt. Der Preis in einem Uniswap-Pool ist öffentlich und kann bis zur Ausführung jederzeit geändert werden. Das ist eine Eigenschaft, keine Schwäche. Es ist notwendig für Liquiditätsmärkte. Aber es bedeutet auch, dass Nutzer immer einem Slippage-Risiko ausgesetzt sind.

Realistische Erwartungen sind: Transaktionssimulation schützt vor Code-Fehlern, bösartigen Verträgen und übersehenen Dezimalzahlen. Sie schützt nicht vor Preisveränderungen, MEV-Reordering oder Flashloan-Attacken. Der Nutzer muss selbst Slippage-Toleranzen setzen, Transaktionsgröße bewerten und entscheiden, ob ein Trade es wert ist, gegeben dieser Risiken.

Vergleich mit zentralisierten und privaten Pools

Eine Alternative zu öffentlichen Liquiditätspools ist es, mit zentralisierten oder privaten Pool-Betreibern zu handeln. Coinbase Prime, Kraken Institutions oder Over-the-Counter (OTC) Desks ermöglichen große Trades ohne öffentliche Preisveränderungen. Der Nachteil ist, dass sie zentralisiert sind: Sie halten Ihre Assets, Ihre Identität ist bekannt, und Sie müssen ihnen vertrauen. Rabby Wallet ist ein non-custodial Wallet, also nicht für diese Anwendung geeignet.

Eine andere Alternative ist es, auf Layer-2s zu handeln, wo Transaktionen schneller und Gebühren niedriger sind, sodass Slippage-Kosten in Verhältnis kleiner werden. Auf Arbitrum oder Optimism kosten Gas-Gebühren 0,10 USD statt 10 USD, und Blöcke werden alle Sekunde baut, nicht jede 12 Sekunden. Das reduziert das MEV-Fenster. Aber es ersetzt das Problem nicht – es minimiert es nur.

Zukünftige Entwicklungen in Rabby und der Wallet-Landschaft

Rabby plant Mobile-Apps für iOS und Android sowie Desktop-Apps für Windows und macOS. Diese neuen Plattformen könnten neue Chancen für MEV-Schutz bieten – z.B. durch Integration mit privaten Rpc-Endpoints oder Intent-Solver-Märkten. Die Desktop-App könnte auch Hardware-Wallet-Integration verbessern, sodass Nutzer offlinener unterzeichnen können (was das MEV-Fenster nicht ändert, aber die Private-Key-Sicherheit erhöht).

Der langfristige Trend in der Wallet-Sicherheit wird wahrscheinlich in zwei Richtungen gehen: (1) Bessere Preis-Transparenz und Slippage-Berechnung in Echtzeit, damit der Nutzer weiß, mit welchem Risiko er rechnet; (2) Integration mit MEV-minimierenden Infrastrukturen wie privaten Mempools, dezentralisierten Solvern und Intent-Protokollen. Aber kurzfristig – für die nächsten ein bis zwei Jahre – wird die Situation so bleiben: Transaktionssimulation schützt vor Code-Risiken, nicht vor Markt-Risiken.