Order-Flow-Auktionen und erste Gegenmaßnahmen

Von monolithischen Proposern zu modularen Buildern

Bisher hatten Block-Proposer – Miner im Proof-of-Work oder Validator:innen im Proof-of-Stake – stets die vollständige Kontrolle darüber, welche Transaktionen ein Block enthält und in welcher Reihenfolge sie einsortiert werden. Diese Machtposition verschaffte ihnen erhebliche Vorteile, denn sie konnten MEV (Maximal Extractable Value) entweder selbst extrahieren oder das Recht dazu an Dritte abtreten. Mit dem Ethereum-Merge und dem Wechsel zu Proof-of-Stake entstand eine neue Möglichkeit: die Entkopplung von Block-Proposer und Block-Builder.

Flashbots brachte dieses Prinzip mit MEV-Boost in die Praxis – einer Middleware, die Validator:innen erlaubt, das Erstellen von Blöcken an einen offenen Markt von Buildern auszulagern. Statt selbst Blöcke zu konstruieren, erhalten Validator:innen nun vorgefertigte Blöcke von konkurrierenden Buildern und wählen den mit dem höchsten Gebot aus. Das System motiviert Builder, um Orderflow zu konkurrieren, indem sie möglichst wertvolle Blöcke bauen und die Belohnung mit den Validator:innen teilen.

Diese Trennung ermöglichte eine stärker modulare Konsensarchitektur. Sie verringerte die Monopolstellung der Validator:innen bei der Transaktionsreihenfolge und öffnete den Blockproduktionsprozess für neue Teilnehmer wie Searcher, Builder und Relays. Außerdem führte sie zu mehr Transparenz bei der MEV-Extraktion und förderte eine Standardisierung ethischer Verhaltensweisen.

Die Rolle von Searchern, Buildern und Relays

Durch MEV-Boost erhielt die MEV-Wertschöpfungskette eine deutlichere Struktur. An der Basis stehen Searcher: Sie sind darauf spezialisiert, den Mempool nach MEV-Chancen zu durchforsten und daraus Transaktionsbündel zu erstellen. Diese Bundles reichen sie an Builder weiter, die sie zusammen mit üblichen Nutzer:innen-Transaktionen und durch Polsterungsstrategien zu möglichst profitablen Blöcken aggregieren. Builder senden ihre fertigen Blöcke dann über Relays an die Validator:innen.

Relays übernehmen die Funktion von Vermittlern, indem sie prüfen, ob Blöcke den Protokollregeln entsprechen und dass zugesicherte Zahlungen an die Validator:innen tatsächlich erfolgen. Sie bilden eine zentrale Vertrauensinstanz – insbesondere wenn Builder ihren Zahlungsverpflichtungen nicht nachkommen. Jedoch entsteht durch die geringe Zahl großer Relays auch das Risiko einer Zentralisierung, da nur wenige Akteure einen Großteil der Validator:innen abdecken.

Diese Lieferkette ermöglichte mehr Transparenz und Spezialisierung, offenbarte jedoch zugleich neue Engpässe und Vertrauensabhängigkeiten. Builder erhielten mehr Einfluss darüber, welche Bundles der Searcher tatsächlich in einen Block kamen. Relays konnten Blöcke zensieren oder ausfallen. Validator:innen, obwohl sie nicht mehr direkt MEV extrahieren, bleiben motiviert, mit bestimmten Buildern für verlässliche Einnahmen zu kooperieren. Zusammenfassend zeigt sich: MEV-Boost entschärft einige Probleme, löst sie aber nicht grundlegend – es findet lediglich eine Verschiebung der Macht statt.

Die Grenzen von MEV-Boost und privatem Orderflow

MEV-Boost bewies, dass wettbewerbliches Block-Building die Zentralisierung unter Validator:innen reduzieren kann – schuf aber zugleich neue Herausforderungen. Builder begannen, ihre Marktanteile zu bündeln, sodass an die Stelle der Validator:innen-Dominanz nun eine Dominanz der Builder trat. Einige Builder erhielten konstant den Zuschlag für die profitabelsten Blöcke, während andere das Nachsehen hatten – die angestrebte Dezentralisierung blieb somit Theorie.

Außerdem nutzte MEV-Boost weiterhin den öffentlichen Mempool, wodurch die meisten Nutzer:innen-Transaktionen vor der Blockaufnahme einsichtig und damit gefährdet blieben. Einige Nutzer:innen und Protokolle suchten daher nach privaten Einreichungsmethoden. Projekte wie Eden Network und Taichi etablierten geschützte Transaktionspfade, die den öffentlichen Mempool umgehen und Transaktionen direkt an Builder oder Validator:innen leiten.

