← Zurück zu den Artikeln
July 17, 2026
5 min read

Anatomie von MEV: Sandwiches, Frontrunning und der dunkle Wald des Mempools

Anatomie von MEV: Sandwiches, Frontrunning und der dunkle Wald des Mempools
#mev
#sandwich attack
#frontrunning
#mempool
#flashbots
#defi
#ethereum

Wenn du einen Swap auf einer dezentralen Börse signierst und an einen öffentlichen RPC-Endpunkt sendest, hast du keine private Anweisung an eine Matching-Engine geschickt. Du hast eine signierte, ausführbare Absichtserklärung auf einem globalen schwarzen Brett veröffentlicht und dabei eine Belohnung — den Gaspreis — an denjenigen geheftet, der sich bereit erklärt, sie auszuführen. Jeder kann diese Erklärung lesen. Niemand ist verpflichtet, sie fair, in der richtigen Reihenfolge oder überhaupt auszuführen. Die Reihenfolge, in der sie relativ zu anderen Transaktionen landet, ist keine Eigenschaft deiner Einreichung — sie ist eine Entscheidung eines Dritten, der davon profitiert, sie gegen dich zu treffen.

Das ist der unbequeme Kern des On-Chain-Handels. In Statistical Arbitrage and Pairs Trading in Crypto Markets haben wir beiläufig erwähnt, dass das Verschieben einer Position zwischen einer CEX und einer DEX ein "MEV-Risiko" birgt, und den Begriff dort unerklärt stehen lassen. Dieser Artikel begleicht diese Schuld. Er ist die Eingangstür zu einer Serie über die Ökonomie der On-Chain-Ausführung, und seine Aufgabe ist es, das Vokabular — Mempool, Bundle, Backrun, Sandwich, PBS — so präzise zu definieren, dass die späteren Beiträge zu atomarer Arbitrage mit Flash-Loans und konzentrierter Liquidität in Uniswap v3 für Quants voraussetzen können, dass du die Maschine bereits verstehst.

MEV — Maximal (oder Maximum) Extractable Value — ist der Gewinn, den eine Partei durch die Wahl der Aufnahme, des Ausschlusses und der Reihenfolge von Transaktionen innerhalb eines Blocks erzielen kann, über die üblichen Blockbelohnungen und Priority Fees hinaus. Es ist kein Bug; es ist eine strukturelle Konsequenz davon, wie permissionless Blockchains Transaktionen ordnen. Seit der Mechanismus 2019 formal charakterisiert wurde, ist der kumulativ extrahierte Wert in die Milliarden gegangen, und eine ganze Industrie — Searcher, Builder, Relays, Block-Proposer — ist entstanden, um ihn abzuschöpfen und umzuverteilen. Wenn du On-Chain handelst, zahlst du entweder diese Steuer, oder du hast bewusste Maßnahmen ergriffen, um es nicht zu tun.

1. Der Transaktions-Lebenszyklus: warum deine Absicht öffentlich ist

Um zu sehen, wo der Wert abfließt, folgen wir einer Transaktion von deiner Wallet bis zum finalisierten Block.

Der öffentliche Mempool

Wenn deine Wallet eine Transaktion signiert und an den RPC-Endpunkt eines Standard-Nodes übermittelt, validiert der Node sie (Signatur, Nonce, ausreichendes Guthaben) und verbreitet sie, falls sie die Prüfung besteht, per Gossip im Peer-to-Peer-Netzwerk an andere Nodes. Jeder Node hält diese noch nicht aufgenommenen Transaktionen in einem lokalen Puffer, dem sogenannten Mempool (Memory Pool). Innerhalb von ein bis zwei Sekunden besitzt praktisch jeder Node im Netzwerk — einschließlich Nodes, die von Parteien betrieben werden, deren gesamtes Geschäft darin besteht, Wert aus ausstehenden Transaktionen zu extrahieren — eine Kopie deiner signierten, vollständig dekodierten Transaktion.

"Vollständig dekodiert" ist der entscheidende Ausdruck. Deine Transaktion ist kein undurchsichtiger Datenblock. Sie ist ein ABI-kodierter Aufruf an einen bekannten Contract. Jeder, der den Mempool beobachtet, kann sie dekodieren und in klaren Worten lesen: diese Adresse ist dabei, 40 ETH gegen USDC im Uniswap-v2-WETH/USDC-Pool zu tauschen, und sie wird mindestens 96.000 USDC akzeptieren. Diese letzte Klausel — der minimal akzeptable Output — ist deine Slippage-Toleranz, und sie ist kein Hinweis. Sie ist ein fest in die Calldata kompilierter Parameter. Wir werden gleich sehen, dass sie auch das Budget des Angreifers ist.

