Maximal Extrahierbarer Wert (MEV) bezieht sich auf den Gewinn, den ein Blockchain-„Insider“ (Miner/Validator oder anderer privilegierter Akteur) erzielen kann, indem er Transaktionen in einem Block willkürlich neu anordnet, einschließt oder ausschließt. Eine unkontrollierte MEV-Extraktion kann zu unfairer Transaktionsreihenfolge, hohen Gebühren (durch Priority Gas Auctions) und einer Zentralisierung der Macht bei der Blockproduktion führen. Eine Reihe von Protokollen ist entstanden, um schädliche MEV zu unterdrücken oder eine faire Reihenfolge von Transaktionen durchzusetzen. Dieser Bericht vergleicht vier prominente Ansätze: Flashbots v2 (das Flashbots MEV-Boost-System nach dem Merge für Ethereum), SUAVE (Flashbots' bevorstehende Single Unifying Auction for Value Expression), Anoma (eine Intent-zentrierte Architektur, die die Art und Weise, wie Transaktionen abgeglichen und geordnet werden, neu überdenkt) und Skip Protocol (ein Cosmos-basiertes Toolkit für souveränes In-Protocol-MEV-Management). Wir untersuchen jedes dieser Protokolle hinsichtlich ihrer Transaktionswarteschlangen-/Reihenfolge-Algorithmen, MEV-Minderungs- oder Extraktionsmechanismen, Anreizmodelle, Compliance- und Neutralitätsfunktionen, technischen Architektur (Konsens und Kryptographie) und des Entwicklungsfortschritts. Strukturierte Zusammenfassungen und eine Vergleichstabelle werden bereitgestellt, um ihre Stärken und Kompromisse bei der Verfolgung von Fairness und der Reduzierung der negativen Externalitäten von MEV hervorzuheben.

Flashbots v2 (MEV-Boost & BuilderNet auf Ethereum)​

Flashbots v2 bezeichnet das aktuelle Flashbots-Ökosystem auf Ethereum nach Proof-of-Stake, das sich um MEV-Boost und jüngste Initiativen wie BuilderNet dreht. Flashbots v2 baut auf dem Proposer/Builder-Separation (PBS)-Paradigma auf, um die Blockkonstruktion einem wettbewerbsorientierten Markt von Buildern zu öffnen und gleichzeitig Ethereum-Nutzer vor öffentlichen Mempool-MEV-Angriffen zu schützen.

• Transaktionsreihenfolge (Warteschlange & Algorithmus): Flashbots MEV-Boost führt einen Off-Chain-Marktplatz für die Blockerstellung ein. Validatoren (Proposer) lagern die Blockkonstruktion über ein Relay an spezialisierte Builder aus, anstatt Transaktionen lokal zu ordnen. Mehrere Builder konkurrieren darum, den höchstbezahlten Block bereitzustellen, und der Validator signiert blind den Header des Blocks mit dem höchsten Gebot (ein PBS-Ansatz). Dieses Design ersetzt effektiv die First-Come, First-Served-Reihenfolge des öffentlichen Mempools durch eine Sealed-Bid-Auktion für ganze Blöcke. Builder bestimmen die Transaktionsreihenfolge intern, um die Gesamtgewinne (einschließlich MEV-Möglichkeiten) zu maximieren, wobei sie typischerweise Bundles mit profitablen Arbitragen oder Liquidationen an den Anfang des Blocks stellen. Durch die Verwendung von MEV-Boost vermied Ethereum die chaotischen Priority Gas Auctions (PGAs), die zuvor die Reihenfolge bestimmten; anstatt dass Nutzer und Bots in Echtzeit über Gasgebühren bieten (was die Überlastung erhöht), zentralisiert MEV-Boost die Reihenfolge pro Block auf den wettbewerbsfähigsten Builder. Transaktionswarteschlangen werden somit privat von Buildern verwaltet, die eingehende Bundles oder Transaktionen sehen und sie für optimalen Gewinn anordnen können. Ein Nachteil ist, dass diese gewinnorientierte Reihenfolge nicht von Natur aus „Fairness“ für Nutzer durchsetzt – z.B. können Builder immer noch toxische Orderflows wie Sandwich-Angriffe einschließen, wenn sie profitabel sind – aber sie optimiert die Effizienz, indem sie MEV durch eine kontrollierte Auktion statt durch Ad-hoc-Gas-Kriege extrahiert. Jüngste Entwicklungen zielen darauf ab, die Reihenfolge neutraler zu gestalten: Zum Beispiel ermöglicht Flashbots' neues BuilderNet (Ende 2024 gestartet), dass mehrere zusammenarbeitende Builder Orderflow teilen und Blöcke gemeinsam in einer Trusted Execution Environment konstruieren, wodurch verifizierbare Reihenfolgeregeln eingeführt werden, um die Fairness zu verbessern. Dies verlagert die Blockreihenfolge von einem einzigen zentralisierten Builder hin zu einem dezentralen Block-Building-Netzwerk mit Regeln, die auf Neutralität geprüft werden können.

• MEV-Unterdrückungs- vs. Extraktionsmechanismen: Flashbots v2 erleichtert in erster Linie die MEV-Extraktion in einer gutartigen Form, anstatt sie zu eliminieren. Das ursprüngliche Flashbots (v1)-System im Jahr 2021 ermöglichte es Searchern, Bundles (bevorzugte Transaktionssätze) direkt an Miner zu senden, was schädliche Externalitäten unterdrückte (kein öffentliches Frontrunning, keine fehlgeschlagenen Transaktionen aufgrund von Wettrennen), während MEV weiterhin extrahiert wurde. In der MEV-Boost-Ära wird MEV von Buildern extrahiert, die profitable Transaktionen bündeln, aber der Negativsummen-Wettbewerb wird reduziert: Searcher spammen den Mempool nicht mehr mit konkurrierenden Transaktionen und exorbitanten Gasgebühren, was Netzwerküberlastung und übermäßige Gebühren für Nutzer mindert. Flashbots v2 bietet auch MEV-Minderungstools für Nutzer: Zum Beispiel ermöglicht Flashbots Protect RPC Nutzern, Transaktionen privat an ein Relay zu senden, wodurch öffentliches Mempool-Frontrunning verhindert wird (niemand kann die Transaktion vor der Aufnahme sehen oder neu anordnen). Eine weitere Initiative, MEV-Share, lässt Nutzer gerade genug Informationen über ihre Transaktionen teilen, um MEV-Gebote anzuziehen, während sie einen Teil des Wertes für sich selbst erfassen. Flashbots v2 „verhindert“ jedoch keine MEV wie Sandwiches oder Arbitrage – es kanalisiert diese Aktivitäten durch eine effiziente Auktion, die wohl demokratisiert, wer die MEV extrahieren kann. Jüngst hat das Design von BuilderNet das explizite Ziel, „Negativsummen-Orderflow-Spiele zu neutralisieren“ und MEV über On-Chain-Rückerstattungsregeln an die Community zurückzugeben. BuilderNet berechnet Rückerstattungen, die an Orderflow-Anbieter (wie Wallets oder DApps) proportional zur MEV gezahlt werden, die ihre Transaktionen generiert haben, wodurch Wert umverteilt wird, der sonst reiner Gewinn für Builder wäre. Zusammenfassend maximiert Flashbots v2 die Effizienz der MEV-Extraktion (stellt sicher, dass fast der gesamte extrahierbare Wert in einem Block tatsächlich erfasst wird), während es Maßnahmen einführt, um die schlimmsten Externalitäten einzudämmen und einen Teil des Wertes an die Nutzer zurückzugeben. Es geht nicht so weit, eine faire Reihenfolge durchzusetzen (Transaktionen werden immer noch nach Builder-Gewinn geordnet), aber durch private Einreichung, Multi-Party-Building und Rückerstattungen unterdrückt es den negativen Nutzerschaden (wie Front-Run-Slippage und Zensureffekte) so weit wie möglich innerhalb des Auktionsmodells.

• Ökonomische Anreizstruktur: Flashbots v2 gleicht die Anreize zwischen Validatoren, Buildern und Searchern durch die PBS-Auktion ab. Validatoren profitieren von der Auslagerung der Blockproduktion – sie akzeptieren einfach das höchste Gebot und erhalten den Gebotsbetrag (zusätzlich zu den Konsensbelohnungen), was den Anteil der MEV, der an Validatoren geht, dramatisch erhöhte im Vergleich zu der Ära, in der Miner keine solchen Auktionen hatten. Builder werden dazu angeregt, sich gegenseitig zu überbieten, indem sie die profitabelste Reihenfolge von Transaktionen finden (oft unter Einbeziehung von Searcher-Strategien), und sie behalten jeden MEV-Gewinn, der nach Zahlung des Validator-Gebots übrig bleibt. In der Praxis zwingt der Wettbewerb Builder dazu, den größten Teil der MEV an Validatoren zu zahlen (oft >90% des Gewinns), wobei sie nur eine geringe Marge behalten. Searcher (die jetzt über Bundles oder direkte Transaktionen mit Buildern interagieren) verdienen immer noch, indem sie MEV-Möglichkeiten (Arbitrage, Liquidation usw.) entdecken, aber sie müssen den größten Teil ihres Gewinns bieten, um die Aufnahme zu gewinnen – effektiv werden Searcher-Gewinne über Builder-Gebote an Validatoren übertragen. Dieses Wettbewerbsgleichgewicht maximiert den gesamten Netzwerkumsatz (was Validatoren/Stakern zugutekommt), drückt aber die individuellen Searcher-Margen. Flashbots v2 entmutigt somit exklusive Deals: Jeder Searcher oder Builder mit einer privaten MEV-Strategie wird dazu angeregt, diese über das offene Relay zu bieten, um nicht unterboten zu werden, was zu einem offeneren Markt führt. Die Einführung von BuilderNet fügt einen Anreiz für Orderflow-Originatoren (wie DEXs oder Wallets) hinzu – indem sie ihnen Rückerstattungen für die MEV geben, die ihre Transaktionen erzeugen, ermutigt es Nutzer und Apps, Orderflow an das BuilderNet-Ökosystem zu senden. Dieser Mechanismus bringt Nutzer mit dem System in Einklang: Anstatt antagonistisch zu sein (Nutzer vs. MEV-Extraktoren), teilen Nutzer an der MEV, sodass sie eher bereit sind, fair an der Auktion teilzunehmen. Insgesamt begünstigt die Ökonomie von Flashbots v2 die Zusammenarbeit gegenüber dem Wettbewerb beim Block-Building: Validatoren erhalten maximale Einnahmen risikofrei, Builder konkurrieren um die Ausführungsqualität, und Searcher innovieren, um MEV zu finden, geben aber die meisten Gewinne ab, um Gebote zu gewinnen, während Nutzer Schutz und möglicherweise Rabatte erhalten.

• Compliance und Zensurresistenz: Die Einhaltung gesetzlicher Vorschriften wurde nach dem Ethereum Merge zu einem strittigen Thema für Flashbots. Das Standard-Flashbots-Relay implementierte zunächst die OFAC-Sanktions-Compliance (Zensur bestimmter Transaktionen wie Tornado Cash) – was Ende 2022 dazu führte, dass ~80% der Ethereum-Blöcke „OFAC-konform“ waren und Bedenken hinsichtlich Zentralisierung/Zensur in der Community aufkommen ließ. Flashbots v2 begegnete dem, indem es ein Multi-Relay-Ökosystem förderte, in dem Validatoren nicht-zensierende Relays (z.B. UltraSound, Agnostic) wählen oder sogar ihre eigenen betreiben können. Flashbots hat seinen Relay-Code Mitte 2022 quelloffen gemacht, um globalen Relay-Wettbewerb und Transparenz zu fördern. Zusätzlich führte MEV-Boost v1.4 Funktionen wie eine Mindestgebots-Einstellung ein, damit Proposer niedrige Gebote von zensierenden Buildern ablehnen und auf lokale Blöcke zurückgreifen konnten, wobei sie etwas Gewinn für die Aufnahme aller Transaktionen opferten. Diese Funktion gab Validatoren explizit eine Möglichkeit, die Zensurresistenz von Ethereum zu geringen Kosten zu verbessern. Ende 2024 ging Flashbots einen weiteren Schritt, indem es seinen eigenen zentralisierten Builder einstellte zugunsten von BuilderNet – einem kollaborativen Netzwerk, das „unzensierbar und neutral“ sein soll. BuilderNet verwendet TEEs (Intel SGX), um den Transaktions-Orderflow verschlüsselt zu halten und sich verifizierbar an eine Reihenfolgeregel zu binden, was dazu beitragen kann, dass einzelne Builder bestimmte Transaktionen nicht zensieren. Mit mehreren Teilnehmern, die gemeinsam Blöcke in sicheren Enklaven bauen, kann keine einzelne Partei eine Transaktion ohne Entdeckung leicht ausschließen. Kurz gesagt, Flashbots v2 hat sich von einem einzelnen (und anfänglich zensierenden) Relay zu einer dezentraleren Infrastruktur mit offener Beteiligung und expliziten Neutralitätszielen entwickelt. Die Compliance wird den Richtlinien der einzelnen Relays/Builder überlassen (und Validatoren können wählen), anstatt vom Protokoll durchgesetzt zu werden. Die Entwicklung geht in Richtung glaubwürdiger Neutralität: die Beseitigung aller von Flashbots kontrollierten Engpässe, die von Regulierungsbehörden unter Druck gesetzt werden könnten. Flashbots hat sich öffentlich dazu verpflichtet, sich als zentraler Betreiber zurückzuziehen und alle Aspekte der MEV-Lieferkette langfristig zu dezentralisieren.

• Technische Architektur & Kryptographie: Flashbots v2 arbeitet Off-Chain und In-Protocol hybrid. Die Kernauktion (MEV-Boost) findet Off-Chain über das Builder- und Relay-Netzwerk statt, ist aber direkt in Ethereums Konsens integriert: Validatoren betreiben einen Sidecar-Client (mev-boost), der über die standardisierte Builder API mit Relays kommuniziert. Konsens-technisch verwendet Ethereum immer noch Standard-PoS (Casper/Hotstuff) – MEV-Boost ändert die L1-Konsensregeln nicht; es ändert nur, wer den Block zusammensetzt. Anfangs erforderte die Flashbots-Auktion Vertrauen in das Relay und den Builder, dass sie Transaktionen nicht stehlen oder zensieren – es gab keine kryptographischen Garantien (das System verließ sich auf den wirtschaftlichen Anreiz, dass Builder eine gültige Payload liefern müssen, die ihrem Gebot entspricht, sonst verlieren sie den Slot). Im Laufe der Zeit hat Flashbots v2 mehr Sicherheitstechnologie integriert. Die Einführung von Trusted Execution Environments (TEE) über BuilderNet ist eine bemerkenswerte architektonische Verschiebung: Builder laufen innerhalb von SGX-Enklaven, sodass selbst der Builder-Betreiber den rohen Transaktions-Orderflow nicht sehen kann (was verhindert, dass sie ihn leaken oder frontrunnen). Diese Enklaven folgen gemeinsam einem Protokoll, um Blöcke zu produzieren, was verifizierbare Fairness ermöglichen kann (z.B. den Nachweis, dass Transaktionen nach einer festgelegten Regel geordnet wurden oder dass keine unbefugte Entität sie vor der Aufnahme gesehen hat). Während SGX verwendet wird (ein hardwarebasierter Ansatz), erforscht Flashbots auch rein kryptographische Primitive – z.B. Schwellenwertverschlüsselung für Mempool-Privatsphäre und sichere Mehrparteienberechnung – um TEEs schließlich zu ersetzen oder zu ergänzen und das Vertrauen weiter zu reduzieren. Der Software-Stack von Flashbots v2 umfasst benutzerdefinierte Clients wie MEV-geth (jetzt obsolet) und Rust-basierte Builder (z.B. rbuilder), und er hält sich an Ethereums Builder-Spezifikationen für Interoperabilität. Zusammenfassend ist die Architektur modular: ein Netzwerk von Relays, Buildern und jetzt Enklaven, das zwischen Nutzern und Ethereum-Proposern sitzt. Es priorisiert Leistung (schnelles Bieten, Blocklieferung) und fügt schrittweise kryptographische Zusicherungen von Privatsphäre und fairer Reihenfolge hinzu. Es wird kein neuer Konsensalgorithmus eingeführt; stattdessen arbeitet Flashbots v2 neben Ethereums Konsens und entwickelt die Blockproduktionspipeline weiter, anstatt die Konsensregeln zu ändern.

• Entwicklungs-Roadmap & Meilensteine: Flashbots hat iterative Phasen durchlaufen. Flashbots v1 (2020–2021) umfasste den Start von MEV-geth und die ersten Off-Chain-Bundle-Auktionen mit Minern. Mitte 2021 liefen über 80% der Ethereum-Hashrate mit Flashbots' MEV-geth, was die Akzeptanz des Ansatzes bestätigte. Flashbots v2 (2022) wurde im Vorfeld des Merge konzipiert: Im November 2021 veröffentlichte Flashbots die MEV-Boost-Architektur für PoS Ethereum. Nachdem Ethereum auf PoS umgestellt hatte (15. September 2022), wurde MEV-Boost innerhalb weniger Tage aktiviert und erreichte schnell eine Mehrheitsbeteiligung der Validatoren. Spätere Meilensteine umfassten die Quelloffenlegung des Relays (August 2022) und des internen Block-Builders von Flashbots (November 2022), um den Wettbewerb anzukurbeln. Ende 2022 fügte Flashbots auch Funktionen hinzu, die sich auf Zensurresistenz und Resilienz konzentrierten (z.B. Min-Bid für Proposer) und schrieb über die „Kosten der Resilienz“, um Validatoren zu ermutigen, manchmal die Aufnahme über den Gewinn zu stellen. Im Laufe des Jahres 2023 wurde die Verbesserung der Builder-Dezentralisierung zu einem Schwerpunkt: Flashbots veröffentlichte „rbuilder“ (einen Hochleistungs-Rust-Builder) im Juli 2024 als Referenzimplementierung, um die Hürde für neue Builder zu senken. Schließlich startete Flashbots Ende 2024 BuilderNet (Alpha) in Zusammenarbeit mit Partnern (Beaverbuild, Nethermind). Bis Dezember 2024 schaltete Flashbots seinen zentralisierten Builder ab und migrierte den gesamten Orderflow zu BuilderNet – ein bedeutender Schritt in Richtung Dezentralisierung. Anfang 2025 wurde BuilderNet v1.2 mit Sicherheits- und Onboarding-Verbesserungen (einschließlich reproduzierbarer Enklaven-Builds) veröffentlicht. Diese Meilensteine markieren den Übergang von Flashbots von einer zweckmäßigen zentralisierten Lösung zu einem offeneren, von der Community betriebenen Protokoll. Mit Blick auf die Zukunft konvergiert Flashbots mit seiner Vision der nächsten Generation (SUAVE), um die Block-Building-Schicht vollständig zu dezentralisieren und fortschrittliche Datenschutztechnologien zu integrieren. Viele Lehren aus Flashbots v2 (z.B. die Notwendigkeit von Neutralität, Multi-Chain-Umfang und Nutzer-Einbeziehung von MEV-Belohnungen) fließen direkt in die SUAVE-Roadmap ein.

SUAVE (Flashbots’ Single Unifying Auction for Value Expression)​

SUAVE ist Flashbots' ehrgeiziges nächstes Protokoll, das als dezentraler, domänenübergreifender MEV-Marktplatz und faire Transaktionssequenzierungsschicht konzipiert ist. Es zielt darauf ab, Mempools und Block-Building von einzelnen Blockchains zu entkoppeln und eine einheitliche Plattform bereitzustellen, auf der Nutzer Präferenzen äußern, ein dezentrales Netzwerk Transaktionen optimal ausführt und Block-Builder Blöcke über viele Chains hinweg auf glaubwürdig neutrale Weise produzieren. Kurz gesagt, SUAVE versucht, die gesamte Wertschöpfung zu maximieren, während es den Nutzern Wert zurückgibt und die Dezentralisierung der Blockchain bewahrt. Flashbots stellte SUAVE Ende 2022 als „die Zukunft von MEV“ vor und entwickelt es seitdem offen.

• Warteschlange und Transaktionsreihenfolge: Aus übergeordneter Sicht fungiert SUAVE als ein unabhängiges Blockchain-Netzwerk, das andere Chains als Plug-and-Play-Mempool und Block-Builder nutzen können. Anstatt dass Transaktionen in den Mempools jeder Chain in die Warteschlange gestellt und von lokalen Minern oder Validatoren geordnet werden, können Nutzer ihre Transaktionen (oder allgemeiner, Präferenzen) in den Mempool des SUAVE-Netzwerks senden. Der SUAVE-Mempool dient dann als globaler Auktionspool von Präferenzen aller teilnehmenden Chains. Die Reihenfolge der Transaktionen wird durch diese Auktion und die anschließende Ausführungsoptimierung bestimmt. Insbesondere führt SUAVE ein Konzept von Präferenzen ein: Die Einreichung eines Nutzers ist nicht nur eine rohe Transaktion für eine Chain, sondern kann ein Ziel oder einen bedingten Handel (möglicherweise über mehrere Chains hinweg) und ein damit verbundenes Gebot kodieren, das der Nutzer für die Erfüllung zu zahlen bereit ist. Der Reihenfolge-/Warteschlangenalgorithmus in SUAVE hat mehrere Stufen: Zuerst posten Nutzer ihre Präferenzen in den SUAVE-Mempool (die „Universal Preference Environment“), der alle Aufträge privat und global aggregiert. Als Nächstes überwachen spezialisierte Knoten, sogenannte Executors (analog zu Searchern/Solvern), diesen Mempool und konkurrieren in einem Optimal Execution Market, um diese Präferenzen zu erfüllen. Sie „reihen“ Transaktionen effektiv ein, indem sie Übereinstimmungen oder optimale Ausführungsreihenfolgen für sie finden. Schließlich produziert SUAVE Block-Outputs für jede verbundene Chain über eine Decentralized Block Building-Schicht: Viele Builder (oder SUAVE-Executors, die als Builder fungieren) arbeiten zusammen, um Blöcke unter Verwendung der (jetzt optimierten) Transaktionsreihenfolge zu konstruieren, die aus den Nutzerpräferenzen abgeleitet wurde. In praktischer Hinsicht ist die Reihenfolge von SUAVE flexibel und nutzergesteuert: Ein Nutzer kann Bedingungen wie „führe meinen Handel nur aus, wenn der Preis < X“ angeben oder sogar eine abstrakte Absicht („tausche Token A gegen B zum besten Kurs innerhalb von 1 Minute“) anstelle einer strengen Transaktion ausdrücken. Das System reiht diese Absichten in die Warteschlange ein, bis ein Executor eine optimale Reihenfolge oder Übereinstimmung findet (möglicherweise durch Batching mit anderen). Da SUAVE Blockchain-agnostisch ist, kann es die Reihenfolge über Chains hinweg koordinieren (wodurch Szenarien verhindert werden, in denen Cross-Chain-Arbitragen aufgrund unkoordinierter separater Mempools verpasst werden). Im Wesentlichen implementiert SUAVE eine globale MEV-Auktion: Alle Teilnehmer teilen sich eine Sequenzierungsschicht, die Transaktionen basierend auf aggregierten Präferenzen und Geboten ordnet, anstatt nach einfacher Zeit oder Gaspreis. Dies hat den Effekt, das Spielfeld zu ebnen – der gesamte Orderflow läuft durch eine transparente Warteschlange (wenn auch zur Wahrung der Privatsphäre verschlüsselt, wie unten erläutert) anstatt durch exklusive Deals oder private Mempools. Der Reihenfolgealgorithmus von SUAVE wird noch verfeinert, aber er wird wahrscheinlich datenschutzfreundliche Batch-Auktionen und Matching-Algorithmen umfassen, damit „faire“ Ergebnisse (wie maximaler Gesamtüberschuss oder nutzeroptimale Preise) erzielt werden können, anstatt reiner First-Come-First-Served. Insbesondere beabsichtigt SUAVE, zu verhindern, dass ein einzelner Akteur die Reihenfolge manipuliert: Es ist Ethereum-nativ und MEV-aware, mit einem datenschutzfreundlichen verschlüsselten Mempool, der vor zentralen Kontrollpunkten schützt. Zusammenfassend ist die Warteschlange von SUAVE ein einheitlicher Orderflow-Pool, in dem die Reihenfolge durch eine Kombination aus Nutzergeboten, Executor-Strategie und (eventuell) kryptographischen Fairness-Einschränkungen bestimmt wird, anstatt durch Block-Proposer, die um Priorität wetteifern.

• MEV-Unterdrückungs-/Extraktionsmechanismen: Die Philosophie von SUAVE besagt, dass MEV zum Nutzen der Nutzer und zur Netzwerksicherheit genutzt werden kann, wenn dies kooperativ und dezentral erfolgt. Anstatt MEV entweder zu ignorieren oder sich in wenigen Händen konzentrieren zu lassen, zeigt SUAVE explizit MEV-Möglichkeiten auf und gibt den Wert so weit wie möglich an diejenigen zurück, die ihn schaffen (Nutzer). Der primäre Mechanismus ist die Orderflow-Auktion: Wann immer die Transaktion (Präferenz) eines Nutzers MEV enthält – zum Beispiel könnte sie gewinnbringend backrunnt werden – führt SUAVE eine Auktion unter Executors (Searchern) für das Recht durch, diese MEV-Möglichkeit auszuführen. Searcher (Executors) bieten, indem sie einen Teil des Gewinns als Zahlung an den Nutzer zurückversprechen (dies ist das „Gebot“-Feld des Nutzers in seiner Präferenz, das an denjenigen geht, der es erfüllt). Das Ergebnis ist eine wettbewerbsorientierte MEV-Extraktion, die Einnahmen an den Nutzer statt an den Extraktor weiterleitet. Wenn beispielsweise ein großer DEX-Handel eines Nutzers eine Arbitrage-Möglichkeit von 100 $schafft, könnten Searcher auf SUAVE den Gewinn drücken, indem sie dem Nutzer beispielsweise 90$ als Rabatt anbieten und nur 10 $ behalten. Dies unterdrückt die negativen Aspekte von MEV wie die Wertentnahme durch den Nutzer und verwandelt MEV in einen Nutzen für den Nutzer (Nutzer erhalten effektiv eine Preisverbesserung oder Rabatte). Das Design von SUAVE unterdrückt auch Front-Running und andere bösartige MEV: Transaktionen im SUAVE-Mempool können verschlüsselt bleiben, bis ein Block gebaut wird (anfangs mit SGX-Enklaven, später mit Schwellenwert-Kryptographie). Das bedeutet, dass kein externer Akteur ausstehende Transaktionen sehen kann, um sie zu frontrunnen; erst wenn genügend Transaktionen gesammelt und ein Block finalisiert ist, werden sie entschlüsselt und ausgeführt, ähnlich wie bei Batch-Auktionen oder verschlüsselten Mempools, die den Zeitprioritätsvorteil von Bots beseitigen. Da Executors die Ausführung über viele Präferenzen hinweg optimieren, kann SUAVE außerdem ineffizienten Wettbewerb eliminieren (wie zwei Bots, die um dieselbe Arbitrage kämpfen, indem sie spammen). Stattdessen wählt SUAVE den besten Executor durch die Auktion aus, und dieser Executor führt den Handel einmal aus, wobei das Ergebnis dem Nutzer und dem Netzwerk zugutekommt. SUAVE fungiert somit als MEV-Aggregator und „gute Fee“: Es eliminiert MEV nicht (die profitablen Möglichkeiten werden immer noch genutzt), aber diese Möglichkeiten werden unter transparenten Regeln und mit Erlösen, die größtenteils an Nutzer und Validatoren verteilt werden (und nicht für Gasgebühren oder Latenzkriege verschwendet werden), realisiert. Durch die Vereinheitlichung von Mempools adressiert SUAVE auch domänenübergreifende MEV auf nutzerfreundliche Weise – z.B. könnte eine Arbitrage zwischen Uniswap auf Ethereum und einem DEX auf Arbitrum von einem SUAVE-Executor erfasst und ein Teil an die Nutzer auf beiden Seiten gezahlt werden, anstatt verpasst zu werden oder einen zentralisierten Arbitrageur zu erfordern. Wichtig ist, dass SUAVE die zentralisierenden Kräfte von MEV unterdrückt: Exklusive Orderflow-Deals (bei denen private Entitäten MEV erfassen) werden unnötig, wenn alle die gemeinsame Auktion nutzen. Die ultimative Vision von SUAVE ist es, schädliche MEV-Extraktion zu reduzieren (wie Sandwich-Angriffe, die Slippage verursachen), indem sie entweder unrentabel gemacht oder die Slippage zurückerstattet wird, und „gute MEV“ (Arbitrage, Liquidationen) zur Stärkung von Netzwerken zu nutzen (durch Umsatzbeteiligung und optimale Ausführung). In Flashbots' eigenen Worten ist es das Ziel von SUAVE, sicherzustellen, dass „Nutzer mit der besten Ausführung und minimalen Gebühren handeln“, während „Validatoren maximale Einnahmen erzielen“ – d.h. jede vorhandene MEV wird auf die nutzerfreundlichste Weise extrahiert.

• Ökonomische Anreizstruktur: SUAVE führt neue Rollen und Anreizflüsse in der MEV-Lieferkette ein. Die Hauptteilnehmer sind Nutzer, Executors, Block-Builder/Validatoren und die SUAVE-Netzwerkbetreiber (Validatoren der SUAVE-Chain). Nutzer legen ein Gebot (Zahlung) in ihrer Präferenz fest, das ausgezahlt wird, wenn ihre Bedingungen erfüllt sind. Dieses Gebot ist der Anreiz für Executors: Ein Executor, der die Absicht des Nutzers erfüllt (z.B. seinen Handel backrunnt, um ihm einen besseren Preis zu verschaffen), kann das Gebot als Belohnung beanspruchen. Nutzer zahlen also direkt für Ausführungsqualität, ähnlich wie bei der Ausschreibung einer Belohnung. Executors (Searcher) sind motiviert, Nutzerpräferenzen aus dem SUAVE-Mempool aufzunehmen und zu optimieren, da sie das Gebot des Nutzers plus jeden zusätzlichen Arbitrage-Gewinn, der der Transaktion innewohnt, verdienen. Executors werden darum konkurrieren, dem Nutzer das beste Ergebnis zu bieten, da der Nutzer sein Gebot so festlegen kann, dass er nur zahlt, wenn der Executor tatsächlich das gewünschte Ergebnis erzielt (das Gebot kann über Orakel an On-Chain-Ergebnisse geknüpft sein). Zum Beispiel könnte ein Nutzer sagen: „Ich zahle 0,5 ETH an denjenigen, der diese Transaktion so ausführt, dass ich mindestens X Output erhalte; wenn nicht, keine Zahlung.“ Dies stimmt die Anreize der Executors mit dem Erfolg des Nutzers überein. SUAVE-Validatoren/Builder: Die SUAVE-Chain selbst wird wahrscheinlich ein Proof-of-Stake-Netzwerk sein (Design noch festzulegen), sodass Validatoren (die Blöcke auf SUAVE produzieren) Transaktionsgebühren auf SUAVE verdienen (die von Nutzern stammen, die Gebote posten und andere Operationen durchführen). Da SUAVE eine EVM-kompatible Chain ist, kann es auch ein natives Token- oder Gasgebührensystem für diese Transaktionen geben. Diese Validatoren spielen auch eine Rolle bei der Sequenzierung domänenübergreifender Blöcke; die endgültige Blockaufnahme auf jeder L1 erfolgt jedoch immer noch durch den Validator dieser L1. In vielen Fällen wird SUAVE eine partielle oder vollständige Blockvorlage produzieren, die ein Ethereum- oder anderer Chain-Proposer übernehmen kann. Dieser Builder könnte SUAVE (oder SUAVE-Executors) einen Teil der MEV zahlen. Flashbots hat erwähnt, dass SUAVE-Validatoren durch normale Netzwerkgebühren und Executors durch Gebote motiviert werden. Wertverteilung: Der Ansatz von SUAVE neigt dazu, Wert an die Ränder zu verschieben: Nutzer erfassen Wert (durch bessere Preise oder direkte Rückerstattungen), und Validatoren erfassen Wert (durch erhöhte Gebühren/Gebote). Theoretisch, wenn SUAVE seine Mission erfüllt, wird der größte Teil der MEV entweder an Nutzer zurückgegeben oder zur Entschädigung von Validatoren für die Sicherung des Netzwerks verwendet, anstatt sich bei Searchern zu konzentrieren. Flashbots selbst hat angedeutet, dass es nicht beabsichtigt, von SUAVE Rent-Seeking zu betreiben und keinen Anteil über das hinausnehmen wird, was zum Bootstrapping benötigt wird – sie wollen den Marktplatz gestalten, nicht monopolisieren. Eine weitere Anreizüberlegung sind Cross-Chain-Builder: SUAVE ermöglicht Block-Buildern den Zugriff auf domänenübergreifende MEV, was bedeutet, dass ein Builder auf einer Chain zusätzliche Gebühren verdienen kann, indem er Transaktionen einschließt, die Arbitrage mit einer anderen Chain abschließen. Dies ermutigt Builder/Validatoren verschiedener Chains, alle an SUAVE teilzunehmen, denn ein Verzicht bedeutet entgangene Einnahmen. Im Wesentlichen versucht das wirtschaftliche Design von SUAVE, alle Teilnehmer dazu zu bringen, der gemeinsamen Auktion beizutreten: Nutzer, weil sie eine bessere Ausführung erhalten (und vielleicht MEV-Rabatte), Validatoren, weil sie maximale Einnahmen erhalten, und Searcher, weil dort der Orderflow aggregiert wird. Durch die Konzentration des Orderflows erhält SUAVE auch einen Informationsvorteil gegenüber jedem isolierten Akteur (alle Präferenzen an einem Ort), was alle wirtschaftlich dazu zwingt, innerhalb von SUAVE zusammenzuarbeiten, anstatt sich abzuspalten. Zusammenfassend fördern die Anreize von SUAVE einen positiven Kreislauf: mehr Orderflow → bessere kombinierte MEV-Möglichkeiten → höhere Gebote an Nutzer/Validatoren → mehr Orderflow. Dies steht im Gegensatz zum Nullsummen-Wettbewerb und den exklusiven Deals der Vergangenheit und zielt stattdessen auf „Koopetition“ ab, bei der MEV ein gemeinsamer Wert ist, der wachsen und verteilt werden soll.

• Compliance und regulatorische Überlegungen: SUAVE wird mit glaubwürdiger Neutralität und Zensurresistenz als Kernprinzipien entwickelt. SUAVE entfernt per Design zentrale Vermittler – es gibt keinen einzigen Mempool oder einzigen Builder, der angegriffen oder reguliert werden könnte. Transaktionen (Präferenzen) in SUAVE können vollständig verschlüsselt und privat bleiben, bis sie ausgeführt werden, unter Verwendung sicherer Enklaven und schließlich kryptographischer Techniken. Das bedeutet, dass Zensur auf der Ebene des Transaktionsinhalts unpraktisch ist, da Validatoren/Builder die Transaktionsdetails vor der Finalisierung der Reihenfolge nicht einmal lesen können. SUAVE erzwingt im Wesentlichen einen „Don't trust, verify“-Ansatz: Teilnehmer müssen keiner Entität vertrauen, nicht zu zensieren, da die Systemarchitektur selbst (dezentrales Netzwerk + Verschlüsselung) sicherstellt, dass die Präferenzen aller fair berücksichtigt werden. Darüber hinaus soll SUAVE ein offenes, erlaubnisfreies Netzwerk sein – Flashbots lädt explizit alle Parteien (Nutzer, Searcher, Wallets, andere Blockchains) zur Teilnahme ein. Es gibt kein KYC oder eine Berechtigungsprüfung in seinem Design. Dies könnte Fragen bei Regulierungsbehörden aufwerfen (z.B. könnte das Protokoll die MEV-Extraktion bei sanktionierten Transaktionen erleichtern), aber da SUAVE nur eine dezentrale Plattform ist, wäre die Durchsetzung schwierig und vergleichbar mit dem Versuch, den Mempool einer Blockchain zu regulieren. Der Fokus von SUAVE auf Privatsphäre (durch SGX und später Kryptographie) schützt auch Nutzerdaten und Orderflow vor unerwünschter Überwachung, was positiv für die Nutzersicherheit ist, aber mit regulatorischen Wünschen nach Transparenz kollidieren könnte. Andererseits könnte der Ansatz von SUAVE als fairer und konformer mit dem Geist offener Märkte angesehen werden: Durch die Schaffung gleicher Wettbewerbsbedingungen und die Rückgabe von Wert an die Nutzer reduziert er die ausbeuterischen Aspekte von MEV, die regulatorischen Zorn hervorrufen könnten (wie das Backrunning von Nutzern ohne deren Zustimmung). SUAVE kann auch dazu beitragen, unregulierte Dark Pools zu eliminieren – ein Grund, warum Regulierungsbehörden wegen MEV besorgt sein könnten, sind exklusive Orderflow-Verkäufe (die Insiderhandel ähneln). SUAVE ersetzt diese durch eine transparente öffentliche Auktion, was wohl eine konformere Marktstruktur darstellt. In Bezug auf explizite Compliance-Funktionen könnte SUAVE mehrere Reihenfolge-Richtlinien zulassen: Zum Beispiel könnten Communities oder Jurisdiktionen ihre eigenen Executors mit bestimmten Filtern oder Präferenzen einsetzen. Der Grundsatz ist jedoch, dass SUAVE versuchen wird, maximal neutral zu sein: „alle zentralen Kontrollpunkte, einschließlich Flashbots, eliminieren“ und die Einbettung von politischen Entscheidungen auf Protokollebene vermeiden. Flashbots hat betont, dass es den SUAVE-Marktplatz nicht selbst kontrollieren wird, wenn er reift – was bedeutet, keinen zentralen Kill-Switch oder Zensur-Schalter. Die Governance (falls vorhanden) von SUAVE ist öffentlich noch nicht definiert, aber man kann erwarten, dass sie die breitere Community und möglicherweise ein Token umfasst, anstatt das Fiat-Geld eines Unternehmens. Zusammenfassend ist SUAVE darauf ausgelegt, sich an dezentrale Prinzipien anzupassen, was von Natur aus bestimmte regulatorische Kontrollen (Zensur) widersteht, während es potenziell einige regulatorische Bedenken lindert, indem es die MEV-Extraktion gerechter und transparenter macht.

• Technische Architektur (Konsens & Krypto): SUAVE wird seine eigene Blockchain-Umgebung betreiben – zumindest anfänglich. Es wird als eine EVM-kompatible Chain beschrieben, die auf Präferenzen und MEV spezialisiert ist. Die Architektur besteht aus drei Hauptkomponenten: (1) die Universal Preference Environment (die SUAVE-Chain + Mempool, wo Präferenzen gepostet und aggregiert werden), (2) der Execution Market (Off-Chain- oder On-Chain-Executors, die die Präferenzen lösen/optimieren, ähnlich einer dezentralen „Order-Matching-Engine“) und (3) Decentralized Block Building (ein Netzwerk von SUAVE-Teilnehmern, die Blöcke für verschiedene Domänen zusammenstellen). Im Kern wird der Konsens von SUAVE wahrscheinlich ein Proof-of-Stake BFT-Konsens sein (ähnlich Ethereum oder Cosmos), um die SUAVE-Chain selbst zu betreiben – obwohl noch entschieden wird, ob SUAVE eine L1, eine Ethereum L2 oder eine Suite von „Restaking“-Verträgen wird. Eine Möglichkeit ist, dass SUAVE als Layer-2 oder Sidechain beginnen könnte, die Ethereum für die Finalität nutzt, oder bestehende Validator-Sets leveraged. Das Sicherheitsmodell ist noch festzulegen, aber Diskussionen umfassten, es zu einer Ethereum L3 oder einer Cosmos-Chain zu machen. Kryptographisch stützt sich SUAVE in seiner frühen Roadmap stark auf vertrauenswürdige Hardware und Verschlüsselung. Die Phase SUAVE Centauri implementiert eine „datenschutzbewusste Orderflow-Auktion“, bei der Flashbots (zentral) SGX-Enklaven betreibt, um den Orderflow von Searchern und Nutzern privat zu halten. In SUAVE Andromeda planen sie, SGX-basierte Auktionen und Block-Building ohne Vertrauen in Flashbots zu verwenden (die Enklaven bieten Vertraulichkeit, sodass selbst Flashbots nicht hineinschauen kann). Bis SUAVE Helios ist das Ziel, ein SGX-basiertes dezentrales Building-Netzwerk zu haben – was bedeutet, dass viele unabhängige Parteien Enklaven betreiben, die gemeinsam Blöcke bauen und sowohl Privatsphäre als auch Dezentralisierung erreichen. Langfristig erforscht Flashbots benutzerdefinierte sichere Enklaven und kryptographische Ersatzlösungen wie Schwellenwert-Entschlüsselung und Mehrparteienberechnung, um die Abhängigkeit von Intels SGX zu reduzieren. Zum Beispiel könnten sie ein Schwellenwert-Verschlüsselungsschema verwenden, bei dem Validatoren von SUAVE gemeinsam einen Schlüssel halten, um Transaktionen erst nach der Entscheidung über die Reihenfolge zu entschlüsseln (wodurch sichergestellt wird, dass niemand frontrunnen kann). Dieses Konzept ähnelt Anomas Ferveo oder anderen „fair ordering via threshold encryption“-Ideen. Zusätzlich behandelt SUAVE Nutzerpräferenzen als Smart Contracts auf seiner Chain. Eine Nutzerpräferenz könnte ein Gültigkeitsprädikat und eine Zahlungsbedingung enthalten – dies ist im Wesentlichen ein Stück Code, das besagt: „Wenn Ergebnis X auf Chain Y erreicht wird, dann zahle Executor Z diesen Betrag“. Die SUAVE-Chain muss Orakel und Cross-Chain-Verifizierung handhaben, um zu wissen, wann eine Präferenz erfüllt wurde (z.B. den Ethereum-Status lesen, um zu sehen, ob ein Swap stattgefunden hat). Dies impliziert, dass die Architektur von SUAVE On-Chain-Light-Clients oder Orakel-Systeme für verbundene Chains sowie potenziell atomare Cross-Chain-Abwicklung umfassen wird (um beispielsweise sicherzustellen, dass ein Executor auf Ethereum und Arbitrum ausführen und das Gebot atomar beanspruchen kann). SUAVE plant, hochgradig erweiterbar zu sein: Da es EVM-kompatibel ist, könnten beliebige Verträge (SUAVE-native „Präferenzen“ oder sogar normale DApps) darauf ausgeführt werden, obwohl die Absicht ist, den Fokus auf die Orderflow-Koordination zu legen. Konsens-technisch könnte SUAVE innovativ sein, indem es eine Intent-zentrierte Chain statt einer Transaktions-zentrierten ist, aber letztendlich muss es Nachrichten (Präferenzen) ordnen und Blöcke wie jede Chain produzieren. Man kann sich vorstellen, dass SUAVE einen Konsensalgorithmus annimmt, der für Durchsatz und geringe Latenz-Finalität optimiert ist, da es im kritischen Pfad von Transaktionen für viele Chains liegen wird. Vielleicht könnte eine Tendermint-ähnliche sofortige Finalität oder sogar ein DAG-basierter Konsens verwendet werden, um Präferenzen schnell zu bestätigen. Unabhängig davon liegen die Unterscheidungsmerkmale von SUAVE auf der Transaktionsschicht, nicht auf der Konsensschicht: die Verwendung von Datenschutztechnologie (SGX, Schwellenwert-Verschlüsselung) für die Reihenfolge, domänenübergreifende Kommunikation und Smart-Order-Routing-Logik, die in das Protokoll integriert ist. Dies macht es zu einer Art „Meta-Schicht“ über bestehenden Blockchains. Technisch gesehen muss jede teilnehmende Chain den SUAVE-Outputs bis zu einem gewissen Grad vertrauen (z.B. müsste ein Ethereum-Proposer einen von SUAVE gebauten Block akzeptieren oder SUAVE-Vorschläge aufnehmen). Flashbots hat angedeutet, dass SUAVE schrittweise und opt-in eingeführt wird – Domänen können wählen, SUAVE-Sequenzierung für ihre Blöcke zu übernehmen. Bei breiter Akzeptanz könnte SUAVE zu einem De-facto-MEV-aware Transaktions-Routing-Netzwerk für Web3 werden. Zusammenfassend ist die Architektur von SUAVE eine Verbindung von Blockchain und Off-Chain-Auktion: eine spezialisierte Chain für die Koordination, verbunden mit Off-Chain-sicherer Berechnung unter Executors, alles verankert durch kryptographische Garantien für Fairness und Privatsphäre.

• Entwicklungs-Roadmap & Meilensteine: Flashbots hat die Roadmap von SUAVE in drei Hauptmeilensteinen skizziert, benannt nach Sternensystemen: Centauri, Andromeda und Helios. Centauri (die erste Phase, in Entwicklung im Jahr 2023) konzentriert sich auf den Aufbau einer zentralisierten, aber datenschutzfreundlichen Orderflow-Auktion. In dieser Phase betreibt Flashbots den Auktionsdienst (wahrscheinlich in SGX), der Searchern ermöglicht, zu bieten, um Nutzertransaktionen backrunnen zu lassen, und MEV privat an die Nutzer zurückzugeben. Es beinhaltet auch den Start eines SUAVE-Devnets für frühe Tests. Tatsächlich hat Flashbots im August 2023 einen frühen SUAVE-Client (suave-geth) quelloffen gemacht und Toliman, das erste öffentliche SUAVE-Testnet, gestartet. Dieses Testnet wurde verwendet, um mit der Präferenzexpression und der grundlegenden Auktionslogik zu experimentieren. Andromeda (die nächste Phase) wird das erste SUAVE-Mainnet einführen. Hier werden Nutzer in der Lage sein, Präferenzen in einem Live-Netzwerk auszudrücken, und der Execution Market wird in Betrieb sein (Executors erfüllen Absichten). Andromeda führt auch SGX-basierte Auktionen und Block-Building auf eine stärker verteilte Weise ein – wodurch die Notwendigkeit entfällt, Flashbots als Betreiber zu vertrauen, und das System für Searcher und Builder wirklich erlaubnisfrei wird. Ein Ergebnis in dieser Phase ist die Verwendung von SGX zur Verschlüsselung des Orderflows auf eine Weise, dass selbst Block-Builder nicht hineinschauen können, aber dennoch Blöcke bauen können (d.h. „offener, aber privater“ Orderflow). Helios ist die ehrgeizige dritte Phase, in der SUAVE volle Dezentralisierung und Cross-Chain-Funktionalität erreicht. In Helios produziert ein dezentrales Netzwerk von Buildern in SGX kollaborativ Blöcke (keine Dominanz eines einzelnen Builders). Außerdem wird SUAVE „eine zweite Domäne“ jenseits von Ethereum aufnehmen – was bedeutet, dass es MEV für mindestens zwei Chains handhaben wird, was Cross-Chain-MEV-Auktionen demonstriert. Zusätzlich wird die Expression und Ausführung von Cross-Domain-MEV ermöglicht (Nutzer können wirklich Multi-Chain-Absichten posten und diese atomar ausführen lassen). Über Helios hinaus erwartet Flashbots die Erforschung benutzerdefinierter Hardware und fortschrittlicher Kryptographie (wie ZK-Proofs oder MPC), um Vertrauensgarantien weiter zu stärken. Bisherige wichtige Updates und Meilensteine: November 2022 – SUAVE angekündigt; August 2023 – erste SUAVE-Code-Veröffentlichung und Testnet (Toliman); laufend 2024 – Centauri-Phase Orderflow-Auktion läuft (Flashbots hat angedeutet, dass dies mit Nutzertransaktionen in einer geschlossenen Umgebung getestet wird). Ein bemerkenswerter Meilenstein wird der Start des SUAVE-Mainnets (Andromeda) sein, der Mitte 2025 bevorsteht. Flashbots hat sich verpflichtet, SUAVE offen zu entwickeln und zur Zusammenarbeit einzuladen aus dem gesamten Ökosystem. Dies spiegelt sich in den Forschungs- und Forumsdiskussionen wider, wie den „Stargazing“-Beiträgen, die über die Designentwicklung von SUAVE informieren. Das Endziel für SUAVE ist, dass es zu einer gemeinschaftseigenen Infrastruktur wird – der „dezentralen Sequenzierungsschicht“ für die gesamte Krypto-Welt. Dies zu erreichen, wird einen wichtigen Meilenstein im Kampf um faire Reihenfolge markieren: Wenn SUAVE erfolgreich ist, wäre MEV kein dunkler Wald mehr, sondern eine transparente, gemeinsame Wertquelle, und keine einzelne Chain müsste die zentralisierenden Effekte von MEV alleine erleiden.

Anoma (Intent-Centric Architecture for Fair Counterparty Discovery)​

Anoma ist ein radikal anderer Ansatz zur Ermöglichung fairer Reihenfolge und MEV-Minderung – es ist eine gesamte Architektur für Intent-basierte Blockchain-Infrastruktur. Anstatt eine Auktion an bestehende Chains anzudocken, überdenkt Anoma das Transaktionsparadigma von Grund auf neu. In Anoma senden Nutzer keine konkreten Transaktionen; sie senden Intents – Erklärungen darüber, welchen Endzustand sie wünschen – und das Netzwerk selbst entdeckt Gegenparteien und bildet Transaktionen, die diese Intents erfüllen. Durch die Integration von Gegenpartei-Entdeckung, fairer Reihenfolge und Privatsphäre auf Protokollebene zielt Anoma darauf ab, bestimmte Formen von MEV (wie Frontrunning) praktisch zu eliminieren und „Frontrunner-freie“ dezentrale Börsen und Abwicklungen zu ermöglichen. Anoma ist eher ein Framework als eine einzelne Chain: Jede Blockchain kann eine „fraktale Instanz“ von Anoma sein, indem sie ihre Intent-Gossip- und Matching-Architektur übernimmt. Für diese Diskussion konzentrieren wir uns auf Anomas erste Implementierung (manchmal Anoma L1 genannt) und ihre Kernprotokollfunktionen, soweit sie sich auf Fairness und MEV beziehen.

• Warteschlange und Transaktionsreihenfolge: Anoma verwirft den konventionellen Mempool von Transaktionen; stattdessen verfügt es über ein Gossip-Netzwerk von Intents. Nutzer senden einen Intent, z.B. „Ich möchte 100 DAI gegen mindestens 1 ETH tauschen“ oder „Ich möchte gegen Sicherheiten zum besten Kurs leihen.“ Diese Intents sind partielle Orders – sie spezifizieren keine exakten Ausführungspfade, sondern nur das gewünschte Ergebnis und die Einschränkungen. Alle Intents werden im Netzwerk verbreitet und gesammelt. Die Reihenfolge in Anoma funktioniert nun in zwei Stufen: (1) Gegenpartei-Entdeckung/Matching und (2) Transaktionsausführung mit fairer Reihenfolge. In Stufe 1 überwachen spezialisierte Knoten, sogenannte Solver, kontinuierlich den Pool von Intents und versuchen, Sätze von Intents zu finden, die sich gegenseitig ergänzen, um eine gültige Transaktion zu bilden. Wenn beispielsweise Alice DAI gegen ETH tauschen möchte und Bob ETH gegen DAI, kann ein Solver sie zusammenführen. Wenn mehrere Intents kompatibel sind (wie ein Orderbuch von Geboten und Anfragen), können Solver ein optimales Matching oder einen Clearing-Preis finden. Wichtig ist, dass dies Off-Chain im Solver-Netzwerk geschieht – effektiv ein algorithmisches Matchmaking. Sobald ein Solver (oder eine Gruppe von Solvern) eine vollständige Transaktion (oder einen Satz von Transaktionen) konstruiert hat, die einige Intents erfüllen, reichen sie diese zur Ausführung an die Chain ein. Hier kommt Stufe 2: Anomas Konsens wird dann diese von Solvern eingereichten Transaktionen in Blöcke ordnen. Anomas Konsens ist jedoch so konzipiert, dass er reihenfolge-fair ist: Er verwendet kryptographische Techniken (Schwellenwert-Verschlüsselung), um sicherzustellen, dass Transaktionen ohne Beeinflussung durch ihren Inhalt oder den genauen Einreichungszeitpunkt geordnet werden. Insbesondere plant Anoma, Ferveo, ein Schwellenwert-Verschlüsselungsschema, auf Mempool-Ebene zu verwenden. Dies funktioniert so: Solver verschlüsseln die Transaktionen, die sie vorschlagen möchten, mit einem kollektiven öffentlichen Schlüssel der Validatoren. Validatoren nehmen diese verschlüsselten Transaktionen in Blöcke auf, ohne deren Details zu kennen. Erst nachdem eine Transaktion in einem Block finalisiert ist, entschlüsseln die Validatoren sie gemeinsam (indem jeder einen Anteil des Entschlüsselungsschlüssels beiträgt). Dies stellt sicher, dass kein Validator selektiv Front-Run oder neu ordnen kann, basierend auf dem Inhalt einer Transaktion – sie verpflichten sich blind zu einer Reihenfolge. Der Konsensalgorithmus ordnet Transaktionen (eigentlich Intents) effektiv in einer Art First-Seen- oder Batch-Manier, da alle Transaktionen in einem gegebenen „Batch“ (Block) verschlüsselt und gleichzeitig offengelegt werden. In der Praxis kann Anoma Batch-Auktionen für bestimmte Anwendungen implementieren: z.B. kann ein Intent zum Handeln über N Blöcke gesammelt (verschlüsselt gehalten), dann nach N Blöcken alle zusammen entschlüsselt und von Solvern in einem Batch abgeglichen werden. Dies verhindert, dass schnelle Akteure die Orders anderer sehen und innerhalb dieses Batches reagieren – ein großer Vorteil für die Fairness (diese Technik ist von Frequent Batch Auctions inspiriert und wurde vorgeschlagen, um die Vorteile des Hochfrequenzhandels zu eliminieren). Zusätzlich können Anomas Gültigkeitsprädikate (Anwendungsebene-Smart Contracts) Fairness-Einschränkungen für das Reihenfolge-Ergebnis durchsetzen. Zum Beispiel könnte eine Anoma-DEX-Anwendung eine Regel haben: „Alle Trades in einem Batch erhalten den gleichen Clearing-Preis, und Solver können keine zusätzlichen Transaktionen einfügen, um Nutzer auszunutzen.“ Da diese Regeln Teil der Zustandsgültigkeit sind, wäre jeder Block, der eine unfaire Übereinstimmung enthält (z.B. ein Solver versuchte, einen Eigenhandel zu einem besseren Preis einzuschleusen), ungültig und würde von Validatoren abgelehnt. Zusammenfassend erfolgt die Reihenfolge in Anoma als Match, dann verschlüsseln+ordnen: Intents werden konzeptionell in die Warteschlange gestellt, bis ein Solver eine Transaktion bildet, und dann wird diese Transaktion durch einen Fair-Order-Konsens geordnet (wodurch typische MEV verhindert wird). Es gibt effektiv kein Mempool-Rennen, da Nutzer-Intents nicht direkt um Gaspreis oder Zeitpriorität konkurrieren. Stattdessen konkurrieren Solver darum, Übereinstimmungen zu finden, und dann werden diese Übereinstimmungen so ausgeführt, dass niemand die Reihenfolge ändern oder sie während des Flugs abfangen kann. Diese Architektur verspricht, viele MEV-Vektoren zu neutralisieren – es gibt kein Konzept des Frontrunning eines Intents, da Intents nicht ausführbar sind, bis der Solver sie zusammensetzt, und dann sind sie bereits in den Block verschlüsselt. Es ist ein grundlegend anderes Warteschlangenmodell, das darauf abzielt, zeitbasierte Prioritätsausnutzungen zu eliminieren.

• MEV-Unterdrückungs-/Extraktionsmechanismen: Anoma ist darauf ausgelegt, „schlechte MEV“ konstruktionsbedingt zu minimieren. Durch die Abwicklung von Trades über Batch-Solving und Schwellenwert-Verschlüsselung sind typische MEV-Angriffe wie Sandwiching unmöglich – niemand sieht einen Intent und kann seinen eigenen davor einfügen, da Intents keine Transaktionen sind, die in einem transparenten Mempool leben. Solver geben endgültig abgeglichene Transaktionen erst nachdem die Möglichkeit zur Einfügung verstrichen ist (aufgrund von Verschlüsselung und Batching) aus. In einem Anoma-basierten DEX würden Nutzer nicht im traditionellen Sinne frontrunnt oder backrunnt, da alle Trades in einem Batch gemeinsam zu einem einheitlichen Preis ausgeführt werden (was verhindert, dass ein Angreifer Preisänderungen zwischen ihnen ausnutzt). Dies unterdrückt im Wesentlichen räuberische MEV wie DEX-Arbitrage oder Sandwiching; der Wert, der von einem Bot genommen worden wäre, bleibt stattdessen bei den Nutzern (sie erhalten einen fairen Preis). Anomas Ansatz zur Arbitrage ist ebenfalls bemerkenswert: In vielen Fällen, wenn mehrere Intents eine Arbitrage-Möglichkeit schaffen, wird der Solver, der sie abgleicht, diesen Gewinn in das Matching einbeziehen (z.B. verschiedene Preise abgleichen und einen Gewinn erzielen). Da jedoch mehrere Solver darum konkurrieren können, das beste Matching zu liefern, kann der Wettbewerb Solver dazu zwingen, den größten Teil dieses Vorteils in Form besserer Füllbedingungen an die Nutzer zurückzugeben. Wenn beispielsweise ein Nutzer zu Preis A verkaufen und ein anderer zu Preis B kaufen möchte (B > A impliziert eine Lücke), könnte ein Solver beide zu einem Zwischenpreis erfüllen und die Differenz als Gewinn erfassen – aber wenn ein anderer Solver den Nutzern einen noch näher beieinander liegenden Preis anbietet (weniger Gewinn übrig lässt), wird er den Intent gewinnen. So konkurrieren Solver MEV-Margen weg, um den Nutzern zugutezukommen, ähnlich wie Searcher in Flashbots über Gebühren konkurrieren. Der Unterschied ist, dass dies algorithmisch über Intent-Matching statt über Gas-Bidding geschieht. Es kann in Anoma immer noch „extrahierte MEV“ geben, aber sie beschränkt sich wahrscheinlich auf Solver, die bescheidene Gebühren für ihren Dienst verdienen. Bemerkenswert ist, dass Anoma erwartet, dass der größte Teil des Orderflows vom Protokoll oder der Anwendungslogik internalisiert wird. In einigen Fällen bedeutet dies, dass eine MEV-Möglichkeit einfach zu einer normalen Protokollgebühr wird. Zum Beispiel implementiert Anomas erste fraktale Instanz (Namada) einen On-Chain-Bonding-Curve-AMM; Arbitrage auf diesem AMM wird vom Mechanismus des AMM erfasst (wie ein eingebauter Rebalancer) und nicht von externen Arbitrageuren. Ein weiteres Beispiel: Ein Lending-Intent, der hohe Zinsen anbietet, könnte mit einem Borrowing-Intent abgeglichen werden; es ist kein Drittanbieter-Liquidator erforderlich, wenn Sicherheiten fallen, da die Intents selbst das Rebalancing übernehmen oder das Protokoll automatisch zu einem fairen Preis liquidieren könnte. Durch das Ausschalten von Drittanbieter-Extraktoren reduziert Anoma die Verbreitung von Off-Chain-MEV-Extraktion. Zusätzlich betont Anoma Privatsphäre (durch das Taiga-Subsystem von ZK-Schaltungen). Nutzer können wählen, ihre Intents teilweise oder vollständig abzuschirmen (z.B. Beträge oder Asset-Typen verbergen). Dies unterdrückt MEV weiter: Wenn die Details einer großen Order verborgen sind, kann niemand sie zur Wertentnahme anvisieren. Erst nach dem Matching und der Ausführung könnten Details auftauchen, aber dann ist es zu spät, um sie auszunutzen. Zusammenfassend geht es bei Anomas Mechanismus größtenteils darum, MEV zu verhindern anstatt sie zu extrahieren: Durch das Batching von Transaktionen, das Verschlüsseln des Mempools und das Einbetten wirtschaftlicher Ausrichtung in das Matching versucht es sicherzustellen, dass es wenig Möglichkeiten für bösartige Arbitrage oder Frontrunning gibt. Die notwendige MEV (wie Arbitrage zur Angleichung von Preisen über Märkte hinweg) wird von Solvern oder der Protokolllogik auf eine vertrauensminimierte Weise gehandhabt. Man könnte sagen, Anoma strebt eine „MEV-Minimierung“ an und bemüht sich um Ergebnisse, als ob jeder Nutzer sofortigen Zugang zur perfekten Gegenpartei hätte, ohne Verluste. Jeder Wert, der bei der Erleichterung dessen extrahiert wird (die Belohnung des Solvers), ist vergleichbar mit einer kleinen Servicegebühr, nicht mit einem unerwarteten Gewinn aus der Ausnutzung von Asymmetrie.

• Ökonomische Anreizstruktur: In Anoma übernehmen Solver die Rolle, die sowohl Matchmakern als auch Block-Buildern entspricht. Sie tragen Kosten (Berechnung, möglicherweise Hinterlegung von Sicherheiten), um Intent-Matches zu finden, und werden belohnt, wenn sie erfolgreich Transaktionen vorschlagen, die aufgenommen werden. Solver können auf verschiedene Weisen verdienen: Sie könnten eine Gebühr oder einen Spread innerhalb der von ihnen konstruierten Transaktion erheben (zum Beispiel den Nutzern etwas weniger günstige Konditionen bieten und die Differenz behalten, ähnlich wie ein DEX-Aggregator einen kleinen Anteil nehmen könnte). Oder bestimmte Intents könnten explizit eine Belohnung für den Solver enthalten (wie „Ich bin bereit, bis zu 0,01 ETH zu zahlen, um dies zu erledigen“). Das genaue Vergütungsmodell ist flexibel, aber der Schlüssel ist, dass Solver konkurrieren. Wenn ein Solver versucht, eine zu hohe Gebühr zu nehmen, kann ein anderer eine Lösung mit einem besseren Nutzerergebnis vorschlagen und die Aufnahme gewinnen. Diese Wettbewerbsdynamik soll die Solver-Gewinne in Schach halten und auf die Wertschöpfung ausrichten. Validatoren (Block-Produzenten): Anoma-Validatoren betreiben den Konsens, der Transaktionen ordnet und ausführt. Sie werden durch Block-Belohnungen und Gebühren motiviert, wie in jeder Blockchain. Bemerkenswert ist, dass, wenn Intents über mehrere Nutzer hinweg abgeglichen werden, die resultierende Transaktion mehrere Gebührenquellen haben könnte (jeder Nutzer könnte eine Gebühr oder einen Teil der Vermögenswerte beisteuern). Es ist möglich, dass Anomas Gebührenmodell eine Gebührenteilung zulässt, aber typischerweise erhalten Validatoren die Standard-Gasgebühren für die Verarbeitung von Transaktionen. In zukünftigen Phasen plant Anoma einen „On-Demand-Konsens“ und ein natives Token. Die Idee ist, dass viele Anoma-Instanzen (oder Shards) existieren könnten, und einige könnten temporär für spezifische Aufgaben hochgefahren werden („Ad-hoc-Konsens“ für bestimmte Anwendungsbedürfnisse). Das Token würde wahrscheinlich zum Staking und zur Sicherung dieser Instanzen verwendet. Anreize hier stellen sicher, dass das Netzwerk genügend Validatoren hat, um alle abgeglichenen Transaktionen zuverlässig zu verarbeiten, und dass sie sich im Schwellenwert-Entschlüsselungsprozess ehrlich verhalten (vielleicht Slashing-Bedingungen, wenn sie versuchen, Daten frühzeitig zu entschlüsseln oder zu zensieren). Nutzer: Nutzer in Anoma sparen potenziell Geld und erzielen bessere Ergebnisse, anstatt implizit MEV zu zahlen. Zum Beispiel könnten sie durchweg bessere Handelspreise erhalten als auf einer traditionellen Chain, was bedeutet, dass der Wert bei ihnen bleibt. In einigen Fällen könnten Nutzer auch explizite Gebühren zahlen, um Solver zu motivieren, insbesondere für komplexe Intents oder wenn sie ein schnelleres Matching wünschen. Da Nutzer jedoch Intents ausdrücken können, ohne anzugeben, wie sie ausgeführt werden sollen, überlassen sie die schwere Arbeit den Solvern und zahlen nur, wenn es sich lohnt. Es gibt auch die Vorstellung, dass „Intent-Besitzer ihre eigenen Sicherheits-/Leistungs-Kompromisse definieren können“ – z.B. könnte ein Nutzer sagen: „Ich warte länger auf einen besseren Preis“ oder „Ich zahle mehr für sofortige Ausführung.“ Diese Flexibilität ermöglicht es den Nutzern selbst zu entscheiden, wie viel sie Solvern oder Validatoren anbieten, wodurch die wirtschaftlichen Anreize an ihre Bedürfnisse angepasst werden. MEV-Umverteilung: Falls MEV auftritt (wie Cross-Chain-ARB o.ä.), könnte die Anoma-Architektur es ermöglichen, diese in das System zu integrieren. Zum Beispiel könnten mehrere Anoma-Shards oder -Instanzen koordinieren, um einen atomaren Multi-Chain-Arb abzuwickeln, und der Gewinn könnte geteilt oder verbrannt werden (je nach Design), anstatt ihn einem externen Arbitrageur vollständig zu überlassen. Im Allgemeinen, da Anoma Anwendungen die Kontrolle über den Transaktionsfluss gibt, ist es möglich, protokolleigene MEV-Strategien (ähnlich der Philosophie von Skip) auf Anwendungsebene zu implementieren. Zum Beispiel könnte eine DeFi-App auf Anoma alle Nutzertransaktionen automatisch über einen In-Protocol-Solver leiten, der die beste Ausführung garantiert und jeden zusätzlichen Gewinn mit Nutzern oder Liquiditätsanbietern teilt. Der Nettoeffekt ist, dass Drittanbieter-MEV-Extraktoren disintermediiert werden. Wirtschaftlich ist dies ein Positivsummenspiel für ehrliche Teilnehmer (Nutzer, LPs usw.), aber es könnte die Möglichkeiten für klassische Searcher reduzieren. Es werden jedoch neue Rollen wie spezialisierte Solver (vielleicht konzentriert sich einer auf NFT-Matching, ein anderer auf FX-Swaps usw.) entstehen. Diese Solver sind analog zu den heutigen MEV-Searchern, aber sie operieren innerhalb der Systemregeln und haben aufgrund von Wettbewerb und Protokolleinschränkungen wahrscheinlich weniger wahnsinnige Gewinnmargen. Schließlich deutet die Vision der Anoma Foundation darauf hin, dass Anoma eine öffentliche Gut-Infrastruktur sein wird. Es wird ein natives Token geben, vermutlich ANOMA, das Wert über Gebühren erfassen oder für das Staking erforderlich sein könnte. Man kann Token-Anreize (inflationäre Belohnungen usw.) für Validatoren und vielleicht sogar für Solver erwarten, um die Aktivität anzukurbeln. Zum Zeitpunkt des Schreibens sind die Details zur Token-Ökonomie noch nicht final, aber die Roadmap bestätigt, dass ein Anoma-Token und ein nativer On-Demand-Konsens in zukünftigen Phasen geplant sind. Zusammenfassend fördert Anomas Anreizmodell kooperatives Verhalten: Solver verdienen, indem sie Nutzern helfen, das zu bekommen, was sie wollen, nicht indem sie sie ausnutzen; Validatoren verdienen, indem sie das Netzwerk sichern und fair ordnen; und Nutzer „zahlen“ hauptsächlich, indem sie einen Teil der MEV an Solver oder Gebühren abgeben, aber idealerweise viel weniger als die implizite MEV, die sie in anderen Systemen verlieren würden.

• Compliance und Neutralität: Anoma, als Framework und nicht als einzelnes Netzwerk, kann auf verschiedene Weisen instanziiert werden – einige könnten permissioned sein, aber die Flaggschiff-Anoma L1 und ähnliche Instanzen sollen permissionless und datenschutzverbessert sein. Durch die Integration starker Datenschutzfunktionen (wie abgeschirmte Intents mit Zero-Knowledge-Proofs in Taiga) stimmt Anoma mit der Ansicht überein, dass finanzielle Privatsphäre ein Recht ist. Dies könnte es in Konflikt mit bestimmten regulatorischen Regimen bringen, die eine offene Sichtbarkeit von Transaktionen fordern. Anomas Design könnte jedoch auch bestimmte regulatorische Fallstricke vermeiden. Wenn beispielsweise Front-Running und unfaire Orderauswahl eliminiert werden, werden Bedenken hinsichtlich Marktmanipulation gemindert – eine Regulierungsbehörde könnte es schätzen, dass Nutzer nicht systematisch von Insidern ausgenutzt werden. Zusätzlich impliziert das Konzept der „nutzerdefinierten Sicherheitsmodelle“, dass Nutzer oder Communities unterschiedliche Vertrauensannahmen wählen könnten. Potenziell könnte eine regulierte Anwendung auf Anoma aufgebaut werden, bei der beispielsweise der Solver oder eine Untergruppe von Validatoren KYC-geprüfte Entitäten sind, die die Compliance für diesen bestimmten Intent-Bereich sicherstellen. Anoma als Basisschicht würde nicht für jeden KYC erzwingen, aber man könnte Gültigkeitsprädikate implementieren, die (zum Beispiel) einen Nachweis der Berechtigung für bestimmte Transaktionen (wie einen Nachweis, keine sanktionierte Adresse zu sein, oder eine Berechtigungsprüfung) erfordern, wenn eine Anwendung dies benötigt. Die Architektur ist flexibel genug, um Compliance auf der Anwendungsebene zu unterstützen, ohne die Neutralität der Basisschicht zu beeinträchtigen. Bezüglich Zensur: Anomas Schwellenwert-Verschlüsselung bedeutet, dass selbst wenn Validatoren zensieren wollten, sie keine spezifischen Intents anvisieren können, weil sie diese nicht im Klartext sehen. Das Einzige, was sie tun könnten, ist, die Aufnahme verschlüsselter Transaktionen von bestimmten Solvern oder Nutzern zu verweigern, aber das wäre offensichtlich (und würde gegen die Protokollregeln verstoßen, wenn es willkürlich geschieht). Es wird erwartet, dass Konsensregeln die Zensur entmutigen – zum Beispiel könnte ein Block als ungültig oder weniger bevorzugt angesehen werden, wenn er nicht alle verfügbaren entschlüsselten Intents des letzten Batches enthält. In jedem Fall gewährleisten die Dezentralisierung der Validatoren und die verschlüsselte Natur der Payloads zusammen ein hohes Maß an Zensurresistenz. Zur Neutralität: Anoma zielt darauf ab, eine allgemeine Plattform zu sein, die von keiner einzelnen Entität kontrolliert wird. Die Forschung und Entwicklung wird von Heliax (dem Team hinter Anoma und Namada) geleitet, aber sobald sie live ist, würde ein Anoma-Netzwerk von der Community betrieben. Es wird wahrscheinlich eine On-Chain-Governance für Upgrades usw. geben, was Compliance-Fragen aufwerfen könnte (z.B. könnte eine Regierung die Governance untergraben, um Regeln zu ändern?), aber das ist ein allgemeines Blockchain-Problem. Eine interessante Compliance-bezogene Funktion ist, dass Anoma mehrere parallele Instanzen unterstützt – was bedeutet, dass man einen isolierten Intent-Pool oder Shard für bestimmte Asset-Typen oder Jurisdiktionen haben könnte. Dies ist nicht explizit für die Regulierung gedacht, könnte aber beispielsweise einen CBDC-Intent-Pool ermöglichen, in dem nur autorisierte Banken Solver betreiben, die mit einem freien DeFi-Pool koexistieren. Die Modularität der Architektur bietet Flexibilität zur Trennung bei Bedarf, während sie dennoch Interoperabilität über Intent-Bridging ermöglicht. Schließlich, in Bezug auf die rechtliche Kompatibilität, könnte Anomas gesamtes Konzept von Intents einige Klassifizierungen vermeiden, die traditionelle Krypto plagen: Da ein Intent keine bindende Transaktion ist, bis er abgeglichen wird, könnte man argumentieren, dass Nutzer mehr Kontrolle behalten (es ist wie das Posten einer Order an einer Börse, was einen klareren rechtlichen Präzedenzfall hat, im Gegensatz zur direkten Ausführung eines Handels). Dies könnte bei Dingen wie der steuerlichen Behandlung helfen (das System könnte potenziell eine einheitliche Quittung eines mehrstufigen Handels anstelle vieler Transaktionen liefern) – obwohl dies spekulativ ist. Insgesamt priorisiert Anoma Dezentralisierung, Privatsphäre und Nutzerautonomie, was historisch mit regulatorischen Erwartungen kollidieren kann, aber die Fairness- und Transparenzgewinne könnten Anklang finden. Es bringt im Wesentlichen die Raffinesse traditioneller Finanz-Matching-Engines On-Chain, aber ohne zentralisierte Betreiber. Wenn Regulierungsbehörden dieses Modell verstehen, könnten sie es als eine geordnetere und fairere Marktstruktur ansehen als das Chaos der Mempools.

Skip Protocol (Cosmos Sovereign MEV Control and Fair Ordering Toolkit)​

Skip Protocol ist eine führende MEV-Lösung im Cosmos-Ökosystem, die darauf abzielt, jeder Blockchain („App-Chain“) die Werkzeuge an die Hand zu geben, um Transaktionsreihenfolge und MEV-Erfassung nach ihren eigenen Bedingungen zu verwalten. Im Gegensatz zu Flashbots oder Anoma, die netzwerkübergreifende Systeme vorschlagen, stimmt Skip mit der Philosophie der Souveränität von Cosmos überein: Jede Chain kann Skips Module integrieren, um benutzerdefinierte faire Reihenfolgeregeln durchzusetzen, In-Protocol-Blockspace-Auktionen durchzuführen und MEV für die Stakeholder oder Nutzer der Chain zu erfassen. Skip kann als eine Suite von Cosmos SDK-Modulen und Infrastruktur betrachtet werden, die zusammen Protocol-Owned Blockbuilding (POB) und flexible Transaktionssequenzierung ermöglichen. Es wurde auf Chains wie Osmosis, Juno, Terra und anderen in Cosmos übernommen und arbeitet auch mit Projekten wie dYdXs kommender Chain zur MEV-Minderung zusammen. Schlüsselelemente umfassen einen On-Chain-Auktionsmechanismus für Prioritätstransaktionen, Konsens-Ebene-Transaktionsreihenfolgelogik und In-App-Mechanismen zur Wiederverwertung von MEV („gute MEV“) zum Nutzen des Protokolls.

• Transaktionswarteschlange & Reihenfolge-Algorithmen: In einer typischen Cosmos-Chain (mit Tendermint/BFT-Konsens) ordnet der Mempool Transaktionen grob nach Gebühr und Ankunftszeit, und der Block-Proposer kann bei der Erstellung eines Blocks jede beliebige Reihenfolge wählen (ohne algorithmische Einschränkungen außer der Aufnahme gültiger Transaktionen). Skip ändert dies durch die Einführung von konsensdurchgesetzten Reihenfolgeregeln und Multi-Lane-Mempools. Unter Verwendung der neuen ABCI++-Schnittstelle von Cosmos (die die Anpassung der Blockvorschläge und -verarbeitung ermöglicht), kann Skips Protocol-Owned Builder (POB)-Modul den Block in verschiedene Lanes mit unterschiedlichen Reihenfolgerichtlinien unterteilen. Zum Beispiel könnte eine Lane eine Top-of-Block-Auktions-Lane sein, in der die höchstbietenden Transaktionen (vielleicht von Arbitrage-Bots oder dringenden Trades) zuerst im Block in einer festen Reihenfolge platziert werden, eine andere Lane könnte eine Free-Lane für gewöhnliche Nutzertransaktionen ohne Gebühren sein, und eine Default-Lane für normale Transaktionen mit Gebühren. Die BlockBuster-Komponente des Skip-Moduls ermöglicht es Entwicklern, diese Lanes und ihre Reihenfolgelogik modular zu definieren. Entscheidend ist, dass diese Regeln von allen Validatoren durchgesetzt werden: Wenn ein Proposer einen Block konstruiert, überprüfen die anderen Validatoren, ob die Transaktionen des Blocks den vereinbarten Reihenfolgeregeln entsprechen (über die ProcessProposal ABCI-Prüfungen). Wenn nicht, können sie den Block ablehnen. Das bedeutet, dass selbst ein bösartiger oder gewinnorientierter Proposer nicht abweichen kann (z.B. kann er seine eigene Front-Run-Transaktion nicht vor einem gewinnenden Auktionsbieter einschleusen, da dies die Reihenfolgeregel verletzen würde). Einige Beispiele für Reihenfolgeregeln, die Skip ermöglicht: (a) Transaktionen nach absteigendem Gaspreis (Gebühr) ordnen – um sicherzustellen, dass die Transaktion mit der höchsten Gebühr immer Priorität erhält. Dies formalisiert ein faires „Pay-for-Priority“-Schema anstelle von zufälliger oder zeitbasierter Reihenfolge. (b) Muss mindestens eine Oracle-Preisaktualisierungs-Transaktion vor allen Trades enthalten – um sicherzustellen, dass Datenfeeds aktualisiert werden, was Szenarien verhindert, in denen ein Proposer Oracle-Updates ignorieren könnte, um veraltete Preise auszunutzen. (c) Begrenzung der Anzahl spezieller Transaktionen am Anfang des Blocks – z.B. kann nur ein Auktions-gewinnendes Bundle den obersten Platz einnehmen, um das Spammen vieler kleiner MEV-Grabs zu verhindern. (d) Keine Transaktionen, die eine Zustandseigenschaft verletzen – Skip ermöglicht zustandsabhängige Reihenfolgeregeln, wie „nach dem Bau des Blocks sicherstellen, dass kein DEX-Trade zu einem schlechteren Preis ausgeführt wurde, als wenn er zuletzt im Block gewesen wäre“ (eine Möglichkeit, sicherzustellen, dass kein Sandwich-Angriff stattgefunden hat). Eine konkrete beschriebene Regel ist eine „Null-Frontrunning-Bedingung über alle DEXs hinweg“, was bedeuten könnte, dass wenn eine Transaktion durch spätere in einer Weise beeinflusst worden wäre, die auf Frontrunning hindeutet, der Block ungültig ist. Dies ist mächtig: Es macht Fairness im Wesentlichen zu einem Teil der Blockgültigkeit. Cosmos-Chains können solche Regeln implementieren, weil sie ihren gesamten Stack kontrollieren. Skips Framework bietet eine strukturierte Möglichkeit, dies über den AuctionDecorator im SDK zu tun, der jede Transaktion gegen konfigurierte Regeln prüfen kann. Zusätzlich bietet Skip Mempool-Verbesserungen: Der Mempool des Knotens kann Blöcke im Voraus simulieren, fehlerhafte Transaktionen herausfiltern usw., um Proposern zu helfen, die Regeln effizient zu befolgen. Wenn beispielsweise die Auktions-Lane eines Blocks die höchsten Gebote haben muss, kann der Mempool für diese Lane nach Geboten sortiert werden. Wenn ein Block nur Transaktionen enthalten darf, die zu einer bestimmten Zustandsbedingung führen, kann der Knoten des Proposers Transaktionen simulieren, während er sie auswählt, um sicherzustellen, dass die Bedingung erfüllt ist. Zusammenfassend ermöglicht Skip eine deterministische, von der Chain definierte Reihenfolge, anstatt sie vollständig der Laune des Proposers oder einer einfachen Gaspreis-Priorität zu überlassen. Chains übernehmen Skips Builder-Modul, um ihre Transaktionsreihenfolgerichtlinie effektiv in das Protokoll zu kodifizieren. Dies fördert die Fairness, da alle Validatoren dieselben Regeln durchsetzen, wodurch die Möglichkeit für einen einzelnen Proposer entfällt, willkürliche Neuanordnungen für MEV vorzunehmen, es sei denn, dies geschieht innerhalb des erlaubten Mechanismus (wie der Auktion, wo es transparent und wettbewerbsorientiert ist). Die Warteschlange von Transaktionen in Skips Modell könnte separate Warteschlangen pro Lane umfassen. Zum Beispiel könnte eine Auktions-Lane spezielle Gebots-Transaktionen in die Warteschlange stellen (Skip verwendet einen speziellen MsgAuctionBid-Typ für das Bieten um Top-of-Block-Aufnahme). Diese Gebote werden in jedem Block gesammelt und das höchste ausgewählt. Währenddessen werden normale Transaktionen im Standard-Mempool in die Warteschlange gestellt. Im Wesentlichen führt Skip eine strukturierte Warteschlange ein: eine für Prioritätsgebote, eine für kostenlose oder andere usw., jede mit ihren eigenen Reihenfolgekriterien. Dieser modulare Ansatz bedeutet, dass jede Chain anpassen kann, wie sie Fairness und Einnahmen ausbalanciert – z.B. könnte Osmosis sagen: „Wir wollen überhaupt keine MEV-Auktion, aber wir erzwingen Reihenfolge-Fairness über Schwellenwert-Verschlüsselung“ (sie haben Schwellenwert-Verschlüsselung mit Hilfe von Skip und anderen implementiert), während eine andere Chain sagen könnte: „Wir erlauben Auktionen für MEV, verlangen aber, dass ein Teil der Erlöse verbrannt wird.“ Skip unterstützt beides. Diese Konfigurierbarkeit der Reihenfolge ist Skips Markenzeichen.

• MEV-Minderung und Extraktionsmechanismen: Skips Ansatz zu MEV wird oft als „protokolleigene MEV“ und „Multiplizität“ beschrieben. Protokolleigene MEV bedeutet, dass das Blockchain-Protokoll selbst, über seinen Code und seine Governance, MEV erfasst oder umverteilt, anstatt sie einzelnen Validatoren oder Außenstehenden zu überlassen. Multiplizität bezieht sich darauf, sicherzustellen, dass die „richtigen“ (mehreren) Transaktionen aufgenommen werden – im Wesentlichen keine legitimen Nutzer-Transaktionen zugunsten von nur MEV-Transaktionen auszuschließen und vielleicht mehrere MEV-Möglichkeiten in einem Block aufzunehmen, wenn möglich (damit kein einzelner Searcher monopolisiert). Konkret bietet Skip Tools zur Erfassung von MEV auf Weisen, die dem Netzwerk zugutekommen: Eine davon ist Skip Select, ein Blockspace-Auktionssystem für die Aufnahme am Anfang des Blocks. In Skip Select reichen Searcher (wie Arbitrage-Bots) Bundles mit Trinkgeldern an Validatoren ein, ähnlich wie Flashbots-Bundles, außer dass dies nativ On-Chain über Skips Module geschieht. Das höchstbezahlte Bundle (oder Bundles) wird dann automatisch am Anfang des Blocks in der angegebenen Reihenfolge eingefügt. Dies garantiert, dass diese Transaktionen wie beabsichtigt ausgeführt werden, und der Validator (oder die Chain) sammelt das Trinkgeld ein. Dieser Mechanismus macht aus einem Off-Chain-OTC-Prozess (in Ethereum) eine offene, On-Chain-Auktion – was Transparenz und Zugang verbessert. Ein weiterer Mechanismus ist ProtoRev (Prototype Revenue module), das Skip für Osmosis entwickelt hat. ProtoRev ist ein On-Chain-Arbitrage-Modul, das zyklische Arbitragen (wie solche, die mehrere Pools betreffen) innerhalb der Blockausführung automatisch erkennt und ausführt und den Gewinn in die Schatzkammer oder den Community-Pool der Chain akkumuliert. Im Wesentlichen entschied Osmosis, dass bestimmte „gute MEV“ (wie Arbitrage, die Preise im Einklang hält) weiterhin stattfinden sollte (für Markteffizienz), aber das Protokoll selbst führt die Arbitrage durch und erfasst den Gewinn, um ihn später zu verteilen (z.B. an Staker oder als Liquiditäts-Mining-Anreize). Dies eliminiert die Notwendigkeit externer Arbitrage-Bots für diese Möglichkeiten und stellt sicher, dass der Wert im Ökosystem verbleibt. ProtoRev war das erste seiner Art auf einer großen Chain und demonstriert, wie tiefe Integration die Externalitäten von MEV mindern kann: Nutzer, die auf Osmosis handeln, erleiden weniger Slippage, denn wenn nach ihrem Handel eine Arbitrage existiert, wird das Protokoll sie schließen und den Wert im Wesentlichen an Osmosis zurückerstatten (was indirekt den Nutzern über niedrigere Gebühren oder Token-Rückkäufe usw. zugutekommen könnte). Darüber hinaus befähigt Skip Chains, Anti-MEV-Maßnahmen wie Schwellenwert-Verschlüsselung für den Mempool zu implementieren. Zum Beispiel implementiert Osmosis in Zusammenarbeit mit Skip und anderen eine Mempool-Verschlüsselung, bei der Transaktionen verschlüsselt eingereicht und erst nach einer festen Zeit offengelegt werden (ähnlich Anomas Idee, aber auf Chain-Ebene). Obwohl kein Skip-Produkt im eigentlichen Sinne, ist Skips Architektur kompatibel – Skips Auktion kann auf verschlüsselten Transaktionen laufen, indem die Auktion auf deklarierten Geboten basiert, anstatt den Transaktionsinhalt zu lesen. In Bezug auf die Unterdrückung schädlicher MEV: Skips Konsensregeln wie „kein Front-Running erlaubt“ (durch Zustandsprüfungen durchgesetzt) sind eine direkte Maßnahme, um bösartiges Verhalten zu stoppen. Wenn ein Validator versucht, einen Sandwich-Angriff einzuschließen, würden andere Validatoren erkennen, dass das Zustandsergebnis die No-Frontrunning-Regel verletzt (zum Beispiel könnten sie prüfen, dass kein Handel unmittelbar von einem anderen von derselben Adresse in einer Weise vor- und nachfolgte, die einen Vorteil nutzte). Dieser Block würde abgelehnt. Da Validatoren dies wissen, werden sie solche Muster gar nicht erst versuchen einzuschließen, wodurch Nutzer durch Protokollrecht geschützt sind. Skip fördert auch das Verbrennen oder Umverteilen von MEV-Einnahmen, um perverse Anreize zu vermeiden. Zum Beispiel könnte eine Chain beschließen, alle Auktionserlöse zu verbrennen oder in einen Community-Fonds zu legen, anstatt sie alle dem Block-Proposer zu geben. Dies reduziert den Anreiz für Validatoren, Transaktionen selbst neu anzuordnen, da sie möglicherweise nicht persönlich davon profitieren (abhängig von der Wahl der Chain). Zusammenfassend ermöglicht Skips Toolkit jeder Chain, MEV dort chirurgisch zu extrahieren, wo es vorteilhaft ist (z.B. Arbitrage zur Aufrechterhaltung der Markteffizienz, Liquidationen zur Aufrechterhaltung gesunder Kreditmärkte) und sicherzustellen, dass dieser Wert vom Protokoll oder den Nutzern erfasst wird, während bösartige MEV (wie nutzerunfreundliches Frontrunning) strengstens verboten und verhindert wird. Es ist eine pragmatische Mischung aus Extraktion und Unterdrückung, maßgeschneidert durch Governance: Anstatt einer Einheitslösung befähigt Skip Communities zu entscheiden, welche MEV „gut“ ist (und ihre Erfassung zu automatisieren) und welche „schlecht“ ist (und sie über Konsensregeln zu verbieten). Das Ergebnis ist eine fairere Handelsumgebung auf Skip-fähigen Chains und eine zusätzliche Einnahmequelle, die öffentliche Güter finanzieren oder Kosten senken kann (einer von Skips Blogbeiträgen weist darauf hin, dass eine faire MEV-Erfassung verwendet werden kann, um „Einnahmen fair unter allen Netzwerkteilnehmern zu verteilen“).

• Ökonomische Anreizstruktur: Die Einführung von Skip verschiebt die Anreize grundlegend, insbesondere für Validatoren und Chain-Communities in Cosmos. Traditionell könnte ein Validator in Cosmos MEV extrahieren, indem er Transaktionen in seinem Block privat neu anordnet (da Cosmos standardmäßig keine MEV-Auktion hat). Mit Skip stimmen Validatoren stattdessen einem Protokoll zu, bei dem MEV über Auktionen oder Module erfasst und oft geteilt wird. Validatoren profitieren immer noch: Sie können einen Anteil an den Auktionserlösen oder zusätzliche Gebühren aus Skips Mechanismen erhalten, aber wichtig ist, dass alle Validatoren (nicht nur der Proposer) davon profitieren können, wenn es so konzipiert ist. Zum Beispiel können einige Skip-Auktionen so konfiguriert werden, dass die Einnahmen unter allen Stakern oder gemäß Governance-Entscheidungen aufgeteilt werden, anstatt dass der Proposer alles gewinnt. Dies stimmt Validatoren kollektiv darauf ab, die Skip-Software auszuführen, da selbst Nicht-Proposer Sicherheit erhalten (wissend, dass ein ungültiger Blockversuch sich nicht auszahlt) und möglicherweise Einnahmen. Einige Chains könnten dem Proposer immer noch den größten Teil der MEV-Auktionsgebühr geben (um den sofortigen Anreiz zur Aufnahme zu maximieren), aber selbst dann ist es transparent und wettbewerbsorientiert, was wohl die Wahrscheinlichkeit von Unter-der-Hand-Geschäften reduziert. Chain/Community: Das Konzept der protokolleigenen MEV bedeutet, dass die Blockchain und ihre Stakeholder MEV erfassen. Zum Beispiel leitet Osmosis ProtoRev-Gewinne in seinen Community-Pool, wodurch MEV effektiv zu einer zusätzlichen Protokolleinnahme wird, die die Entwicklung finanzieren oder an OSMO-Staker verteilt werden könnte. Dies macht die Community im Allgemeinen zu einem „Eigentümer“ dieser MEV, wodurch die Interessen aller auf eine gesunde MEV-Extraktion ausgerichtet werden. Wenn Nutzer wissen, dass die MEV zur Verbesserung der Chain oder Tokenomics zurückfließt, akzeptieren sie dies möglicherweise eher, als wenn sie an einen zufälligen Bot geht. Searcher: In Skips Modell haben unabhängige Searcher/Bots möglicherweise weniger On-Chain zu tun, da einige Möglichkeiten von der Protokolllogik (wie ProtoRev) übernommen und andere über Auktionen kanalisiert werden. Skip eliminiert Searcher jedoch nicht – vielmehr kanalisiert es sie dazu, über die richtigen Wege zu bieten. Ein Searcher kann immer noch eine komplexe Strategie versuchen, aber um die Aufnahme an einer bestimmten Stelle zu garantieren, sollte er an Skips Auktion (Skip Select) teilnehmen, indem er sein Bundle mit einem Gebot einreicht. Wenn nicht, riskiert er, dass ein Validator ihn zugunsten eines Bieters ignoriert oder der eigene Mechanismus der Chain die Möglichkeit nutzt. So entwickeln sich Searcher in Cosmos, um mit Skip zu arbeiten: z.B. reichen viele Arbitrageure auf Osmosis ihre Arbs jetzt über Skips System ein. Sie zahlen einen Teil an die Chain, behalten weniger Gewinn, aber das ist der Preis, um mitzuspielen. Im Laufe der Zeit könnten einige „Searcher“-Rollen vollständig absorbiert werden (wie Backrunning-Arbitrage – ProtoRev erledigt dies, sodass kein externer Searcher konkurrieren kann). Dies könnte Spam und verschwendete Mühe im Netzwerk reduzieren (keine mehreren Bots mehr, die sich gegenseitig überbieten; nur eine Protokollausführung). Nutzer: Endnutzer profitieren von einer faireren Umgebung (keine überraschenden MEV-Angriffe). Außerdem belohnen einige Skip-Konfigurationen Nutzer explizit: MEV-Umverteilung an Nutzer ist möglich. Zum Beispiel könnte eine Chain beschließen, einen Teil der MEV-Auktionserlöse an die Nutzer zurückzuerstatten, deren Trades diese MEV erzeugt haben (ähnlich Flashbots' Rückerstattungsidee). Astroport, ein DEX auf Terra, integrierte Skip, um MEV-Einnahmen mit Swappern zu teilen – was bedeutet, dass, wenn der Handel eines Nutzers MEV hatte, ein Teil dieses Wertes standardmäßig an ihn zurückgegeben wird. Dies stimmt mit dem Ethos überein, dass MEV an Nutzer gehen sollte. Obwohl nicht alle Chains dies tun, besteht die Möglichkeit über Skips Infrastruktur, solche Schemata zu implementieren. Skip Protocol selbst (das Unternehmen/Team) hat ein Geschäftsmodell, bei dem sie diese Tools oft kostenlos an Validatoren bereitstellen (um die Akzeptanz zu fördern), und sie monetarisieren, indem sie mit Chains zusammenarbeiten (B2B). Zum Beispiel könnte Skip eine kleine Gebühr von der erfassten MEV nehmen oder Chains für erweiterte Funktionen/Support berechnen. Es wird erwähnt, dass Skip für Validatoren kostenlos ist, aber ein B2B-Modell mit Chains verwendet. Das bedeutet, Skip hat einen Anreiz, die von der Chain und Community erfasste MEV zu maximieren (damit die Chain zufrieden ist und vielleicht einen Teil gemäß Vereinbarung teilt). Da jedoch Governance involviert ist, wird jede Gebühr, die Skip nimmt, normalerweise von der Community vereinbart. Der wirtschaftliche Effekt ist interessant: Es professionalisiert die MEV-Extraktion als Dienstleistung, die Chains angeboten wird. Dabei entmutigt es Fehlverhalten – Validatoren müssen nicht einzeln zwielichtige Geschäfte machen, sie können einfach Skip nutzen und erhalten einen zuverlässigen Fluss zusätzlicher Einnahmen, der sozial akzeptiert ist. Ehrliches Verhalten (Befolgen der Protokollregeln) bringt fast genauso viel oder mehr Gewinn als der Versuch zu betrügen, denn wenn man betrügt, könnte der Block ungültig sein oder man könnte sozial bestraft werden usw. Governance spielt eine wichtige Rolle: Die Übernahme von Skips Modul oder die Festlegung der Parameter (wie Auktionsanteil, Verteilung der Erlöse) erfolgt über On-Chain-Vorschläge. Das bedeutet, dass die wirtschaftlichen Ergebnisse (wer die MEV erhält) letztendlich durch Community-Abstimmung bestimmt werden. Zum Beispiel diskutiert der Cosmos Hub die Übernahme von Skips Builder SDK, um MEV möglicherweise an die Schatzkammer oder Staker des Hubs umzuleiten. Diese Ausrichtung durch Governance stellt sicher, dass die Nutzung von MEV von der Community als legitim angesehen wird. Sie verwandelt MEV von einem toxischen Nebenprodukt in eine öffentliche Ressource, die zugewiesen werden kann (für Sicherheit, Nutzer, Entwickler usw.). Zusammenfassend formt Skip Anreize so um, dass Validatoren kollektiv und Nutzer/Community profitieren, während opportunistische MEV-Nehmer entweder in das System integriert (als Bieter) oder ausgeschlossen werden. Theoretisch sind alle besser dran: Nutzer verlieren weniger Wert an MEV, Validatoren werden immer noch entschädigt (sogar möglicherweise insgesamt mehr, aufgrund von Auktionen), und das Netzwerk als Ganzes kann MEV nutzen, um sich selbst zu stärken (finanziell oder durch eine fairere Erfahrung). Die einzigen Verlierer sind diejenigen, die von Nullsummen-Extraktion lebten, ohne Wert zurückzugeben.

• Compliance und regulatorische Kompatibilität: Skips Framework, indem es die Chain-Governance stärkt, erleichtert es Chains tatsächlich, Compliance oder spezifische Richtlinien sicherzustellen, wenn sie dies wünschen. Da Skip auf Protokollebene arbeitet, könnte eine Chain wählen, bestimmte Transaktionsfilter- oder Reihenfolgeregeln durchzusetzen, um Vorschriften einzuhalten. Wenn beispielsweise eine Chain sanktionierte Adressen blockieren wollte, könnte sie eine AnteHandler- oder AuctionDecorator-Regel in Skips Modul integrieren, die Blöcke mit auf der Blacklist stehenden Adressen für ungültig erklärt. Dies ist wohl einfacher als in Ethereum, wo Zensur eine Off-Chain-Wahl einzelner Validatoren ist; in Cosmos mit Skip könnte es eine Chain-weite Regel sein (obwohl es kontrovers wäre und für viele gegen Dezentralisierungs-Ideale verstößt). Alternativ könnte eine Chain etwas wie „FIAT-Onramp-Transaktionen müssen vor anderen erscheinen“ durchsetzen, wenn dies gesetzlich vorgeschrieben ist. Das Skip-Toolkit kommt nicht mit voreingestellten Compliance-Regeln, aber es ist flexibel genug, um sie zu implementieren, wenn eine Community dazu gezwungen ist (durch Governance). Auf der anderen Seite kann Skip die Zensurresistenz stärken: Durch die Verteilung von MEV-Einnahmen und die Gewährung gleichen Zugangs reduziert es den Vorteil eines einzelnen Validators, der aus Profitgründen zensieren könnte. Wenn außerdem Schwellenwert-Verschlüsselungs-Mempools (wie der, den Osmosis hinzufügt) mit Skip Standard werden, wird dies Transaktionsinhalte verbergen, was die Zensur erschwert (wie in Anoma). Skip ist eine neutrale Infrastruktur – es kann je nach Governance entweder zur Einhaltung oder zum Widerstand verwendet werden. Da Cosmos-Chains oft jurisdiktionsspezifisch sind (die Terra-Community könnte sich um koreanische Gesetze sorgen, Kava um US-Gesetze usw.), ist die Option, Compliance zu konfigurieren, wertvoll. Zum Beispiel könnte eine permissioned Cosmos-Chain (wie eine institutionelle Chain) immer noch Skips Builder-Modul verwenden, aber vielleicht verlangen, dass nur Whitelist-Adressen an Auktionen bieten dürfen usw., um ihren Vorschriften zu entsprechen. Regulatorische Kompatibilität betrifft auch die Transparenz: Skips On-Chain-Auktionen erzeugen einen öffentlichen Datensatz von MEV-Transaktionen und wer was bezahlt hat. Dies könnte tatsächlich einige regulatorische Bedenken hinsichtlich der Fairness befriedigen (jeder hatte die Möglichkeit zu bieten, und es ist auditierbar). Es ist transparenter als Unter-der-Hand-Zahlungen an Validatoren. Auch durch die Erfassung von MEV On-Chain reduziert Skip die Wahrscheinlichkeit von Off-Chain-Kartellen oder Dark Pools, die Regulierungsbehörden aufgrund ihrer Undurchsichtigkeit fürchten. Zum Beispiel könnten Validatoren ohne Skip private Deals mit Searchern eingehen (wie bei den Relay-Zensurproblemen gesehen). Mit Skip wird erwartet, dass man die offizielle Auktion – die offen und protokolliert ist – nutzt, um Priorität zu erhalten. Dies fördert einen offenen Markt, der allen Bots gleichermaßen zugänglich ist, was wohl fairer und weniger anfällig für Absprachen ist (Absprachen sind möglich, aber es gibt eine Governance-Aufsicht). Ein weiterer Compliance-Aspekt: Da Skip die Werterfassung behandelt, könnten Fragen aufgeworfen werden, wenn MEV-Einnahmen in einen Community-Pool oder eine Schatzkammer fließen (ist es eine Gebühr, ist es steuerpflichtig usw.?). Aber diese ähneln der Handhabung von Transaktionsgebühren, also nichts grundlegend Neues rechtlich. In Cosmos können Chain-Communities auch entscheiden, wie sie diesen Fonds verwenden (verbrennen, verteilen usw.), was sie bei Bedarf an rechtliche Vorgaben anpassen können (zum Beispiel könnten sie vermeiden, ihn an eine Stiftung zu senden, wenn dies Steuerprobleme auslöst, und ihn stattdessen verbrennen). In Bezug auf die Zensurresistenz ein interessanter Hinweis: Durch die Durchsetzung von Blockgültigkeitsregeln verhindert Skip, dass Validatoren bestimmte Transaktionen zensieren, wenn dies Regeln verletzen würde. Wenn beispielsweise eine Chain die Regel hätte „muss mindestens ein Oracle-Update enthalten“, könnte ein zensierender Validator nicht einfach alle Oracle-Transaktionen (die aus bestimmten Quellen stammen könnten) weglassen, weil sein Block ungültig wäre. Ironischerweise können Skip-Regeln also die Aufnahme kritischer Transaktionen erzwingen (Anti-Zensur), genauso wie sie verwendet werden könnten, um den Ausschluss nicht erlaubter zu erzwingen. Es hängt alles davon ab, was die Community festlegt. Neutralität: Skips Standardhaltung ist, Chains zu befähigen, „Nutzer vor negativer MEV zu schützen und die Nutzererfahrung zu verbessern“, was Neutralität und Nutzerfreundlichkeit impliziert. Es gibt kein zentrales Skip-Netzwerk, das Entscheidungen trifft – jede Chain ist souverän. Skip als Unternehmen könnte beraten oder Standardeinstellungen bereitstellen (wie ein empfohlenes Auktionsformat), aber letztendlich entscheiden die Token-Inhaber der Chain. Diese Dezentralisierung der MEV-Politik auf die Governance jeder Chain kann als kompatibler mit regulatorischer Vielfalt angesehen werden: z.B. könnte eine US-basierte Chain die OFAC-Compliance implementieren, wenn sie rechtlich unter Druck gesetzt wird, ohne andere Chains zu beeinflussen. Es ist kein einziges Relay, das über viele Chains hinweg zensiert; es ist eine pro-Chain-Wahl. Aus regulatorischer Sicht führt Skip keine zusätzlichen illegalen Aktivitäten ein – es reorganisiert lediglich, wie Transaktionen geordnet werden. Wenn überhaupt, könnte es die Volatilität reduzieren (weniger Gas-Kriege) und eine vorhersehbarere Ausführung schaffen, was ein Pluspunkt sein könnte. Zusammenfassend ist Skips Architektur hochgradig anpassbar an Compliance-Bedürfnisse, während die Option für maximale Zensurresistenz erhalten bleibt, wenn Communities dies priorisieren. Es hält MEV im Tageslicht und unter kollektiver Kontrolle, was Blockchain-Ökosysteme wahrscheinlich robuster gegen bösartige Akteure und regulatorische Maßnahmen macht, da die Selbstverwaltung Missbräuche proaktiv angehen kann.

• Technische Architektur & Implementierung: Skip Protocol ist eng in den Cosmos SDK Stack integriert. Die Kernleistung ist ein Satz von Modulen (z.B. x/builder) und Modifikationen wie die BlockBuster Mempool-Implementierung. Cosmos-Chains betreiben einen Konsens (Tendermint/CometBFT), der ABCI-Hooks für die Vorbereitung und Verarbeitung von Vorschlägen bietet. Skip nutzt die ABCI++-Erweiterungen, die die Ausführung von Code zwischen Blockvorschlag und Finalisierung ermöglichen. So wird die Reihenfolge durchgesetzt: PrepareProposal kann die Blocktransaktionen gemäß den Lane-Regeln neu anordnen, bevor der Vorschlag gesendet wird, und ProcessProposal bei empfangenden Validatoren kann die Reihenfolge und die Zustandsgültigkeit auf Übereinstimmung mit den Erwartungen überprüfen. Dies ist eine moderne Funktion (Cosmos SDK v0.47+), und Skips POB ist mit aktuellen SDK-Versionen kompatibel. Unter der Haube pflegen Skips Module Datenstrukturen für Auktionen (z.B. ein On-Chain-Orderbuch von Geboten für Top-of-Block). Sie verwenden wahrscheinlich auch Prioritätstransaktionstypen. Die README zeigt eine spezielle MsgAuctionBid und benutzerdefinierte Logik zur Handhabung. Searcher interagieren also, indem sie diese Nachrichten über normale Cosmos-Transaktionen senden, die das Modul dann abfängt und entsprechend platziert. Der AnteHandler des Builder-Moduls (der AuctionDecorator) kann Auktionsgebote verbrauchen und Gewinner bestimmen in der Block-Assembly-Phase. Kryptographisch fügt Skip keine neuen kryptographischen Anforderungen hinzu (abgesehen von dem, was die Chain wählt, wie Schwellenwert-Kryptographie für den Mempool, was separat ist). Es verlässt sich auf die Ehrlichkeit von >2/3 der Validatoren, um die Regeln durchzusetzen und nicht zu kolludieren, um sie zu brechen. Wenn eine Mehrheit kolludieren würde, könnten sie technisch die Regeln über Governance ändern oder sie ignorieren, indem sie dies zur neuen De-facto-Regel machen. Aber das ist bei jeder Chain-Logik der Fall. Skips Design versucht, es einem einzelnen Validator mechanisch unmöglich zu machen, im kleinen Maßstab zu betrügen. Zum Beispiel wird jeder Versuch, die Reihenfolge zu ändern, von anderen erkannt, weil es objektiv ist. Es reduziert also das Vertrauen in einzelne Proposer. In Bezug auf die Leistung fügt das Ausführen von Auktionen und zusätzlichen Prüfungen Overhead hinzu. Cosmos-Blöcke sind jedoch relativ klein und die Zeit zwischen den Blöcken beträgt oft ein paar Sekunden, was in den meisten Fällen für diese Operationen ausreicht. Die Simulation (Vorab-Ausführung von Transaktionen, um sicherzustellen, dass keine Fehler auftreten und die Reihenfolge-Einschränkungen eingehalten werden) könnte der aufwendigste Teil sein, aber Validatoren führen Blockausführungen normalerweise bereits durch, daher ist dies ähnlich. Die Anwesenheit von Multi-Lane bedeutet Mempool-Trennung: z.B. muss eine Transaktion möglicherweise angeben, welche Lane sie anvisiert (Auktion vs. Free vs. Default). Das Skip BlockBuster-Design hatte tatsächlich separate Lanes wie lanes/auction, lanes/free usw., wahrscheinlich separate Mempool-Warteschlangen. Das stellt sicher, dass beispielsweise kostenlose Transaktionen Auktions-Transaktionen nicht verzögern oder stören. Es ist ein bisschen wie mehrere Prioritätsklassen in der Zeitplanung zu haben. Ein weiterer Aspekt ist Sicherheit und Fehlverhalten: Wenn ein Proposer versucht, die Auktion zu manipulieren (z.B. seine eigene Transaktion aufzunehmen, aber zu behaupten, sie habe die Regeln befolgt), werden andere Validatoren den Block ablehnen. Der Cosmos-Konsens geht dann wahrscheinlich zum nächsten Proposer über und bestraft den vorherigen für Double-Signing oder einfach das Verpassen (je nach Szenario). Das Chain-Sicherheitsmodell handhabt dies also – keine spezielle Slashing durch Skip erforderlich, die über den bestehenden Konsens hinausgeht. Man könnte Skip erweitern, um für bösartige Reihenfolge zu bestrafen, aber wahrscheinlich unnötig, wenn der Block einfach fehlschlägt. Entwicklung und Tools: Skips Code wurde quelloffen gemacht (anfänglich unter skip-mev/pob und jetzt wahrscheinlich nach stabilen Releases in ein neues Repo verschoben). Sie haben Testnets und Iterationen mit Partner-Chains durchlaufen. Auf der Roadmap haben wir gesehen: Osmosis Prop 341 (im Herbst 2022 verabschiedet) zur Integration von ProtoRev und Auktionen mit Skip – im Frühjahr 2023 geliefert. Terras Astroport integrierte MEV-Sharing mit Skip im Jahr 2023. Der Cosmos Hub evaluiert Skips „Block SDK“, das ähnliche Funktionen in den Hub bringen würde. Eine weitere interessante Grenze ist Cross-Chain-MEV über den Interchain Scheduler – die Cosmos Hub-Community erforscht eine Interchain-MEV-Auktion, bei der MEV von vielen Chains im Hub gehandelt werden könnte, und Skip ist an diesen Diskussionen beteiligt (die Zerocap-Forschung erwähnte den geplanten Interchain Scheduler von IBC). Skips Technologie könnte als Rückgrat für solche Cross-Chain-Auktionen dienen, da sie bereits Auktionen auf einzelnen Chains durchführt. Das wäre analog zu SUAVEs Cross-Domain-Ziel, aber innerhalb von Cosmos. Was wichtige Updates betrifft: Skip wurde Mitte 2022 gestartet. Mitte 2023 hatten sie eine stabile POB-Veröffentlichung für SDK v0.47+ (auf das viele Chains aktualisieren). Sie haben auch Startkapital erhalten, was auf eine aktive Entwicklung hindeutet. Ein weiterer Konkurrent in Cosmos, Mekatek, bietet ähnliche Funktionen. Dies hat Skips Roadmap vielleicht beschleunigt, um die Nase vorn zu behalten. Skip verfeinert weiterhin Funktionen wie private Transaktions-Lanes (vielleicht zum Verbergen von Transaktionen bis zur Aufnahme) und komplexere Gültigkeitsregeln, wenn Anwendungsfälle entstehen. Da es modular ist, könnte eine Chain wie dYdX (die ein Orderbuch haben wird) Skip verwenden, um Fairness beim Order-Matching On-Chain usw. zu gewährleisten, sodass Skips Tools sich an unterschiedliche Anwendungslogiken anpassen könnten. Technisch gesehen ist Skips Lösung einfacher als der Aufbau einer ganz neuen Chain: Es ist eine Verbesserung der Fähigkeiten bestehender Chains. Dieser inkrementelle, Opt-in-Ansatz hat eine ziemlich schnelle Akzeptanz ermöglicht – z.B. erforderte die Aktivierung von Auktionen auf Osmosis keinen neuen Konsensalgorithmus, sondern nur das Hinzufügen eines Moduls und die Koordination der Validatoren, die aktualisierte Software auszuführen (was sie taten, da es vorteilhaft war und von der Governance verabschiedet wurde). Zusammenfassend ist Skips Architektur in die Node-Software jeder Chain eingebettet und passt den Mempool und die Blockvorschlags-Pipeline an. Es ist ein pragmatischer technischer Ansatz für faire Reihenfolge: Verwenden, was bereits vorhanden ist (Tendermint BFT), Logik hinzufügen, um es zu steuern. Die schwere Arbeit (wie das Finden von Arbitragen) kann sogar vom eigenen Modul der Chain erledigt werden (ProtoRev verwendet Osmosis' eingebauten Wasm- und Rust-Code, um Pools zu scannen). So wird ein Großteil der MEV-Handhabung On-Chain verlagert. Dieser On-Chain-Ansatz muss sorgfältig auf Effizienz und Sicherheit kodiert werden, steht aber unter der Aufsicht der Community. Wenn eine Regel problematisch ist (zu streng usw.), kann die Governance sie anpassen. Technisch und sozial verwandelt Skip MEV somit in einen weiteren Parameter der Chain, der optimiert und verwaltet werden muss, anstatt in einen Wilden Westen. Dies ist eine einzigartige Haltung, die durch die Flexibilität von Cosmos ermöglicht wird.

Vergleichende Analyse von SUAVE, Anoma, Skip und Flashbots v2​

Diese vier Protokolle nähern sich dem MEV- und Fair-Ordering-Problem aus verschiedenen Blickwinkeln, zugeschnitten auf ihre jeweiligen Ökosysteme und Designphilosophien. Flashbots v2 ist eine inkrementelle, pragmatische Lösung für Ethereums aktuelle Architektur: Es umfasst MEV-Auktionen, versucht aber, deren Auswirkungen zu demokratisieren und abzumildern (durch Off-Chain-Koordination, SGX-Privatsphäre und Sharing-Mechanismen). SUAVE ist Flashbots' zukunftsweisender Plan, eine Inter-Chain-MEV-Plattform zu schaffen, die den Gesamtwert und die Nutzervorteile maximiert – im Wesentlichen die Skalierung des Auktionsmodells auf ein dezentrales, datenschutzfreundliches globales Netzwerk. Anoma ist eine grundlegende Neukonzeption der Formulierung und Ausführung von Transaktionen, die darauf abzielt, die Grundursachen unfairer Reihenfolge durch die Verwendung von Intents, Solver-vermittelter Übereinstimmung und kryptographischer Fairness im Konsens zu eliminieren. Skip ist ein souveräner Chain-Ansatz, der Fairness und MEV-Erfassung auf Protokollebene pro Chain integriert, insbesondere in Cosmos, durch konfigurierbare Regeln und Auktionen.

Jedes hat Stärken und Kompromisse:

• Fairness- und Reihenfolgegarantien: Anoma bietet die stärkste theoretische Fairness (kein Frontrunning per Design, verschlüsselte Batches), erfordert aber ein neues Paradigma und komplexe Technologie, die noch bewiesen werden muss. Skip kann konkrete Fairness-Regeln auf bestehenden Chains durchsetzen (Front-Runs verhindern oder First-In-First-Out innerhalb von Lanes erzwingen), ist aber durch das begrenzt, was jede Community durchzusetzen wählt. SUAVE und Flashbots v2 verbessern die Fairness in Bezug auf den Zugang (offene Auktionen statt geheimer Deals, Schutz vor öffentlichem Mempool-Sniping), verhindern aber nicht von Natur aus, dass eine entschlossene MEV-Strategie ausgeführt wird – sie stellen lediglich sicher, dass sie die Nutzer bezahlt oder neutral durchgeführt wird.
• MEV-Umverteilung: SUAVE und Flashbots zielen explizit darauf ab, MEV „zurück“ an Nutzer/Validatoren zu geben: SUAVE über Nutzergebote/Rückerstattungen, Flashbots über Builder-Wettbewerbe und Rückerstattungen. Skip kann MEV an Nutzer (wie konfiguriert, z.B. im Fall von Astroport) oder an Community-Fonds leiten. Anoma vermeidet eine explizite Umverteilung, da das Ziel darin besteht, die Extraktion überhaupt zu vermeiden – idealerweise erhalten Nutzer einfach faire Preise, was gleichbedeutend damit ist, keinen Wert an MEV zu verlieren.
• Umfang (Einzel- vs. Mehrfachdomäne): Flashbots v2 und Skip konzentrieren sich auf ihre eigenen Domänen (Ethereum bzw. einzelne Cosmos-Chains). SUAVE ist von Natur aus mehrfachdomänenfähig – es sieht Cross-Chain-MEV als Hauptmotivation. Anoma berücksichtigt schließlich auch Multi-Chain-Intents, aber in den Anfangsphasen könnte dies innerhalb einer fraktalen Instanz gleichzeitig geschehen, dann über Adapter überbrückt werden. SUAVEs Cross-Chain-Auktion könnte Arbitrage und Koordination ermöglichen, die andere nicht so einfach erreichen können (außer vielleicht ein Interchain Scheduler mit Skips Hilfe in Cosmos).
• Komplexität und Akzeptanz: Flashbots v2 war relativ einfach zu übernehmen (ein Client-Sidecar) und erfasste schnell die Mehrheit der Ethereum-Blöcke. Skip nutzt ebenfalls bestehende Technologie und findet in Cosmos mit unkomplizierten Governance-Vorschlägen Akzeptanz. SUAVE und Anoma sind revolutionärer – sie erfordern neue Netzwerke oder größere Änderungen. SUAVEs Herausforderung wird darin bestehen, viele Chains und Nutzer dazu zu bringen, sich für eine neue Schicht zu entscheiden; Anomas Herausforderung besteht darin, ein neues Ökosystem zu schaffen und Entwickler davon zu überzeugen, in einem Intent-zentrierten Modell zu bauen.
• Compliance und Neutralität: Alle vier bieten Verbesserungen in der Transparenz. Flashbots v2/SUAVE entfernen Dark-Forest-Elemente, mussten aber Zensurprobleme bewältigen – SUAVE wird explizit gebaut, um diese zentralen Punkte zu vermeiden. Anoma schützt Nutzer mit standardmäßiger Privatsphäre maximal (könnte aber Regulierungsbehörden aufgrund verschlüsselter Aktivitäten beunruhigen). Skips Modell gibt jeder Chain Autonomie, einen Compliance-Kompromiss zu finden. Wenn eine Regulierungsbehörde „keine MEV-Auktionen“ oder „keine Privatsphäre“ forderte, könnte ein Ethereum, das Flashbots verwendet, in Konflikt geraten, während eine Cosmos-Chain, die Skip verwendet, diese Funktionen einfach nicht implementieren oder anpassen könnte. In Bezug auf Neutralität: SUAVE und Anoma streben glaubwürdige Neutralität an (jeder greift zu gleichen Bedingungen auf ein System zu; beide sind im Wesentlichen öffentliche Güternetzwerke). Flashbots v2 ist neutral, indem es offenen Zugang bietet, aber eine gewisse Zentralisierung im Builder-Markt besteht (obwohl durch BuilderNet-Bemühungen gemildert). Skips Neutralität hängt von der Governance ab – idealerweise begünstigt MEV keinen einzelnen Insider, aber man könnte es schlecht konfigurieren und die Neutralität schädigen (obwohl unwahrscheinlich, da dies einen Governance-Konsens erfordern würde).
• Technische Architekturunterschiede: Flashbots v2 und SUAVE sind Off-Chain-Marktplätze, die auf der Chain geschichtet sind: Sie führen spezialisierte Rollen (Builder, Relays, Executors) ein und verwenden Hardware oder Kryptographie, um sie zu sichern. Anoma und Skip integrieren sich direkt in den Konsens oder die Zustandsmaschine. Anoma ändert den Transaktionslebenszyklus und den Konsens selbst (mit Schwellenwert-Verschlüsselung und vereinheitlichten Intents). Skip greift über ABCI++ in den Konsens von Tendermint ein, ändert aber den grundlegenden Algorithmus nicht – es ist eine Anwendungsschicht-Anpassung. Dieser Unterschied bedeutet, dass SUAVE/Flashbots theoretisch viele Chains bedienen können, ohne dass jede Chain ein Upgrade benötigt (sie laufen parallel zu ihnen), während Anoma/Skip erfordern, dass jede Chain oder Instanz die neue Software verwendet. SUAVE ist etwas dazwischen: Es ist eine separate Chain, aber um sie effektiv zu nutzen, benötigen andere Chains geringfügige Anpassungen (um von SUAVE gebaute Blöcke zu akzeptieren oder an SUAVE auszugeben). Die kryptographische Raffinesse ist am höchsten in Anoma (ZK, MPC, Schwellenwert-Krypto alles in einem), moderat in SUAVE (Schwellenwert-Krypto und SGX, plus normale Krypto für Bridging) und relativ gering in Flashbots v2 (SGX, Standard-Signaturen) und Skip (hauptsächlich Standard-Signaturen, plus was die Chain verwendet, wie Schwellenwert-Entschlüsselung, wenn gewählt).
• Entwicklungsstand: Flashbots v2 ist in Produktion auf Ethereum (seit September 2022). Skip ist in Produktion auf mehreren Cosmos-Chains (ab 2022–2023). SUAVE befindet sich in der Testnet-/Devnet-Phase, wobei Teile ausgerollt werden (einige Auktionsfunktionen in Tests, Testnet Toliman live). Anoma befindet sich ebenfalls in der Testnet-Phase (ein Vision-Paper, partielle Implementierungen wie Namada Mainnet und wahrscheinlich ein Anoma Testnet, das 2023 Einladungscodes erfordert). In Bezug auf reale Daten: Flashbots v2 und Skip haben Ergebnisse gezeigt (z.B. lieferte Flashbots v2 Millionen an Validatoren und senkte die durchschnittlichen Gaspreise in Zeiten hoher MEV; Skips ProtoRev generierte erhebliche Mittel für die Osmosis-Community und verhinderte viele Sandwich-Angriffe, als die Schwellenwert-Verschlüsselung begann). SUAVE und Anoma sind vielversprechend, müssen sich aber operativ und wirtschaftlich noch bewähren.

Um diese Vergleiche zu verdeutlichen, fasst die folgende Tabelle die wichtigsten Aspekte jedes Protokolls nebeneinander zusammen:

| Protokoll | Transaktionsreihenfolge Flash to the German translation:

Summary of differences in the German translation:

• Title: "MEV Suppression and Fair Transaction Ordering: SUAVE vs. Anoma vs. Skip vs. Flashbots v2" -> "MEV-Unterdrückung und faire Transaktionsreihenfolge: SUAVE vs. Anoma vs. Skip vs. Flashbots v2"
• Tags/Keywords/Description: Translated accordingly, preserving technical terms.
• Image URLs: The title parameter in the opengraph-image.blockeden.xyz URLs has been updated with the URL-encoded German title.
• Terminology: Consistent use of German blockchain/Web3 terms (e.g., "Maximal Extrahierbarer Wert" for MEV, "Transaktionsreihenfolge", "Blockproduktion", "Konsens", "Smart Contracts", "Dezentralisierung", "Liquiditätsanbieter", "Staking", "Slashing", "Schatzkammer", "Community-Pool").
• Spacing: Ensured proper spacing around punctuation and symbols as per German grammar rules.
• Technical Concepts: All technical concepts like PBS, TEE, SGX, ZK-proofs, MPC, IBC, Cosmos SDK, Tendermint, ABCI++, mempool, frontrunning, backrunning, sandwich attack, arbitrage, liquidation, validator, builder, searcher, relay, bundle, orderflow are either kept in their English form (as they are commonly used in the German crypto space) or translated where a standard German equivalent exists and is widely accepted. For example, "Frontrunning" is often used directly, but "Front-Run-Slippage" might be translated to "Front-Run-Slippage" or explained. I've opted to keep common English terms where they are prevalent in the German Web3 context to maintain accuracy and avoid awkward translations.

---

title: "MEV-Unterdrückung und faire Transaktionsreihenfolge: SUAVE vs. Anoma vs. Skip vs. Flashbots v2" tags: [MEV, Blockchain, Transaktionsreihenfolge, Flashbots, SUAVE, Anoma, Skip Protocol] keywords: [MEV-Unterdrückung, faire Transaktionsreihenfolge, Blockchain-Protokolle, Flashbots v2, SUAVE, Anoma, Skip Protocol] description: "Ein umfassender Vergleich von Blockchain-Protokollen zur Unterdrückung schädlicher MEV und zur Durchsetzung einer fairen Transaktionsreihenfolge, mit Fokus auf Flashbots v2, SUAVE, Anoma und Skip Protocol. Entdecken Sie deren Transaktionswarteschlangen-Algorithmen, MEV-Minderungsmechanismen und Anreizmodelle, um deren Auswirkungen auf Fairness und Dezentralisierung zu verstehen." authors: [dora] image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=MEV-Unterdr%C3%BCckung%20und%20faire%20Transaktionsreihenfolge%3A%20SUAVE%20vs.%20Anoma%20vs.%20Skip%20vs.%20Flashbots%20v2"​

MEV-Unterdrückung und faire Transaktionsreihenfolge: SUAVE vs. Anoma vs. Skip vs. Flashbots v2

Maximal Extrahierbarer Wert (MEV) bezieht sich auf den Gewinn, den ein Blockchain-„Insider“ (Miner/Validator oder anderer privilegierter Akteur) erzielen kann, indem er Transaktionen in einem Block willkürlich neu anordnet, einschließt oder ausschließt. Eine unkontrollierte MEV-Extraktion kann zu unfairer Transaktionsreihenfolge, hohen Gebühren (durch Priority Gas Auctions) und einer Zentralisierung der Macht bei der Blockproduktion führen. Eine Reihe von Protokollen ist entstanden, um schädliche MEV zu unterdrücken oder eine faire Reihenfolge von Transaktionen durchzusetzen. Dieser Bericht vergleicht vier prominente Ansätze: Flashbots v2 (das Flashbots MEV-Boost-System nach dem Merge für Ethereum), SUAVE (Flashbots' bevorstehende Single Unifying Auction for Value Expression), Anoma (eine Intent-zentrierte Architektur, die die Art und Weise, wie Transaktionen abgeglichen und geordnet werden, neu überdenkt) und Skip Protocol (ein Cosmos-basiertes Toolkit für souveränes In-Protocol-MEV-Management). Wir untersuchen jedes dieser Protokolle hinsichtlich ihrer Transaktionswarteschlangen-/Reihenfolge-Algorithmen, MEV-Minderungs- oder Extraktionsmechanismen, Anreizmodelle, Compliance- und Neutralitätsfunktionen, technischen Architektur (Konsens und Kryptographie) und des Entwicklungsfortschritts. Strukturierte Zusammenfassungen und eine Vergleichstabelle werden bereitgestellt, um ihre Stärken und Kompromisse bei der Verfolgung von Fairness und der Reduzierung der negativen Externalitäten von MEV hervorzuheben.

Flashbots v2 (MEV-Boost & BuilderNet auf Ethereum)​

Flashbots v2 bezeichnet das aktuelle Flashbots-Ökosystem auf Ethereum nach Proof-of-Stake, das sich um MEV-Boost und jüngste Initiativen wie BuilderNet dreht. Flashbots v2 baut auf dem Proposer/Builder-Separation (PBS)-Paradigma auf, um die Blockkonstruktion einem wettbewerbsorientierten Markt von Buildern zu öffnen und gleichzeitig Ethereum-Nutzer vor öffentlichen Mempool-MEV-Angriffen zu schützen.

• Transaktionsreihenfolge (Warteschlange & Algorithmus): Flashbots MEV-Boost führt einen Off-Chain-Marktplatz für die Blockerstellung ein. Validatoren (Proposer) lagern die Blockkonstruktion über ein Relay an spezialisierte Builder aus, anstatt Transaktionen lokal zu ordnen. Mehrere Builder konkurrieren darum, den höchstbezahlten Block bereitzustellen, und der Validator signiert blind den Header des Blocks mit dem höchsten Gebot (ein PBS-Ansatz). Dieses Design ersetzt effektiv die First-Come, First-Served-Reihenfolge des öffentlichen Mempools durch eine Sealed-Bid-Auktion für ganze Blöcke. Builder bestimmen die Transaktionsreihenfolge intern, um die Gesamtgewinne (einschließlich MEV-Möglichkeiten) zu maximieren, wobei sie typischerweise Bundles mit profitablen Arbitragen oder Liquidationen an den Anfang des Blocks stellen. Durch die Verwendung von MEV-Boost vermied Ethereum die chaotischen Priority Gas Auctions (PGAs), die zuvor die Reihenfolge bestimmten; anstatt dass Nutzer und Bots in Echtzeit über Gasgebühren bieten (was die Überlastung erhöht), zentralisiert MEV-Boost die Reihenfolge pro Block auf den wettbewerbsfähigsten Builder. Transaktionswarteschlangen werden somit privat von Buildern verwaltet, die eingehende Bundles oder Transaktionen sehen und sie für optimalen Gewinn anordnen können. Ein Nachteil ist, dass diese gewinnorientierte Reihenfolge nicht von Natur aus „Fairness“ für Nutzer durchsetzt – z.B. können Builder immer noch toxische Orderflows wie Sandwich-Angriffe einschließen, wenn sie profitabel sind – aber sie optimiert die Effizienz, indem sie MEV durch eine kontrollierte Auktion statt durch Ad-hoc-Gas-Kriege extrahiert. Jüngste Entwicklungen zielen darauf ab, die Reihenfolge neutraler zu gestalten: Zum Beispiel ermöglicht Flashbots' neues BuilderNet (Ende 2024 gestartet), dass mehrere zusammenarbeitende Builder Orderflow teilen und Blöcke gemeinsam in einer Trusted Execution Environment konstruieren, wodurch verifizierbare Reihenfolgeregeln eingeführt werden, um die Fairness zu verbessern. Dies verlagert die Blockreihenfolge von einem einzigen zentralisierten Builder hin zu einem dezentralen Block-Building-Netzwerk mit Regeln, die auf Neutralität geprüft werden können.

• MEV-Unterdrückungs- vs. Extraktionsmechanismen: Flashbots v2 erleichtert in erster Linie die MEV-Extraktion in einer gutartigen Form, anstatt sie zu eliminieren. Das ursprüngliche Flashbots (v1)-System im Jahr 2021 ermöglichte es Searchern, Bundles (bevorzugte Transaktionssätze) direkt an Miner zu senden, was schädliche Externalitäten unterdrückte (kein öffentliches Frontrunning, keine fehlgeschlagenen Transaktionen aufgrund von Wettrennen), während MEV weiterhin extrahiert wurde. In der MEV-Boost-Ära wird MEV von Buildern extrahiert, die profitable Transaktionen bündeln, aber der Negativsummen-Wettbewerb wird reduziert: Searcher spammen den Mempool nicht mehr mit konkurrierenden Transaktionen und exorbitanten Gasgebühren, was Netzwerküberlastung und übermäßige Gebühren für Nutzer mindert. Flashbots v2 bietet auch MEV-Minderungstools für Nutzer: Zum Beispiel ermöglicht Flashbots Protect RPC Nutzern, Transaktionen privat an ein Relay zu senden, wodurch öffentliches Mempool-Frontrunning verhindert wird (niemand kann die Transaktion vor der Aufnahme sehen oder neu anordnen). Eine weitere Initiative, MEV-Share, lässt Nutzer gerade genug Informationen über ihre Transaktionen teilen, um MEV-Gebote anzuziehen, während sie einen Teil des Wertes für sich selbst erfassen. Flashbots v2 „verhindert“ jedoch keine MEV wie Sandwiches oder Arbitrage – es kanalisiert diese Aktivitäten durch eine effiziente Auktion, die wohl demokratisiert, wer die MEV extrahieren kann. Jüngst hat das Design von BuilderNet das explizite Ziel, „Negativsummen-Orderflow-Spiele zu neutralisieren“ und MEV über On-Chain-Rückerstattungsregeln an die Community zurückzugeben. BuilderNet berechnet Rückerstattungen, die an Orderflow-Anbieter (wie Wallets oder DApps) proportional zur MEV gezahlt werden, die ihre Transaktionen generiert haben, wodurch Wert umverteilt wird, der sonst reiner Gewinn für Builder wäre. Zusammenfassend maximiert Flashbots v2 die Effizienz der MEV-Extraktion (stellt sicher, dass fast der gesamte extrahierbare Wert in einem Block tatsächlich erfasst wird), während es Maßnahmen einführt, um die schlimmsten Externalitäten einzudämmen und einen Teil des Wertes an die Nutzer zurückzugeben. Es geht nicht so weit, eine faire Reihenfolge durchzusetzen (Transaktionen werden immer noch nach Builder-Gewinn geordnet), aber durch private Einreichung, Multi-Party-Building und Rückerstattungen unterdrückt es den negativen Nutzerschaden (wie Front-Run-Slippage und Zensureffekte) so weit wie möglich innerhalb des Auktionsmodells.

• Ökonomische Anreizstruktur: Flashbots v2 gleicht die Anreize zwischen Validatoren, Buildern und Searchern durch die PBS-Auktion ab. Validatoren profitieren von der Auslagerung der Blockproduktion – sie akzeptieren einfach das höchste Gebot und erhalten den Gebotsbetrag (zusätzlich zu den Konsensbelohnungen), was den Anteil der MEV, der an Validatoren geht, dramatisch erhöhte im Vergleich zu der Ära, in der Miner keine solchen Auktionen hatten. Builder werden dazu angeregt, sich gegenseitig zu überbieten, indem sie die profitabelste Reihenfolge von Transaktionen finden (oft unter Einbeziehung von Searcher-Strategien), und sie behalten jeden MEV-Gewinn, der nach Zahlung des Validator-Gebots übrig bleibt. In der Praxis zwingt der Wettbewerb Builder dazu, den größten Teil der MEV an Validatoren zu zahlen (oft >90% des Gewinns), wobei sie nur eine geringe Marge behalten. Searcher (die jetzt über Bundles oder direkte Transaktionen mit Buildern interagieren) verdienen immer noch, indem sie MEV-Möglichkeiten (Arbitrage, Liquidation usw.) entdecken, aber sie müssen den größten Teil ihres Gewinns bieten, um die Aufnahme zu gewinnen – effektiv werden Searcher-Gewinne über Builder-Gebote an Validatoren übertragen. Dieses Wettbewerbsgleichgewicht maximiert den gesamten Netzwerkumsatz (was Validatoren/Stakern zugutekommt), drückt aber die individuellen Searcher-Margen. Flashbots v2 entmutigt somit exklusive Deals: Jeder Searcher oder Builder mit einer privaten MEV-Strategie wird dazu angeregt, diese über das offene Relay zu bieten, um nicht unterboten zu werden, was zu einem offeneren Markt führt. Die Einführung von BuilderNet fügt einen Anreiz für Orderflow-Originatoren (wie DEXs oder Wallets) hinzu – indem sie ihnen Rückerstattungen für die MEV geben, die ihre Transaktionen erzeugen, ermutigt es Nutzer und Apps, Orderflow an das BuilderNet-Ökosystem zu senden. Dieser Mechanismus bringt Nutzer mit dem System in Einklang: Anstatt antagonistisch zu sein (Nutzer vs. MEV-Extraktoren), teilen Nutzer an der MEV, sodass sie eher bereit sind, fair an der Auktion teilzunehmen. Insgesamt begünstigt die Ökonomie von Flashbots v2 die Zusammenarbeit gegenüber dem Wettbewerb beim Block-Building: Validatoren erhalten maximale Einnahmen risikofrei, Builder konkurrieren um die Ausführungsqualität, und Searcher innovieren, um MEV zu finden, geben aber die meisten Gewinne ab, um Gebote zu gewinnen, während Nutzer Schutz und möglicherweise Rabatte erhalten.

• Compliance und Zensurresistenz: Die Einhaltung gesetzlicher Vorschriften wurde nach dem Ethereum Merge zu einem strittigen Thema für Flashbots. Das Standard-Flashbots-Relay implementierte zunächst die OFAC-Sanktions-Compliance (Zensur bestimmter Transaktionen wie Tornado Cash) – was Ende 2022 dazu führte, dass ~80% der Ethereum-Blöcke „OFAC-konform“ waren und Bedenken hinsichtlich Zentralisierung/Zensur in der Community aufkommen ließ. Flashbots v2 begegnete dem, indem es ein Multi-Relay-Ökosystem förderte, in dem Validatoren nicht-zensierende Relays (z.B. UltraSound, Agnostic) wählen oder sogar ihre eigenen betreiben können. Flashbots hat seinen Relay-Code Mitte 2022 quelloffen gemacht, um globalen Relay-Wettbewerb und Transparenz zu fördern. Zusätzlich führte MEV-Boost v1.4 Funktionen wie eine Mindestgebots-Einstellung ein, damit Proposer niedrige Gebote von zensierenden Buildern ablehnen und auf lokale Blöcke zurückgreifen konnten, wobei sie etwas Gewinn für die Aufnahme aller Transaktionen opferten. Diese Funktion gab Validatoren explizit eine Möglichkeit, die Zensurresistenz von Ethereum zu geringen Kosten zu verbessern. Ende 2024 ging Flashbots einen weiteren Schritt, indem es seinen eigenen zentralisierten Builder einstellte zugunsten von BuilderNet – einem kollaborativen Netzwerk, das „unzensierbar und neutral“ sein soll. BuilderNet verwendet TEEs (Intel SGX), um den Transaktions-Orderflow verschlüsselt zu halten und sich verifizierbar an eine Reihenfolgeregel zu binden, was dazu beitragen kann, dass einzelne Builder bestimmte Transaktionen nicht zensieren. Mit mehreren Teilnehmern, die gemeinsam Blöcke in sicheren Enklaven bauen, kann keine einzelne Partei eine Transaktion ohne Entdeckung leicht ausschließen. Kurz gesagt, Flashbots v2 hat sich von einem einzelnen (und anfänglich zensierenden) Relay zu einer dezentraleren Infrastruktur mit offener Beteiligung und expliziten Neutralitätszielen entwickelt. Die Compliance wird den Richtlinien der einzelnen Relays/Builder überlassen (und Validatoren können wählen), anstatt vom Protokoll durchgesetzt zu werden. Die Entwicklung geht in Richtung glaubwürdiger Neutralität: die Beseitigung aller von Flashbots kontrollierten Engpässe, die von Regulierungsbehörden unter Druck gesetzt werden könnten. Flashbots hat sich öffentlich dazu verpflichtet, sich als zentraler Betreiber zurückzuziehen und alle Aspekte der MEV-Lieferkette langfristig zu dezentralisieren.

• Technische Architektur & Kryptographie: Flashbots v2 arbeitet Off-Chain und In-Protocol hybrid. Die Kernauktion (MEV-Boost) findet Off-Chain über das Builder- und Relay-Netzwerk statt, ist aber direkt in Ethereums Konsens integriert: Validatoren betreiben einen Sidecar-Client (mev-boost), der über die standardisierte Builder API mit Relays kommuniziert. Konsens-technisch verwendet Ethereum immer noch Standard-PoS (Casper/Hotstuff) – MEV-Boost ändert die L1-Konsensregeln nicht; es ändert nur, wer den Block zusammensetzt. Anfangs erforderte die Flashbots-Auktion Vertrauen in das Relay und den Builder, dass sie Transaktionen nicht stehlen oder zensieren – es gab keine kryptographischen Garantien (das System verließ sich auf den wirtschaftlichen Anreiz, dass Builder eine gültige Payload liefern müssen, die ihrem Gebot entspricht, sonst verlieren sie den Slot). Im Laufe der Zeit hat Flashbots v2 mehr Sicherheitstechnologie integriert. Die Einführung von Trusted Execution Environments (TEE) über BuilderNet ist eine bemerkenswerte architektonische Verschiebung: Builder laufen innerhalb von SGX-Enklaven, sodass selbst der Builder-Betreiber den rohen Transaktions-Orderflow nicht sehen kann (was verhindert, dass sie ihn leaken oder frontrunnen). Diese Enklaven folgen gemeinsam einem Protokoll, um Blöcke zu produzieren, was verifizierbare Fairness ermöglichen kann (z.B. den Nachweis, dass Transaktionen nach einer festgelegten Regel geordnet wurden oder dass keine unbefugte Entität sie vor der Aufnahme gesehen hat). Während SGX verwendet wird (ein hardwarebasierter Ansatz), erforscht Flashbots auch rein kryptographische Primitive – z.B. Schwellenwertverschlüsselung für Mempool-Privatsphäre und sichere Mehrparteienberechnung – um TEEs schließlich zu ersetzen oder zu ergänzen und das Vertrauen weiter zu reduzieren. Der Software-Stack von Flashbots v2 umfasst benutzerdefinierte Clients wie MEV-geth (jetzt obsolet) und Rust-basierte Builder (z.B. rbuilder), und er hält sich an Ethereums Builder-Spezifikationen für Interoperabilität. Zusammenfassend ist die Architektur modular: ein Netzwerk von Relays, Buildern und jetzt Enklaven, das zwischen Nutzern und Ethereum-Proposern sitzt. Es priorisiert Leistung (schnelles Bieten, Blocklieferung) und fügt schrittweise kryptographische Zusicherungen von Privatsphäre und fairer Reihenfolge hinzu. Es wird kein neuer Konsensalgorithmus eingeführt; stattdessen arbeitet Flashbots v2 neben Ethereums Konsens und entwickelt die Blockproduktionspipeline weiter, anstatt die Konsensregeln zu ändern.

• Entwicklungs-Roadmap & Meilensteine: Flashbots hat iterative Phasen durchlaufen. Flashbots v1 (2020–2021) umfasste den Start von MEV-geth und die ersten Off-Chain-Bundle-Auktionen mit Minern. Mitte 2021 liefen über 80% der Ethereum-Hashrate mit Flashbots' MEV-geth, was die Akzeptanz des Ansatzes bestätigte. Flashbots v2 (2022) wurde im Vorfeld des Merge konzipiert: Im November 2021 veröffentlichte Flashbots die MEV-Boost-Architektur für PoS Ethereum. Nachdem Ethereum auf PoS umgestellt hatte (15. September 2022), wurde MEV-Boost innerhalb weniger Tage aktiviert und erreichte schnell eine Mehrheitsbeteiligung der Validatoren. Spätere Meilensteine umfassten die Quelloffenlegung des Relays (August 2022) und des internen Block-Builders von Flashbots (November 2022), um den Wettbewerb anzukurbeln. Ende 2022 fügte Flashbots auch Funktionen hinzu, die sich auf Zensurresistenz und Resilienz konzentrierten (z.B. Min-Bid für Proposer) und schrieb über die „Kosten der Resilienz“, um Validatoren zu ermutigen, manchmal die Aufnahme über den Gewinn zu stellen. Im Laufe des Jahres 2023 wurde die Verbesserung der Builder-Dezentralisierung zu einem Schwerpunkt: Flashbots veröffentlichte „rbuilder“ (einen Hochleistungs-Rust-Builder) im Juli 2024 als Referenzimplementierung, um die Hürde für neue Builder zu senken. Schließlich startete Flashbots Ende 2024 BuilderNet (Alpha) in Zusammenarbeit mit Partnern (Beaverbuild, Nethermind). Bis Dezember 2024 schaltete Flashbots seinen zentralisierten Builder ab und migrierte den gesamten Orderflow zu BuilderNet – ein bedeutender Schritt in Richtung Dezentralisierung. Anfang 2025 wurde BuilderNet v1.2 mit Sicherheits- und Onboarding-Verbesserungen (einschließlich reproduzierbarer Enklaven-Builds) veröffentlicht. Diese Meilensteine markieren den Übergang von Flashbots von einer zweckmäßigen zentralisierten Lösung zu einem offeneren, von der Community betriebenen Protokoll. Mit Blick auf die Zukunft konvergiert Flashbots mit seiner Vision der nächsten Generation (SUAVE), um die Block-Building-Schicht vollständig zu dezentralisieren und fortschrittliche Datenschutztechnologien zu integrieren. Viele Lehren aus Flashbots v2 (z.B. die Notwendigkeit von Neutralität, Multi-Chain-Umfang und Nutzer-Einbeziehung von MEV-Belohnungen) fließen direkt in die SUAVE-Roadmap ein.

SUAVE (Flashbots’ Single Unifying Auction for Value Expression)​

SUAVE ist Flashbots' ehrgeiziges nächstes Protokoll, das als dezentraler, domänenübergreifender MEV-Marktplatz und faire Transaktionssequenzierungsschicht konzipiert ist. Es zielt darauf ab, Mempools und Block-Building von einzelnen Blockchains zu entkoppeln und eine einheitliche Plattform bereitzustellen, auf der Nutzer Präferenzen äußern, ein dezentrales Netzwerk Transaktionen optimal ausführt und Block-Builder Blöcke über viele Chains hinweg auf glaubwürdig neutrale Weise produzieren. Kurz gesagt, SUAVE versucht, die gesamte Wertschöpfung zu maximieren, während es den Nutzern Wert zurückgibt und die Dezentralisierung der Blockchain bewahrt. Flashbots stellte SUAVE Ende 2022 als „die Zukunft von MEV“ vor und entwickelt es seitdem offen.

• Warteschlange und Transaktionsreihenfolge: Aus übergeordneter Sicht fungiert SUAVE als ein unabhängiges Blockchain-Netzwerk, das andere Chains als Plug-and-Play-Mempool und Block-Builder nutzen können. Anstatt dass Transaktionen in den Mempools jeder Chain in die Warteschlange gestellt und von lokalen Minern oder Validatoren geordnet werden, können Nutzer ihre Transaktionen (oder allgemeiner, Präferenzen) in den Mempool des SUAVE-Netzwerks senden. Der SUAVE-Mempool dient dann als globaler Auktionspool von Präferenzen aller teilnehmenden Chains. Die Reihenfolge der Transaktionen wird durch diese Auktion und die anschließende Ausführungsoptimierung bestimmt. Insbesondere führt SUAVE ein Konzept von Präferenzen ein: Die Einreichung eines Nutzers ist nicht nur eine rohe Transaktion für eine Chain, sondern kann ein Ziel oder einen bedingten Handel (möglicherweise über mehrere Chains hinweg) und ein damit verbundenes Gebot kodieren, das der Nutzer für die Erfüllung zu zahlen bereit ist. Der Reihenfolge-/Warteschlangenalgorithmus in SUAVE hat mehrere Stufen: Zuerst posten Nutzer ihre Präferenzen in den SUAVE-Mempool (die „Universal Preference Environment“), der alle Aufträge privat und global aggregiert. Als Nächstes überwachen spezialisierte Knoten, sogenannte Executors (analog zu Searchern/Solvern), diesen Mempool und konkurrieren in einem Optimal Execution Market, um diese Präferenzen zu erfüllen. Sie „reihen“ Transaktionen effektiv ein, indem sie Übereinstimmungen oder optimale Ausführungsreihenfolgen für sie finden. Schließlich produziert SUAVE Block-Outputs für jede verbundene Chain über eine Decentralized Block Building-Schicht: Viele Builder (oder SUAVE-Executors, die als Builder fungieren) arbeiten zusammen, um Blöcke unter Verwendung der (jetzt optimierten) Transaktionsreihenfolge zu konstruieren, die aus den Nutzerpräferenzen abgeleitet wurde. In praktischer Hinsicht ist die Reihenfolge von SUAVE flexibel und nutzergesteuert: Ein Nutzer kann Bedingungen wie „führe meinen Handel nur aus, wenn der Preis < X“ angeben oder sogar eine abstrakte Absicht („tausche Token A gegen B zum besten Kurs innerhalb von 1 Minute“) anstelle einer strengen Transaktion ausdrücken. Das System reiht diese Absichten in die Warteschlange ein, bis ein Executor eine optimale Reihenfolge oder Übereinstimmung findet (möglicherweise durch Batching mit anderen). Da SUAVE Blockchain-agnostisch ist, kann es die Reihenfolge über Chains hinweg koordinieren (wodurch Szenarien verhindert werden, in denen Cross-Chain-Arbitragen aufgrund unkoordinierter separater Mempools verpasst werden). Im Wesentlichen implementiert SUAVE eine globale MEV-Auktion: Alle Teilnehmer teilen sich eine Sequenzierungsschicht, die Transaktionen basierend auf aggregierten Präferenzen und Geboten ordnet, anstatt nach einfacher Zeit oder Gaspreis. Dies hat den Effekt, das Spielfeld zu ebnen – der gesamte Orderflow läuft durch eine transparente Warteschlange (wenn auch zur Wahrung der Privatsphäre verschlüsselt, wie unten erläutert) anstatt durch exklusive Deals oder private Mempools. Der Reihenfolgealgorithmus von SUAVE wird noch verfeinert, aber er wird wahrscheinlich datenschutzfreundliche Batch-Auktionen und Matching-Algorithmen umfassen, damit „faire“ Ergebnisse (wie maximaler Gesamtüberschuss oder nutzeroptimale Preise) erzielt werden können, anstatt reiner First-Come-First-Served. Insbesondere beabsichtigt SUAVE, zu verhindern, dass ein einzelner Akteur die Reihenfolge manipuliert: Es ist Ethereum-nativ und MEV-aware, mit einem datenschutzfreundlichen verschlüsselten Mempool, der vor zentralen Kontrollpunkten schützt. Zusammenfassend ist die Warteschlange von SUAVE ein einheitlicher Orderflow-Pool, in dem die Reihenfolge durch eine Kombination aus Nutzergeboten, Executor-Strategie und (eventuell) kryptographischen Fairness-Einschränkungen bestimmt wird, anstatt durch Block-Proposer, die um Priorität wetteifern.

• MEV-Unterdrückungs-/Extraktionsmechanismen: Die Philosophie von SUAVE besagt, dass MEV zum Nutzen der Nutzer und zur Netzwerksicherheit genutzt werden kann, wenn dies kooperativ und dezentral erfolgt. Anstatt MEV entweder zu ignorieren oder sich in wenigen Händen konzentrieren zu lassen, zeigt SUAVE explizit MEV-Möglichkeiten auf und gibt den Wert so weit wie möglich an diejenigen zurück, die ihn schaffen (Nutzer). Der primäre Mechanismus ist die Orderflow-Auktion: Wann immer die Transaktion (Präferenz) eines Nutzers MEV enthält – zum Beispiel könnte sie gewinnbringend backrunnt werden – führt SUAVE eine Auktion unter Executors (Searchern) für das Recht durch, diese MEV-Möglichkeit auszuführen. Searcher (Executors) bieten, indem sie einen Teil des Gewinns als Zahlung an den Nutzer zurückversprechen (dies ist das „Gebot“-Feld des Nutzers in seiner Präferenz, das an denjenigen geht, der es erfüllt). Das Ergebnis ist eine wettbewerbsorientierte MEV-Extraktion, die Einnahmen an den Nutzer statt an den Extraktor weiterleitet. Wenn beispielsweise ein großer DEX-Handel eines Nutzers eine Arbitrage-Möglichkeit von 100 $schafft, könnten Searcher auf SUAVE den Gewinn drücken, indem sie dem Nutzer beispielsweise 90$ als Rabatt anbieten und nur 10 $ behalten. Dies unterdrückt die negativen Aspekte von MEV wie die Wertentnahme durch den Nutzer und verwandelt MEV in einen Nutzen für den Nutzer (Nutzer erhalten effektiv eine Preisverbesserung oder Rabatte). Das Design von SUAVE unterdrückt auch Front-Running und andere bösartige MEV: Transaktionen im SUAVE-Mempool können verschlüsselt bleiben, bis ein Block gebaut wird (anfangs mit SGX-Enklaven, später mit Schwellenwert-Kryptographie). Das bedeutet, dass kein externer Akteur ausstehende Transaktionen sehen kann, um sie zu frontrunnen; erst wenn genügend Transaktionen gesammelt und ein Block finalisiert ist, werden sie entschlüsselt und ausgeführt, ähnlich wie bei Batch-Auktionen oder verschlüsselten Mempools, die den Zeitprioritätsvorteil von Bots beseitigen. Da Executors die Ausführung über viele Präferenzen hinweg optimieren, kann SUAVE außerdem ineffizienten Wettbewerb eliminieren (wie zwei Bots, die um dieselbe Arbitrage kämpfen, indem sie spammen). Stattdessen wählt SUAVE den besten Executor durch die Auktion aus, und dieser Executor führt den Handel einmal aus, mit dem Ergebnis, das dem Nutzer und dem Netzwerk zugutekommt. SUAVE fungiert somit als MEV-Aggregator und „gute Fee“: Es eliminiert MEV nicht (die profitablen Möglichkeiten werden immer noch genutzt), aber diese Möglichkeiten werden unter transparenten Regeln und mit Erlösen, die größtenteils an Nutzer und Validatoren verteilt werden (und nicht für Gasgebühren oder Latenzkriege verschwendet werden), realisiert. Durch die Vereinheitlichung von Mempools adressiert SUAVE auch domänenübergreifende MEV auf nutzerfreundliche Weise – z.B. könnte eine Arbitrage zwischen Uniswap auf Ethereum und einem DEX auf Arbitrum von einem SUAVE-Executor erfasst und ein Teil an die Nutzer auf beiden Seiten gezahlt werden, anstatt verpasst zu werden oder einen zentralisierten Arbitrageur zu erfordern. Wichtig ist, dass SUAVE die zentralisierenden Kräfte von MEV unterdrückt: Exklusive Orderflow-Deals (bei denen private Entitäten MEV erfassen) werden unnötig, wenn alle die gemeinsame Auktion nutzen. SUAVE’s ultimative Vision ist es, schädliche MEV-Extraktion zu reduzieren (wie Sandwich-Angriffe, die Slippage verursachen), indem sie entweder unrentabel gemacht oder die Slippage zurückerstattet wird, und „gute MEV“ (Arbitrage, Liquidationen) zur Stärkung von Netzwerken zu nutzen (durch Umsatzbeteiligung und optimale Ausführung). In Flashbots' eigenen Worten ist es das Ziel von SUAVE, sicherzustellen, dass „Nutzer mit der besten Ausführung und minimalen Gebühren handeln“, während „Validatoren maximale Einnahmen erzielen“ – d.h. jede vorhandene MEV wird auf die nutzerfreundlichste Weise extrahiert.

• Ökonomische Anreizstruktur: SUAVE führt neue Rollen und Anreizflüsse in der MEV-Lieferkette ein. Die Hauptteilnehmer sind Nutzer, Executors, Block-Builder/Validatoren und die SUAVE-Netzwerkbetreiber (Validatoren der SUAVE-Chain). Nutzer legen ein Gebot (Zahlung) in ihrer Präferenz fest, das ausgezahlt wird, wenn ihre Bedingungen erfüllt sind. Dieses Gebot ist der Anreiz für Executors: Ein Executor, der die Absicht des Nutzers erfüllt (z.B. seinen Handel backrunnt, um ihm einen besseren Preis zu verschaffen), kann das Gebot als Belohnung beanspruchen. Nutzer zahlen also direkt für Ausführungsqualität, ähnlich wie bei der Ausschreibung einer Belohnung. Executors (Searcher) sind motiviert, Nutzerpräferenzen aus dem SUAVE-Mempool aufzunehmen und zu optimieren, da sie das Gebot des Nutzers plus jeden zusätzlichen Arbitrage-Gewinn, der der Transaktion innewohnt, verdienen. Executors werden darum konkurrieren, dem Nutzer das beste Ergebnis zu bieten, da der Nutzer sein Gebot so festlegen kann, dass er nur zahlt, wenn der Executor tatsächlich das gewünschte Ergebnis erzielt (das Gebot kann über Orakel an On-Chain-Ergebnisse geknüpft sein). Zum Beispiel könnte ein Nutzer sagen: „Ich zahle 0,5 ETH an denjenigen, der diese Transaktion so ausführt, dass ich mindestens X Output erhalte; wenn nicht, keine Zahlung.“ Dies stimmt die Anreize der Executors mit dem Erfolg des Nutzers überein. SUAVE-Validatoren/Builder: Die SUAVE-Chain selbst wird wahrscheinlich ein Proof-of-Stake-Netzwerk sein (Design noch festzulegen), sodass Validatoren (die Blöcke auf SUAVE produzieren) Transaktionsgebühren auf SUAVE verdienen (die von Nutzern stammen, die Gebote posten und andere Operationen durchführen). Da SUAVE eine EVM-kompatible Chain ist, kann es auch ein natives Token- oder Gasgebührensystem für diese Transaktionen geben. Diese Validatoren spielen auch eine Rolle bei der Sequenzierung domänenübergreifender Blöcke; die endgültige Blockaufnahme auf jeder L1 erfolgt jedoch immer noch durch den Validator dieser L1. In vielen Fällen wird SUAVE eine partielle oder vollständige Blockvorlage produzieren, die ein Ethereum- oder anderer Chain-Proposer übernehmen kann. Dieser Builder könnte SUAVE (oder SUAVE-Executors) einen Teil der MEV zahlen. Flashbots hat erwähnt, dass SUAVE-Validatoren durch normale Netzwerkgebühren und Executors durch Gebote motiviert werden. Wertverteilung: Der Ansatz von SUAVE neigt dazu, Wert an die Ränder zu verschieben: Nutzer erfassen Wert (durch bessere Preise oder direkte Rückerstattungen), und Validatoren erfassen Wert (durch erhöhte Gebühren/Gebote). Theoretisch, wenn SUAVE seine Mission erfüllt, wird der größte Teil der MEV entweder an Nutzer zurückgegeben oder zur Entschädigung von Validatoren für die Sicherung des Netzwerks verwendet, anstatt sich bei Searchern zu konzentrieren. Flashbots selbst hat angedeutet, dass es nicht beabsichtigt, von SUAVE Rent-Seeking zu betreiben und keinen Anteil über das hinausnehmen wird, was zum Bootstrapping benötigt wird – sie wollen den Marktplatz gestalten, nicht monopolisieren. Eine weitere Anreizüberlegung sind Cross-Chain-Builder: SUAVE ermöglicht Block-Buildern den Zugriff auf domänenübergreifende MEV, was bedeutet, dass ein Builder auf einer Chain zusätzliche Gebühren verdienen kann, indem er Transaktionen einschließt, die Arbitrage mit einer anderen Chain abschließen. Dies ermutigt Builder/Validatoren verschiedener Chains, alle an SUAVE teilzunehmen, denn ein Verzicht bedeutet entgangene Einnahmen. Im Wesentlichen versucht das wirtschaftliche Design von SUAVE, alle Teilnehmer dazu zu bringen, der gemeinsamen Auktion beizutreten: Nutzer, weil sie eine bessere Ausführung erhalten (und vielleicht MEV-Rabatte), Validatoren, weil sie maximale Einnahmen erhalten, und Searcher, weil dort der Orderflow aggregiert wird. Durch die Konzentration des Orderflows erhält SUAVE auch einen Informationsvorteil gegenüber jedem isolierten Akteur (alle Präferenzen an einem Ort), was alle wirtschaftlich dazu zwingt, innerhalb von SUAVE zusammenzuarbeiten, anstatt sich abzuspalten. Zusammenfassend fördern die Anreize von SUAVE einen positiven Kreislauf: mehr Orderflow → bessere kombinierte MEV-Möglichkeiten → höhere Gebote an Nutzer/Validatoren → mehr Orderflow. Dies steht im Gegensatz zum Nullsummen-Wettbewerb und den exklusiven Deals der Vergangenheit und zielt stattdessen auf „Koopetition“ ab, bei der MEV ein gemeinsamer Wert ist, der wachsen und verteilt werden soll.

• Compliance und regulatorische Überlegungen: SUAVE wird mit glaubwürdiger Neutralität und Zensurresistenz als Kernprinzipien entwickelt. SUAVE entfernt per Design zentrale Vermittler – es gibt keinen einzigen Mempool oder einzigen Builder, der angegriffen oder reguliert werden könnte. Transaktionen (Präferenzen) in SUAVE können vollständig verschlüsselt und privat bleiben, bis sie ausgeführt werden, unter Verwendung sicherer Enklaven und schließlich kryptographischer Techniken. Das bedeutet, dass Zensur auf der Ebene des Transaktionsinhalts unpraktisch ist, da Validatoren/Builder die Transaktionsdetails vor der Finalisierung der Reihenfolge nicht einmal lesen können. SUAVE erzwingt im Wesentlichen einen „Don't trust, verify“-Ansatz: Teilnehmer müssen keiner Entität vertrauen, nicht zu zensieren, da die Systemarchitektur selbst (dezentrales Netzwerk + Verschlüsselung) sicherstellt, dass die Präferenzen aller fair berücksichtigt werden. Darüber hinaus soll SUAVE ein offenes, erlaubnisfreies Netzwerk sein – Flashbots lädt explizit alle Parteien (Nutzer, Searcher, Wallets, andere Blockchains) zur Teilnahme ein. Es gibt kein KYC oder eine Berechtigungsprüfung in seinem Design. Dies könnte Fragen bei Regulierungsbehörden aufwerfen (z.B. könnte das Protokoll die MEV-Extraktion bei sanktionierten Transaktionen erleichtern), aber da SUAVE nur eine dezentrale Plattform ist, wäre die Durchsetzung schwierig und vergleichbar mit dem Versuch, den Mempool einer Blockchain zu regulieren. Der Fokus von SUAVE auf Privatsphäre (durch SGX und später Kryptographie) schützt auch Nutzerdaten und Orderflow vor unerwünschter Überwachung, was positiv für die Nutzersicherheit ist, aber mit regulatorischen Wünschen nach Transparenz kollidieren könnte. Andererseits könnte der Ansatz von SUAVE als fairer und konformer mit dem Geist offener Märkte angesehen werden: Durch die Schaffung gleicher Wettbewerbsbedingungen und die Rückgabe von Wert an die Nutzer reduziert er die ausbeuterischen Aspekte von MEV, die regulatorischen Zorn hervorrufen könnten (wie das Backrunning von Nutzern ohne deren Zustimmung). SUAVE kann auch dazu beitragen, unregulierte Dark Pools zu eliminieren – ein Grund, warum Regulierungsbehörden wegen MEV besorgt sein könnten, sind exklusive Orderflow-Verkäufe (die Insiderhandel ähneln). SUAVE ersetzt diese durch eine transparente öffentliche Auktion, was wohl eine konformere Marktstruktur darstellt. In Bezug auf explizite Compliance-Funktionen könnte SUAVE mehrere Reihenfolge-Richtlinien zulassen: Zum Beispiel könnten Communities oder Jurisdiktionen ihre eigenen Executors mit bestimmten Filtern oder Präferenzen einsetzen. Der Grundsatz ist jedoch, dass SUAVE versuchen wird, maximal neutral zu sein: „alle zentralen Kontrollpunkte, einschließlich Flashbots, eliminieren“ und die Einbettung von politischen Entscheidungen auf Protokollebene vermeiden. Flashbots hat betont, dass es den SUAVE-Marktplatz nicht selbst kontrollieren wird, wenn er reift – was bedeutet, keinen zentralen Kill-Switch oder Zensur-Schalter. Die Governance (falls vorhanden) von SUAVE ist öffentlich noch nicht definiert, aber man kann erwarten, dass sie die breitere Community und möglicherweise ein Token umfasst, anstatt das Fiat-Geld eines Unternehmens. Zusammenfassend ist SUAVE darauf ausgelegt, sich an dezentrale Prinzipien anzupassen, was von Natur aus bestimmte regulatorische Kontrollen (Zensur) widersteht, während es potenziell einige regulatorische Bedenken lindert, indem es die MEV-Extraktion gerechter und transparenter macht.

• Technische Architektur (Konsens & Krypto): SUAVE wird seine eigene Blockchain-Umgebung betreiben – zumindest anfänglich. Es wird als eine EVM-kompatible Chain beschrieben, die auf Präferenzen und MEV spezialisiert ist. Die Architektur besteht aus drei Hauptkomponenten: (1) die Universal Preference Environment (die SUAVE-Chain + Mempool, wo Präferenzen gepostet und aggregiert werden), (2) der Execution Market (Off-Chain- oder On-Chain-Executors, die die Präferenzen lösen/optimieren, ähnlich einer dezentralen „Order-Matching-Engine“) und (3) Decentralized Block Building (ein Netzwerk von SUAVE-Teilnehmern, die Blöcke für verschiedene Domänen zusammenstellen). Im Kern wird der Konsens von SUAVE wahrscheinlich ein Proof-of-Stake BFT-Konsens sein (ähnlich Ethereum oder Cosmos), um die SUAVE-Chain selbst zu betreiben – obwohl noch entschieden wird, ob SUAVE eine L1, eine Ethereum L2 oder eine Suite von „Restaking“-Verträgen wird. Eine Möglichkeit ist, dass SUAVE als Layer-2 oder Sidechain beginnen könnte, die Ethereum für die Finalität nutzt, oder bestehende Validator-Sets leveraged. Das Sicherheitsmodell ist noch festzulegen, aber Diskussionen umfassten, es zu einer Ethereum L3 oder einer Cosmos-Chain zu machen. Kryptographisch stützt sich SUAVE in seiner frühen Roadmap stark auf vertrauenswürdige Hardware und Verschlüsselung. Die Phase SUAVE Centauri implementiert eine „datenschutzbewusste Orderflow-Auktion“, bei der Flashbots (zentral) SGX-Enklaven betreibt, um den Orderflow von Searchern und Nutzern privat zu halten. In SUAVE Andromeda planen sie, SGX-basierte Auktionen und Block-Building ohne Vertrauen in Flashbots zu verwenden (die Enklaven bieten Vertraulichkeit, sodass selbst Flashbots nicht hineinschauen kann). Bis SUAVE Helios ist das Ziel, ein SGX-basiertes dezentrales Building-Netzwerk zu haben – was bedeutet, dass viele unabhängige Parteien Enklaven betreiben, die gemeinsam Blöcke bauen und sowohl Privatsphäre als auch Dezentralisierung erreichen. Langfristig erforscht Flashbots benutzerdefinierte sichere Enklaven und kryptographische Ersatzlösungen wie Schwellenwert-Entschlüsselung und Mehrparteienberechnung, um die Abhängigkeit von Intels SGX zu reduzieren. Zum Beispiel könnten sie ein Schwellenwert-Verschlüsselungsschema verwenden, bei dem Validatoren von SUAVE gemeinsam einen Schlüssel halten, um Transaktionen erst nach der Entscheidung über die Reihenfolge zu entschlüsseln (wodurch sichergestellt wird, dass niemand frontrunnen kann). Dieses Konzept ähnelt Anomas Ferveo oder anderen „fair ordering via threshold encryption“-Ideen. Zusätzlich behandelt SUAVE Nutzerpräferenzen als Smart Contracts auf seiner Chain. Eine Nutzerpräferenz könnte ein Gültigkeitsprädikat und eine Zahlungsbedingung enthalten – dies ist im Wesentlichen ein Stück Code, das besagt: „Wenn Ergebnis X auf Chain Y erreicht wird, dann zahle Executor Z diesen Betrag“. Die SUAVE-Chain muss Orakel und Cross-Chain-Verifizierung handhaben, um zu wissen, wann eine Präferenz erfüllt wurde (z.B. den Ethereum-Status lesen, um zu sehen, ob ein Swap stattgefunden hat). Dies impliziert, dass die Architektur von SUAVE On-Chain-Light-Clients oder Orakel-Systeme für verbundene Chains sowie potenziell atomare Cross-Chain-Abwicklung umfassen wird (um beispielsweise sicherzustellen, dass ein Executor auf Ethereum und Arbitrum ausführen und das Gebot atomar beanspruchen kann). SUAVE plant, hochgradig erweiterbar zu sein: Da es EVM-kompatibel ist, könnten beliebige Verträge (SUAVE-native „Präferenzen“ oder sogar normale DApps) darauf ausgeführt werden, obwohl die Absicht ist, den Fokus auf die Orderflow-Koordination zu legen. Konsens-technisch könnte SUAVE innovativ sein, indem es eine Intent-zentrierte Chain statt einer Transaktions-zentrierten ist, aber letztendlich muss es Nachrichten (Präferenzen) ordnen und Blöcke wie jede Chain produzieren. Man kann sich vorstellen, dass SUAVE einen Konsensalgorithmus annimmt, der für Durchsatz und geringe Latenz-Finalität optimiert ist, da es im kritischen Pfad von Transaktionen für viele Chains liegen wird. Vielleicht könnte eine Tendermint-ähnliche sofortige Finalität oder sogar ein DAG-basierter Konsens verwendet werden, um Präferenzen schnell zu bestätigen. Unabhängig davon liegen die Unterscheidungsmerkmale von SUAVE auf der Transaktionsschicht, nicht auf der Konsensschicht: die Verwendung von Datenschutztechnologie (SGX, Schwellenwert-Verschlüsselung) für die Reihenfolge, domänenübergreifende Kommunikation und Smart-Order-Routing-Logik, die in das Protokoll integriert ist. Dies macht es zu einer Art „Meta-Schicht“ über bestehenden Blockchains. Technisch gesehen muss jede teilnehmende Chain den SUAVE-Outputs bis zu einem gewissen Grad vertrauen (z.B. müsste ein Ethereum-Proposer einen von SUAVE gebauten Block akzeptieren oder SUAVE-Vorschläge aufnehmen). Flashbots hat angedeutet, dass SUAVE schrittweise und opt-in eingeführt wird – Domänen können wählen, SUAVE-Sequenzierung für ihre Blöcke zu übernehmen. Bei breiter Akzeptanz könnte SUAVE zu einem De-facto-MEV-aware Transaktions-Routing-Netzwerk für Web3 werden. Zusammenfassend ist die Architektur von SUAVE eine Verbindung von Blockchain und Off-Chain-Auktion: eine spezialisierte Chain für die Koordination, verbunden mit Off-Chain-sicherer Berechnung unter Executors, alles verankert durch kryptographische Garantien für Fairness und Privatsphäre.

• Entwicklungs-Roadmap & Meilensteine: Flashbots hat die Roadmap von SUAVE in drei Hauptmeilensteinen skizziert, benannt nach Sternensystemen: Centauri, Andromeda und Helios. Centauri (die erste Phase, in Entwicklung im Jahr 2023) konzentriert sich auf den Aufbau einer zentralisierten, aber datenschutzfreundlichen Orderflow-Auktion. In dieser Phase betreibt Flashbots den Auktionsdienst (wahrscheinlich in SGX), der Searchern ermöglicht, zu bieten, um Nutzertransaktionen backrunnen zu lassen, und MEV privat an die Nutzer zurückzugeben. Es beinhaltet auch den Start eines SUAVE-Devnets für frühe Tests. Tatsächlich hat Flashbots im August 2023 einen frühen SUAVE-Client (suave-geth) quelloffen gemacht und Toliman, das erste öffentliche SUAVE-Testnet, gestartet. Dieses Testnet wurde verwendet, um mit der Präferenzexpression und der grundlegenden Auktionslogik zu experimentieren. Andromeda (die nächste Phase) wird das erste SUAVE-Mainnet einführen. Hier werden Nutzer in der Lage sein, Präferenzen in einem Live-Netzwerk auszudrücken, und der Execution Market wird in Betrieb sein (Executors erfüllen Absichten). Andromeda führt auch SGX-basierte Auktionen und Block-Building auf eine stärker verteilte Weise ein – wodurch die Notwendigkeit entfällt, Flashbots als Betreiber zu vertrauen, und das System für Searcher und Builder wirklich erlaubnisfrei wird. Ein Ergebnis in dieser Phase ist die Verwendung von SGX zur Verschlüsselung des Orderflows auf eine Weise, dass selbst Block-Builder nicht hineinschauen können, aber dennoch Blöcke bauen können (d.h. „offener, aber privater“ Orderflow). Helios ist die ehrgeizige dritte Phase, in der SUAVE volle Dezentralisierung und Cross-Chain-Funktionalität erreicht. In Helios produziert ein dezentrales Netzwerk von Buildern in SGX kollaborativ Blöcke (keine Dominanz eines einzelnen Builders). Außerdem wird SUAVE „eine zweite Domäne“ jenseits von Ethereum aufnehmen – was bedeutet, dass es MEV für mindestens zwei Chains handhaben wird, was Cross-Chain-MEV-Auktionen demonstriert. Zusätzlich wird die Expression und Ausführung von Cross-Domain-MEV ermöglicht (Nutzer können wirklich Multi-Chain-Absichten posten und diese atomar ausführen lassen). Über Helios hinaus erwartet Flashbots die Erforschung benutzerdefinierter Hardware und fortschrittlicher Kryptographie (wie ZK-Proofs oder MPC), um Vertrauensgarantien weiter zu stärken. Bisherige wichtige Updates und Meilensteine: November 2022 – SUAVE angekündigt; August 2023 – erste SUAVE-Code-Veröffentlichung und Testnet (Toliman); laufend 2024 – Centauri-Phase Orderflow-Auktion läuft (Flashbots hat angedeutet, dass dies mit Nutzertransaktionen in einer geschlossenen Umgebung getestet wird). Ein bemerkenswerter Meilenstein wird der Start des SUAVE-Mainnets (Andromeda) sein, der Mitte 2025 bevorsteht. Flashbots hat sich verpflichtet, SUAVE offen zu entwickeln und zur Zusammenarbeit einzuladen aus dem gesamten Ökosystem. Dies spiegelt sich in den Forschungs- und Forumsdiskussionen wider, wie den „Stargazing“-Beiträgen, die über die Designentwicklung von SUAVE informieren. Das Endziel für SUAVE ist, dass es zu einer gemeinschaftseigenen Infrastruktur wird – der „dezentralen Sequenzierungsschicht“ für die gesamte Krypto-Welt. Dies zu erreichen, wird einen wichtigen Meilenstein im Kampf um faire Reihenfolge markieren: Wenn SUAVE erfolgreich ist, wäre MEV kein dunkler Wald mehr, sondern eine transparente, gemeinsame Wertquelle, und keine einzelne Chain müsste die zentralisierenden Effekte von MEV alleine erleiden.

Anoma (Intent-Centric Architecture for Fair Counterparty Discovery)​

Anoma ist ein radikal anderer Ansatz zur Ermöglichung fairer Reihenfolge und MEV-Minderung – es ist eine gesamte Architektur für Intent-basierte Blockchain-Infrastruktur. Anstatt eine Auktion an bestehende Chains anzudocken, überdenkt Anoma das Transaktionsparadigma von Grund auf neu. In Anoma senden Nutzer keine konkreten Transaktionen; sie senden Intents – Erklärungen darüber, welchen Endzustand sie wünschen – und das Netzwerk selbst entdeckt Gegenparteien und bildet Transaktionen, die diese Intents erfüllen. Durch die Integration von Gegenpartei-Entdeckung, fairer Reihenfolge und Privatsphäre auf Protokollebene zielt Anoma darauf ab, bestimmte Formen von MEV (wie Frontrunning) praktisch zu eliminieren und „Frontrunner-freie“ dezentrale Börsen und Abwicklungen zu ermöglichen. Anoma ist eher ein Framework als eine einzelne Chain: Jede Blockchain kann eine „fraktale Instanz“ von Anoma sein, indem sie ihre Intent-Gossip- und Matching-Architektur übernimmt. Für diese Diskussion konzentrieren wir uns auf Anomas erste Implementierung (manchmal Anoma L1 genannt) und ihre Kernprotokollfunktionen, soweit sie sich auf Fairness und MEV beziehen.

• Warteschlange und Transaktionsreihenfolge: Anoma verwirft den konventionellen Mempool von Transaktionen; stattdessen verfügt es über ein Gossip-Netzwerk von Intents. Nutzer senden einen Intent, z.B. „Ich möchte 100 DAI gegen mindestens 1 ETH tauschen“ oder „Ich möchte gegen Sicherheiten zum besten Kurs leihen.“ Diese Intents sind partielle Orders – sie spezifizieren keine exakten Ausführungspfade, sondern nur das gewünschte Ergebnis und die Einschränkungen. Alle Intents werden im Netzwerk verbreitet und gesammelt. Die Reihenfolge in Anoma funktioniert nun in zwei Stufen: (1) Gegenpartei-Entdeckung/Matching und (2) Transaktionsausführung mit fairer Reihenfolge. In Stufe 1 überwachen spezialisierte Knoten, sogenannte Solver, kontinuierlich den Pool von Intents und versuchen, Sätze von Intents zu finden, die sich gegenseitig ergänzen, um eine gültige Transaktion zu bilden. Wenn beispielsweise Alice DAI gegen ETH tauschen möchte und Bob ETH gegen DAI, kann ein Solver sie zusammenführen. Wenn mehrere Intents kompatibel sind (wie ein Orderbuch von Geboten und Anfragen), können Solver ein optimales Matching oder einen Clearing-Preis finden. Wichtig ist, dass dies Off-Chain im Solver-Netzwerk geschieht – effektiv ein algorithmisches Matchmaking. Sobald ein Solver (oder eine Gruppe von Solvern) eine vollständige Transaktion (oder einen Satz von Transaktionen) konstruiert hat, die einige Intents erfüllen, reichen sie diese zur Ausführung an die Chain ein. Hier kommt Stufe 2: Anomas Konsens wird dann diese von Solvern eingereichten Transaktionen in Blöcke ordnen. Anomas Konsens ist jedoch so konzipiert, dass er reihenfolge-fair ist: Er verwendet kryptographische Techniken (Schwellenwert-Verschlüsselung), um sicherzustellen, dass Transaktionen ohne Beeinflussung durch ihren Inhalt oder den genauen Einreichungszeitpunkt geordnet werden. Insbesondere plant Anoma, Ferveo, ein Schwellenwert-Verschlüsselungsschema, auf Mempool-Ebene zu verwenden. Dies funktioniert so: Solver verschlüsseln die Transaktionen, die sie vorschlagen möchten, mit einem kollektiven öffentlichen Schlüssel der Validatoren. Validatoren nehmen diese verschlüsselten Transaktionen in Blöcke auf, ohne deren Details zu kennen. Erst nachdem eine Transaktion in einem Block finalisiert ist, entschlüsseln die Validatoren sie gemeinsam (indem jeder einen Anteil des Entschlüsselungsschlüssels beiträgt). Dies stellt sicher, dass kein Validator selektiv Front-Run oder neu ordnen kann, basierend auf dem Inhalt einer Transaktion – sie verpflichten sich blind zu einer Reihenfolge. Der Konsensalgorithmus ordnet Transaktionen (eigentlich Intents) effektiv in einer Art First-Seen- oder Batch-Manier, da alle Transaktionen in einem gegebenen „Batch“ (Block) verschlüsselt und gleichzeitig offengelegt werden. In der Praxis kann Anoma Batch-Auktionen für bestimmte Anwendungen implementieren: z.B. kann ein Intent zum Handeln über N Blöcke gesammelt (verschlüsselt gehalten), dann nach N Blöcken alle zusammen entschlüsselt und von Solvern in einem Batch abgeglichen werden. Dies verhindert, dass schnelle Akteure die Orders anderer sehen und innerhalb dieses Batches reagieren – ein großer Vorteil für die Fairness (diese Technik ist von Frequent Batch Auctions inspiriert und wurde vorgeschlagen, um die Vorteile des Hochfrequenzhandels zu eliminieren). Zusätzlich können Anomas Gültigkeitsprädikate (Anwendungsebene-Smart Contracts) Fairness-Einschränkungen für das Reihenfolge-Ergebnis durchsetzen. Zum Beispiel könnte eine Anoma-DEX-Anwendung eine Regel haben: „Alle Trades in einem Batch erhalten den gleichen Clearing-Preis, und Solver können keine zusätzlichen Transaktionen einfügen, um Nutzer auszunutzen.“ Da diese Regeln Teil der Zustandsgültigkeit sind, wäre jeder Block, der eine unfaire Übereinstimmung enthält (z.B. ein Solver versuchte, einen Eigenhandel zu einem besseren Preis einzuschleusen), ungültig und würde von Validatoren abgelehnt. Zusammenfassend erfolgt die Reihenfolge in Anoma als Match, dann verschlüsseln+ordnen: Intents werden konzeptionell in die Warteschlange gestellt, bis ein Solver eine Transaktion bildet, und dann wird diese Transaktion durch einen Fair-Order-Konsens geordnet (wodurch typische MEV verhindert wird). Es gibt effektiv kein Mempool-Rennen, da Nutzer-Intents nicht direkt um Gaspreis oder Zeitpriorität konkurrieren. Stattdessen konkurrieren Solver darum, Übereinstimmungen zu finden, und dann werden diese Übereinstimmungen so ausgeführt, dass niemand die Reihenfolge ändern oder sie während des Flugs abfangen kann. Diese Architektur verspricht, viele MEV-Vektoren zu neutralisieren – es gibt kein Konzept des Frontrunning eines Intents, da Intents nicht ausführbar sind, bis der Solver sie zusammensetzt, und dann sind sie bereits in den Block verschlüsselt. Es ist ein grundlegend anderes Warteschlangenmodell, das darauf abzielt, zeitbasierte Prioritätsausnutzungen zu eliminieren.

• MEV-Unterdrückungs-/Extraktionsmechanismen: Anoma ist darauf ausgelegt, „schlechte MEV“ konstruktionsbedingt zu minimieren. Durch die Abwicklung von Trades über Batch-Solving und Schwellenwert-Verschlüsselung sind typische MEV-Angriffe wie Sandwiching unmöglich – niemand sieht einen Intent und kann seinen eigenen davor einfügen, da Intents keine Transaktionen sind, die in einem transparenten Mempool leben. Solver geben endgültig abgeglichene Transaktionen erst nachdem die Möglichkeit zur Einfügung verstrichen ist (aufgrund von Verschlüsselung und Batching) aus. In einem Anoma-basierten DEX würden Nutzer nicht im traditionellen Sinne frontrunnt oder backrunnt, da alle Trades in einem Batch gemeinsam zu einem einheitlichen Preis ausgeführt werden (was verhindert, dass ein Angreifer Preisänderungen zwischen ihnen ausnutzt). Dies unterdrückt im Wesentlichen räuberische MEV wie DEX-Arbitrage oder Sandwiching; der Wert, der von einem Bot genommen worden wäre, bleibt stattdessen bei den Nutzern (sie erhalten einen fairen Preis). Anomas Ansatz zur Arbitrage ist ebenfalls bemerkenswert: In vielen Fällen, wenn mehrere Intents eine Arbitrage-Möglichkeit schaffen, wird der Solver, der sie abgleicht, diesen Gewinn in das Matching einbeziehen (z.B. verschiedene Preise abgleichen und einen Gewinn erzielen). Aber da mehrere Solver darum konkurrieren können, das beste Matching zu liefern, kann der Wettbewerb Solver dazu zwingen, den größten Teil dieses Vorteils in Form besserer Füllbedingungen an die Nutzer zurückzugeben. Zum Beispiel, wenn ein Nutzer zu Preis A verkaufen und ein anderer zu Preis B kaufen möchte (B > A impliziert eine Lücke), könnte ein Solver beide zu einem Zwischenpreis erfüllen und die Differenz als Gewinn erfassen – aber wenn ein anderer Solver den Nutzern einen noch näher beieinander liegenden Preis anbietet (weniger Gewinn übrig lässt), wird er den Intent gewinnen. So konkurrieren Solver MEV-Margen weg, um den Nutzern zugutezukommen, ähnlich wie Searcher in Flashbots über Gebühren konkurrieren. Der Unterschied ist, dass dies algorithmisch über Intent-Matching statt über Gas-Bidding geschieht. Es kann in Anoma immer noch „extrahierte MEV“ geben, aber sie beschränkt sich wahrscheinlich auf Solver, die bescheidene Gebühren für ihren Dienst verdienen. Bemerkenswert ist, dass Anoma erwartet, dass der größte Teil des Orderflows vom Protokoll oder der Anwendungslogik internalisiert wird. In einigen Fällen bedeutet dies, dass eine MEV-Möglichkeit einfach zu einer normalen Protokollgebühr wird. Zum Beispiel implementiert Anomas erste fraktale Instanz (Namada) einen On-Chain-Bonding-Curve-AMM; Arbitrage auf diesem AMM wird vom Mechanismus des AMM erfasst (wie ein eingebauter Rebalancer) und nicht von externen Arbitrageuren. Ein weiteres Beispiel: Ein Lending-Intent, der hohe Zinsen anbietet, könnte mit einem Borrowing-Intent abgeglichen werden; es ist kein Drittanbieter-Liquidator erforderlich, wenn Sicherheiten fallen, da die Intents selbst das Rebalancing übernehmen oder das Protokoll automatisch zu einem fairen Preis liquidieren könnte. Durch das Ausschalten von Drittanbieter-Extraktoren reduziert Anoma die Verbreitung von Off-Chain-MEV-Extraktion. Zusätzlich betont Anoma Privatsphäre (durch das Taiga-Subsystem von ZK-Schaltungen). Nutzer können wählen, ihre Intents teilweise oder vollständig abzuschirmen (z.B. Beträge oder Asset-Typen verbergen). Dies unterdrückt MEV weiter: Wenn die Details einer großen Order verborgen sind, kann niemand sie zur Wertentnahme anvisieren. Erst nach dem Matching und der Ausführung könnten Details auftauchen, aber dann ist es zu spät, um sie auszunutzen. Zusammenfassend geht es bei Anomas Mechanismus größtenteils darum, MEV zu verhindern anstatt sie zu extrahieren: Durch das Batching von Transaktionen, das Verschlüsseln des Mempools und das Einbetten wirtschaftlicher Ausrichtung in das Matching versucht es sicherzustellen, dass es wenig Möglichkeiten für bösartige Arbitrage oder Frontrunning gibt. Die notwendige MEV (wie Arbitrage zur Angleichung von Preisen über Märkte hinweg) wird von Solvern oder der Protokolllogik auf eine vertrauensminimierte Weise gehandhabt. Man könnte sagen, Anoma strebt eine „MEV-Minimierung“ an und bemüht sich um Ergebnisse, als ob jeder Nutzer sofortigen Zugang zur perfekten Gegenpartei hätte, ohne Verluste. Jeder Wert, der bei der Erleichterung dessen extrahiert wird (die Belohnung des Solvers), ist vergleichbar mit einer kleinen Servicegebühr, nicht mit einem unerwarteten Gewinn aus der Ausnutzung von Asymmetrie.

• Ökonomische Anreizstruktur: In Anoma übernehmen Solver die Rolle, die sowohl Matchmakern als auch Block-Buildern entspricht. Sie tragen Kosten (Berechnung, möglicherweise Hinterlegung von Sicherheiten), um Intent-Matches zu finden, und werden belohnt, wenn sie erfolgreich Transaktionen vorschlagen, die aufgenommen werden. Solver können auf verschiedene Weisen verdienen: Sie könnten eine Gebühr oder einen Spread innerhalb der von ihnen konstruierten Transaktion erheben (zum Beispiel den Nutzern etwas weniger günstige Konditionen bieten und die Differenz behalten, ähnlich wie ein DEX-Aggregator einen kleinen Anteil nehmen könnte). Oder bestimmte Intents könnten explizit eine Belohnung für den Solver enthalten (wie „Ich bin bereit, bis zu 0,01 ETH zu zahlen, um dies zu erledigen“). Das genaue Vergütungsmodell ist flexibel, aber der Schlüssel ist, dass Solver konkurrieren. Wenn ein Solver versucht, eine zu hohe Gebühr zu nehmen, kann ein anderer eine Lösung mit einem besseren Nutzerergebnis vorschlagen und die Aufnahme gewinnen. Diese Wettbewerbsdynamik soll die Solver-Gewinne in Schach halten und auf die Wertschöpfung ausrichten. Validatoren (Block-Produzenten): Anoma-Validatoren betreiben den Konsens, der Transaktionen ordnet und ausführt. Sie werden durch Block-Belohnungen und Gebühren motiviert, wie in jeder Blockchain. Bemerkenswert ist, dass, wenn Intents über mehrere Nutzer hinweg abgeglichen werden, die resultierende Transaktion mehrere Gebührenquellen haben könnte (jeder Nutzer könnte eine Gebühr oder einen Teil der Vermögenswerte beisteuern). Es ist möglich, dass Anomas Gebührenmodell eine Gebührenteilung zulässt, aber typischerweise erhalten Validatoren die Standard-Gasgebühren für die Verarbeitung von Transaktionen. In zukünftigen Phasen plant Anoma einen „On-Demand-Konsens“ und ein natives Token. Die Idee ist, dass viele Anoma-Instanzen (oder Shards) existieren könnten, und einige könnten temporär für spezifische Aufgaben hochgefahren werden („Ad-hoc-Konsens“ für bestimmte Anwendungsbedürfnisse). Das Token würde wahrscheinlich zum Staking und zur Sicherung dieser Instanzen verwendet. Anreize hier stellen sicher, dass das Netzwerk genügend Validatoren hat, um alle abgeglichenen Transaktionen zuverlässig zu verarbeiten, und dass sie sich im Schwellenwert-Entschlüsselungsprozess ehrlich verhalten (vielleicht Slashing-Bedingungen, wenn sie versuchen, Daten frühzeitig zu entschlüsseln oder zu zensieren). Nutzer: Nutzer in Anoma sparen potenziell Geld und erzielen bessere Ergebnisse, anstatt implizit MEV zu zahlen. Zum Beispiel könnten sie durchweg bessere Handelspreise erhalten als auf einer traditionellen Chain, was bedeutet, dass der Wert bei ihnen bleibt. In einigen Fällen könnten Nutzer auch explizite Gebühren zahlen, um Solver zu motivieren, insbesondere für komplexe Intents oder wenn sie ein schnelleres Matching wünschen. Da Nutzer jedoch Intents ausdrücken können, ohne anzugeben, wie sie ausgeführt werden sollen, überlassen sie die schwere Arbeit den Solvern und zahlen nur, wenn es sich lohnt. Es gibt auch die Vorstellung, dass „Intent-Besitzer ihre eigenen Sicherheits-/Leistungs-Kompromisse definieren können“ – z.B. könnte ein Nutzer sagen: „Ich warte länger auf einen besseren Preis“ oder „Ich zahle mehr für sofortige Ausführung.“ Diese Flexibilität ermöglicht es den Nutzern selbst zu entscheiden, wie viel sie Solvern oder Validatoren anbieten, wodurch die wirtschaftlichen Anreize an ihre Bedürfnisse angepasst werden. MEV-Umverteilung: Falls MEV auftritt (wie Cross-Chain-ARB o.ä.), könnte die Anoma-Architektur es ermöglichen, diese in das System zu integrieren. Zum Beispiel könnten mehrere Anoma-Shards oder -Instanzen koordinieren, um einen atomaren Multi-Chain-Arb abzuwickeln, und der Gewinn könnte geteilt oder verbrannt werden (je nach Design), anstatt ihn einem externen Arbitrageur vollständig zu überlassen. Im Allgemeinen, da Anoma Anwendungen die Kontrolle über den Transaktionsfluss gibt, ist es möglich, protokolleigene MEV-Strategien (ähnlich der Philosophie von Skip) auf Anwendungsebene zu implementieren. Zum Beispiel könnte eine DeFi-App auf Anoma alle Nutzertransaktionen automatisch über einen In-Protocol-Solver leiten, der die beste Ausführung garantiert und jeden zusätzlichen Gewinn mit Nutzern oder mit Liquiditätsanbietern teilt. Der Nettoeffekt ist, dass Drittanbieter-MEV-Extraktoren disintermediiert werden. Wirtschaftlich ist dies ein Positivsummenspiel für ehrliche Teilnehmer (Nutzer, LPs usw.), aber es könnte die Möglichkeiten für klassische Searcher reduzieren. Es werden jedoch neue Rollen wie spezialisierte Solver (vielleicht konzentriert sich einer auf NFT-Matching, ein anderer auf FX-Swaps usw.) entstehen. Diese Solver sind analog zu den heutigen MEV-Searchern, aber sie operieren innerhalb der Systemregeln und haben aufgrund von Wettbewerb und Protokolleinschränkungen wahrscheinlich weniger wahnsinnige Gewinnmargen. Schließlich deutet die Vision der Anoma Foundation darauf hin, dass Anoma eine öffentliche Gut-Infrastruktur sein wird. Es wird ein natives Token geben, vermutlich ANOMA, das Wert über Gebühren erfassen oder für das Staking erforderlich sein könnte. Man kann Token-Anreize (inflationäre Belohnungen usw.) für Validatoren und vielleicht sogar für Solver erwarten, um die Aktivität anzukurbeln. Zum Zeitpunkt des Schreibens sind die Details zur Token-Ökonomie noch nicht final, aber die Roadmap bestätigt, dass ein Anoma-Token und ein nativer On-Demand-Konsens in zukünftigen Phasen geplant sind. Zusammenfassend fördert Anomas Anreizmodell kooperatives Verhalten: Solver verdienen, indem sie Nutzern helfen, das zu bekommen, was sie wollen, nicht indem sie sie ausnutzen; Validatoren verdienen, indem sie das Netzwerk sichern und fair ordnen; und Nutzer „zahlen“ hauptsächlich, indem sie einen Teil der MEV an Solver oder Gebühren abgeben, aber idealerweise viel weniger als die implizite MEV, die sie in anderen Systemen verlieren würden.

• Compliance und Neutralität: Anoma, als Framework und nicht als einzelnes Netzwerk, kann auf verschiedene Weisen instanziiert werden – einige könnten permissioned sein, aber die Flaggschiff-Anoma L1 und ähnliche Instanzen sollen permissionless und datenschutzverbessert sein. Durch die Integration starker Datenschutzfunktionen (wie abgeschirmte Intents mit Zero-Knowledge-Proofs in Taiga) stimmt Anoma mit der Ansicht überein, dass finanzielle Privatsphäre ein Recht ist. Dies könnte es in Konflikt mit bestimmten regulatorischen Regimen bringen, die eine offene Sichtbarkeit von Transaktionen fordern. Anomas Design könnte jedoch auch bestimmte regulatorische Fallstricke vermeiden. Wenn beispielsweise Front-Running und unfaire Orderauswahl eliminiert werden, werden Bedenken hinsichtlich Marktmanipulation gemindert – eine Regulierungsbehörde könnte es schätzen, dass Nutzer nicht systematisch von Insidern ausgenutzt werden. Zusätzlich impliziert das Konzept der „nutzerdefinierten Sicherheitsmodelle“, dass Nutzer oder Communities unterschiedliche Vertrauensannahmen wählen könnten. Potenziell könnte eine regulierte Anwendung auf Anoma aufgebaut werden, bei der beispielsweise der Solver oder eine Untergruppe von Validatoren KYC-geprüfte Entitäten sind, die die Compliance für diesen bestimmten Intent-Bereich sicherstellen. Anoma als Basisschicht würde nicht für jeden KYC erzwingen, aber man könnte Gültigkeitsprädikate implementieren, die (zum Beispiel) einen Nachweis der Berechtigung für bestimmte Transaktionen (wie einen Nachweis, keine sanktionierte Adresse zu sein, oder eine Berechtigungsprüfung) erfordern, wenn eine Anwendung dies benötigt. Die Architektur ist flexibel genug, um Compliance auf der Anwendungsebene zu unterstützen, ohne die Neutralität der Basisschicht zu beeinträchtigen. Bezüglich Zensur: Anomas Schwellenwert-Verschlüsselung bedeutet, dass selbst wenn Validatoren zensieren wollten, sie keine spezifischen Intents anvisieren können, weil sie diese nicht im Klartext sehen. Das Einzige, was sie tun könnten, ist, die Aufnahme verschlüsselter Transaktionen von bestimmten Solvern oder Nutzern zu verweigern, aber das wäre offensichtlich (und würde gegen die Protokollregeln verstoßen, wenn es willkürlich geschieht). Es wird erwartet, dass Konsensregeln die Zensur entmutigen – zum Beispiel könnte ein Block als ungültig oder weniger bevorzugt angesehen werden, wenn er nicht alle verfügbaren entschlüsselten Intents des letzten Batches enthält. In jedem Fall gewährleisten die Dezentralisierung der Validatoren und die verschlüsselte Natur der Payloads zusammen ein hohes Maß an Zensurresistenz. Zur Neutralität: Anoma zielt darauf ab, eine allgemeine Plattform zu sein, die von keiner einzelnen Entität kontrolliert wird. Die Forschung und Entwicklung wird von Heliax (dem Team hinter Anoma und Namada) geleitet, aber sobald sie live ist, würde ein Anoma-Netzwerk von der Community betrieben. Es wird wahrscheinlich eine On-Chain-Governance für Upgrades usw. geben, was Compliance-Fragen aufwerfen könnte (z.B. könnte eine Regierung die Governance untergraben, um Regeln zu ändern?), aber das ist ein allgemeines Blockchain-Problem. Eine interessante Compliance-bezogene Funktion ist, dass Anoma mehrere parallele Instanzen unterstützt – was bedeutet, dass man einen isolierten Intent-Pool oder Shard für bestimmte Asset-Typen oder Jurisdiktionen haben könnte. Dies ist nicht explizit für die Regulierung gedacht, könnte aber beispielsweise einen CBDC-Intent-Pool ermöglichen, in dem nur autorisierte Banken Solver betreiben, die mit einem freien DeFi-Pool koexistieren. Die Modularität der Architektur bietet Flexibilität zur Trennung bei Bedarf, während sie dennoch Interoperabilität über Intent-Bridging ermöglicht. Schließlich, in Bezug auf die rechtliche Kompatibilität, könnte Anomas gesamtes Konzept von Intents einige Klassifizierungen vermeiden, die traditionelle Krypto plagen: Da ein Intent keine bindende Transaktion ist, bis er abgeglichen wird, könnte man argumentieren, dass Nutzer mehr Kontrolle behalten (es ist wie das Posten einer Order an einer Börse, was einen klareren rechtlichen Präzedenzfall hat, im Gegensatz zur direkten Ausführung eines Handels). Dies könnte bei Dingen wie der steuerlichen Behandlung helfen (das System könnte potenziell eine einheitliche Quittung eines mehrstufigen Handels anstelle vieler Transaktionen liefern) – obwohl dies spekulativ ist. Insgesamt priorisiert Anoma Dezentralisierung, Privatsphäre und Nutzerautonomie, was historisch mit regulatorischen Erwartungen kollidieren kann, aber die Fairness- und Transparenzgewinne könnten Anklang finden. Es bringt im Wesentlichen die Raffinesse traditioneller Finanz-Matching-Engines On-Chain, aber ohne zentralisierte Betreiber. Wenn Regulierungsbehörden dieses Modell verstehen, könnten sie es als eine geordnetere und fairere Marktstruktur ansehen als das Chaos der Mempools.

• Technische Architektur (Konsens & Krypto): Anomas Architektur ist komplex und umfasst mehrere Komponenten: Typhon (Netzwerk, Mempool, Konsens, Ausführung) und Taiga (die Zero-Knowledge-Datenschutzschicht). Der Kern von Typhon ist die Intent-Gossip-Schicht und ein neuartiger Ansatz für kombinierten Konsens + Matching. Anomas Konsensprotokoll erweitert den typischen BFT-Konsens um das Konzept der „Gültigkeitsprädikate“ und des „Proof-of-Order-Matching“. Im Wesentlichen kann jede Anwendung in Anoma ein Gültigkeitsprädikat definieren, das für Transaktionen erfüllt sein muss (man stelle es sich wie Smart-Contract-Bedingungen vor, die auf Blockebene und nicht nur auf Transaktionsebene gelten). Dies ermöglicht die Durchsetzung von Eigenschaften wie Batch-Auktions-Clearing-Preisen usw., wie beschrieben. Der Konsensalgorithmus selbst baut wahrscheinlich auf Tendermint- oder HotStuff-ähnlichem BFT auf (da Anoma im Cosmos-Bereich angesiedelt ist und IBC unterstützt). Tatsächlich verwenden Anomas anfängliches Testnet (Feigenbaum im Jahr 2021) und Namada einen Tendermint-ähnlichen Konsens mit Modifikationen. Eine wichtige Modifikation ist die Integration der Schwellenwert-Verschlüsselung (Ferveo) in die Mempool-Pipeline. Typischerweise wählt Tendermint einen Proposer, der Transaktionen ordnet. In Anoma würde der Proposer verschlüsselte Intents/Transaktionen ordnen. Ferveo funktioniert wahrscheinlich so, dass Validatoren periodisch einen Schwellenwert-Public-Key vereinbaren und jeder von Solvern eingereichte Intent mit diesem Schlüssel verschlüsselt wird. Während des Blockvorschlags werden alle verschlüsselten Transaktionen aufgenommen; nach dem Vorschlag führen die Validatoren ein Protokoll zur Entschlüsselung durch (vielleicht enthält der nächste Block die entschlüsselten Outputs oder ein ähnliches Schema). Dies fügt dem Konsens eine Phase hinzu, gewährleistet aber die Reihenfolge-Fairness. Kryptographisch verwendet dies verteilte Schlüsselgenerierung und Schwellenwert-Entschlüsselung (es beruht also auf Annahmen wie mindestens 2/3 der Validatoren, die ehrlich sind, um Daten nicht zu leaken oder frühzeitig zu entschlüsseln). Auf der Datenschutzseite bietet Taiga zkSNARK- oder zk-STARK-Proofs, die es ermöglichen, Intents teilweise oder vollständig abzuschirmen. Zum Beispiel könnte ein Nutzer einen Intent zum Tauschen einreichen, ohne den Asset-Typ oder Betrag preiszugeben; er liefert einen ZK-Proof, dass er ausreichend Guthaben hat und dass die Transaktion gültig ist, wenn sie abgeglichen wird, ohne Spezifika preiszugeben. Dies ist analog zur Funktionsweise von abgeschirmten Transaktionen in Zcash, aber auf Intents erweitert. Die Verwendung rekursiver Proofs wird erwähnt, was bedeutet, dass mehrere Schritte einer Transaktion (oder mehrere Intents) in einem prägnanten Proof für Effizienz nachgewiesen werden können. Das Zusammenspiel von Taiga und Typhon bedeutet, dass einige Solver und Validatoren möglicherweise mit Chiffretext oder Commitments statt mit Klartextwerten arbeiten. Zum Beispiel könnte ein Solver Intents abgleichen, die auf vertrauliche Weise ausgedrückt werden, indem er eine Gleichung von Commitments löst. Dies ist modernste Kryptographie und geht über das hinaus, was die meisten aktuellen Blockchains tun. Ein weiteres Schlüsselstück ist die IBC-Integration: Anoma-Instanzen können mit anderen Chains (insbesondere Cosmos-Chains) über das Inter-Blockchain Communication-Protokoll kommunizieren. Das bedeutet, ein Intent auf Anoma könnte potenziell eine Aktion auf einer anderen Chain auslösen (über eine IBC-Nachricht) oder Daten aus dem Zustand einer anderen Chain konsumieren. Die Mainnet-Phase 1 in Anomas Roadmap erwähnt ausdrücklich einen „Adapter“ auf Ethereum und Rollups, um Anoma-Intents den Zugriff auf EVM-Liquidität zu ermöglichen. Wahrscheinlich könnte ein Anoma-Solver eine Transaktion zusammenstellen, die beispielsweise Uniswap auf Ethereum verwendet, indem er einen Intent erstellt, der bei Übereinstimmung eine Nachricht an Ethereum sendet, um einen Swap auszuführen (vielleicht über einen Relayer oder über etwas wie eine IBC-Bridge). Der Konsens muss Atomizität gewährleisten: Vermutlich könnte Anomas Output wie eine einzelne Transaktion sein, die mehrere Chains umfasst (so etwas wie das Initiieren einer Transaktion auf Chain A und das Erwarten eines Ergebnisses auf Chain B). Das Erreichen einer atomaren Cross-Chain-Abwicklung ist schwierig; möglicherweise wird Anoma zunächst auf einer Chain gleichzeitig abwickeln (Phase 1 konzentriert sich auf das Ethereum-Ökosystem, was wahrscheinlich bedeutet, dass Anoma-Intents auf Ethereum L1 oder L2s in einem Rutsch abgewickelt werden). Später könnten „Chimera-Chains“ und On-Demand-Konsens benutzerdefinierte Sidechains ermöglichen, die für bestimmte Cross-Chain-Matches hochgefahren werden. Leistungstechnisch könnte Anomas Ansatz rechenintensiver sein (Solver, die NP-harte Matching-Probleme lösen, Validatoren, die schwere Krypto durchführen). Aber der Kompromiss ist eine erheblich verbesserte Nutzererfahrung (keine fehlgeschlagenen Transaktionen, bessere Preise usw.). Die Entwicklung von Anoma erfordert den Aufbau dieser neuartigen Komponenten nahezu von Grund auf: Heliax hat Juvix entwickelt, eine neue Sprache zum Schreiben von Gültigkeitsprädikaten und Intents, und viel Forschung betrieben (einige Referenzen von Anomas Website behandeln diese Konzepte detailliert). Wichtige Meilensteine: Anomas erstes öffentliches Testnet Feigenbaum wurde im November 2021 als Demo für grundlegendes Intent-Gossip gestartet. Anschließend verlagerte Heliax den Fokus auf den Start von Namada (einer datenschutzorientierten L1, die als Instanz von Anoma betrachtet werden kann, die sich auf Asset-Transfers konzentriert) – Namada ging 2023 live und umfasst Funktionen wie abgeschirmte Transfers und Ferveo-Schwellenwert-Verschlüsselung für seinen Mempool. Dies zeigt die Technologie in Aktion für einen engeren Anwendungsfall. Währenddessen wurden Anomas vollständige Vision-Testnets in Phasen ausgerollt (ein „Sommer 2023 Testnet“ wurde in der Community ebenfalls erwähnt). Die Roadmap zeigt an, dass Phase 1 Mainnet Ethereum integrieren wird, Phase 2 weitere Chains und fortgeschrittene Kryptographie hinzufügt, und schließlich native Konsens und Token hinzukommen. Die Trennung von „Konsens und Token in zukünftiger Phase“ deutet darauf hin, dass das anfängliche Anoma Mainnet auf Ethereum angewiesen sein könnte (z.B. Nutzung der Ethereum-Sicherheit oder bestehender Token, anstatt von Anfang an ein eigenes zu haben). Möglicherweise starten sie eine L2 oder Sidechain, die an Ethereum postet. Dann später ihr eigenes PoS-Netzwerk mit einem Token aufbauen. Dieser phasenweise Ansatz ist interessant – er könnte dazu dienen, die Hürde für die Akzeptanz zu senken (bestehendes Kapital auf Ethereum nutzen, anstatt anfänglich eine neue Coin zu starten). Zusammenfassend ist Anomas Architektur neu und umfassend: Sie verbindet kryptographische Fairness (Schwellenwert-Verschlüsselung, ZK-Proofs) mit einem neuen Transaktionsparadigma (Intent-basiertes Matching) und Cross-Chain-Fähigkeiten. Es ist wohl der aggressivste Versuch, traditionelle MEV auf Protokollebene auszumerzen, indem es das tut, was keine Legacy-Chain tut: eingebaute faire Matching-Engines. Die Komplexität ist hoch, aber wenn erfolgreich, könnte eine Anoma-Chain Nutzern nahezu CEX-ähnliche Ausführungsgarantien in einer dezentralen Umgebung bieten, was ein Heiliger Gral in Blockchain-UX und Fairness ist.

Skip Protocol (Cosmos Sovereign MEV Control and Fair Ordering Toolkit)​

Skip Protocol ist eine führende MEV-Lösung im Cosmos-Ökosystem, die darauf abzielt, jeder Blockchain („App-Chain“) die Werkzeuge an die Hand zu geben, um Transaktionsreihenfolge und MEV-Erfassung nach ihren eigenen Bedingungen zu verwalten. Im Gegensatz zu Flashbots oder Anoma, die netzwerkübergreifende Systeme vorschlagen, stimmt Skip mit der Philosophie der Souveränität von Cosmos überein: Jede Chain kann Skips Module integrieren, um benutzerdefinierte faire Reihenfolgeregeln durchzusetzen, In-Protocol-Blockspace-Auktionen durchzuführen und MEV für die Stakeholder oder Nutzer der Chain zu erfassen. Skip kann als eine Suite von Cosmos SDK-Modulen und Infrastruktur betrachtet werden, die zusammen Protocol-Owned Blockbuilding (POB) und flexible Transaktionssequenzierung ermöglichen. Es wurde auf Chains wie Osmosis, Juno, Terra und anderen in Cosmos übernommen und arbeitet auch mit Projekten wie dYdXs kommender Chain zur MEV-Minderung zusammen. Schlüsselelemente umfassen einen On-Chain-Auktionsmechanismus für Prioritätstransaktionen, Konsens-Ebene-Transaktionsreihenfolgelogik und In-App-Mechanismen zur Wiederverwertung von MEV („gute MEV“) zum Nutzen des Protokolls.

• Transaktionswarteschlange & Reihenfolge-Algorithmen: In einer typischen Cosmos-Chain (mit Tendermint/BFT-Konsens) ordnet der Mempool Transaktionen grob nach Gebühr und Ankunftszeit, und der Block-Proposer kann bei der Erstellung eines Blocks jede beliebige Reihenfolge wählen (ohne algorithmische Einschränkungen außer der Aufnahme gültiger Transaktionen). Skip ändert dies durch die Einführung von konsensdurchgesetzten Reihenfolgeregeln und Multi-Lane-Mempools. Unter Verwendung der neuen ABCI++-Schnittstelle von Cosmos (die die Anpassung der Blockvorschläge und -verarbeitung ermöglicht), kann Skips Protocol-Owned Builder (POB)-Modul den Block in verschiedene Lanes mit unterschiedlichen Reihenfolgerichtlinien unterteilen. Zum Beispiel könnte eine Lane eine Top-of-Block-Auktions-Lane sein, in der die höchstbietenden Transaktionen (vielleicht von Arbitrage-Bots oder dringenden Trades) zuerst im Block in einer festen Reihenfolge platziert werden, eine andere Lane könnte eine Free-Lane für gewöhnliche Nutzertransaktionen ohne Gebühren sein, und eine Default-Lane für normale Transaktionen mit Gebühren. Die BlockBuster-Komponente des Skip-Moduls ermöglicht es Entwicklern, diese Lanes und ihre Reihenfolgelogik modular zu definieren. Entscheidend ist, dass diese Regeln von allen Validatoren durchgesetzt werden: Wenn ein Proposer einen Block konstruiert, überprüfen die anderen Validatoren, ob die Transaktionen des Blocks den vereinbarten Reihenfolgeregeln entsprechen (über die ProcessProposal ABCI-Prüfungen). Wenn nicht, können sie den Block ablehnen. Das bedeutet, dass selbst ein bösartiger oder gewinnorientierter Proposer nicht abweichen kann (z.B. kann er seine eigene Front-Run-Transaktion nicht vor einem gewinnenden Auktionsbieter einschleusen, da dies die Reihenfolgeregel verletzen würde). Einige Beispiele für Reihenfolgeregeln, die Skip ermöglicht: (a) Transaktionen nach absteigendem Gaspreis (Gebühr) ordnen – um sicherzustellen, dass die Transaktion mit der höchsten Gebühr immer Priorität erhält. Dies formalisiert ein faires „Pay-for-Priority“-Schema anstelle von zufälliger oder zeitbasierter Reihenfolge. (b) Muss mindestens eine Oracle-Preisaktualisierungs-Transaktion vor allen Trades enthalten – um sicherzustellen, dass Datenfeeds aktualisiert werden, was Szenarien verhindert, in denen ein Proposer Oracle-Updates ignorieren könnte, um veraltete Preise auszunutzen. (c) Begrenzung der Anzahl spezieller Transaktionen am Anfang des Blocks – z.B. kann nur ein Auktions-gewinnendes Bundle den obersten Platz einnehmen, um das Spammen vieler kleiner MEV-Grabs zu verhindern. (d) Keine Transaktionen, die eine Zustandseigenschaft verletzen – Skip ermöglicht zustandsabhängige Reihenfolgeregeln, wie „nach dem Bau des Blocks sicherstellen, dass kein DEX-Trade zu einem schlechteren Preis ausgeführt wurde, als wenn er zuletzt im Block gewesen wäre“ (eine Möglichkeit, sicherzustellen, dass kein Sandwich-Angriff stattgefunden hat). Eine konkrete beschriebene Regel ist eine „Null-Frontrunning-Bedingung über alle DEXs hinweg“, was bedeuten könnte, dass wenn eine Transaktion durch spätere in einer Weise beeinflusst worden wäre, die auf Frontrunning hindeutet, der Block ungültig ist. Dies ist mächtig: Es macht Fairness im Wesentlichen zu einem Teil der Blockgültigkeit. Cosmos-Chains können solche Regeln implementieren, weil sie ihren gesamten Stack kontrollieren. Skips Framework bietet eine strukturierte Möglichkeit, dies über den AuctionDecorator im SDK zu tun, der jede Transaktion gegen konfigurierte Regeln prüfen kann. Zusätzlich bietet Skip Mempool-Verbesserungen: Der Mempool des Knotens kann Blöcke im Voraus simulieren, fehlerhafte Transaktionen herausfiltern usw., um Proposern zu helfen, die Regeln effizient zu befolgen. Wenn beispielsweise die Auktions-Lane eines Blocks die höchsten Gebote haben muss, kann der Mempool für diese Lane nach Geboten sortiert werden. Wenn ein Block nur Transaktionen enthalten darf, die zu einer bestimmten Zustandsbedingung führen, kann der Knoten des Proposers Transaktionen simulieren, während er sie auswählt, um sicherzustellen, dass die Bedingung erfüllt ist. Zusammenfassend ermöglicht Skip eine deterministische, von der Chain definierte Reihenfolge, anstatt sie vollständig der Laune des Proposers oder einer einfachen Gaspreis-Priorität zu überlassen. Chains übernehmen Skips Builder-Modul, um ihre Transaktionsreihenfolgerichtlinie effektiv in das Protokoll zu kodifizieren. Dies fördert die Fairness, da alle Validatoren dieselben Regeln durchsetzen, wodurch die Möglichkeit für einen einzelnen Proposer entfällt, willkürliche Neuanordnungen für MEV vorzunehmen, es sei denn, dies geschieht innerhalb des erlaubten Mechanismus (wie der Auktion, wo es transparent und wettbewerbsorientiert ist). Die Warteschlange von Transaktionen in Skips Modell könnte separate Warteschlangen pro Lane umfassen. Zum Beispiel könnte eine Auktions-Lane spezielle Gebots-Transaktionen in die Warteschlange stellen (Skip verwendet einen speziellen MsgAuctionBid-Typ für das Bieten um Top-of-Block-Aufnahme). Diese Gebote werden in jedem Block gesammelt und das höchste ausgewählt. Währenddessen werden normale Transaktionen im Standard-Mempool in die Warteschlange gestellt. Im Wesentlichen führt Skip eine strukturierte Warteschlange ein: eine für Prioritätsgebote, eine für kostenlose oder andere usw., jede mit ihren eigenen Reihenfolgekriterien. Dieser modulare Ansatz bedeutet, dass jede Chain anpassen kann, wie sie Fairness und Einnahmen ausbalanciert – z.B. könnte Osmosis sagen: „Wir wollen überhaupt keine MEV-Auktion, aber wir erzwingen Reihenfolge-Fairness über Schwellenwert-Verschlüsselung“ (sie haben Schwellenwert-Verschlüsselung mit Hilfe von Skip und anderen implementiert), während eine andere Chain sagen könnte: „Wir erlauben Auktionen für MEV, verlangen aber, dass ein Teil der Erlöse verbrannt wird.“ Skip unterstützt beides. Diese Konfigurierbarkeit der Reihenfolge ist Skips Markenzeichen.

• MEV-Minderung und Extraktionsmechanismen: Skips Ansatz zu MEV wird oft als „protokolleigene MEV“ und „Multiplizität“ beschrieben. Protokolleigene MEV bedeutet, dass das Blockchain-Protokoll selbst, über seinen Code und seine Governance, MEV erfasst oder umverteilt, anstatt sie einzelnen Validatoren oder Außenstehenden zu überlassen. Multiplizität bezieht sich darauf, sicherzustellen, dass die „richtigen“ (mehreren) Transaktionen aufgenommen werden – im Wesentlichen keine legitimen Nutzer-Transaktionen zugunsten von nur MEV-Transaktionen auszuschließen und vielleicht mehrere MEV-Möglichkeiten in einem Block aufzunehmen, wenn möglich (damit kein einzelner Searcher monopolisiert). Konkret bietet Skip Tools zur Erfassung von MEV auf Weisen, die dem Netzwerk zugutekommen: Eine davon ist Skip Select, ein Blockspace-Auktionssystem für die Aufnahme am Anfang des Blocks. In Skip Select reichen Searcher (wie Arbitrage-Bots) Bundles mit Trinkgeldern an Validatoren ein, ähnlich wie Flashbots-Bundles, außer dass dies nativ On-Chain über Skips Module geschieht. Das höchstbezahlte Bundle (oder Bundles) wird dann automatisch am Anfang des Blocks in der angegebenen Reihenfolge eingefügt. Dies garantiert, dass diese Transaktionen wie beabsichtigt ausgeführt werden, und der Validator (oder die Chain) sammelt das Trinkgeld ein. Dieser Mechanismus macht aus einem Off-Chain-OTC-Prozess (in Ethereum) eine offene, On-Chain-Auktion – was Transparenz und Zugang verbessert. Ein weiterer Mechanismus ist ProtoRev (Prototype Revenue module), das Skip für Osmosis entwickelt hat. ProtoRev ist ein On-Chain-Arbitrage-Modul, das zyklische Arbitragen (wie solche, die mehrere Pools betreffen) innerhalb der Blockausführung automatisch erkennt und ausführt und den Gewinn in die Schatzkammer oder den Community-Pool der Chain akkumuliert. Im Wesentlichen entschied Osmosis, dass bestimmte „gute MEV“ (wie Arbitrage, die Preise im Einklang hält) weiterhin stattfinden sollte (für Markteffizienz), aber das Protokoll selbst führt die Arbitrage durch und erfasst den Gewinn, um ihn später zu verteilen (z.B. an Staker oder als Liquiditäts-Mining-Anreize). Dies eliminiert die Notwendigkeit externer Arbitrage-Bots für diese Möglichkeiten und stellt sicher, dass der Wert im Ökosystem verbleibt. ProtoRev war das erste seiner Art auf einer großen Chain und demonstriert, wie tiefe Integration die Externalitäten von MEV mindern kann: Nutzer, die auf Osmosis handeln, erleiden weniger Slippage, denn wenn nach ihrem Handel eine Arbitrage existiert, wird das Protokoll sie schließen und den Wert im Wesentlichen an Osmosis zurückerstatten (was indirekt den Nutzern über niedrigere Gebühren oder Token-Rückkäufe usw. zugutekommen könnte). Darüber hinaus befähigt Skip Chains, Anti-MEV-Maßnahmen wie Schwellenwert-Verschlüsselung für den Mempool zu implementieren. Zum Beispiel implementiert Osmosis in Zusammenarbeit mit Skip und anderen eine Mempool-Verschlüsselung, bei der Transaktionen verschlüsselt eingereicht und erst nach einer festen Zeit offengelegt werden (ähnlich Anomas Idee, aber auf Chain-Ebene). Obwohl kein Skip-Produkt im eigentlichen Sinne, ist Skips Architektur kompatibel – Skips Auktion kann auf verschlüsselten Transaktionen laufen, indem die Auktion auf deklarierten Geboten basiert, anstatt den Transaktionsinhalt zu lesen. In Bezug auf die Unterdrückung schädlicher MEV: Skips Konsensregeln wie „kein Front-Running erlaubt“ (durch Zustandsprüfungen durchgesetzt) sind eine direkte Maßnahme, um bösartiges Verhalten zu stoppen. Wenn ein Validator versucht, einen Sandwich-Angriff einzuschließen, würden andere Validatoren erkennen, dass das Zustandsergebnis die No-Frontrunning-Regel verletzt (zum Beispiel könnten sie prüfen, dass kein Handel unmittelbar von einem anderen von derselben Adresse in einer Weise vor- und nachfolgte, die einen Vorteil nutzte). Dieser Block würde abgelehnt. Da Validatoren dies wissen, werden sie solche Muster gar nicht erst versuchen einzuschließen, wodurch Nutzer durch Protokollrecht geschützt sind. Skip fördert auch das Verbrennen oder Umverteilen von MEV-Einnahmen, um perverse Anreize zu vermeiden. Zum Beispiel könnte eine Chain beschließen, alle Auktionserlöse zu verbrennen oder in einen Community-Fonds zu legen, anstatt sie alle dem Block-Proposer zu geben. Dies reduziert den Anreiz für Validatoren, Transaktionen selbst neu anzuordnen, da sie möglicherweise nicht persönlich davon profitieren (abhängig von der Wahl der Chain). Zusammenfassend ermöglicht Skips Toolkit jeder Chain, MEV dort chirurgisch zu extrahieren, wo es vorteilhaft ist (z.B. Arbitrage zur Aufrechterhaltung der Markteffizienz, Liquidationen zur Aufrechterhaltung gesunder Kreditmärkte) und sicherzustellen, dass dieser Wert vom Protokoll oder den Nutzern erfasst wird, während bösartige MEV (wie nutzerunfreundliches Frontrunning) strengstens verboten und verhindert wird. Es ist eine pragmatische Mischung aus Extraktion und Unterdrückung, maßgeschneidert durch Governance: Anstatt einer Einheitslösung befähigt Skip Communities zu entscheiden, welche MEV „gut“ ist (und ihre Erfassung zu automatisieren) und welche „schlecht“ ist (und sie über Konsensregeln zu verbieten). Das Ergebnis ist eine fairere Handelsumgebung auf Skip-fähigen Chains und eine zusätzliche Einnahmequelle, die öffentliche Güter finanzieren oder Kosten senken kann (einer von Skips Blogbeiträgen weist darauf hin, dass eine faire MEV-Erfassung verwendet werden kann, um „Einnahmen fair unter allen Netzwerkteilnehmern zu verteilen“).

• Ökonomische Anreizstruktur: Die Einführung von Skip verschiebt die Anreize grundlegend, insbesondere für Validatoren und Chain-Communities in Cosmos. Traditionell könnte ein Validator in Cosmos MEV extrahieren, indem er Transaktionen in seinem Block privat neu anordnet (da Cosmos standardmäßig keine MEV-Auktion hat). Mit Skip stimmen Validatoren stattdessen einem Protokoll zu, bei dem MEV über Auktionen oder Module erfasst und oft geteilt wird. Validatoren profitieren immer noch: Sie können einen Anteil an den Auktionserlösen oder zusätzliche Gebühren aus Skips Mechanismen erhalten, aber wichtig ist, dass alle Validatoren (nicht nur der Proposer) davon profitieren können, wenn es so konzipiert ist. Zum Beispiel können einige Skip-Auktionen so konfiguriert werden, dass die Einnahmen unter allen Stakern oder gemäß Governance-Entscheidungen aufgeteilt werden, anstatt dass der Proposer alles gewinnt. Dies stimmt Validatoren kollektiv darauf ab, die Skip-Software auszuführen, da selbst Nicht-Proposer Sicherheit erhalten (wissend, dass ein ungültiger Blockversuch sich nicht auszahlt) und möglicherweise Einnahmen. Einige Chains könnten dem Proposer immer noch den größten Teil der MEV-Auktionsgebühr geben (um den sofortigen Anreiz zur Aufnahme zu maximieren), aber selbst dann ist es transparent und wettbewerbsorientiert, was wohl die Wahrscheinlichkeit von Unter-der-Hand-Geschäften reduziert. Chain/Community: Das Konzept der protokolleigenen MEV bedeutet, dass die Blockchain und ihre Stakeholder MEV erfassen. Zum Beispiel leitet Osmosis ProtoRev-Gewinne in seinen Community-Pool, wodurch MEV effektiv zu einer zusätzlichen Protokolleinnahme wird, die die Entwicklung finanzieren oder an OSMO-Staker verteilt werden könnte. Dies macht die Community im Allgemeinen zu einem „Eigentümer“ dieser MEV, wodurch die Interessen aller auf eine gesunde MEV-Extraktion ausgerichtet werden. Wenn Nutzer wissen, dass die MEV zur Verbesserung der Chain oder Tokenomics zurückfließt, akzeptieren sie dies möglicherweise eher, als wenn sie an einen zufälligen Bot geht. Searcher: In Skips Modell haben unabhängige Searcher/Bots möglicherweise weniger On-Chain zu tun, da einige Möglichkeiten von der Protokolllogik (wie ProtoRev) übernommen und andere über Auktionen kanalisiert werden. Skip eliminiert Searcher jedoch nicht – vielmehr kanalisiert es sie dazu, über die richtigen Wege zu bieten. Ein Searcher kann immer noch eine komplexe Strategie versuchen, aber um die Aufnahme an einer bestimmten Stelle zu garantieren, sollte er an Skips Auktion (Skip Select) teilnehmen, indem er sein Bundle mit einem Gebot einreicht. Wenn nicht, riskiert er, dass ein Validator ihn zugunsten eines Bieters ignoriert oder der eigene Mechanismus der Chain die Möglichkeit nutzt. So entwickeln sich Searcher in Cosmos, um mit Skip zu arbeiten: z.B. reichen viele Arbitrageure auf Osmosis ihre Arbs jetzt über Skips System ein. Sie zahlen einen Teil an die Chain, behalten weniger Gewinn, aber das ist der Preis, um mitzuspielen. Im Laufe der Zeit könnten einige „Searcher“-Rollen vollständig absorbiert werden (wie Backrunning-Arbitrage – ProtoRev erledigt dies, sodass kein externer Searcher konkurrieren kann). Dies könnte Spam und verschwendete Mühe im Netzwerk reduzieren (keine mehreren Bots mehr, die sich gegenseitig überbieten; nur eine Protokollausführung). Nutzer: Endnutzer profitieren von einer faireren Umgebung (keine überraschenden MEV-Angriffe). Außerdem belohnen einige Skip-Konfigurationen Nutzer explizit: MEV-Umverteilung an Nutzer ist möglich. Zum Beispiel könnte eine Chain beschließen, einen Teil der MEV-Auktionserlöse an die Nutzer zurückzuerstatten, deren Trades diese MEV erzeugt haben (ähnlich Flashbots' Rückerstattungsidee). Astroport, ein DEX auf Terra, integrierte Skip, um MEV-Einnahmen mit Swappern zu teilen – was bedeutet, dass, wenn der Handel eines Nutzers MEV hatte, ein Teil dieses Wertes standardmäßig an ihn zurückgegeben wird. Dies stimmt mit dem Ethos überein, dass MEV an Nutzer gehen sollte. Obwohl nicht alle Chains dies tun, besteht die Möglichkeit über Skips Infrastruktur, solche Schemata zu implementieren. Skip Protocol selbst (das Unternehmen/Team) hat ein Geschäftsmodell, bei dem sie diese Tools oft kostenlos an Validatoren bereitstellen (um die Akzeptanz zu fördern), und sie monetarisieren, indem sie mit Chains zusammenarbeiten (B2B). Zum Beispiel könnte Skip eine kleine Gebühr von der erfassten MEV nehmen oder Chains für erweiterte Funktionen/Support berechnen. Es wird erwähnt, dass Skip für Validatoren kostenlos ist, aber ein B2B-Modell mit Chains verwendet. Das bedeutet, Skip hat einen Anreiz, die von der Chain und Community erfasste MEV zu maximieren (damit die Chain zufrieden ist und vielleicht einen Teil gemäß Vereinbarung teilt). Aber da Governance involviert ist, wird jede Gebühr, die Skip nimmt, normalerweise von der Community vereinbart. Der wirtschaftliche Effekt ist interessant: Es professionalisiert die MEV-Extraktion als Dienstleistung, die Chains angeboten wird. Dabei entmutigt es Fehlverhalten – Validatoren müssen nicht einzeln zwielichtige Geschäfte machen, sie können einfach Skip nutzen und erhalten einen zuverlässigen Fluss zusätzlicher Einnahmen, der sozial akzeptiert ist. Ehrliches Verhalten (Befolgen der Protokollregeln) bringt fast genauso viel oder mehr Gewinn als der Versuch zu betrügen, denn wenn man betrügt, könnte der Block ungültig sein oder man könnte sozial bestraft werden usw. Governance spielt eine wichtige Rolle: Die Übernahme von Skips Modul oder die Festlegung der Parameter (wie Auktionsanteil, Verteilung der Erlöse) erfolgt über On-Chain-Vorschläge. Das bedeutet, dass die wirtschaftlichen Ergebnisse (wer die MEV erhält) letztendlich durch Community-Abstimmung bestimmt werden. Zum Beispiel diskutiert der Cosmos Hub die Übernahme von Skips Builder SDK, um MEV möglicherweise an die Schatzkammer oder Staker des Hubs umzuleiten. Diese Ausrichtung durch Governance stellt sicher, dass die Nutzung von MEV von der Community als legitim angesehen wird. Sie verwandelt MEV von einem toxischen Nebenprodukt in eine öffentliche Ressource, die zugewiesen werden kann (für Sicherheit, Nutzer, Entwickler usw.). Zusammenfassend formt Skip Anreize so um, dass Validatoren kollektiv und Nutzer/Community profitieren, während opportunistische MEV-Nehmer entweder in das System integriert (als Bieter) oder ausgeschlossen werden. Theoretisch sind alle besser dran: Nutzer verlieren weniger Wert an MEV, Validatoren werden immer noch entschädigt (sogar möglicherweise insgesamt mehr, aufgrund von Auktionen), und das Netzwerk als Ganzes kann MEV nutzen, um sich selbst zu stärken (finanziell oder durch eine fairere Erfahrung). Die einzigen Verlierer sind diejenigen, die von Nullsummen-Extraktion lebten, ohne Wert zurückzugeben.

• Compliance und regulatorische Kompatibilität: Skips Framework, indem es die Chain-Governance stärkt, erleichtert es Chains tatsächlich, Compliance oder spezifische Richtlinien sicherzustellen, wenn sie dies wünschen. Da Skip auf Protokollebene arbeitet, könnte eine Chain wählen, bestimmte Transaktionsfilter- oder Reihenfolgeregeln durchzusetzen, um Vorschriften einzuhalten. Wenn beispielsweise eine Chain sanktionierte Adressen blockieren wollte, könnte sie eine AnteHandler- oder AuctionDecorator-Regel in Skips Modul integrieren, die Blöcke mit auf der Blacklist stehenden Adressen für ungültig erklärt. Dies ist wohl einfacher als in Ethereum, wo Zensur eine Off-Chain-Wahl einzelner Validatoren ist; in Cosmos mit Skip könnte es eine Chain-weite Regel sein (obwohl es kontrovers wäre und für viele gegen Dezentralisierungs-Ideale verstößt). Alternativ könnte eine Chain etwas wie „FIAT-Onramp-Transaktionen müssen vor anderen erscheinen“ durchsetzen, wenn dies gesetzlich vorgeschrieben ist. Das Skip-Toolkit kommt nicht mit voreingestellten Compliance-Regeln, aber es ist flexibel genug, um sie zu implementieren, wenn eine Community dazu gezwungen ist (durch Governance). Auf der anderen Seite kann Skip die Zensurresistenz stärken: Durch die Verteilung von MEV-Einnahmen und die Gewährung gleichen Zugangs reduziert es den Vorteil eines einzelnen Validators, der aus Profitgründen zensieren könnte. Wenn außerdem Schwellenwert-Verschlüsselungs-Mempools (wie der, den Osmosis hinzufügt) mit Skip Standard werden, wird dies Transaktionsinhalte verbergen, was die Zensur erschwert (wie in Anoma). Skip ist eine neutrale Infrastruktur – es kann je nach Governance entweder zur Einhaltung oder zum Widerstand verwendet werden. Da Cosmos-Chains oft jurisdiktionsspezifisch sind (die Terra-Community könnte sich um koreanische Gesetze sorgen, Kava um US-Gesetze usw.), ist die Option, Compliance zu konfigurieren, wertvoll. Zum Beispiel könnte eine permissioned Cosmos-Chain (wie eine institutionelle Chain) immer noch Skips Builder-Modul verwenden, aber vielleicht verlangen, dass nur Whitelist-Adressen an Auktionen bieten dürfen usw., um ihren Vorschriften zu entsprechen. Regulatorische Kompatibilität betrifft auch die Transparenz: Skips On-Chain-Auktionen erzeugen einen öffentlichen Datensatz von MEV-Transaktionen und wer was bezahlt hat. Dies könnte tatsächlich einige regulatorische Bedenken hinsichtlich der Fairness befriedigen (jeder hatte die Möglichkeit zu bieten, und es ist auditierbar). Es ist transparenter als Unter-der-Hand-Zahlungen an Validatoren. Auch durch die Erfassung von MEV On-Chain reduziert Skip die Wahrscheinlichkeit von Off-Chain-Kartellen oder Dark Pools, die Regulierungsbehörden aufgrund ihrer Undurchsichtigkeit fürchten. Zum Beispiel könnten Validatoren ohne Skip private Deals mit Searchern eingehen (wie bei den Relay-Zensurproblemen gesehen). Mit Skip wird erwartet, dass man die offizielle Auktion – die offen und protokolliert ist – nutzt, um Priorität zu erhalten. Dies fördert einen offenen Markt, der allen Bots gleichermaßen zugänglich ist, was arguably fairer und weniger anfällig für Absprachen ist (Absprachen sind möglich, aber es gibt eine Governance-Aufsicht). Ein weiterer Compliance-Aspekt: Da Skip die Werterfassung behandelt, wenn MEV-Einnahmen in einen Community-Pool oder eine Schatzkammer fließen, könnte das Fragen aufwerfen (ist es eine Gebühr, ist es steuerpflichtig usw.?). Aber diese ähneln der Handhabung von Transaktionsgebühren, also nichts grundlegend Neues rechtlich. In Cosmos können Chain-Communities auch entscheiden, wie sie diesen Fonds verwenden (verbrennen, verteilen usw.), was sie bei Bedarf an rechtliche Vorgaben anpassen können (zum Beispiel könnten sie vermeiden, ihn an eine Stiftung zu senden, wenn dies Steuerprobleme auslöst, und ihn stattdessen verbrennen). In Bezug auf die Zensurresistenz ein interessanter Hinweis: Durch die Durchsetzung von Blockgültigkeitsregeln verhindert Skip, dass Validatoren bestimmte Transaktionen zensieren, wenn dies Regeln verletzen würde. Wenn beispielsweise eine Chain die Regel hätte „muss mindestens ein Oracle-Update enthalten“, könnte ein zensierender Validator nicht einfach alle Oracle-Transaktionen (die aus bestimmten Quellen stammen könnten) weglassen, weil sein Block ungültig wäre. So, ironischerweise, können Skip-Regeln die Aufnahme kritischer Transaktionen erzwingen (Anti-Zensur), genauso wie sie verwendet werden könnten, um den Ausschluss nicht erlaubter zu erzwingen. Es hängt alles davon ab, was die Community festlegt. Neutralität: Skips Standardhaltung ist, Chains zu befähigen, „Nutzer vor negativer MEV zu schützen und die Nutzererfahrung zu verbessern“, was Neutralität und Nutzerfreundlichkeit impliziert. Es gibt kein zentrales Skip-Netzwerk, das Entscheidungen trifft – jede Chain ist souverän. Skip als Unternehmen könnte beraten oder Standardeinstellungen bereitstellen (wie ein empfohlenes Auktionsformat), aber letztendlich entscheiden die Token-Inhaber der Chain. Diese Dezentralisierung der MEV-Politik auf die Governance jeder Chain kann als kompatibler mit regulatorischer Vielfalt angesehen werden: z.B. könnte eine US-basierte Chain die OFAC-Compliance implementieren, wenn sie rechtlich unter Druck gesetzt wird, ohne andere Chains zu beeinflussen. Es ist kein einziges Relay, das über viele Chains hinweg zensiert; es ist eine pro-Chain-Wahl. Aus regulatorischer Perspektive führt Skip keine zusätzlichen illegalen Aktivitäten ein – es reorganisiert lediglich, wie Transaktionen geordnet werden. Wenn überhaupt, könnte es die Volatilität reduzieren (weniger Gas-Kriege) und eine vorhersehbarere Ausführung schaffen, was ein Pluspunkt sein könnte. Summing up, Skips Architektur ist hochgradig anpassbar an Compliance-Bedürfnisse, während die Option für maximale Zensurresistenz erhalten bleibt, wenn Communities dies priorisieren. Es hält MEV im Tageslicht und unter kollektiver Kontrolle, was Blockchain-Ökosysteme wahrscheinlich robuster gegen sowohl bösartige Akteure als auch regulatorische Maßnahmen macht, da die Selbstverwaltung Missbräuche proaktiv angehen kann.

• Technische Architektur & Implementierung: Skip Protocol ist eng in den Cosmos SDK Stack integriert. Die Kernleistung ist ein Satz von Modulen (z.B. x/builder) und Modifikationen wie die BlockBuster Mempool-Implementierung. Cosmos-Chains betreiben einen Konsens (Tendermint/CometBFT), der ABCI-Hooks für die Vorbereitung und Verarbeitung von Vorschlägen bietet. Skip nutzt die ABCI++-Erweiterungen, die die Ausführung von Code zwischen Blockvorschlag und Finalisierung ermöglichen. So wird die Reihenfolge durchgesetzt: PrepareProposal kann die Blocktransaktionen gemäß den Lane-Regeln neu anordnen, bevor der Vorschlag gesendet wird, und ProcessProposal bei empfangenden Validatoren kann die Reihenfolge und die Zustandsgültigkeit auf Übereinstimmung mit den Erwartungen überprüfen. Dies ist eine moderne Funktion (Cosmos SDK v0.47+), und Skips POB ist mit aktuellen SDK-Versionen kompatibel. Unter der Haube pflegen Skips Module Datenstrukturen für Auktionen (z.B. ein On-Chain-Orderbuch von Geboten für Top-of-Block). Sie verwenden wahrscheinlich auch Prioritätstransaktionstypen. Die README zeigt eine spezielle MsgAuctionBid und benutzerdefinierte Logik zur Handhabung. Searcher interagieren also, indem sie diese Nachrichten über normale Cosmos-Transaktionen senden, die das Modul dann abfängt und entsprechend platziert. Der AnteHandler des Builder-Moduls (der AuctionDecorator) kann Auktionsgebote verbrauchen und Gewinner bestimmen in der Block-Assembly-Phase. Kryptographisch fügt Skip keine neuen kryptographischen Anforderungen hinzu (abgesehen von dem, was die Chain wählt, wie Schwellenwert-Kryptographie für den Mempool, was separat ist). Es verlässt sich auf die Ehrlichkeit von >2/3 der Validatoren, um die Regeln durchzusetzen und nicht zu kolludieren, um sie zu brechen. Wenn eine Mehrheit kolludieren würde, könnten sie technisch die Regeln über Governance ändern oder sie ignorieren, indem sie dies zur neuen De-facto-Regel machen. Aber das ist bei jeder Chain-Logik der Fall. Skips Design versucht, es einem einzelnen Validator mechanisch unmöglich zu machen, im kleinen Maßstab zu betrügen. Zum Beispiel wird jeder Versuch, die Reihenfolge zu ändern, von anderen erkannt, weil es objektiv ist. So reduziert es das Vertrauen in einzelne Proposer. In Bezug auf die Leistung fügt das Ausführen von Auktionen und zusätzlichen Prüfungen Overhead hinzu. Cosmos-Blöcke sind jedoch relativ klein und die Zeit zwischen den Blöcken beträgt oft ein paar Sekunden, was in den meisten Fällen für diese Operationen ausreicht. Die Simulation (Vorab-Ausführung von Transaktionen, um sicherzustellen, dass keine Fehler auftreten und die Reihenfolge-Einschränkungen eingehalten werden) könnte der aufwendigste Teil sein, aber Validatoren führen Blockausführungen normalerweise bereits durch, daher ist dies ähnlich. Die Anwesenheit von Multi-Lane bedeutet Mempool-Trennung: z.g. muss eine Transaktion möglicherweise angeben, welche Lane sie anvisiert (Auktion vs. Free vs. Default). Das Skip BlockBuster-Design hatte tatsächlich separate Lanes wie lanes/auction, lanes/free usw., wahrscheinlich separate Mempool-Warteschlangen. Das stellt sicher, dass beispielsweise kostenlose Transaktionen Auktions-Transaktionen nicht verzögern oder stören. Es ist ein bisschen wie mehrere Prioritätsklassen in der Zeitplanung zu haben. Ein weiterer Aspekt ist Sicherheit und Fehlverhalten: Wenn ein Proposer versucht, die Auktion zu manipulieren (z.B. seine eigene Transaktion aufzunehmen, aber zu behaupten, sie habe die Regeln befolgt), werden andere Validatoren den Block ablehnen. Der Cosmos-Konsens geht dann wahrscheinlich zum nächsten Proposer über und bestraft den vorherigen für Double-Signing oder einfach das Verpassen (je nach Szenario). Das Chain-Sicherheitsmodell handhabt dies also – keine spezielle Slashing durch Skip erforderlich, die über den bestehenden Konsens hinausgeht. Man könnte Skip erweitern, um für bösartige Reihenfolge zu bestrafen, aber wahrscheinlich unnötig, wenn der Block einfach fehlschlägt. Entwicklung und Tools: Skips Code wurde quelloffen gemacht (anfänglich unter skip-mev/pob und jetzt wahrscheinlich nach stabilen Releases in ein neues Repo verschoben). Sie haben Testnets und Iterationen mit Partner-Chains durchlaufen. Auf der Roadmap haben wir gesehen: Osmosis Prop 341 (im Herbst 2022 verabschiedet) zur Integration von ProtoRev und Auktionen mit Skip – im Frühjahr 2023 geliefert. Terras Astroport integrierte MEV-Sharing mit Skip im Jahr 2023. Der Cosmos Hub evaluiert Skips „Block SDK“, das ähnliche Funktionen in den Hub bringen würde. Eine weitere interessante Grenze ist Cross-Chain-MEV über den Interchain Scheduler – die Cosmos Hub-Community erforscht eine Interchain-MEV-Auktion, bei der MEV von vielen Chains im Hub gehandelt werden könnte, und Skip ist an diesen Diskussionen beteiligt (die Zerocap-Forschung erwähnte den geplanten Interchain Scheduler von IBC). Skips Technologie könnte als Rückgrat für solche Cross-Chain-Auktionen dienen, da sie bereits Auktionen auf einzelnen Chains durchführt. Das wäre analog zu SUAVEs Cross-Domain-Ziel, aber innerhalb von Cosmos. Was wichtige Updates betrifft: Skip wurde Mitte 2022 gestartet. Bis Mitte 2023 hatten sie eine stabile POB-Veröffentlichung für SDK v0.47+ (auf das viele Chains aktualisieren). Sie haben auch Startkapital erhalten, was auf eine aktive Entwicklung hindeutet. Ein weiterer Konkurrent in Cosmos, Mekatek, bietet ähnliche Funktionen. Dies hat Skips Roadmap vielleicht beschleunigt, um die Nase vorn zu behalten. Skip verfeinert weiterhin Funktionen wie private Transaktions-Lanes (vielleicht zum Verbergen von Transaktionen bis zur Aufnahme) und komplexere Gültigkeitsregeln, wenn Anwendungsfälle entstehen. Da es modular ist, könnte eine Chain wie dYdX (die ein Orderbuch haben wird) Skip verwenden, um Fairness beim Order-Matching On-Chain usw. zu gewährleisten, sodass Skips Tools sich an unterschiedliche Anwendungslogiken anpassen könnten. Technisch gesehen ist Skips Lösung einfacher als der Aufbau einer ganz neuen Chain: Es ist eine Verbesserung der Fähigkeiten bestehender Chains. Dieser inkrementelle, Opt-in-Ansatz hat eine ziemlich schnelle Akzeptanz ermöglicht – z.B. erforderte die Aktivierung von Auktionen auf Osmosis keinen neuen Konsensalgorithmus, sondern nur das Hinzufügen eines Moduls und die Koordination der Validatoren, die aktualisierte Software auszuführen (was sie taten, da es vorteilhaft war und von der Governance verabschiedet wurde). Zusammenfassend ist Skips Architektur in die Node-Software jeder Chain eingebettet und passt den Mempool und die Blockvorschlags-Pipeline an. Es ist ein pragmatischer technischer Ansatz für faire Reihenfolge: Verwenden, was bereits vorhanden ist (Tendermint BFT), Logik hinzufügen, um es zu steuern. Die schwere Arbeit (wie das Finden von Arbitragen) kann sogar vom eigenen Modul der Chain erledigt werden (ProtoRev verwendet Osmosis' eingebauten Wasm- und Rust-Code, um Pools zu scannen). So wird ein Großteil der MEV-Handhabung On-Chain verlagert. Dieser On-Chain-Ansatz muss sorgfältig auf Effizienz und Sicherheit kodiert werden, steht aber unter der Aufsicht der Community. Wenn eine Regel problematisch ist (zu streng usw.), kann die Governance sie anpassen. Technisch und sozial verwandelt Skip MEV somit in einen weiteren Parameter der Chain, der optimiert und verwaltet werden muss, anstatt in einen Wilden Westen. Dies ist eine einzigartige Haltung, die durch die Flexibilität von Cosmos ermöglicht wird.

Vergleichende Analyse von SUAVE, Anoma, Skip und Flashbots v2​

Diese vier Protokolle nähern sich dem MEV- und Fair-Ordering-Problem aus verschiedenen Blickwinkeln, zugeschnitten auf ihre jeweiligen Ökosysteme und Designphilosophien. Flashbots v2 ist eine inkrementelle, pragmatische Lösung für Ethereums aktuelle Architektur: Es umfasst MEV-Auktionen, versucht aber, deren Auswirkungen zu demokratisieren und abzumildern (durch Off-Chain-Koordination, SGX-Privatsphäre und Sharing-Mechanismen). SUAVE ist Flashbots' zukunftsweisender Plan, eine Inter-Chain-MEV-Plattform zu schaffen, die den Gesamtwert und die Nutzervorteile maximiert – im Wesentlichen die Skalierung des Auktionsmodells auf ein dezentrales, datenschutzfreundliches globales Netzwerk. Anoma ist eine grundlegende Neukonzeption der Formulierung und Ausführung von Transaktionen, die darauf abzielt, die Grundursachen unfairer Reihenfolge durch die Verwendung von Intents, Solver-vermittelter Übereinstimmung und kryptographischer Fairness im Konsens zu eliminieren. Skip ist ein souveräner Chain-Ansatz, der Fairness und MEV-Erfassung auf Protokollebene pro Chain integriert, insbesondere in Cosmos, durch konfigurierbare Regeln und Auktionen.

Jedes hat Stärken und Kompromisse:

• Fairness- und Reihenfolgegarantien: Anoma bietet die stärkste theoretische Fairness (kein Frontrunning per Design, verschlüsselte Batches), erfordert aber ein neues Paradigma und komplexe Technologie, die noch bewiesen werden muss. Skip kann konkrete Fairness-Regeln auf bestehenden Chains durchsetzen (Front-Runs verhindern oder First-In-First-Out innerhalb von Lanes erzwingen), ist aber durch das begrenzt, was jede Community durchzusetzen wählt. SUAVE und Flashbots v2 verbessern die Fairness in Bezug auf den Zugang (offene Auktionen statt geheimer Deals, Schutz vor öffentlichem Mempool-Sniping), verhindern aber nicht von Natur aus, dass eine entschlossene MEV-Strategie ausgeführt wird – sie stellen lediglich sicher, dass sie die Nutzer bezahlt oder neutral durchgeführt wird.
• MEV-Umverteilung: SUAVE und Flashbots zielen explizit darauf ab, MEV „zurück“ an Nutzer/Validatoren zu geben: SUAVE über Nutzergebote/Rückerstattungen, Flashbots über Builder-Wettbewerbe und Rückerstattungen. Skip kann MEV an Nutzer (wie konfiguriert, z.B. im Fall von Astroport) oder an Community-Fonds leiten. Anoma vermeidet eine explizite Umverteilung, da das Ziel darin besteht, die Extraktion überhaupt zu vermeiden – idealerweise erhalten Nutzer einfach faire Preise, was gleichbedeutend damit ist, keinen Wert an MEV zu verlieren.
• Umfang (Einzel- vs. Mehrfachdomäne): Flashbots v2 und Skip konzentrieren sich auf ihre eigenen Domänen (Ethereum bzw. einzelne Cosmos-Chains). SUAVE ist von Natur aus mehrfachdomänenfähig – es sieht Cross-Chain-MEV als Hauptmotivation. Anoma berücksichtigt schließlich auch Multi-Chain-Intents, aber in den Anfangsphasen könnte dies innerhalb einer fraktalen Instanz gleichzeitig geschehen, dann über Adapter überbrückt werden. SUAVEs Cross-Chain-Auktion könnte Arbitrage und Koordination ermöglichen, die andere nicht so einfach erreichen können (außer vielleicht ein Interchain Scheduler mit Skips Hilfe in Cosmos).
• Komplexität und Akzeptanz: Flashbots v2 war relativ einfach zu übernehmen (ein Client-Sidecar) und erfasste schnell die Mehrheit der Ethereum-Blöcke. Skip nutzt ebenfalls bestehende Technologie und findet in Cosmos mit unkomplizierten Governance-Vorschlägen Akzeptanz. SUAVE und Anoma sind revolutionärer – sie erfordern neue Netzwerke oder größere Änderungen. SUAVEs Herausforderung wird darin bestehen, viele Chains und Nutzer dazu zu bringen, sich für eine neue Schicht zu entscheiden; Anomas Herausforderung besteht darin, ein neues Ökosystem zu schaffen und Entwickler davon zu überzeugen, in einem Intent-zentrierten Modell zu bauen.
• Compliance und Neutralität: Alle vier bieten Verbesserungen in der Transparenz. Flashbots v2/SUAVE entfernen Dark-Forest-Elemente, mussten aber Zensurprobleme bewältigen – SUAVE wird explizit gebaut, um diese zentralen Punkte zu vermeiden. Anoma schützt Nutzer mit standardmäßiger Privatsphäre maximal (könnte aber Regulierungsbehörden aufgrund verschlüsselter Aktivitäten beunruhigen). Skips Modell gibt jeder Chain Autonomie, einen Compliance-Kompromiss zu finden. Wenn eine Regulierungsbehörde „keine MEV-Auktionen“ oder „keine Privatsphäre“ forderte, könnte ein Ethereum, das Flashbots verwendet, in Konflikt geraten, während eine Cosmos-Chain, die Skip verwendet, diese Funktionen einfach nicht implementieren oder anpassen könnte. In Bezug auf Neutralität: SUAVE und Anoma streben glaubwürdige Neutralität an (jeder greift zu gleichen Bedingungen auf ein System zu; beide sind im Wesentlichen öffentliche Güternetzwerke). Flashbots v2 ist neutral, indem es offenen Zugang bietet, aber eine gewisse Zentralisierung im Builder-Markt besteht (obwohl durch BuilderNet-Bemühungen gemildert). Skips Neutralität hängt von der Governance ab – idealerweise begünstigt MEV keinen einzelnen Insider, aber man könnte es schlecht konfigurieren und die Neutralität schädigen (obwohl unwahrscheinlich, da dies einen Governance-Konsens erfordern würde).
• Technische Architekturunterschiede: Flashbots v2 und SUAVE sind Off-Chain-Marktplätze, die auf der Chain geschichtet sind: Sie führen spezialisierte Rollen (Builder, Relays, Executors) ein und verwenden Hardware oder Kryptographie, um sie zu sichern. Anoma und Skip integrieren sich direkt in den Konsens oder die Zustandsmaschine. Anoma ändert den Transaktionslebenszyklus und den Konsens selbst (mit Schwellenwert-Verschlüsselung und vereinheitlichten Intents). Skip greift über ABCI++ in den Konsens von Tendermint ein, ändert aber den grundlegenden Algorithmus nicht – es ist eine Anwendungsschicht-Anpassung. Dieser Unterschied bedeutet, dass SUAVE/Flashbots theoretisch viele Chains bedienen können, ohne dass jede Chain ein Upgrade benötigt (sie laufen parallel zu ihnen), während Anoma/Skip erfordern, dass jede Chain oder Instanz die neue Software verwendet. SUAVE ist etwas dazwischen: Es ist eine separate Chain, aber um sie effektiv zu nutzen, benötigen andere Chains geringfügige Anpassungen (um von SUAVE gebaute Blöcke zu akzeptieren oder an SUAVE auszugeben). Die kryptographische Raffinesse ist am höchsten in Anoma (ZK, MPC, Schwellenwert-Krypto alles in einem), moderat in SUAVE (Schwellenwert-Krypto und SGX, plus normale Krypto für Bridging) und relativ gering in Flashbots v2 (SGX, Standard-Signaturen) und Skip (hauptsächlich Standard-Signaturen, plus was die Chain verwendet, wie Schwellenwert-Entschlüsselung, wenn gewählt).
• Entwicklungsstand: Flashbots v2 ist in Produktion auf Ethereum (seit September 2022). Skip ist in Produktion auf mehreren Cosmos-Chains (ab 2022–2023). SUAVE befindet sich in der Testnet-/Devnet-Phase, wobei Teile ausgerollt werden (einige Auktionsfunktionen in Tests, Testnet Toliman live). Anoma befindet sich ebenfalls in der Testnet-Phase (ein Vision-Paper, partielle Implementierungen wie Namada Mainnet und wahrscheinlich ein Anoma Testnet, das 2023 Einladungscodes erfordert). In Bezug auf reale Daten: Flashbots v2 und Skip haben Ergebnisse gezeigt (z.B. lieferte Flashbots v2 Millionen an Validatoren und senkte die durchschnittlichen Gaspreise in Zeiten hoher MEV; Skips ProtoRev generierte erhebliche Mittel für die Osmosis-Community und verhinderte viele Sandwich-Angriffe, als die Schwellenwert-Verschlüsselung begann). SUAVE und Anoma sind vielversprechend, müssen sich aber operativ und wirtschaftlich noch bewähren.

Um diese Vergleiche zu verdeutlichen, fasst die folgende Tabelle die wichtigsten Aspekte jedes Protokolls nebeneinander zusammen:

Protokoll	Transaktionsreihenfolge	MEV-Mechanismus (Unterdrücken vs. Extrahieren)	Ökonomische Anreize (Ausrichtung)	Compliance & Neutralität	Architektur & Technologie	Entwicklungsstatus
Flashbots v2 (Ethereum)	Off-Chain-Builder-Auktionen entscheiden über die Blockreihenfolge (PBS über MEV-Boost). Öffentliche Mempool-Transaktionen werden für private Bundles umgangen. Die Reihenfolge ist gewinnorientiert (höchstbezahltes Bundle zuerst).	Extrahiert MEV über Sealed-Bid-Block-Auktionen, aber mildert schädliche Nebeneffekte (keine Gas-Kriege, kein öffentliches Frontrunning). Bietet private Transaktionseinreichung (Flashbots Protect) zur Unterdrückung von nutzersichtbarer MEV wie direktem Frontrunning. Zensurresistenz verbessert sich durch Multi-Relay- und Builder-Dezentralisierung.	Validatoren maximieren Einnahmen durch Auslagerung von Blöcken (erhalten höchste Gebote). Searcher konkurrieren um die Aufnahme und geben Gewinne ab (meiste MEV geht an Validatoren). Builder verdienen eine Marge, falls vorhanden. Neue Rückerstattungen teilen MEV mit Nutzern (über BuilderNet). Anreize fördern offenen Wettbewerb gegenüber exklusiven Deals.	Anfangs mit OFAC-Zensur konfrontiert (zentrales Relay), wechselte aber zu mehreren Relays und Open-Source-Buildern. Verfolgt nun glaubwürdige Neutralität: BuilderNets TEE-Netzwerk stellt sicher, dass kein einzelner Builder zensieren kann. Insgesamt transparenter als Mempool, aber immer noch auf Off-Chain-Entitäten (Relays) angewiesen.	Off-Chain-Marktplatz integriert mit Ethereum PoS. Nutzt Trusted HW (SGX) für privaten Orderflow in BuilderNet. Keine Konsensänderung auf L1; verwendet Standard-Builder-API. Stark auf Engineering (Sidecar-Clients, Relays) ausgerichtet, aber wenig neue Kryptographie.	Produktion auf Ethereum Mainnet (seit Sep 2022). >90% der Blöcke über MEV-Boost. Kontinuierliche Upgrades: Open-Source-Builder, BuilderNet Alpha live (Ende 2024). Stabil bewährt, mit laufenden Dezentralisierungsbemühungen.
SUAVE (Flashbots’ nächste Gen.)	Vereinheitlichter Cross-Chain-Mempool von Präferenzen (Nutzer-Intents + Gebote). Executors bilden daraus optimale Transaktions-Bundles. Dezentrale Sequenzierung – SUAVE gibt geordnete Blockfragmente an Domänen aus. Reihenfolge basiert auf Nutzergeboten & globalem Wohl (nicht einfachem FIFO oder Gas). Privatsphäre (Verschlüsselung) verhindert Order-Manipulation bis zur Ausführung.	Unterdrückt „schlechte MEV“ durch Rückgabe von MEV an Nutzer: z.B. Orderflow-Auktionen zahlen Nutzer für Backrunning. Aggregiert „gute MEV“ (wie Cross-Domain-Arbs) zur maximalen Extraktion, verteilt sie aber an Nutzer/Validatoren. Nutzt verschlüsselten Mempool & kollaboratives Block-Building, um Frontrunning und exklusiven Zugang zu verhindern.	Nutzer posten Präferenzen mit zahlbaren Geboten; konkurrierende Executors verdienen das Gebot, indem sie das Nutzerziel erfüllen. Validatoren jeder Chain erhalten höhere Gebühren durch optimale Blöcke und Cross-Chain-MEV-Erfassung. SUAVEs eigene Validatoren verdienen Netzwerkgebühren. Das Design verschiebt MEV-Gewinn an Nutzer und Validatoren, minimiert die Rentabilität für Searcher. Flashbots will nur als Vermittler agieren.	Für glaubwürdige Neutralität gebaut: eine neutrale öffentliche Plattform, die nicht von einem einzelnen Akteur kontrolliert wird. Datenschutz zuerst (Transaktionen in SGX oder über Kryptographie verschlüsselt) bedeutet, dass keine Entität aufgrund des Inhalts zensieren kann. Hofft, Flashbots-Vertrauensanforderungen durch progressive Dezentralisierung zu vermeiden. Compliance ist nicht explizit eingebaut, aber Neutralität und globale Reichweite werden priorisiert (könnte regulatorische Fragen zur Privatsphäre aufwerfen).	Unabhängige Chain (EVM-kompatibel) für Präferenzen & Auktionen. Nutzt Intel SGX-Enklaven extensiv (für privaten Mempool und kollaboratives Block-Building). Plant die Einführung von Schwellenwert-Verschlüsselung und MPC zur Eliminierung vertrauenswürdiger Hardware. Im Wesentlichen eine Blockchain + sichere Berechnungsschicht über anderen.	In Entwicklung – Centauri-Testnet-Phase aktiv (Devnet, grundlegende Auktionen). Open-Source-SUAVE-Client (Aug 2023); Toliman-Testnet für Community-Tests gestartet. Mainnet noch nicht live (in Phasen erwartet: Andromeda, Helios). Ehrgeizige Roadmap, noch nicht in großem Maßstab bewährt.
Anoma (Intent-zentriertes Protokoll)	Kein konventioneller Mempool; Nutzer senden Intents (gewünschte Ergebnisse). Solver sammeln Intents und produzieren abgeglichene Transaktionen. Nutzt Schwellenwert-Verschlüsselung von Transaktionen, sodass Validatoren sie ohne Kenntnis des Inhalts ordnen, was reaktive MEV verhindert. Oft werden Batch-Verarbeitungen eingesetzt (z.B. Entschlüsseln und Abgleichen von Intents in Batches alle N Blöcke) für faire Preise. Konsens sichert Order-Commitments vor der Offenlegung, wodurch Order-Fairness erreicht wird.	Starke MEV-Minderung per Design: Frontrunning unmöglich (Transaktionen werden erst nach Finalisierung der Reihenfolge offengelegt). Batch-Auktionen eliminieren Prioritätsvorteile (z.B. alle Trades im Batch teilen sich den Clearing-Preis). Solver konkurrieren, um Intents zu erfüllen, was die Preise nutzeroptimal macht und wenig MEV übrig lässt. Im Wesentlichen minimiert es den extrahierbaren Wert – jede notwendige Arbitrage erfolgt als Teil des Matchings, nicht durch Außenstehende.	Solver verdienen Gebühren oder Spreads für das Finden von Matches (ähnlich DEX-Aggregatoren), aber der Wettbewerb zwingt sie, Nutzern die besten Deals zu liefern. Validatoren erhalten Gebühren und Staking-Belohnungen; sie sichern auch die faire Ausführung (keine zusätzliche MEV über Konsens). Nutzer profitieren von besserer Ausführung (sie handeln nur zu fairen Preisen, ohne Wert an MEV zu verlieren). Wert, der MEV wäre, bleibt bei den Nutzern oder dem Protokoll (oder wird minimal mit Solvern als Servicegebühr geteilt). Die Architektur richtet Anreize für ehrliche Teilnahme aus (Solver und Validatoren werden für die Erleichterung von Trades belohnt, nicht für deren Ausnutzung).	Privatsphäre und Fairness sind Kern – Intents können teilweise oder vollständig abgeschirmt werden (mit ZK-Proofs), was Nutzerdaten schützt. Zensurresistenz: Validatoren können nicht selektiv zensieren, was sie nicht im Klartext sehen (verschlüsselte Transaktionen), und müssen algorithmische Matching-Regeln befolgen. Hochgradig neutral – alle Intents werden von derselben Matching-Logik behandelt. Regulatorische Compliance ist nicht eingebaut (starke Privatsphäre könnte für KYC eine Herausforderung sein), aber das Intent-Framework könnte konforme Designs auf Anwendungsebene ermöglichen.	Neue Blockchain-Architektur. Nutzt BFT-Konsens mit integrierter Intent-Gossip- & Solver-Schicht. Verlässt sich auf Schwellenwert-Kryptographie (Ferveo) für Mempool-Privatsphäre und ZK-SNARKs (Taiga) für Datenprivatsphäre. Die Ausführung wird durch Gültigkeitsprädikate (anwendungsspezifische Logik zur Durchsetzung fairer Ergebnisse) gesteuert. Interoperabel über IBC (Multi-Chain-Intents in Zukunft möglich). Kryptographisch sehr fortschrittlich (Verschlüsselung, ZK, MPC-Konzepte kombiniert).	Testnets und teilweise Starts. Anomas erstes Testnet Feigenbaum (Nov 2021) demonstrierte grundlegendes Intent-Matching. Viele Konzepte werden in Phasen implementiert; z.B. Namada (2023) wurde mit Anomas Datenschutztechnologie und Ferveo für einen Single-Chain-Anwendungsfall gestartet. Das vollständige Anoma L1 mit Intents befindet sich im Testnet (Einladungstests Mitte 2023). Mainnet Phase 1 (geplant) zielt auf Ethereum-Integration ab; natives Token und vollständiger Konsens später. Noch unter intensiver F&E, noch nicht in der Praxis bewährt.
Skip Protocol (Cosmos)	In-Protocol-Transaktionsreihenfolgeregeln und Block-Lanes, konfiguriert durch die Governance jeder Chain. Z.B. bestimmen Auktionen die Top-of-Block-Reihenfolge, dann Standardtransaktionen usw. Konsensdurchgesetzt: Validatoren lehnen Blöcke ab, die die Reihenfolge verletzen (wie eine ungültige Transaktionssequenz). Ermöglicht benutzerdefinierte Richtlinien (nach Gaspreis ordnen, Oracle-Transaktion zuerst aufnehmen, bestimmte Muster verbieten) – effektiv deterministische Reihenfolge-Algorithmen, die von der Chain gewählt werden.	Hybridansatz – extrahiert MEV auf kontrollierte Weise (über On-Chain-Auktionen und protokolleigene Arbitrage), während bösartige MEV unterdrückt wird (durch Regeldurchsetzung). Frontrunning kann durch Chain-Regeln verboten werden. Backrunning/Arbitrage kann internalisiert werden: z.B. führt die Chain ihre eigene Arbitrage durch (ProtoRev) und teilt die Einnahmen. Blockspace-Auktionen (Skip Select) lassen Searcher um Priorität bieten, sodass MEV transparent erfasst und oft umverteilt wird. Insgesamt wird negative MEV (Sandwiches usw.) eingeschränkt, während „positive MEV“ (Arbs, Liquidationen) zum Nutzen der Chain genutzt wird.	Validatoren erhalten eine neue Einnahmequelle aus Auktionsgebühren oder protokollierter MEV, ohne Konsensregeln zu brechen. Das Risiko individueller betrügerischer MEV wird reduziert (muss Regeln befolgen, sonst ist Block ungültig), wodurch Validatoren kollektiv ausgerichtet werden. Chain/Community kann MEV-Einnahmen lenken (z.B. an Staker oder Community-Fonds). Searcher müssen über Auktionen konkurrieren und geben oft einen Teil des Gewinns an Chain/Validatoren ab. Einige MEV-Rollen werden von On-Chain-Modulen übernommen (weniger einfache Gewinne für Searcher). Nutzer profitieren von weniger Angriffen und können sogar MEV-Rabatte erhalten (z.B. Astroport teilt MEV mit Tradern). Anreize werden Community-ausgerichtet – MEV wird als öffentliche Einnahme behandelt oder bei Schädigung überhaupt nicht zugelassen, anstatt als privater Gewinn.	Souveräne Compliance: Jede Chain wählt ihre Richtlinie. Das bedeutet, eine Chain könnte strenge Anti-MEV-Regeln durchsetzen oder KYC-Anforderungen bei Bedarf über die Modulkonfiguration aufnehmen. Skips Transparenz (On-Chain-Gebote) und Governance-Kontrolle verbessern die Legitimität. Es erhöht inhärent die Zensurresistenz innerhalb der gewählten Regeln jeder Chain – z.B. wenn die Regel besagt „immer Oracle-Transaktionen aufnehmen“, kann ein zensierender Validator diese nicht weglassen. Aber wenn eine Chain beschließt zu zensieren (per Regel), könnte Skip dies auch durchsetzen. Im Allgemeinen fördert Skip Transparenz und Fairness, wie von der Community bestimmt. Keine einzelne Entität (wie ein Relay) kontrolliert die Reihenfolge – es ist im Protokoll und Open Source.	Cosmos SDK-Module (Protocol-Owned Builder) zur Node-Software hinzugefügt. Nutzt ABCI++-Hooks für benutzerdefinierte Block-Assembly und -Validierung. Implementiert On-Chain-Auktionen (Smart Contracts oder Module handhaben Gebote und Auszahlungen). Standardmäßig keine spezialisierte Kryptographie (außer der Standard-Cosmos-Technologie), aber kompatibel mit Schwellenwert-Verschlüsselung – z.B. hat Osmosis einen verschlüsselten Mempool mit Skip im Hinterkopf hinzugefügt. Im Wesentlichen eine Erweiterung von Tendermint BFT, die MEV-bewusste Logik in den Blockvorschlag einfügt. Leicht für Chains zu übernehmen (nur Modulintegration, kein neues Konsensprotokoll).	Live auf mehreren Chains. Skips Auktions- und Builder-Modul auf Osmosis (2023) eingesetzt – ProtoRev-Modul generierte Protokolleinnahmen und Auktionen für Top-of-Block sind live. Wird auf Terra/Astroport, Juno usw. verwendet und vom Cosmos Hub in Betracht gezogen. Code ist Open-Source und entwickelt sich weiter (v1 von POB für SDK 0.47+). In Produktion bewährt, mit realer MEV erfasst und verteilt. Rollt weiterhin Funktionen aus (z.B. neue Lane-Typen) und bindet Chains ein.

Jede Lösung zielt auf das MEV-Problem aus einer anderen Schicht ab – Flashbots v2 arbeitet um den L1-Konsens herum, SUAVE schlägt eine neue L1.5-Schicht vor, Anoma gestaltet den L1 selbst neu, und Skip nutzt modulare L1-Anpassung. In der Praxis schließen sich diese Ansätze nicht gegenseitig aus und könnten sich sogar ergänzen (zum Beispiel könnte eine Cosmos-Chain Skip intern nutzen und auch Intents an SUAVE für Cross-Chain-MEV senden, oder Ethereum könnte in Zukunft eine Anoma-ähnliche Order-Fairness implementieren, während es Flashbots weiterhin für Builder-Märkte nutzt). Die Tabelle veranschaulicht ihre vergleichenden Eigenschaften: Flashbots v2 liefert bereits Verbesserungen auf Ethereum, extrahiert aber immer noch MEV (nur gerechter und effizienter); SUAVE strebt ein maximales Synergieergebnis an, bei dem alle über ein Netzwerk zusammenarbeiten – sein Erfolg wird von breiter Akzeptanz und technischer Umsetzung der versprochenen Privatsphäre und Dezentralisierung abhängen; Anoma bietet vielleicht die mächtigste MEV-Unterdrückung, indem es die Funktionsweise von Transaktionen vollständig ändert, steht aber vor der großen Herausforderung, ein neues Ökosystem aufzubauen und sein komplexes Protokoll zu beweisen; Skip findet ein pragmatisches Gleichgewicht für Cosmos, indem es Communities die Möglichkeit gibt, MEV-Einnahmen und Nutzerschutz nach ihren eigenen Bedingungen zu steuern – es ist weniger radikal als Anoma, aber stärker integriert als Flashbots und zeigt bereits greifbare Ergebnisse in Cosmos.

Fazit und Ausblick​

MEV-Unterdrückung und faire Reihenfolge bleiben eines der „Millennium-Preisprobleme der Krypto-Welt“. Die vier analysierten Protokolle – Flashbots v2, SUAVE, Anoma und Skip – repräsentieren ein Spektrum von Lösungen: von sofortigen Minderungen in bestehenden Frameworks bis hin zu vollständigen Paradigmenwechseln in der Transaktionsverarbeitung. Flashbots v2 hat die Kraft offener MEV-Märkte demonstriert, Chaos zu reduzieren und Werte umzuverteilen, wenn auch unter Berücksichtigung von Kompromissen wie Zensur, die durch Dezentralisierung angegangen werden. Es zeigt, dass inkrementelle Änderungen (wie PBS-Auktionen und private Mempools) die negativen Auswirkungen von MEV kurzfristig erheblich reduzieren können. SUAVE, Flashbots' nächster Schritt, führt dieses Ethos in eine vereinheitlichte Cross-Chain-Arena – wenn es erfolgreich ist, könnten wir eine Zukunft sehen, in der Nutzer routinemäßig für die MEV bezahlt werden, die ihre Trades erzeugen, und in der die Blockproduktion über viele Netzwerke hinweg kollaborativ und für Fairness verschlüsselt ist. Anoma weist auf eine grundlegendere Entwicklung hin: Indem es das Konzept von Prioritätstransaktionen entfernt und durch ein Intent-Matchmaking-System ersetzt, könnte es ganze Klassen von MEV eliminieren und ausdrucksstärkere Finanz-DApps ermöglichen. Seine faire Reihenfolge auf Konsensebene (über Schwellenwert-Verschlüsselung und Batch-Auktionen) ist ein Einblick, wie Blockchains selbst Fairnessgarantien bieten können, nicht nur Off-Chain-Add-ons. Skip Protocol wiederum veranschaulicht einen Mittelweg in einem Multi-Chain-Kontext – es gibt einzelnen Chains die Möglichkeit zu entscheiden, wie MEV-Einnahmen und Nutzerschutz ausbalanciert werden. Seine frühe Akzeptanz in Cosmos zeigt, dass viele der negativen Auswirkungen von MEV heute mit durchdachter Protokollentwicklung und Community-Zustimmung angegangen werden können.

Für die Zukunft können wir eine gegenseitige Befruchtung von Ideen erwarten: Ethereum-Forscher untersuchen Order-Fair-Konsens und Schwellenwert-Verschlüsselung (inspiriert von Projekten wie Anoma und Osmos' verschlüsseltem Mempool) für eine potenzielle Aufnahme in L1- oder L2-Lösungen. Flashbots' SUAVE könnte mit Cosmos-Chains (vielleicht sogar über Skip) interagieren, da es kettenagnostisch sein will. Anomas Intent-Konzept könnte das Anwendungsdesign auch auf traditionellen Plattformen beeinflussen (z.B. verwendet CoW Swap auf Ethereum bereits ein Solver-Modell; man kann es als eine „Anoma-ähnliche“ DApp betrachten). Skips Erfolg könnte andere Ökosysteme (Polkadot, Solana usw.) ermutigen, ähnliche In-Protocol-MEV-Kontrollen zu übernehmen. Ein Schlüsselthema ist die wirtschaftliche Ausrichtung – all diese Protokolle streben danach, die Anreize derjenigen, die das Netzwerk sichern, mit dem Wohlergehen der Nutzer in Einklang zu bringen, sodass die Ausnutzung von Nutzern nicht profitabel oder nicht möglich ist. Dies ist entscheidend für die langfristige Gesundheit von Blockchain-Ökosystemen und zur Vermeidung von Zentralisierung.

Zusammenfassend tragen SUAVE, Anoma, Skip und Flashbots v2 jeweils Teile des Puzzles zu fairer Reihenfolge und MEV-Minderung bei. Flashbots v2 hat eine Vorlage für MEV-Auktionen geschaffen, die andere nachahmen, Skip hat bewiesen, dass On-Chain-Durchsetzung praktikabel ist, Anoma hat die Vorstellungskraft dessen erweitert, was durch den Umbau des Transaktionsmodells möglich ist, und SUAVE versucht, die Gewinne der letzten Jahre zu vereinheitlichen und zu dezentralisieren. Die ultimative Lösung könnte Elemente von allem umfassen: datenschutzfreundliche globale Auktionen, Intent-zentrierte Benutzeroberflächen, kettenweite Fairnessregeln und kollaboratives Block-Building. Im Jahr 2025 ist der Kampf gegen MEV-induzierte Ungerechtigkeit in vollem Gange – diese Protokolle verwandeln MEV von einer dunklen Unvermeidlichkeit in einen verwalteten, sogar produktiven Teil der Kryptoökonomie, während sie dem Ideal der „besten Ausführung für Nutzer mit der dezentralsten Infrastruktur“ näherkommen.