Diese Schutzmechanismen erfordern jedoch Kompromisse: Sie mindern zwar das Risiko durch Frontrunning- und Sandwich-Angriffe, verlangen aber Vertrauen in zentrale Betreiber und erheben oft Schutzgebühren. Hinzu kommt, dass die Komponierbarkeit verloren geht – privat eingereichte Transaktionen können nicht mehr zuverlässig mit öffentlichen Mempool-Transaktionen interagieren. Letztlich bieten solche Lösungen Nutzer:innen Schutz, aber dies geschieht auf Kosten von Transparenz und Koordination auf Protokollebene.

Private Mempools, wie sie Shutter Network oder Gnosis Chain entwickeln, gehen noch einen Schritt weiter und verschlüsseln Transaktionen bis zur Blockaufnahme. Dadurch wird die Sichtbarkeit verzögert, was MEV-Möglichkeiten reduziert, aber auch eine komplexe Abstimmung und höhere Latenz mit sich bringt. Verschlüsselte Mempools beeinträchtigen zudem Anwendungen wie Arbitrage-Bots oder Portfolio-Manager, die auf Echtzeitdaten angewiesen sind.

Der Aufstieg von Orderflow-Auktionen (OFAs)

Mit dem Aufkommen von Orderflow-Auktionen (OFAs) entstand ein vielversprechenderer Ansatz. In diesem Modell senden Nutzer:innen ihre Transaktionen nicht mehr einfach in den Mempool oder an private Endpunkte. Stattdessen verkaufen Nutzer:innen – oder Wallets in ihrem Namen – das Recht, ihre Transaktion einzuschließen, über eine Auktion. Builder oder sogenannte Solver konkurrieren darum, dieses Recht zu ersteigern, und die Nutzer:innen erhalten einen Anteil am MEV, der ansonsten auf Kosten der Nutzer:innen abgeschöpft worden wäre.

Dieser Ansatz stellt einen Paradigmenwechsel dar: von der MEV-Extraktion zur MEV-Teilung. Er erkennt an, dass Nutzer:innen-Transaktionen einen Wert haben, der fair vergütet werden sollte. Projekte wie CowSwap und MEV-Share (ein Prototyp von Flashbots) erlauben es, Transaktionsabsichten zu äußern und im Gegenzug ein Angebot oder einen Rabatt zu erhalten. Die Mechanik basiert auf vertrauensfreien Ausführungsumgebungen, kryptografischen Commitments und versteckten Gebotsauktionen, wodurch Frontrunning verhindert wird.

Orderflow-Auktionen schaffen zudem einen programmierbaren Markt für die Aufnahme von Transaktionen. Statt zentraler Schutzmechanismen gibt es eine offene und transparente Möglichkeit, Transaktionen einzureichen und faire Ausführung zu erhalten. Der Wettbewerb zwischen Solvern und Buildern wird gefördert, und die Interessen von Nutzer:innen und Infrastrukturbetreiber:innen werden stärker aufeinander abgestimmt.

OFAs stehen allerdings noch am Anfang. Für breite Akzeptanz sind Wallet-Integrationen, Standardisierung über verschiedene Chains und eine robuste Kryptographie erforderlich. Zudem müssen Nutzer:innen die Vorteile des Orderflow-Verkaufs verstehen, und Protokolle müssen in der Lage sein, Transaktionen sicher durch Auktionsschichten zu leiten, ohne bestehende Funktionen zu beeinträchtigen.

Warum diese Maßnahmen nicht ausreichen

Trotz deutlicher Fortschritte reichen frühe Tools zur MEV-Abschwächung und OFAs nicht aus, um vollständigen Schutz vor MEV zu bieten. MEV-Boost adressiert einen Teilaspekt, belässt jedoch viele Angriffsflächen. Private Transaktionen bieten punktuellen Schutz, sind aber weder skalierbar noch universell verfügbar. Orderflow-Auktionen sind zwar zukunftsweisend, doch fragmentiert und noch nicht interoperabel.

Diesen Ansätzen fehlt eine einheitliche, dezentralisierte und programmierbare Infrastruktur, die als Ausführungsschicht für MEV-bewusste Anwendungen über verschiedene Blockchains hinweg dienen kann – ein System, das verschlüsselte Transaktionsweitergabe, faire Auktionsmechanismen und programmierbare Ausführungslogik vereint und dabei Komponierbarkeit, geringe Latenz und Nutzer:innenkontrolle aufrechterhält.

Aus dieser Einsicht heraus wurde SUAVE entwickelt – eine Architektur mit dem Ziel, die Orderflow-Schicht zu absorbieren, zu dezentralisieren und völlig neu zu gestalten. SUAVE setzt nicht bei der Symptombekämpfung an, sondern setzt bei der grundlegenden Infrastruktur an, die MEV überhaupt erst ermöglicht.