Der Mempool wird manchmal als dunkler Wald bezeichnet, nach einem Essay von Dan Robinson und Georgios Konstantopoulos aus dem Jahr 2020, der sich die Metapher von Liu Cixin auslieh: ein Raum, in dem jede sichtbare Entität sofort von Raubtieren gejagt wird, die man selbst nicht sehen kann. Sendet man eine naive, profitable Transaktion in den öffentlichen Mempool, erreicht sie womöglich nie in der signierten Form einen Block — ein Bot wird die Gelegenheit bereits konsumiert und den umliegenden Block gegen einen selbst umgestaltet haben.

Gaspreis als Prioritätswarteschlange

Der Gebührenmarkt von Ethereum (nach EIP-1559) teilt den Gaspreis in eine protokollseitige Base Fee, die verbrannt wird, und eine Priority Fee (das "Trinkgeld"), die an den Block-Proposer geht. Beim Bauen eines Blocks ist der Builder wirtschaftlich motiviert, die Transaktionen aufzunehmen, die ihm am meisten zahlen. Vereinfacht gesagt ist der Mempool eine Prioritätswarteschlange, sortiert nach dem Trinkgeld: höheres Trinkgeld, frühere Aufnahme.

Das ist der Mechanismus, der die Reihenfolge käuflich macht. Sehe ich deinen ausstehenden Swap und will meine Transaktion unmittelbar vor deiner ausführen, muss ich nichts hacken. Ich reiche einfach eine Transaktion mit einem höheren Trinkgeld ein. Der Builder platziert, seinem Anreiz folgend, meine zuerst. Die Reihenfolge ist keine vom Protokoll garantierte Fairness; sie ist eine vom Protokoll durchgeführte Auktion, und das versteigerte Los ist das Recht, auf Basis der Information in deiner ausstehenden Transaktion zu handeln.

Zwei Tatsachen ergeben zusammen das gesamte MEV-Problem:

  1. Ausstehende Transaktionen sind sichtbar (öffentlicher Mempool).
  2. Ihre Reihenfolge steht zum Verkauf (Trinkgeld-Prioritätsauktion).

Alles Weitere ist ein Korollar.

Transaktions-Lebenszyklus von der Wallet zum Block: signierte Tx wird an den öffentlichen Mempool gesendet, ist für Searcher sichtbar und wird vom Builder nach Priority Fee in einen Block geordnet

2. Sandwich-Mechanik, mit der tatsächlichen Mathematik

Das Sandwich ist die kanonische toxische MEV-Strategie gegen einen Swapper, und es lohnt sich, die Arithmetik durchzurechnen, denn die Zahlen erklären, warum deine Slippage-Einstellung der wichtigste Verteidigungsparameter ist, den du kontrollierst.

Die Constant-Product-Invariante

Ein Uniswap-v2-Pool hält Reserven xx von Token X und yy von Token Y und erzwingt nach jedem Trade die Invariante

xy=kx \cdot y = k

(Gebühren zunächst ignoriert). Verkauft ein Trader Δx\Delta x von Token X in den Pool, ist die neue X-Reserve x+Δxx + \Delta x, und um kk zu erhalten, muss der Pool

Δy=ykx+Δx=yΔxx+Δx.\Delta y = y - \frac{k}{x + \Delta x} = \frac{y \, \Delta x}{x + \Delta x}.

auszahlen. Mit der 0,3%-Gebühr von Uniswap v2 wird der Input mit γ=0,997\gamma = 0{,}997 skaliert:

Δy=yγΔxx+γΔx.\Delta y = \frac{y \, \gamma \, \Delta x}{x + \gamma \, \Delta x}.

Die entscheidende Eigenschaft: Je mehr man in eine Richtung kauft, desto schlechter der Grenzpreis. Die Preiswirkung ist konvex. Genau diese Konvexität monetarisiert der Angreifer.

Das Setup

Nehmen wir einen WETH/USDC-Pool. Um die Zahlen übersichtlich zu halten, nehmen wir Reserven an, die ETH auf etwa 2.500 USDC setzen:

  • x=10.000x = 10.000 WETH
  • y=25.000.000y = 25.000.000 USDC
  • k=2,5×1011k = 2{,}5 \times 10^{11}

Du möchtest USDC mit 40 WETH kaufen (ein Verkauf von WETH in den Pool). Ignoriert man für die Veranschaulichung die Gebühren, würde eine ehrliche Ausführung in einem leeren Block

Δy=25,000,0004010,000+40=1,000,000,00010,04099,601 USDC.\Delta y = \frac{25{,}000{,}000 \cdot 40}{10{,}000 + 40} = \frac{1{,}000{,}000{,}000}{10{,}040} \approx 99{,}601 \text{ USDC}.

ergeben. Der Spotpreis vor deinem Trade liegt bei 25.000.000/10.000=2.50025.000.000 / 10.000 = 2.500 USDC/WETH, sodass 40 WETH zum Mid-Preis vor dem Trade "wert" sind: 100.000 USDC. Du erhältst 99.601 — die Lücke von etwa 399 USDC ist deine eigene Preiswirkung plus Gebühren. Nehmen wir nun an, du setzt eine Slippage-Toleranz von 1%. Das amountOutMin deiner Transaktion ist

99,601×0.9998,605 USDC.99{,}601 \times 0.99 \approx 98{,}605 \text{ USDC}.

Diese Zahl ist jetzt öffentlich im Mempool sichtbar. Sie teilt jedem Beobachter mit: diese Person akzeptiert für ihre 40 WETH mindestens 98.605 USDC. Die Differenz zwischen dem, was du in einem sauberen Block bekommen würdest (99.601), und deinem Boden (98.605) — etwa 996 USDC — ist der Spielraum, den du freiwillig demjenigen überlassen hast, der dich frontrunnt. Das ist das Budget des Angreifers.

Der Angriff, Schritt für Schritt

Ein Searcher konstruiert drei Transaktionen und erzwingt diese Reihenfolge innerhalb eines Blocks:

1. Frontrun (Angreifer kauft zuerst). Der Angreifer verkauft eigenes WETH vor deiner Transaktion in den Pool und treibt so den Preis von USDC nach oben (WETH nach unten), sodass du beim Ausführen deines Trades weniger USDC pro WETH bekommst. Der Angreifer bemisst das so, dass deine Transaktion immer noch dein amountOutMin erreicht — tut sie das nicht, wird dein Swap zurückgerollt, und es gibt kein Opfer für das Sandwich. Die optimale Frontrun-Größe ist die größte, die dich exakt an deinem Boden belässt.

Angenommen, der Angreifer frontrunnt mit eigenen 40 WETH. Der Pool bewegt sich zu x=10.040x = 10.040, und gemäß der Invariante erhält der Angreifer

25,000,0004010,04099,601 USDC out,\frac{25{,}000{,}000 \cdot 40}{10{,}040} \approx 99{,}601 \text{ USDC out},

wodurch die Reserven bei x=10.040x = 10.040 WETH, y24.900.399y \approx 24.900.399 USDC liegen.

2. Opfer (dein Swap wird gegen den verschlechterten Pool ausgeführt). Deine 40 WETH landen jetzt gegen diese Reserven:

Δy=24,900,3994010,040+40=996,015,96010,08098,811 USDC.\Delta y = \frac{24{,}900{,}399 \cdot 40}{10{,}040 + 40} = \frac{996{,}015{,}960}{10{,}080} \approx 98{,}811 \text{ USDC}.

Prüfen wir die Bedingung: 98.811 > 98.605, also wird deine Transaktion nicht zurückgerollt — du wirst ausgeführt, nur schlechter. Du hast 98.811 statt der 99.601 erhalten, die du in einem sauberen Block bekommen hättest. Du bist um etwa 790 USDC ärmer, und du hast keine Ahnung, dass es passiert ist; dein Swap "war erfolgreich". Der Pool liegt jetzt bei x=10.080x = 10.080 WETH, y24.801.588y \approx 24.801.588 USDC.

3. Backrun (Angreifer verkauft zurück). Der Angreifer verkauft nun das in Schritt 1 gekaufte USDC zurück in den Pool — oder kauft äquivalent sein WETH zurück — und vereinnahmt so den erhöhten Preis, den dein Trade geschaffen hat. Kauft er WETH mit den ~99.601 USDC zurück, die er hält:

Δx=10,08099,60124,801,588+99,6011,004,010,08024,901,18940.32 WETH.\Delta x = \frac{10{,}080 \cdot 99{,}601}{24{,}801{,}588 + 99{,}601} \approx \frac{1{,}004{,}010{,}080}{24{,}901{,}189} \approx 40.32 \text{ WETH}.

Der Angreifer hat in Schritt 1 40 WETH ausgegeben und in Schritt 3 40,32 WETH zurückbekommen — ein Gewinn von etwa 0,32 WETH (~800 USDC) vor Gas, fast vollständig aus deinem Slippage-Budget extrahiert. Verringerst du deine Slippage, schrumpft dieses Budget; die optimale Frontrun-Größe des Angreifers sinkt, und unterhalb einer gewissen Schwelle ist das Sandwich nach Gas nicht mehr profitabel, und der Searcher lässt dich in Ruhe.

Die Lehre daraus lautet nicht "Slippage-Toleranz ist schlecht". Du brauchst etwas Toleranz, sonst werden deine Transaktionen bei gewöhnlicher Preisbewegung zurückgerollt. Die Lehre ist, dass die Slippage-Toleranz eine direkt extrahierbare Größe ist, und sie auf einen bequemen Standardwert wie 1% zu setzen — oder schlimmer, auf "auto" bei einem dünnen Pool — bedeutet, genau diesen Betrag für jeden Beobachter offen liegen zu lassen. Bei einem Pool mit geringer Liquidität, bei dem dein eigener Trade den Preis um mehrere Prozent bewegt, kann eine Standard-Slippage einen erschreckenden Anteil deines Notionals kosten.

Eine minimale Skizze der Profitbedingung eines Searchers:

def sandwich_profit(x, y, gamma, victim_dx, victim_min_out, attack_dx, gas_cost):
    out1 = (y * gamma * attack_dx) / (x + gamma * attack_dx)
    x1, y1 = x + attack_dx, y - out1
    vout = (y1 * gamma * victim_dx) / (x1 + gamma * victim_dx)
    if vout < victim_min_out:
        return None  # victim would revert; no sandwich
    x2, y2 = x1 + victim_dx, y1 - vout
    got_back = (x2 * gamma * out1) / (y2 + gamma * out1)
    return got_back - attack_dx - gas_cost  # profit in WETH

Der Searcher führt eine kleine Optimierung über attack_dx durch, um den größten Frontrun zu finden, der vout >= victim_min_out einhält. Dieses Optimum liegt genau dort, wo deine Slippage-Grenze bindend wird — was nur eine andere Art ist zu sagen, dass die Beute des Angreifers exakt durch den Spielraum begrenzt ist, den du gelassen hast.

3. Eine Taxonomie von MEV: toxisch versus gutartig

"MEV" wird als Schimpfwort benutzt, aber nicht alles davon ist Extraktion auf Kosten eines Opfers. Es hilft, Strategien danach zu sortieren, ob jemand durch die Reihenfolge schlechter gestellt wird.

Frontrunning. Man beobachtet eine ausstehende profitable Transaktion, kopiert oder antizipiert sie und zahlt ein höheres Trinkgeld, um zuerst auszuführen. Der Archetyp ist, einen großen Kauf zu sehen, der den Preis bewegen wird, und ihm zuvorzukommen. Rein toxisch: Das Opfer bekommt einen schlechteren Preis, oder seine Gelegenheit wird schlicht gestohlen.

Backrunning. Man platziert die eigene Transaktion unmittelbar nach einer Zieltransaktion, um auf den dadurch geschaffenen Zustand zu reagieren. Entscheidend: Ein reiner Backrun verschlechtert die Ausführung des Ziels nicht — er läuft danach, der Preis des Opfers ist bereits fixiert. Wenn dein großer Swap den WETH/USDC-Pool aus dem Gleichgewicht mit Binance bringt, backrunnt ihn ein Arbitrageur, um ihn wieder anzugleichen, und steckt die Differenz ein. Du wirst nicht geschädigt; tatsächlich ist diese Arbitrage genau das, was On-Chain-Preise am globalen Markt ausrichtet hält. Backrunning ist das gutartige Ende des Spektrums, und — wie wir sehen werden — moderne MEV-Schutzsysteme sind genau darauf ausgelegt, Backrun-Gewinn an den Nutzer zurückzugeben, der ihn geschaffen hat.

Sandwiching. Ein Frontrun und ein Backrun, um dasselbe Opfer gelegt, wie oben seziert. Toxisch per Konstruktion: Der Frontrun existiert nur, um die Ausführung des Opfers zu verschlechtern, damit der Backrun sie abschöpfen kann.

Atomare Arbitrage. Eine einzelne Transaktion, die einen Vermögenswert an einem Ort günstig kauft und an einem anderen teuer verkauft — etwa WETH günstiger auf Uniswap als auf Sushiswap — und dabei risikofrei Gewinn erzielt, alles-oder-nichts innerhalb einer Transaktion (sie wird zurückgerollt, wenn unprofitabel). Es gibt kein konkretes Opfer; sie schließt lediglich eine Preisdiskrepanz, die der Markt offen gelassen hat. Wird allgemein als gutartig betrachtet — sie verbessert die Preiskonsistenz über Venues hinweg — und ist Thema des Beitrags Atomare Arbitrage und Flash-Loans dieser Serie, wo die Eigenschaft "kein Kapital erforderlich" von Flash-Loans sie besonders scharf macht.

Liquidationen. Fällt eine Kreditposition (Aave, Compound, Maker) unter ihre Sicherheitenschwelle, bietet das Protokoll demjenigen einen Bonus, der die faule Schuld zurückzahlt und die Sicherheiten einzieht. Searcher konkurrieren darum, dieser Liquidator zu sein. Es gibt ein "Opfer" — den liquidierten Kreditnehmer —, aber er wird unabhängig davon nach den Regeln des Protokolls liquidiert; der MEV-Wettbewerb bestimmt vor allem, wer den Bonus bekommt, und kann ihn durch Konkurrenz verkleinern. Man kann das für die Marktgesundheit als neutral bis gutartig bezeichnen, für den Kreditnehmer als unangenehm.

Eine grobe Übersicht:

Strategie Opfer geschädigt? Urteil
Frontrun Ja Toxisch
Sandwich Ja Toxisch
Backrun (rein) Nein Gutartig
Atomare Arbitrage Nein Gutartig (verbessert Preiskonsistenz)
Liquidation Kreditnehmer (nach Protokollregeln) Neutral

Die Trennlinie zwischen toxisch und gutartig ist wichtig, weil der gesamte moderne MEV-Minderungsstack ein Versuch ist, die toxischen Strategien zu unterdrücken und dabei die gutartigen zu erhalten — und umzuverteilen. Man kann Ordering-Spiele nicht verbieten, ohne auch die Arbitrage zu zerstören, die DEX-Preise ehrlich hält. Der Trick besteht darin, den toxischen Wert an die Person zurückzuleiten, der er entnommen wurde.

4. Eine kurze Geschichte: von Gasauktionen zu Flashbots

Flash Boys 2.0 und Priority Gas Auctions

Das Phänomen wurde 2019 im Paper "Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges" von Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach und Ari Juels benannt und vermessen. Das Paper führte den Begriff "Miner Extractable Value" ein (später zu Maximal Extractable Value verallgemeinert, als die Branche von Proof-of-Work-Minern zu Proof-of-Stake-Proposern wechselte) und dokumentierte Priority Gas Auctions (PGAs): Bots, die sich in Echtzeit gegenseitig beim Gaspreis überbieten, um die Reihenfolge einer profitablen Gelegenheit zu gewinnen.

PGAs waren sichtbar pathologisch. Da der einzige Hebel, den Bots hatten, der öffentliche Gaspreis war, führten sie offene Bieterkriege — wiederholtes Nachreichen mit immer höheren Trinkgeldern innerhalb derselben wenigen Sekunden —, um eine einzelne Arbitrage oder Liquidation zu ergattern. Zwei hässliche Konsequenzen folgten daraus. Erstens verstopfte dies das Netzwerk und trieb die Gaspreise für alle in die Höhe, ob mit MEV verbunden oder nicht. Zweitens, und beunruhigender, argumentierte das Paper, dass rationale Miner, sofern der in einem Block verfügbare MEV die Blockbelohnung überstieg, einen Anreiz hätten, die Chain zu reorganisieren, um ihn zu stehlen — eine Bedrohung für die Konsensstabilität selbst. MEV war nicht nur ein Fairness-Problem für Nutzer; es war eine Bedrohung für die Chain.

Flashbots als Antwort

Flashbots startete 2020, um die PGA zu entschärfen. Die zentrale Einsicht: die Ordering-Auktion aus dem öffentlichen Mempool heraus in einen verdeckten (sealed-bid), off-chain Kanal verlagern. Statt eine Transaktion zu senden und einen öffentlichen Gaskrieg zu führen, stellt ein Searcher ein Bundle zusammen — eine geordnete Liste von Transaktionen, die atomar, alles-oder-nichts, in einer bestimmten relativen Reihenfolge aufgenommen werden sollen — und reicht es privat bei einem Block-Builder ein, zusammen mit einem Gebot (oft als direkte Überweisung an den Proposer gezahlt statt über den Gaspreis). Der Builder stellt aus allen erhaltenen Bundles und Transaktionen den wertvollsten Block zusammen, den er kann, und bietet ihn dem Proposer an.

Zwei Dinge verbessern sich gleichzeitig. Searcher hören auf, den öffentlichen Mempool mit fehlgeschlagenen Geboten zuzuspammen, wodurch die Gaspreis-Externalität für gewöhnliche Nutzer sinkt. Und das gewinnende Bundle landet entweder vollständig oder gar nicht, was die "fehlgeschlagenen Frontrun"-Transaktionen eliminiert, die früher Blöcke verstopften. Der Bieterkrieg findet weiterhin statt — nur eben als private Auktion innerhalb des Builders statt als öffentliches Geschrei on-chain.

PBS: Proposer-Builder-Trennung

Die Architektur von Flashbots verallgemeinerte sich zur Proposer-Builder-Separation (PBS), dem heute dominierenden Modell auf Ethereum. Die Rollen teilen sich auf:

  • Searcher finden MEV-Gelegenheiten und packen sie in Bundles.
  • Builder konkurrieren darum, aus Bundles und öffentlichen Transaktionen den einen wertvollsten vollständigen Block zusammenzustellen.
  • Relays sitzen zwischen Buildern und Proposern, erhalten vollständige Blöcke von Buildern und geben nur Block-Header plus ein Wertgebot an den Proposer weiter, sodass sich der Proposer auf einen Block festlegt, bevor er dessen Inhalt sieht (was verhindert, dass der Proposer den MEV einfach selbst stiehlt).
  • Proposer (Validatoren) wählen den Header mit dem höchsten Gebot, signieren ihn und kassieren die Zahlung.

Dies wird außerhalb des Protokolls über MEV-Boost umgesetzt, eine Middleware, die die überwältigende Mehrheit der Ethereum-Validatoren betreibt — in der Größenordnung von 80–90% der Blöcke werden über externe Builder via MEV-Boost gebaut. Es funktioniert, verlässt sich aber auf vertrauenswürdige Relays. Der nächste Schritt, verankertes PBS (ePBS, EIP-7732), zielt darauf ab, die Proposer-Builder-Trennung direkt ins Ethereum-Protokoll einzubacken und die Abhängigkeit von vertrauenswürdigen Relays zu entfernen. Stand Mitte 2026 ist es für das Glamsterdam-Upgrade vorgesehen, mit einer angestrebten Mainnet-Aktivierung später in 2026, wobei Befürworter behaupten, dass es die MEV-Verluste für Nutzer erheblich senken kann, indem es verbessert, wie Blöcke committet werden, und das Zeitfenster für toxisches Reordering verengt. Man sollte die genauen Zahlen bis zur Auslieferung als angestrebt behandeln, aber die Richtung ist klar: Das Protokoll absorbiert die MEV-Lieferkette, deren Existenz es jahrelang verdrängt hat.

MEV-Share: den Wert zurückgeben

Die für gewöhnliche Trader folgenreichste Entwicklung ist MEV-Share, die Order-Flow-Auktion von Flashbots. Die Idee dreht den dunklen Wald um. Statt dass deine Transaktion für jeden Räuber sichtbar ist, sendest du sie privat an einen MEV-Share-Node, der Searchern nur partielle Hinweise darüber offenlegt (du bestimmst, wie viel). Searcher bieten darauf, deine Transaktion zu backrunnen — bedenke: ein Backrun schadet dir nicht — und ein großer Teil des dabei entstehenden Gewinns wird an dich zurückerstattet, während der Rest zwischen dem Searcher und dem Proposer aufgeteilt wird, um die Aufnahme des Bundles zu sichern.

Die ökonomische Neurahmung ist elegant. Ein großer Swap schafft eine Backrun-Gelegenheit; die Frage ist, wer sie einheimst. In der Welt des dunklen Waldes nehmen Searcher und Builder alles davon. Unter MEV-Share wird der Wert, den deine eigene Transaktion geschaffen hat, größtenteils an dich zurückgegeben. Die verbraucherorientierte RPC von Flashbots, Flashbots Protect, leitet Retail-Transaktionen durch dieses System, und 2025 kamen zusätzlich Gasgebühren-Rückerstattungen hinzu, was das, was Nutzer zurückbekommen, spürbar erhöht. Das ist das Prinzip "das Gutartige umverteilen, das Toxische unterdrücken" ganz konkret gemacht.

5. Praktische Verteidigung für einen Trader

Man muss keinen Searcher betreiben, um kein Beutetier mehr zu sein. In grober Reihenfolge nach Wirkung:

Slippage bewusst setzen, pro Pool

Abschnitt 2 hat gezeigt, dass deine Slippage-Toleranz das Budget des Angreifers ist. Daraus folgen zwei Regeln. Erstens: Die Slippage an die tatsächliche Liquidität des Pools und die Preiswirkung deines Trades bemessen, nicht an ein gewohnheitsmäßiges 1%. Bei einem tiefen Pool kann eine Toleranz von 0,1–0,3% völlig ausreichen; bei einem dünnen entweder akzeptieren, dass man diese Größe nicht sicher handeln kann, oder in kleinere Tranchen aufteilen. Zweitens: niemals "auto"/unbegrenzte Slippage bei einem Paar mit geringer Liquidität verwenden — das ist ein signierter Blankoscheck. Wenn ein Swap bei enger Toleranz ständig zurückgerollt wird, sagt einem der Markt damit, dass der Trade zu groß für den Pool ist — nicht, dass man den Boden lockern sollte.

Über eine private RPC routen

Die sauberste strukturelle Lösung besteht darin, die eigene Transaktion vollständig aus dem öffentlichen Mempool herauszuhalten. Die Wallet auf eine private RPC richten, die Transaktionen direkt an Builder weiterleitet, statt sie per Gossip zu verbreiten:

  • Flashbots Protect — schickt deine Transaktion in das MEV-Share-System, sodass sie für Frontrunner niemals öffentlich sichtbar ist, und gibt einen Anteil an jeglichem Backrun-Wert plus Gas-Rückerstattungen zurück.
  • MEV Blocker (von CoW Protocol und anderen) — ein ähnlicher Private-RPC-Dienst, der vor Frontrunning und Sandwiching schützt und Backrun-Gewinn an Nutzer rückerstattet, mit einem kostenlosen Gebührenmodell.

Da ein Sandwich voraussetzt, dass der Angreifer deine ausstehende Transaktion sieht und einen Frontrun davor einfügt, entfernt das Herausnehmen deiner Transaktion aus dem öffentlichen Mempool die Frontrun-Gelegenheit vollständig. Die Backrun-Gelegenheit bleibt bestehen, wird nun aber an dich zurückversteigert statt gestohlen. Der Kompromiss besteht in etwas Vertrauen gegenüber dem RPC-Betreiber und gelegentlich einer geringfügig langsameren Aufnahme — meist trivial im Vergleich zur Eliminierung des Sandwich-Risikos. (Eine Benchmark-Studie von 2025 zu Private-Protection-RPCs fand, dass deren tatsächliche Abwicklung nicht immer strikt besser ist als öffentliche Einreichung, der Effekt ist also stark, aber nicht universell; für die meisten Retail-großen DEX-Swaps bleibt privates Routing dennoch die richtige Standardwahl.)

Batch-Auktions- und Intent-basierte Venues bevorzugen

Manche DEX-Designs entfernen den Ordering-Vorteil per Konstruktion. CoW Protocol wickelt Trades in Batch-Auktionen mit einem einheitlichen Clearing-Preis ab — jeder Trade in einem Batch wird zum gleichen Preis abgewickelt, es gibt also keine "erste" und "letzte" Position, die man ausnutzen könnte, und Solver konkurrieren darum, dir die beste Ausführung zu liefern, statt um dich herum umzuordnen. Intent-basierte Systeme, bei denen man signiert, was man will, und Solver die Ausführung finden lässt, statt einen konkreten Pfad zu signieren, entziehen dem Sandwich ähnlich den Boden. Wer in Größenordnung handelt, für den sind diese Venues mehr wert als jede Slippage-Anpassung.

Verstehen, warum L2s anders sind

Auf den meisten Ethereum-Rollups heute (Arbitrum, Optimism, Base) werden Blöcke von einem einzelnen Sequencer produziert, der vom Rollup-Team betrieben wird. Es gibt keinen öffentlichen Mempool ausstehender Transaktionen, den Searcher beobachten könnten, und es gibt eine vertrauenswürdige Partei, die über die Reihenfolge entscheidet. In der Praxis ordnen die meisten Sequencer Transaktionen nach dem First-Come-First-Served-Prinzip und führen keine Sandwich-Angriffe gegen ihre Nutzer durch, sodass Sandwiching auf diesen Chains auf Protokollebene weitgehend abwesend ist.

Aber man sollte den Kompromiss genau lesen: Der Grund, warum man vor dezentraler MEV-Extraktion sicher ist, ist, dass man einem zentralisierten Orderer vertraut, sie nicht durchzuführen. Der Sequencer könnte einen frontrunnen; er entscheidet sich (gebunden durch seinen Ruf) einfach dagegen. Das ist ein vorübergehendes Gleichgewicht. Während Rollups ihre Sequencer dezentralisieren — Shared Sequencer, Based Sequencing, PBS-artige Auktionen auf L2 — können dieselbe Mempool-Sichtbarkeit und die Dynamik der käuflichen Reihenfolge wieder auftauchen, und die L2-MEV-Frage wird zu einem offenen Designproblem statt einem gelösten. Man sollte nicht annehmen, dass "ich bin auf einer L2" dauerhaft bedeutet, dass "MEV mich nicht erreichen kann"; es bedeutet, dass "eine vertrauenswürdige Partei vorerst versprochen hat, es nicht zu tun".

Was man in den Rest der Serie mitnimmt

Reduziert man das Thema auf seine tragenden Fakten:

  1. Ein Swap im öffentlichen Mempool ist öffentliche Absicht plus ein käuflicher Ordering-Slot. Diese Kombination, nicht irgendein einzelner Bug, ist das gesamte Problem.
  2. Auf einem Constant-Product-AMM ist deine Slippage-Toleranz eine Größe, die ein Angreifer extrahieren kann, und die Beute eines Sandwiches ist exakt durch den Spielraum begrenzt, den du gelassen hast. Slippage zu setzen ist eine Sicherheitsentscheidung, kein Komfort-Schalter.
  3. MEV ist nicht monolithisch: Frontruns und Sandwiches sind toxisch; Backruns und atomare Arbitrage sind gutartig und sogar nützlich, weil sie On-Chain-Preise konsistent halten. Gute Minderung unterdrückt Ersteres und verteilt Letzteres um.
  4. Die Reaktion der Branche verlief von PGAs (öffentliche Gaskriege, Flash Boys 2.0, 2019) über Flashbots / Bundles / PBS (verdeckte private Auktionen) zu MEV-Share (Backrun-Wert an den Nutzer zurückgeben) und als Nächstes zu verankertem PBS im Protokoll.
  5. Als Trader bestehen deine Verteidigungslinien aus enger, pro Pool gesetzter Slippage, privaten RPCs (Flashbots Protect, MEV Blocker) und Batch-Auktions-Venues — sowie dem Bewusstsein, dass L2-Sicherheit derzeit eine Vertrauensannahme gegenüber dem Sequencer ist, kein Naturgesetz.

Der Beitrag Atomare Arbitrage und Flash-Loans nimmt die Seite des Searchers in dieser Gleichung ein — wie die gutartige Extraktion aufgebaut wird, mit geliehenem Kapital und atomaren Rollbacks als Sicherheitsnetz. Der Beitrag Konzentrierte Liquidität in Uniswap v3 greift die obige Constant-Product-Mathematik erneut auf und zeigt, wie konzentrierte Liquidität die Preiswirkungskurve — und damit das hier hergeleitete Sandwich-Budget — umgestaltet. Der Mempool ist ein dunkler Wald. Jetzt weißt du, was darin jagt.

Referenzen

  • Daian, Goldfeder, Kell, Li, Zhao, Bentov, Breidenbach, Juels (2019), Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges. arXiv:1904.05234.
  • Robinson & Konstantopoulos (2020), Ethereum is a Dark Forest.
  • Flashbots-Dokumentation: MEV-Boost, MEV-Share, Flashbots Protect, MEV-Rückerstattungen (docs.flashbots.net).
  • Ethereum PBS / EIP-7732 (verankerte Proposer-Builder-Separation), Materialien zum Glamsterdam-Upgrade.
  • MEV Blocker (mevblocker.io); Batch-Auktions-Design von CoW Protocol.
  • Private MEV Protection RPCs: A Benchmark Study (arXiv:2505.19708, 2025).
blog.disclaimer

Authors

Eugen Soloviov
Eugen Soloviov

Trading-systems engineer

Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.

Newsletter

Dem Markt einen Schritt voraus

Abonniere unseren Newsletter für exklusive KI-Trading-Einblicke, Marktanalysen und Plattform-Updates.

Wir respektieren deine Privatsphäre. Jederzeit abbestellbar.