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

Maximal Extractable Value (MEV) bezieht sich auf den Gewinn, den ein Blockchain-„Insider“ (Miner / Validator oder ein anderer privilegierter Akteur) durch das willkürliche Umordnen, Einschließen oder Ausschließen von Transaktionen in einem Block erzielen kann. Eine unkontrollierte MEV-Extraktion kann zu einer unfairen Transaktionsreihenfolge, hohen Gebühren (durch Priority Gas Auctions) und einer Machtzentralisierung bei der Blockproduktion führen. Eine Reihe von Protokollen ist entstanden, um schädliches MEV zu unterdrücken oder eine faire Reihenfolge von Transaktionen zu erzwingen. Dieser Bericht vergleicht vier prominente Ansätze: Flashbots v2 (das MEV-Boost-System für Ethereum nach dem Merge), SUAVE (Flashbots’ kommende Single Unifying Auction for Value Expression), Anoma (eine intent-zentrierte Architektur, die das Matching und Ordnen von Transaktionen neu konzipiert) und Skip Protocol (ein Cosmos-basiertes Toolkit für souveränes, protokollinternes MEV-Management). Wir untersuchen jeden Ansatz im Hinblick auf seine Algorithmen zur Transaktionswarteschlange / -reihenfolge, MEV-Minderungs- oder Extraktionsmechanismen, Anreizmodelle, Compliance- und Neutralitätsmerkmale, technische Architektur (Konsens und Kryptographie) sowie den Entwicklungsfortschritt. Strukturierte Zusammenfassungen und eine Vergleichstabelle heben ihre Stärken und Kompromisse bei der Verfolgung von Fairness und der Reduzierung negativer MEV-Externalitäten hervor.

Flashbots v2 (MEV-Boost & BuilderNet auf Ethereum)

Flashbots v2 bezeichnet das aktuelle Flashbots-Ökosystem auf Ethereum nach dem Umstieg auf Proof-of-Stake, konzentriert auf MEV-Boost und jüngste Initiativen wie BuilderNet. Flashbots v2 baut auf dem Paradigma der Proposer / Builder Separation (PBS) auf, um den Blockaufbau für einen wettbewerbsorientierten Markt von Buildern zu öffnen und gleichzeitig Ethereum-Nutzer vor MEV-Angriffen im öffentlichen Mempool zu schützen.

• Transaktionsreihenfolge (Warteschlangen & Algorithmus): Flashbots MEV-Boost führt einen Off-Chain-Marktplatz für den Blockaufbau ein. Validatoren (Proposer) lagern den Blockaufbau über ein Relay an spezialisierte Builder aus, anstatt Transaktionen lokal zu ordnen. Mehrere Builder konkurrieren darum, den am höchsten zahlenden 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-Ordnung des öffentlichen Mempools durch eine Sealed-Bid-Auktion für gesamte Blöcke. Builder bestimmen die Transaktionsreihenfolge intern, um die Gesamtauszahlungen (einschließlich MEV-Möglichkeiten) zu maximieren, wobei sie typischerweise Bundles mit profitablen Arbitragen oder Liquidationen an der Spitze des Blocks bevorzugen. Durch den Einsatz 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 Netzlast erhöhte), zentralisiert MEV-Boost die Ordnung pro Block beim wettbewerbsfähigsten Builder. Transaktionswarteschlangen werden somit privat von Buildern verwaltet, die eingehende Bundles oder Transaktionen sehen und für optimalen Gewinn anordnen können. Ein Nachteil ist, dass diese gewinnorientierte Ordnung nicht von Natur aus „Fairness“ für die Nutzer erzwingt – Builder können beispielsweise immer noch toxische Orderflows wie Sandwich-Attacken einbeziehen, sofern diese profitabel sind. Dennoch wird die Effizienz optimiert, indem MEV über eine kontrollierte Auktion statt über Ad-hoc-Gas-Kriege extrahiert wird. Jüngste Entwicklungen zielen darauf ab, die Ordnung neutraler zu gestalten: Zum Beispiel ermöglicht das neue BuilderNet von Flashbots (Ende 2024 gestartet), dass mehrere kooperierende Builder Orderflows teilen und Blöcke gemeinsam in einem Trusted Execution Environment konstruieren, wobei verifizierbare Ordnungsregeln zur Verbesserung der Fairness eingeführt werden. Dies bewegt die Blockordnung weg von einem einzelnen zentralisierten Builder hin zu einem dezentralen Blockaufbau-Netzwerk mit Regeln, die auf Neutralität geprüft werden können.

• MEV-Unterdrückung vs. Extraktionsmechanismen: Flashbots v2 ermöglicht primär die MEV-Extraktion in einer weniger schädlichen Form, anstatt sie zu eliminieren. Das ursprüngliche Flashbots-System (v1) von 2021 erlaubte es Searchern, Bundles (bevorzugte Transaktionssätze) direkt an Miner zu senden, was schädliche Externalitäten unterdrückte (kein öffentliches Frontrunning, keine fehlgeschlagenen Transaktionen durch Wettläufe), während MEV weiterhin extrahiert wurde. In der MEV-Boost-Ära wird MEV durch Builder extrahiert, die profitable Transaktionen bündeln, aber der Negativsummen-Wettbewerb wird reduziert: Searcher spammen den Mempool nicht mehr mit konkurrierenden Transaktionen und exorbitant hohen Gasgebühren, was die Netzwerküberlastung und übermäßige Gebühren für Nutzer mildert. Flashbots v2 bietet zudem Tools zur MEV-Minderung für Nutzer an: Beispielsweise erlaubt Flashbots Protect RPC den Nutzern, Transaktionen privat an ein Relay zu senden, was Frontrunning im öffentlichen Mempool verhindert (niemand kann die Transaktion vor der Aufnahme sehen oder umordnen). Eine weitere Initiative, MEV-Share, ermöglicht es Nutzern, gerade genug Informationen über ihre Transaktionen preiszugeben, um MEV-Gebote anzuziehen, während sie einen Teil des Wertes für sich selbst beanspruchen. Flashbots v2 „verhindert“ jedoch kein MEV wie Sandwiches oder Arbitrage – es kanalisiert diese Aktivitäten durch eine effiziente Auktion, die wohl demokratisiert, wer das MEV extrahieren kann. Das Design von BuilderNet verfolgt explizit das Ziel, „Negativsummen-Orderflow-Spiele zu neutralisieren“ und MEV über On-Chain-Rückerstattungsregeln mit der Community zu teilen. BuilderNet berechnet Rückerstattungen an Orderflow-Anbieter (wie Wallets oder DApps) proportional zu dem durch ihre Transaktionen generierten MEV und verteilt so Werte um, die andernfalls reiner Gewinn für die Builder wären. Zusammenfassend lässt sich sagen, dass Flashbots v2 die Effizienz der MEV-Extraktion maximiert (um sicherzustellen, dass fast der gesamte extrahierbare Wert in einem Block tatsächlich erfasst wird) und gleichzeitig Maßnahmen einführt, um die schlimmsten Externalitäten einzudämmen und einen Teil des Wertes an die Nutzer zurückzugeben. Es verzichtet auf die Durchsetzung einer absolut fairen Reihenfolge (Transaktionen werden immer noch nach Builder-Gewinn geordnet), unterdrückt aber durch private Übermittlung, Multi-Party-Building und Rückerstattungen den negativen Schaden für Nutzer (wie Slippage durch Frontrunning und Zensureffekte) so weit wie möglich innerhalb des Auktionsmodells.

• Ökonomische Anreizstruktur: Flashbots v2 richtet die Anreize zwischen Validatoren, Buildern und Searchern über die PBS-Auktion aus. Validatoren profitieren von der Auslagerung der Blockproduktion – sie akzeptieren einfach das höchste Gebot und erhalten den Gebotsbetrag (zusätzlich zu den Konsens-Belohnungen), was den Anteil des MEV, der an die Validatoren geht, im Vergleich zur Ära, in der Miner keine solchen Auktionen hatten, drastisch erhöht hat. Builder sind motiviert, einander zu übertreffen, indem sie die profitabelste Transaktionsreihenfolge finden (oft unter Einbeziehung von Searcher-Strategien), und sie behalten jeglichen MEV-Gewinn, der nach Zahlung des Validator-Gebots übrig bleibt. In der Praxis zwingt der Wettbewerb die Builder dazu, den Großteil des MEV an die Validatoren zu zahlen (oft > 90 % des Gewinns), sodass ihnen nur eine geringe Marge verbleibt. Searcher (die nun über Bundles oder direkte Transaktionen mit Buildern interagieren) verdienen weiterhin durch das Entdecken von MEV-Möglichkeiten (Arbitrage, Liquidation etc.), müssen aber den Großteil ihres Gewinns bieten, um aufgenommen zu werden – effektiv werden Searcher-Gewinne über Builder-Gebote an Validatoren transferiert. Dieses Wettbewerbsgleichgewicht maximiert den Gesamtumsatz des Netzwerks (wovon Validatoren / Staker profitieren), drückt jedoch die Margen der einzelnen Searcher. Flashbots v2 entmutigt somit exklusive Deals: Jeder Searcher oder Builder mit einer privaten MEV-Strategie hat einen Anreiz, diese über das offene Relay anzubieten, um nicht unterboten zu werden, was zu einem offeneren Markt führt. Die Einführung von BuilderNet fügt einen Anreiz für Orderflow-Urheber (wie DEXs oder Wallets) hinzu – indem ihnen Rückerstattungen für das durch ihre Transaktionen erzeugte MEV gewährt werden, werden Nutzer und Apps ermutigt, den Orderflow an das BuilderNet-Ökosystem zu senden. Dieser Mechanismus bringt die Nutzer mit dem System in Einklang: Anstatt gegeneinander zu arbeiten (Nutzer gegen MEV-Extraktoren), partizipieren die Nutzer am MEV, weshalb sie eher bereit sind, fair an der Auktion teilzunehmen. Insgesamt begünstigt die Ökonomik von Flashbots v2 die Zusammenarbeit gegenüber dem Wettbewerb beim Blockaufbau: Validatoren erhalten maximale Einnahmen ohne Risiko, Builder konkurrieren über die Ausführungsqualität, 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: Regulatorische Compliance wurde für Flashbots nach dem Ethereum-Merge zu einem umstrittenen Thema. Das Standard-Relay von Flashbots implementierte anfänglich die Einhaltung von OFAC-Sanktionen (Zensur bestimmter Transaktionen wie Tornado Cash) – was dazu führte, dass Ende 2022 ca. 80 % der Ethereum-Blöcke „OFAC-konform“ waren, was Bedenken hinsichtlich Zentralisierung und Zensur in der Community auslöste. Flashbots v2 begegnete dem durch die Förderung eines Ökosystems mit mehreren Relays, in dem Validatoren nicht-zensierende Relays (z. B. UltraSound, Agnostic) wählen oder sogar eigene betreiben können. Flashbots stellte seinen Relay-Code Mitte 2022 als Open Source zur Verfügung, um den globalen Wettbewerb und die Transparenz unter den Relays zu fördern. Zusätzlich führte MEV-Boost v1.4 Funktionen wie eine Mindestgebots-Einstellung (Min-Bid) 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. Bis Ende 2024 ging Flashbots einen weiteren Schritt und stellte seinen eigenen zentralisierten Builder zugunsten von BuilderNet ein – einem kollaborativen Netzwerk, das darauf abzielt, „unzensierbar und neutral“ zu sein. BuilderNet verwendet TEEs (Intel SGX), um den Transaktions-Orderflow verschlüsselt zu halten und verpflichtet sich verifizierbar zu einer Ordnungsregel, was verhindern kann, dass einzelne Builder spezifische Transaktionen zensieren. Wenn mehrere Teilnehmer gemeinsam Blöcke innerhalb sicherer Enklaven bauen, kann keine einzelne Partei eine Transaktion ohne Entdeckung ausschließen. Kurz gesagt: Flashbots v2 hat sich von einem einzelnen (und anfangs zensierenden) Relay zu einer dezentraleren Infrastruktur mit offener Teilnahme und expliziten Neutralitätszielen entwickelt. Compliance wird den Richtlinien einzelner Relays / Builder überlassen (und Validatoren können wählen), anstatt vom Protokoll erzwungen zu werden. Die Entwicklung geht in Richtung glaubwürdiger Neutralität: Eliminierung 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 operiert als Hybrid aus Off-Chain und protokollinternen Elementen. Die Kernauktion (MEV-Boost) findet Off-Chain über das Builder- und Relay-Netzwerk statt, ist aber direkt in den Konsens von Ethereum eingebunden: Validatoren führen einen Sidecar-Client (mev-boost) aus, der über die standardisierte Builder-API mit Relays kommuniziert. Konsensseitig nutzt Ethereum weiterhin Standard-PoS (Casper / Hotstuff) – MEV-Boost ändert die L1-Konsensregeln nicht; es ändert nur, wer den Block zusammenstellt. Anfangs erforderte die Flashbots-Auktion Vertrauen in das Relay und den Builder, Transaktionen nicht zu stehlen oder zu zensieren – es gab keine kryptographischen Garantien (das System verließ sich auf den ökonomischen 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 ein bemerkenswerter architektonischer Wandel: Builder laufen innerhalb von SGX-Enklaven, sodass selbst der Builder-Betreiber den rohen Transaktions-Orderflow nicht sehen kann (was ihn daran hindert, Informationen preiszugeben oder Frontrunning zu betreiben). Diese Enklaven folgen gemeinsam einem Protokoll zur Blockproduktion, was eine verifizierbare Fairness ermöglichen kann (z. B. der Beweis, 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 die Flashbots-Forschung auch rein kryptographische Primitive – z. B. Threshold Encryption für Mempool-Privatsphäre und Secure Multi-Party Computation –, um TEEs eventuell zu ersetzen oder zu ergänzen und das Vertrauen weiter zu reduzieren. Der Software-Stack von Flashbots v2 umfasst angepasste Clients wie MEV-geth (jetzt veraltet) und Rust-basierte Builder (z. B. rbuilder) und hält sich an die Ethereum-Builder-Spezifikationen für Interoperabilität. Zusammenfassend ist die Architektur modular: Ein Netzwerk aus Relays, Buildern und nun Enklaven, das zwischen Nutzern und Ethereum-Proposern angesiedelt ist. Sie priorisiert Performance (schnelles Bieten, Blockbereitstellung) und fügt schrittweise kryptographische Zusicherungen für Privatsphäre und faire Ordnung hinzu. Es wird kein neuer Konsensalgorithmus eingeführt; stattdessen arbeitet Flashbots v2 neben dem Konsens von Ethereum und entwickelt die Blockproduktions-Pipeline weiter, anstatt die Konsensregeln selbst zu verändern.

• Entwicklungs-Roadmap & Meilensteine: Flashbots hat sich durch iterative Phasen entwickelt. Flashbots v1 (2020–2021) beinhaltete den Start von MEV-geth und die ersten Off-Chain-Bundle-Auktionen mit Minern. Bis Mitte 2021 nutzten über 80 % der Hashrate von Ethereum MEV-geth von Flashbots, was die Akzeptanz des Ansatzes bestätigte. Flashbots v2 (2022) wurde im Vorfeld von „The Merge“ konzipiert: Im November 2021 veröffentlichte Flashbots die MEV-Boost-Architektur für PoS-Ethereum. Nachdem Ethereum auf PoS umgestellt hatte (15. Sept. 2022), wurde MEV-Boost innerhalb weniger Tage aktiviert und erreichte schnell eine Mehrheitsbeteiligung durch die Validatoren. Weitere Meilensteine waren die Offenlegung des Relay-Codes (Aug. 2022) und des internen Block-Builders von Flashbots (Nov. 2022), um den Wettbewerb anzukurbeln. Ende 2022 fügte Flashbots zudem Funktionen mit Fokus auf Zensurresistenz und Resilienz hinzu (z. B. Min-Bid für Proposer) und thematisierte die „Kosten der Resilienz“, um Validatoren zu ermutigen, gelegentlich die Inklusion dem Gewinn vorzuziehen. 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 stellte Flashbots seinen zentralisierten Builder ein und migrierte den gesamten Orderflow zu BuilderNet – ein bedeutender Schritt in Richtung Dezentralisierung. Anfang 2025 wurde BuilderNet v1.2 mit Verbesserungen bei Sicherheit und Onboarding (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 in die Zukunft verschmilzt Flashbots mit seiner Vision der nächsten Generation (SUAVE), um die Blockaufbauschicht vollständig zu dezentralisieren und fortschrittliche Privatsphäre-Technologien zu integrieren. Viele Lehren aus Flashbots v2 (z. B. die Notwendigkeit von Neutralität, Multi-Chain-Scope und die Einbeziehung der Nutzer in MEV-Belohnungen) fließen direkt in die SUAVE-Roadmap ein.

SUAVE (Flashbots’ Single Unifying Auction for Value Expression)

SUAVE ist das ehrgeizige Folgeprotokoll von Flashbots, das als dezentraler, domänenübergreifender (Cross-Domain) MEV-Marktplatz und faire Transaktions-Sequenzierungsschicht konzipiert wurde. Es zielt darauf ab, Mempools und die Block-Erstellung von einzelnen Blockchains zu entbündeln und eine einheitliche Plattform bereitzustellen, auf der Benutzer ihre Präferenzen äußern, ein dezentrales Netzwerk Transaktionen optimal ausführt und Block-Builder auf glaubwürdig neutrale Weise Blöcke über viele Ketten hinweg produzieren. Kurz gesagt: SUAVE versucht, die gesamte Wertschöpfung (Value Extraction) zu maximieren, während der Wert an die Benutzer zurückgegeben und die Dezentralisierung der Blockchain bewahrt wird. Flashbots führte SUAVE Ende 2022 als „die Zukunft des MEV“ ein und entwickelt es seitdem offen.

• Warteschlangen und Transaktions-Reihenfolge: Auf hoher Ebene fungiert SUAVE als unabhängiges Blockchain-Netzwerk, das andere Ketten als Plug-and-Play-Mempool und Block-Builder nutzen können. Anstatt dass Transaktionen im Mempool jeder einzelnen Kette anstehen und von lokalen Minern oder Validatoren geordnet werden, können Benutzer ihre Transaktionen (oder allgemeiner: Präferenzen) in den Mempool des SUAVE-Netzwerks senden. Der Mempool von SUAVE dient dann als globaler Auktionspool für Präferenzen aller teilnehmenden Ketten. Die Reihenfolge der Transaktionen wird durch diese Auktion und die anschließende Ausführungsoptimierung bestimmt. Konkret führt SUAVE das Konzept der Präferenzen (Preferences) ein: Die Einreichung eines Benutzers ist nicht nur eine einfache Transaktion für eine Kette, sondern kann ein Ziel oder einen bedingten Handel kodieren (der möglicherweise mehrere Ketten umfasst) sowie ein zugehöriges Gebot (Bid), das der Benutzer für die Erfüllung zu zahlen bereit ist. Der Sortier- und Warteschlangenalgorithmus in SUAVE umfasst mehrere Phasen: Zuerst posten Benutzer ihre Präferenzen in den SUAVE-Mempool (das „Universal Preference Environment“), das alle Aufträge privat und global aggregiert. Als Nächstes überwachen spezialisierte Knoten, sogenannte Executoren (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 eine optimale Ausführungsreihenfolge finden. Schließlich produziert SUAVE Block-Outputs für jede verbundene Kette über eine dezentrale Block-Erstellungsschicht: Viele Builder (oder SUAVE-Executoren, die als Builder fungieren) arbeiten zusammen, um Blöcke unter Verwendung der (nun optimierten) Transaktionsreihenfolge zu konstruieren, die aus den Benutzerpräferenzen abgeleitet wurde. In der Praxis ist die Sortierung von SUAVE flexibel und benutzergesteuert: Ein Benutzer kann Bedingungen festlegen wie „führe meinen Handel nur aus, wenn der Preis < X ist“ oder sogar eine abstrakte Absicht äußern („tausche Token A gegen B zum besten Kurs innerhalb von 1 Minute“) anstatt einer strikten Transaktion. Das System stellt diese Intents in eine Warteschlange, 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 Ketten 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, welche Transaktionen basierend auf aggregierten Präferenzen und Geboten ordnet, anstatt nach einfacher Zeit oder Gaspreis. Dies hat den Effekt, dass gleiche Wettbewerbsbedingungen geschaffen werden – der gesamte Orderflow läuft durch eine transparente Warteschlange (wenn auch zur Wahrung der Privatsphäre verschlüsselt, wie unten besprochen), anstatt über exklusive Deals oder private Mempools. Der Sortieralgorithmus von SUAVE wird noch verfeinert, wird aber wahrscheinlich datenschutzfreundliche Batch-Auktionen und Matching-Algorithmen beinhalten, damit „faire“ Ergebnisse (wie maximaler Gesamtüberschuss oder benutzeroptimale Preise) erzielt werden können, anstatt eines reinen „First-Come-First-Served“-Prinzips. Bemerkenswert ist, dass SUAVE verhindern will, dass ein einzelner Akteur die Reihenfolge manipuliert: Es ist Ethereum-nativ und MEV-bewusst, mit einem Privacy-First 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 Benutzergeboten, Executor-Strategien und (schließlich) kryptografischen Fairness-Beschränkungen bestimmt wird, anstatt durch Block-Proposer, die um Priorität konkurrieren.

• MEV-Unterdrückungs- und Extraktionsmechanismen: Die Philosophie von SUAVE besagt, dass MEV zum Vorteil der Benutzer und für die Netzwerksicherheit genutzt werden kann, wenn dies auf kooperative, dezentrale Weise geschieht. Anstatt MEV entweder zu ignorieren oder es in wenigen Händen konzentrieren zu lassen, macht SUAVE MEV-Möglichkeiten explizit sichtbar und gibt den Wert so weit wie möglich an diejenigen zurück, die ihn erschaffen (die Benutzer). Der primäre Mechanismus ist die Orderflow-Auktion: Wann immer die Transaktion (Präferenz) eines Benutzers MEV enthält – zum Beispiel, wenn sie gewinnbringend „backrunned“ werden könnte –, führt SUAVE eine Auktion unter Executoren (Searchern) um das Recht durch, diese MEV-Gelegenheit auszuführen. Searcher (Executoren) bieten mit, indem sie versprechen, einen Teil des Gewinns als Zahlung an den Benutzer zurückzugeben (dies ist das „Bid“-Feld des Benutzers in seiner Präferenz, das an denjenigen geht, der sie erfüllt). Das Ergebnis ist eine kompetitive MEV-Extraktion, die Einnahmen eher zum Benutzer als zum Extrahierer leitet. Wenn zum Beispiel der große DEX-Handel eines Benutzers eine Arbitrage-Möglichkeit von 100 $ schafft, könnten Searcher auf SUAVE den Gewinn herunterbieten, indem sie dem Benutzer beispielsweise 90 $ als Rabatt anbieten und nur 10 $ behalten. Dies unterdrückt die negativen Aspekte von MEV, wie die Wertabschöpfung beim Benutzer, und macht MEV zu einem Vorteil für den Benutzer (Benutzer erhalten effektiv Preisverbesserungen oder Rabatte). Das Design von SUAVE unterdrückt auch Front-Running und anderes bösartiges MEV: Transaktionen im SUAVE-Mempool können verschlüsselt bleiben, bis ein Block erstellt wird (anfänglich unter Verwendung von SGX-Enklaven, später durch Schwellenwert-Kryptografie). Dies bedeutet, dass kein externer Akteur ausstehende Transaktionen sehen kann, um sie zu frontrunnen; erst wenn genügend Transaktionen gesammelt wurden und ein Block finalisiert ist, werden sie entschlüsselt und ausgeführt, ähnlich dem Prinzip von Batch-Auktionen oder verschlüsselten Mempools, die den Zeit-Prioritäts-Vorteil von Bots eliminieren. Da Executoren zudem die Ausführung über viele Präferenzen hinweg optimieren, kann SUAVE ineffizienten Wettbewerb eliminieren (wie zwei Bots, die durch Spamming um dieselbe Arbitrage kämpfen). Stattdessen wählt SUAVE über die Auktion den besten Executor aus, und dieser führt den Handel einmalig aus, wobei das Ergebnis dem Benutzer und dem Netzwerk zugutekommt. SUAVE agiert somit als MEV-Aggregator und „gute Fee“: Es eliminiert MEV nicht (die profitablen Gelegenheiten werden weiterhin genutzt), aber diese Gelegenheiten werden unter transparenten Regeln realisiert, wobei die Erlöse weitgehend an Benutzer und Validatoren verteilt werden (und nicht für Gasgebühren oder Latenzkriege verschwendet werden). Durch die Vereinheitlichung der Mempools adressiert SUAVE auch Cross-Domain MEV auf benutzerfreundliche Weise – z. B. könnte eine Arbitrage zwischen Uniswap auf Ethereum und einer DEX auf Arbitrum von einem SUAVE-Executor erfasst und ein Teil an die Benutzer 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 Einheiten MEV abgreifen) werden unnötig, wenn jeder die gemeinsame Auktion nutzt. Die ultimative Vision von SUAVE ist es, schädliche MEV-Extraktion zu reduzieren (wie Sandwich-Attacken, die Slippage verursachen), indem sie entweder unprofitabel gemacht werden oder die Slippage erstattet wird, und „gutes MEV“ (Arbitrage, Liquidationen) zur Stärkung der Netzwerke zu nutzen (durch Umsatzbeteiligung und optimale Ausführung). In den Worten von Flashbots ist es das Ziel von SUAVE, sicherzustellen, dass „Benutzer mit der besten Ausführung und minimalen Gebühren transagieren“, während „Validatoren maximale Einnahmen erzielen“ – d. h. jedes vorhandene MEV wird auf die benutzerfreundlichste Weise extrahiert.

• Ökonomische Anreizstruktur: SUAVE führt neue Rollen und Anreizflüsse in die MEV-Lieferkette ein. Die Hauptteilnehmer sind Benutzer, Executoren, Block-Builder/Validatoren und die SUAVE-Netzwerkbetreiber (Validatoren der SUAVE-Kette). Benutzer legen in ihrer Präferenz ein Gebot (Zahlung) fest, das ausgezahlt wird, wenn ihre Bedingungen erfüllt sind. Dieses Gebot ist der Anreiz für Executoren: Ein Executor, der die Absicht des Benutzers erfüllt (z. B. seinen Handel backrunned, um ihm einen besseren Preis zu verschaffen), kann das Gebot als Belohnung beanspruchen. Benutzer zahlen daher direkt für die Qualität der Ausführung, ähnlich wie beim Aussetzen eines Kopfgeldes. Executoren (Searcher) sind motiviert, Benutzerpräferenzen aus dem SUAVE-Mempool aufzugreifen und zu optimieren, da sie das Gebot des Benutzers plus etwaige zusätzliche Arbitrage-Gewinne aus der Transaktion verdienen. Executoren werden konkurrieren, um dem Benutzer das beste Ergebnis zu bieten, da der Benutzer sein Gebot so gestalten kann, dass er nur zahlt, wenn der Executor tatsächlich das gewünschte Ergebnis erzielt (das Gebot kann über Orakel von On-Chain-Ergebnissen abhängig gemacht werden). Beispielsweise könnte ein Benutzer sagen: „Ich zahle 0,5 ETH an denjenigen, der diese Transaktion so ausführt, dass ich mindestens X Output erhalte; wenn nicht, erfolgt keine Zahlung.“ Dies bringt die Anreize der Executoren mit dem Erfolg des Benutzers in Einklang. SUAVE-Validatoren/Builder: Die SUAVE-Kette selbst wird wahrscheinlich ein Proof-of-Stake-Netzwerk sein (Design noch offen), sodass Validatoren (die Blöcke auf SUAVE produzieren) Transaktionsgebühren auf SUAVE verdienen (die von Benutzern stammen, die Gebote abgeben). Da SUAVE eine EVM-kompatible Kette ist, kann es auch ein natives Token- oder Gasgebührensystem für diese Transaktionen geben. Diese Validatoren spielen auch eine Rolle bei der Sequenzierung von Cross-Domain-Blöcken; die endgültige Block-Inklusion auf jedem L1 erfolgt jedoch weiterhin durch den Validator dieses L1. In vielen Fällen wird SUAVE ein teilweises oder vollständiges Block-Template produzieren, das ein Ethereum- oder ein anderer Chain-Proposer übernehmen kann. Dieser Builder könnte SUAVE (oder den SUAVE-Executoren) einen Teil des MEV zahlen. Flashbots hat erwähnt, dass SUAVE-Validatoren durch normale Netzwerkgebühren incentiviert werden, während Executoren durch Gebote (Bids) incentiviert werden. Wertverteilung: Der Ansatz von SUAVE neigt dazu, den Wert an die Ränder zu verlagern: Benutzer erfassen Wert (durch bessere Preise oder direkte Rückerstattungen) und Validatoren erfassen Wert (durch erhöhte Gebühren/Gebote). Wenn SUAVE seine Mission erfüllt, wird theoretisch das meiste MEV entweder an die Benutzer zurückgegeben oder zur Entschädigung der Validatoren für die Sicherung des Netzwerks verwendet, anstatt sich bei Searchern zu konzentrieren. Flashbots selbst hat angedeutet, dass es kein Rent-Seeking bei SUAVE plant und keinen Anteil über das hinaus nehmen wird, was für den Systemstart erforderlich ist – sie wollen den Marktplatz gestalten, nicht monopolisieren. Ein weiterer Anreizfaktor sind Cross-Chain-Builder: SUAVE ermöglicht Block-Buildern den Zugriff auf Cross-Domain MEV, was bedeutet, dass ein Builder auf einer Kette zusätzliche Gebühren verdienen kann, indem er Transaktionen einschließt, die eine Arbitrage mit einer anderen Kette vervollständigen. Dies ermutigt Builder/Validatoren verschiedener Ketten, an SUAVE teilzunehmen, da ein Opt-out den Verzicht auf Einnahmen bedeutet. Im Wesentlichen versucht das ökonomische Design von SUAVE, alle Teilnehmer zur Teilnahme an der gemeinsamen Auktion zu bewegen: Benutzer, weil sie eine bessere Ausführung erhalten (und vielleicht MEV-Rabatte), Validatoren, weil sie maximale Einnahmen erzielen, und Searcher, weil dort der Orderflow aggregiert wird. Durch die Konzentration des Orderflows gewinnt SUAVE auch einen Informationsvorteil gegenüber jedem isolierten Akteur (alle Präferenzen an einem Ort), was ökonomischen Druck auf alle ausübt, innerhalb von SUAVE zu kooperieren, anstatt sich abzuspalten. Zusammenfassend fördern die Anreize von SUAVE einen positiven Kreislauf: mehr Orderflow → bessere kombinierte MEV-Möglichkeiten → höhere Gebote für Benutzer/Validatoren → mehr Orderflow. Dies steht im Gegensatz zum Nullsummenspiel und den exklusiven Deals der Vergangenheit und zielt stattdessen auf eine „Koopetition“ (Coopetition) 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. Bauartbedingt entfernt SUAVE zentrale Vermittler – es gibt keinen einzelnen Mempool oder Builder, den man angreifen oder regulieren könnte. Transaktionen (Präferenzen) in SUAVE können vollständig verschlüsselt und privat sein, bis sie ausgeführt werden, wobei sichere Enklaven und später kryptografische Techniken zum Einsatz kommen. Dies bedeutet, dass Zensur auf Ebene des Transaktionsinhalts unpraktikabel ist, da Validatoren/Builder die Transaktionsdetails nicht einmal lesen können, bevor die Reihenfolge festgelegt ist. SUAVE erzwingt im Grunde einen „Don’t trust, verify“-Ansatz: Teilnehmer müssen keiner einzelnen Instanz vertrauen, dass sie nicht zensiert, 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, erlaubnisloses Netzwerk sein – Flashbots lädt explizit alle Parteien (Benutzer, Searcher, Wallets, andere Blockchains) zur Teilnahme ein. Es gibt kein KYC oder eine Zugangsbeschränkung im 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 eine Durchsetzung schwierig und analog zum Versuch, den Mempool einer Blockchain zu regulieren. Der Fokus von SUAVE auf Privatsphäre (über SGX und später Kryptografie) schützt zudem Benutzerdaten und Orderflow vor unerwünschter Überwachung, was positiv für die Benutzersicherheit ist, aber mit regulatorischen Wünschen nach Transparenz in Konflikt geraten 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 Werten an die Benutzer reduziert es die ausbeuterischen Aspekte von MEV, die regulatorischen Zorn auf sich ziehen könnten (wie das Backrunning von Benutzern ohne deren Zustimmung). SUAVE kann auch dazu beitragen, unregulierte Dark Pools zu eliminieren – ein Grund, warum Regulierungsbehörden über 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 Sortierrichtlinien zulassen: Beispielsweise könnten Communities oder Gerichtsbarkeiten ihre eigenen Executoren mit bestimmten Filtern oder Präferenzen einsetzen. Die Basislinie ist jedoch, dass SUAVE versuchen wird, maximal neutral zu sein: „alle zentralen Kontrollpunkte, einschließlich Flashbots, zu eliminieren“ und zu vermeiden, Richtlinienentscheidungen auf Protokollebene einzubetten. Flashbots hat betont, dass es den Marktplatz von SUAVE mit zunehmender Reife nicht selbst kontrollieren wird – was bedeutet, dass es keinen zentralen Kill-Switch oder Zensurschalter gibt. Die Governance (sofern vorhanden) von SUAVE ist öffentlich noch nicht definiert, es ist jedoch zu erwarten, dass sie die breitere Community und möglicherweise einen Token einbezieht, anstatt das Machtwort eines Unternehmens. Zusammenfassend ist SUAVE darauf ausgelegt, mit dezentralen Prinzipien in Einklang zu stehen, was von Natur aus bestimmten regulatorischen Kontrollen (Zensur) widersteht, während es potenziell einige regulatorische Bedenken mildert, indem es die MEV-Extraktion gerechter und transparenter macht.

• Technische Architektur (Konsens & Krypto): SUAVE wird – zumindest anfangs – eine eigene Blockchain-Umgebung betreiben. Es wird als eine EVM-kompatible Kette beschrieben, die auf Präferenzen und MEV spezialisiert ist. Die Architektur besteht aus drei Hauptkomponenten: (1) dem Universal Preference Environment (die SUAVE-Kette + Mempool, wo Präferenzen gepostet und aggregiert werden), (2) dem Execution Market (Off-Chain- oder On-Chain-Executoren, welche die Präferenzen lösen/optimieren, ähnlich einer dezentralen „Order Matching Engine“), und (3) der dezentralen Block-Erstellung (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 wie bei Ethereum oder Cosmos), um die SUAVE-Kette selbst zu betreiben – wobei noch entschieden wird, ob SUAVE ein L1, ein Ethereum-L2 oder eine Suite von „Restaking“-Verträgen wird. Eine Möglichkeit ist, dass SUAVE als Layer-2 oder Sidechain startet, die Ethereum für die Finalität nutzt oder bestehende Validatoren-Sets verwendet. Das Sicherheitsmodell ist noch offen (TBD), aber es gab Diskussionen darüber, es zu einem Ethereum-L3 oder einer Cosmos-Kette zu machen. Kryptografisch setzt SUAVE in seiner frühen Roadmap stark auf Trusted Hardware und Verschlüsselung. Die Phase SUAVE Centauri implementiert eine „datenschutzbewusste Orderflow-Auktion“, in der Flashbots (zentral) SGX-Enklaven betreibt, um den Orderflow von Searchern und Benutzern privat zu halten. In SUAVE Andromeda ist geplant, SGX-basierte Auktionen und Block-Erstellung einzusetzen, ohne Flashbots vertrauen zu müssen (die Enklaven bieten Vertraulichkeit, sodass selbst Flashbots nicht hineinschauen kann). Mit SUAVE Helios wird das Ziel verfolgt, ein SGX-basiertes dezentrales Building-Netzwerk zu haben – das bedeutet, dass viele unabhängige Parteien Enklaven betreiben, die kollektiv Blöcke erstellen und so sowohl Privatsphäre als auch Dezentralisierung erreichen. Langfristig erforscht Flashbots maßgeschneiderte sichere Enklaven und kryptografische Alternativen wie Schwellenwert-Entschlüsselung (Threshold Decryption) und Multi-Party Computation, um die Abhängigkeit von Intels SGX zu verringern. Beispielsweise könnten sie ein Schwellenwert-Verschlüsselungsschema verwenden, bei dem die Validatoren von SUAVE gemeinsam einen Schlüssel halten, um Transaktionen erst zu entschlüsseln, nachdem die Reihenfolge festgelegt wurde (um sicherzustellen, dass niemand frontrunnen kann). Dieses Konzept ähnelt Anomas Ferveo oder anderen Ideen zur „fairen Sortierung via Schwellenwert-Verschlüsselung“. Zusätzlich behandelt SUAVE Benutzerpräferenzen als Smart Contracts auf seiner Kette. Die Präferenz eines Benutzers könnte ein Gültigkeitsprädikat und eine Zahlungsbedingung enthalten – im Grunde ein Stück Code, das besagt: „Wenn das Ergebnis X auf der Kette Y erreicht wird, dann zahle dem Executor Z diesen Betrag“. Die SUAVE-Kette muss Orakel und Cross-Chain-Verifizierungen handhaben, um zu wissen, wann eine Präferenz erfüllt wurde (z. B. das Auslesen des Ethereum-Status, um zu sehen, ob ein Swap stattgefunden hat). Dies impliziert, dass die Architektur von SUAVE On-Chain-Light-Clients oder Orakelsysteme für verbundene Ketten sowie potenziell atomares Cross-Chain-Settlement umfassen wird (um sicherzustellen, dass ein Executor beispielsweise auf Ethereum und Arbitrum ausführen und das Gebot atomar beanspruchen kann). SUAVE soll hochgradig erweiterbar sein: Da es EVM-kompatibel ist, könnten beliebige Verträge (SUAVE-native „Preferences“ oder sogar normale dApps) darauf laufen, wobei die Absicht ist, den Fokus auf der Orderflow-Koordination zu halten. In Bezug auf den Konsens könnte SUAVE innovativ sein, indem es eine Intent-zentrierte Kette anstelle einer transaktionszentrierten Kette ist, aber letztendlich muss es Nachrichten (Präferenzen) ordnen und Blöcke produzieren wie jede andere Kette. Man kann sich vorstellen, dass SUAVE einen Konsensalgorithmus übernimmt, der auf Durchsatz und Finalität mit geringer Latenz optimiert ist, da es im kritischen Pfad der Transaktionen für viele Ketten liegen wird. Vielleicht könnte eine Tendermint-artige sofortige Finalität oder sogar ein DAG-basierter Konsens verwendet werden, um Präferenzen schnell zu bestätigen. Ungeachtet dessen liegen die Unterscheidungsmerkmale von SUAVE auf der Transaktionsebene, nicht auf der Konsensebene: die Nutzung von Privacy-Tech (SGX, Schwellenwert-Verschlüsselung) für die Sortierung, domänenübergreifende Kommunikation und eine im Protokoll integrierte Smart-Order-Routing-Logik. Dies macht es zu einer Art „Meta-Layer“ über bestehenden Blockchains. Technisch gesehen wird jede teilnehmende Kette den Outputs von SUAVE bis zu einem gewissen Grad vertrauen müssen (z. B. müsste ein Ethereum-Proposer einen von SUAVE erstellten Block akzeptieren oder SUAVE-Vorschläge einbeziehen). Flashbots hat angedeutet, dass SUAVE schrittweise und auf Opt-in-Basis eingeführt wird – Domänen können wählen, ob sie die SUAVE-Sequenzierung für ihre Blöcke übernehmen möchten. Bei breiter Akzeptanz könnte SUAVE zu einem De-facto-MEV-bewussten Transaktions-Routing-Netzwerk für Web3 werden. Zusammenfassend ist die Architektur von SUAVE eine Verbindung aus Blockchain und Off-Chain-Auktion: eine spezialisierte Kette zur Koordination, gepaart mit sicherer Off-Chain-Berechnung unter Executoren, alles verankert durch kryptografische Garantien für Fairness und Privatsphäre.

• Entwicklungs-Roadmap & Meilensteine: Flashbots skizzierte die Roadmap von SUAVE in drei großen Meilensteinen, benannt nach Sternensystemen: Centauri, Andromeda und Helios. Centauri (die erste Phase, in Entwicklung im Jahr 2023) konzentriert sich auf den Aufbau einer zentralisierten, aber datenschutzwahrenden Orderflow-Auktion. In dieser Phase betreibt Flashbots den Auktionsdienst (wahrscheinlich in SGX), der es Searchern ermöglicht, darauf zu bieten, Benutzertransaktionen zu backrunnen und MEV privat an die Benutzer zurückzugeben. Dazu gehört auch der Start eines SUAVE-Devnets für erste Tests. Tatsächlich hat Flashbots im August 2023 einen frühen SUAVE-Client (suave-geth) als Open Source veröffentlicht und Toliman, das erste öffentliche SUAVE-Testnet, gestartet. Dieses Testnet wurde verwendet, um mit der Äußerung von Präferenzen und grundlegender Auktionslogik zu experimentieren. Andromeda (die nächste Phase) wird das erste SUAVE-Mainnet einführen. Hier werden Benutzer in der Lage sein, Präferenzen in einem Live-Netzwerk zu äußern, und der Execution Market wird in Betrieb gehen (Executoren erfüllen Intents). Andromeda führt auch SGX-basierte Auktionen und Block-Erstellung in einer verteilteren Form 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 Nutzung von SGX zur Verschlüsselung des Orderflows in einer Weise, dass selbst Block-Builder noch nicht hineinsehen können, aber dennoch Blöcke bauen können (d. h. „offener, aber privater“ Orderflow). Helios ist die ehrgeizige dritte Phase, in der SUAVE eine vollständige 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“ über Ethereum hinaus einbinden – was bedeutet, dass es MEV für mindestens zwei Ketten handhabt und Cross-Chain-MEV-Auktionen demonstriert. Zusätzlich wird die Äußerung und Ausführung von Cross-Domain MEV ermöglicht (Benutzer können wirklich multikettige Intents posten und diese atomar ausführen lassen). Über Helios hinaus plant Flashbots, maßgeschneiderte Hardware und fortgeschrittene Kryptografie (wie ZK-Proofs oder MPC) zu erforschen, um die 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 der Orderflow-Auktion in Betrieb (Flashbots hat angedeutet, dass dies mit Benutzertransaktionen in einer geschlossenen Umgebung getestet wird). Ein bemerkenswerter Meilenstein wird der Start des SUAVE-Mainnets (Andromeda) sein, der ab Mitte 2025 am Horizont steht. Flashbots hat sich verpflichtet, SUAVE offen zu entwickeln und zur Zusammenarbeit aus dem gesamten Ökosystem einzuladen. Dies spiegelt sich in der Forschung und den Forumsdiskussionen wider, wie etwa den Posts der „Stargazing“-Serie, die über die Entwicklung des Designs von SUAVE informieren. Das Endziel für SUAVE ist es, eine im Gemeinschaftsbesitz befindliche Infrastruktur zu werden – die „dezentrale Sequenzierungsschicht“ für den gesamten Kryptosektor. Dies zu erreichen, markiert einen wichtigen Meilenstein im Kampf um eine faire Sortierung: Wenn SUAVE erfolgreich ist, wäre MEV kein dunkler Wald mehr, sondern eine transparente, geteilte Wertquelle, und keine einzelne Kette müsste die zentralisierenden Effekte von MEV allein ertragen.

Anoma ( Intent-zentrierte Architektur für faire Gegenpartei-Suche )

Anoma ist ein radikal anderer Ansatz zur Ermöglichung von fairem Ordering und der MEV-Abschwächung – es handelt sich um eine vollständige Architektur für intent-basierte Blockchain-Infrastruktur. Anstatt eine Auktion an bestehende Chains anzudocken, überdenkt Anoma das Transaktionsparadigma von Grund auf. In Anoma senden Benutzer keine konkreten Transaktionen; sie senden Intents ( Absichten ) – 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-Suche ( Counterparty Discovery ), fairem Ordering und Datenschutz auf Protokollebene zielt Anoma darauf ab, bestimmte Formen von MEV ( wie Frontrunning ) praktisch zu eliminieren und einen „frontrunning-freien“ dezentralen Austausch und Settlement zu ermöglichen. Anoma ist eher ein Framework als eine einzelne Chain: Jede Blockchain kann eine „fraktale Instanz“ von Anoma sein, indem sie deren Intent-Gossip- und Matching-Architektur übernimmt. Für diese Diskussion konzentrieren wir uns auf die erste Implementierung von Anoma ( manchmal Anoma L1 genannt ) und deren Kernprotokoll-Features im Zusammenhang mit Fairness und MEV.

• Warteschlangen und Transaktionsreihenfolge: Anoma verwirft den herkömmlichen Mempool von Transaktionen; stattdessen verfügt es über ein Gossip-Netzwerk von Intents. Benutzer senden einen Intent, z. B. „Ich möchte 100 DAI gegen mindestens 1 ETH tauschen“ oder „Ich möchte einen Kredit gegen Sicherheiten zum besten Zinssatz aufnehmen“. Diese Intents sind Teilaufträge – sie spezifizieren keine exakten Ausführungspfade, sondern nur das gewünschte Ergebnis und die Bedingungen. Alle Intents werden im gesamten Netzwerk verbreitet und gesammelt. Das Ordering in Anoma funktioniert nun in zwei Phasen: ( 1 ) Gegenpartei-Suche/Matching und ( 2 ) Transaktionsausführung mit fairem Ordering. In Phase 1 überwachen spezialisierte Knoten, sogenannte Solver, kontinuierlich den Pool der Intents und versuchen, Sets von Intents zu finden, die sich gegenseitig ergänzen, um eine gültige Transaktion zu bilden. Wenn Alice beispielsweise beabsichtigt, DAI gegen ETH zu tauschen, und Bob beabsichtigt, ETH gegen DAI zu tauschen, kann ein Solver sie zusammenführen. Wenn mehrere Intents kompatibel sind ( wie ein Orderbuch mit Geboten und Nachfragen ), können Solver einen optimalen Matching- oder 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 ein Set von Transaktionen ) konstruiert hat, die einige Intents erfüllt, wird diese zur Ausführung an die Chain übermittelt. Hier kommt Phase 2 ins Spiel: Der Konsens von Anoma wird diese vom Solver übermittelten Transaktionen dann in Blöcke ordnen. Der Konsens von Anoma ist jedoch darauf ausgelegt, ordnungsfair zu sein: Er verwendet kryptografische Techniken ( Schwellenwert-Verschlüsselung / Threshold Encryption ), um sicherzustellen, dass Transaktionen geordnet werden, ohne durch ihren Inhalt oder den genauen Zeitpunkt der Übermittlung beeinflusst zu werden. Konkret plant Anoma den Einsatz von Ferveo, einem Schwellenwert-Verschlüsselungsschema, auf Mempool-Ebene. 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 wurde, entschlüsseln die Validatoren sie kollektiv ( indem jeder einen Anteil des Entschlüsselungsschlüssels beiträgt ). Dies stellt sicher, dass kein Validator selektiv Frontrunning betreiben oder die Reihenfolge basierend auf dem Inhalt einer Transaktion ändern kann – sie verpflichten sich blind zu einer Reihenfolge. Der Konsensalgorithmus ordnet Transaktionen ( eigentlich Intents ) effektiv in einer Art First-Seen- oder Batch-Verfahren an, da alle Transaktionen in einem bestimmten „Batch“ ( Block ) gleichzeitig verschlüsselt und offengelegt werden. In der Praxis kann Anoma Batch-Auktionen für bestimmte Anwendungen implementieren: Z. B. kann ein Handels-Intent über N Blöcke gesammelt ( verschlüsselt gehalten ), dann nach N Blöcken zusammen entschlüsselt und von Solvern in einem Batch gematcht werden. Dies verhindert, dass schnelle Akteure die Orders anderer sehen und innerhalb dieses Batches reagieren – ein enormer Vorteil für die Fairness ( diese Technik ist von Frequent Batch Auctions inspiriert und wurde vorgeschlagen, um Vorteile im Hochfrequenzhandel zu eliminieren ). Zusätzlich können die Gültigkeitsprädikate ( Validity Predicates ) von Anoma ( Smart Contracts auf Anwendungsebene ) Fairness-Beschränkungen für das Ergebnis des Orderings durchsetzen. Beispielsweise könnte eine Anoma-DEX-Anwendung die Regel haben: „Alle Trades in einem Batch erhalten denselben Clearing-Preis, und Solver können keine zusätzlichen Transaktionen einfügen, um Benutzer auszunutzen“. Da diese Regeln Teil der Statusgültigkeit sind, wäre jeder Block, der ein unfaires Matching enthält ( wenn z. B. ein Solver versucht hat, einen Eigenhandel zu einem besseren Preis einzuschmuggeln ), ungültig und würde von den Validatoren abgelehnt. Zusammenfassend lässt sich sagen, dass das Ordering in Anoma nach dem Prinzip Matchen, dann Verschlüsseln + Ordnen erfolgt: Intents werden konzeptionell in die Warteschlange gestellt, bis ein Solver eine Transaktion bildet, und diese Transaktion wird dann durch einen Fair-Order-Konsens geordnet ( was typisches MEV verhindert ). Es gibt praktisch kein Rennen im Mempool, da die Intents der Benutzer nicht direkt über den Gas-Preis oder die Zeitpriorität konkurrieren. Stattdessen besteht der Wettbewerb darin, dass Solver Matches finden, und diese Matches werden dann so ausgeführt, dass niemand die Reihenfolge ändern oder sie während der Übertragung abfangen kann. Diese Architektur verspricht, viele MEV-Vektoren zu neutralisieren – es gibt kein Konzept für das Frontrunning eines Intents, da Intents erst dann umsetzbar sind, wenn der Solver sie zusammenstellt, und zu diesem Zeitpunkt sind sie bereits im Block verschlüsselt. Es ist ein grundlegend anderes Warteschlangenmodell, das darauf abzielt, zeitbasierte Prioritäts-Exploits zu eliminieren.

• MEV-Unterdrückungs-/Extraktionsmechanismen: Anoma ist darauf ausgelegt, „schlechtes MEV“ konstruktionsbedingt zu minimieren. Da Trades über Batch-Solving und Schwellenwert-Verschlüsselung aufgelöst werden, sind typische MEV-Angriffe wie Sandwiching unmöglich – niemand sieht einen Intent und kann vor ihm einen eigenen einfügen, da Intents keine Transaktionen sind, die in einem transparenten Mempool leben. Solver geben finale gematchte Transaktionen erst aus, nachdem die Gelegenheit zur Einfügung ( aufgrund von Verschlüsselung und Batching ) verstrichen ist. In einer Anoma-basierten DEX würden Benutzer nicht im traditionellen Sinne front- oder backrunned, da alle Trades in einem Batch zusammen zu einem einheitlichen Preis ausgeführt werden ( was verhindert, dass ein Angreifer Preisänderungen zwischen ihnen ausnutzt ). Dies unterdrückt im Wesentlichen räuberisches MEV wie DEX-Arbitrage oder Sandwiching; der Wert, der von einem Bot abgeschöpft worden wäre, bleibt stattdessen bei den Benutzern ( sie erhalten einen fairen Preis ). Auch der Ansatz von Anoma zur Arbitrage ist bemerkenswert: In vielen Fällen, wenn mehrere Intents eine Arbitrage-Gelegenheit schaffen, wird der Solver, der sie matcht, diesen Gewinn in das Matching einbeziehen ( z. B. unterschiedliche Preise matchen und einen Gewinn ausgleichen ). Da jedoch mehrere Solver konkurrieren können, um das beste Matching anzubieten, kann der Wettbewerb die Solver dazu zwingen, den Großteil dieses Vorteils in Form von besseren Ausführungsbedingungen an die Benutzer zurückzugeben. Wenn beispielsweise ein Benutzer zum Preis A verkaufen möchte und ein anderer zum Preis B kaufen möchte ( B > A impliziert eine Lücke ), könnte ein Solver beide zu einem mittleren Preis bedienen und die Differenz als Gewinn einbehalten – aber wenn ein anderer Solver den Benutzern einen noch engeren Preis anbietet ( und weniger Gewinn übrig lässt ), wird er den Intent gewinnen. Somit konkurrieren Solver MEV-Margen weg, um den Benutzern zugutezukommen, ähnlich wie Searcher in Flashbots über Gebühren konkurrieren. Der Unterschied besteht darin, dass dies algorithmisch über Intent-Matching geschieht und nicht über Gas-Bidding. Es kann in Anoma immer noch „extrahiertes MEV“ geben, aber dieses beschränkt sich wahrscheinlich darauf, dass Solver bescheidene Gebühren für ihren Service verdienen. Insbesondere erwartet Anoma, dass der Großteil des Orderflows durch das Protokoll oder die Anwendungslogik internalisiert wird. In einigen Fällen bedeutet dies, dass das, was eine MEV-Gelegenheit wäre, zu einer normalen Protokollgebühr wird. Beispielsweise implementiert Anomas erste fraktale Instanz ( Namada ) einen On-Chain Bonding-Curve AMM; Arbitrage auf diesem AMM wird durch den Mechanismus des AMM ( wie einen integrierten Rebalancer ) erfasst und nicht durch externe Arbitrageure. Ein weiteres Beispiel: Ein Lending-Intent mit hohen Zinsen könnte mit einem Borrowing-Intent gematcht werden; es ist kein dritter Liquidator erforderlich, wenn die Sicherheiten fallen, da die Intents selbst das Rebalancing übernehmen könnten 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. Darüber hinaus betont Anoma den Datenschutz ( durch das Taiga-Subsystem aus ZK-Schaltkreisen ). Benutzer können wählen, ob sie ihre Intents teilweise oder vollständig abschirmen ( shielded ) möchten ( 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 für die Wertextraktion ins Visier nehmen. Erst nach dem Matching und der Ausführung könnten Details ans Licht kommen, aber zu diesem Zeitpunkt ist es zu spät für eine Ausnutzung. Zusammenfassend lässt sich sagen, dass es beim Mechanismus von Anoma weitgehend darum geht, MEV zu verhindern, anstatt es zu extrahieren: Durch das Batching von Transaktionen, die Verschlüsselung des Mempools und die Verankerung ökonomischer Ausrichtung im Matching versucht es sicherzustellen, dass es kaum Gelegenheiten für bösartige Arbitrage oder Frontrunning gibt. Das notwendige MEV ( wie Arbitrage zum Preisabgleich zwischen Märkten ) 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 hätte jeder Benutzer sofortigen Zugang zur perfekten Gegenpartei ohne Informationsverlust. Jeder Wert, der bei der Ermöglichung dessen extrahiert wird ( die Belohnung des Solvers ), ist vergleichbar mit einer kleinen Servicegebühr und kein Zufallsgewinn aus der Ausnutzung von Asymmetrie.

• Ökonomische Anreizstruktur: In Anoma übernehmen Solver eine Rolle, die analog zu Matchmakern und Block-Buildern ist. Ihnen entstehen Kosten ( Rechenaufwand, eventuell das Hinterlegen von Sicherheiten ), um Intent-Matches zu finden, und sie werden belohnt, wenn sie erfolgreich Transaktionen vorschlagen, die aufgenommen werden. Solver können auf verschiedene Weise verdienen: Sie könnten eine Gebühr oder einen Spread innerhalb der von ihnen konstruierten Transaktion erheben ( indem sie den Benutzern beispielsweise etwas weniger günstige Bedingungen gewähren und die Differenz einbehalten, ä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 verlangen, kann ein anderer eine Lösung mit einem besseren Ergebnis für den Benutzer 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 Blockbelohnungen und Gebühren incentiviert, wie in jeder Blockchain. Wenn Intents über mehrere Benutzer hinweg gematcht werden, könnte die resultierende Transaktion insbesondere mehrere Gebührenquellen haben ( jeder Benutzer könnte eine Gebühr oder einen Teil der Assets beisteuern ). Es ist möglich, dass das Gebührenmodell von Anoma ein Fee-Splitting erlaubt, aber normalerweise erhalten Validatoren die Standard-Gas-Gebühren für die Verarbeitung von Transaktionen. In zukünftigen Phasen plant Anoma einen „On-Demand-Konsens“ und einen nativen Token. Die Idee ist, dass viele Anoma-Instanzen ( oder Shards ) existieren könnten und einige temporär für spezifische Aufgaben hochfahren könnten ( „Ad-hoc-Konsens“ für besondere Anwendungsanforderungen ). Der Token würde wahrscheinlich verwendet werden, um diese Instanzen zu staken und abzusichern. Anreize stellen hier sicher, dass das Netzwerk über genügend Validatoren verfügt, um alle gematchten Transaktionen zuverlässig zu verarbeiten, und dass sie sich im Schwellenwert-Entschlüsselungsprozess ehrlich verhalten ( möglicherweise Slashing-Bedingungen, wenn sie versuchen, vorzeitig zu entschlüsseln oder zu zensieren ). Benutzer: Benutzer in Anoma sparen potenziell Geld und erzielen bessere Ergebnisse, anstatt implizit MEV zu zahlen. Beispielsweise könnten sie konsistent bessere Handelspreise als auf einer herkömmlichen Chain erhalten, was bedeutet, dass der Wert bei ihnen bleibt. In einigen Fällen könnten Benutzer auch explizite Gebühren zahlen, um Solver zu incentivieren, insbesondere bei komplexen Intents oder wenn sie ein schnelleres Matching wünschen. Da Benutzer jedoch Intents ausdrücken können, ohne spezifizieren zu müssen, wie diese umzusetzen sind, verlagern sie die Schwerarbeit auf die Solver und zahlen nur, wenn es sich lohnt. Es gibt auch die Vorstellung, dass „Intent-Besitzer ihre eigenen Sicherheits-/Performance-Trade-offs definieren können“ – z. B. könnte ein Benutzer sagen: „Ich warte länger auf einen besseren Preis“ oder „Ich zahle mehr für eine sofortige Ausführung“. Diese Flexibilität lässt die Benutzer selbst entscheiden, wie viel sie Solvern oder Validatoren anbieten möchten, wodurch die ökonomischen Anreize auf ihre Bedürfnisse abgestimmt werden. MEV-Umverteilung: Falls MEV auftritt ( wie Cross-Chain-ARB oder ähnliches ), könnte die Anoma-Architektur es ermöglichen, dieses in das System zu leiten. Beispielsweise könnten mehrere Anoma-Shards oder -Instanzen koordinieren, um ein atomares Multi-Chain-ARB abzuwickeln, und der Gewinn könnte geteilt oder verbrannt werden ( je nach Design ), anstatt ihn einem externen Arbitrageur zu überlassen. Da Anoma den Anwendungen die Kontrolle über den Transaktionsfluss gibt, ist es generell möglich, Strategien für protokolleigenes MEV ( ähnlich der Philosophie von Skip ) auf Anwendungsebene zu implementieren. Beispielsweise könnte eine DeFi-App auf Anoma alle Benutzer-Trades automatisch über einen protokollinternen Solver leiten, der die beste Ausführung garantiert und jeglichen zusätzlichen Gewinn mit den Benutzern oder Liquiditätsanbietern teilt. Der Nettoeffekt ist, dass Drittanbieter-MEV-Extraktoren ausgeschaltet werden. Ökonomisch gesehen ist dies ein Positivsummenspiel für ehrliche Teilnehmer ( Benutzer, LPs usw. ), könnte aber die Möglichkeiten für klassische Searcher verringern. Es werden jedoch neue Rollen wie spezialisierte Solver entstehen ( vielleicht konzentriert sich einer auf NFT-Matching, ein anderer auf FX-Swaps usw. ). Diese Solver sind analog zu den heutigen MEV-Searchern, agieren aber innerhalb der Systemregeln und haben aufgrund von Wettbewerb und Protokollbeschränkungen wahrscheinlich weniger extreme Gewinnmargen. Schließlich deutet die Vision der Anoma Foundation darauf hin, dass Anoma eine Public-Good-Infrastruktur ( Gemeingut ) ist. Es wird einen nativen Token geben, vermutlich ANOMA, der möglicherweise Wert über Gebühren generiert oder für das Staking erforderlich ist. Man kann Token-Anreize ( inflationäre Belohnungen usw. ) für Validatoren und vielleicht sogar für Solver vorhersehen, um die Aktivität anzukurbeln. Zum Zeitpunkt der Erstellung dieses Textes sind die Details zur Token-Ökonomie noch nicht final, aber die Roadmap bestätigt, dass ein Anoma-Token und nativer On-Demand-Konsens in zukünftigen Phasen geplant sind. Zusammenfassend lässt sich sagen, dass das Anreizmodell von Anoma kooperatives Verhalten fördert: Solver verdienen, indem sie Benutzern helfen, das zu bekommen, was sie wollen, nicht indem sie sie ausbeuten; Validatoren verdienen, indem sie das Netzwerk sichern und fair ordnen; und Benutzer „zahlen“ hauptsächlich, indem sie etwas MEV an Solver oder Gebühren abgeben, aber idealerweise viel weniger als das implizite MEV, das sie in anderen Systemen verlieren würden.

• Compliance und Neutralität: Anoma kann als Framework, nicht als einzelnes Netzwerk, auf verschiedene Weise instanziiert werden – einige könnten zugangsbeschränkt ( permissioned ) sein, aber das Flaggschiff Anoma L1 und ähnliche Instanzen sollen permissionless ( erlaubnisfrei ) und datenschutzorientiert sein. Durch die Einbeziehung starker Datenschutzfunktionen ( wie shielded Intents unter Verwendung von Zero-Knowledge-Proofs in Taiga ) steht Anoma im Einklang mit der Ansicht, dass finanzielle Privatsphäre ein Recht ist. Dies könnte im Widerspruch zu bestimmten Regulierungsregimen stehen, die eine offene Sichtbarkeit von Transaktionen fordern. Das Design von Anoma könnte jedoch auch bestimmte regulatorische Fallstricke vermeiden. Wenn beispielsweise Frontrunning und unfaire Order-Auswahl eliminiert werden, werden Bedenken hinsichtlich Marktmanipulation gemildert – ein Regulator könnte es begrüßen, dass Benutzer nicht systematisch von Insidern ausgenutzt werden. Darüber hinaus impliziert das Konzept der „benutzerdefinierten Sicherheitsmodelle“, dass Benutzer oder Communities sich für verschiedene Vertrauensannahmen entscheiden könnten. Potenziell könnte eine regulierte Anwendung auf Anoma aufgebaut werden, bei der beispielsweise der Solver oder eine Teilmenge der Validatoren KYC-geprüfte Einheiten sind, die die Compliance für diesen speziellen Intent-Bereich sicherstellen. Anoma als Basisschicht würde KYC nicht für jeden erzwingen, aber man könnte Gültigkeitsprädikate implementieren, die ( zum Beispiel ) einen Nachweis der Berechtigung für bestimmte Transaktionen erfordern ( wie den Nachweis, dass es sich nicht um eine sanktionierte Adresse handelt, oder eine Prüfung von Anmeldedaten ), falls 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 gefährden. In Bezug auf Zensur: Anomas Schwellenwert-Verschlüsselung bedeutet, dass Validatoren, selbst wenn sie zensieren wollten, keine spezifischen Intents ins Visier nehmen können, da sie diese nicht im Klartext sehen. Das Einzige, was sie tun könnten, ist, sich zu weigern, verschlüsselte Transaktionen von bestimmten Solvern oder Benutzern aufzunehmen, aber das wäre offensichtlich ( und würde gegen die Protokollregeln verstoßen, wenn es willkürlich geschieht ). Es wird erwartet, dass Konsensregeln Zensur entmutigen – zum Beispiel könnte ein Block als ungültig oder weniger bevorzugt gelten, wenn er nicht alle verfügbaren entschlüsselten Intents aus dem letzten Batch 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 strebt danach, eine allgemeine Plattform zu sein, die nicht von einer einzelnen Entität kontrolliert wird. Die Forschung und Entwicklung wird von Heliax ( dem Team hinter Anoma und Namada ) angeführt, aber sobald ein Anoma-Netzwerk live ist, würde es 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 unterwandern, um Regeln zu ändern? ), aber das ist ein allgemeines Blockchain-Problem. Ein interessantes Compliance-bezogenes Merkmal ist, dass Anoma mehrere parallele Instanzen unterstützt – was bedeutet, dass man einen isolierten Intent-Pool oder Shard für bestimmte Asset-Typen oder Gerichtsbarkeiten haben könnte. Dies dient nicht explizit der Regulierung, könnte aber beispielsweise einen CBDC-Intent-Pool ermöglichen, in dem nur autorisierte Banken Solver betreiben, der koexistent mit einem freien DeFi-Pool ist. Die Modularität der Architektur bietet Flexibilität zur Trennung bei Bedarf, während gleichzeitig Interoperabilität über Intent-Bridging ermöglicht wird. Schließlich könnte das gesamte Konzept der Intents in Bezug auf die rechtliche Kompatibilität einige Klassifizierungen vermeiden, die das traditionelle Krypto-Umfeld plagen: Da ein Intent keine verbindliche Transaktion ist, bis er gematcht wurde, könnte man argumentieren, dass Benutzer mehr Kontrolle behalten ( es ist vergleichbar mit dem Einstellen einer Order an einer Börse, was eine klarere rechtliche Präzedenz hat, im Gegensatz zur direkten Ausführung eines Trades ). Dies könnte bei Dingen wie der steuerlichen Behandlung helfen ( das System könnte potenziell einen einheitlichen Beleg für einen mehrstufigen Handel ausstellen statt vieler einzelner Transaktionen ) – wenngleich dies spekulativ ist. Insgesamt priorisiert Anoma Dezentralisierung, Datenschutz und Benutzerautonomie, was historisch gesehen mit regulatorischen Erwartungen kollidieren kann, aber die Gewinne an Fairness und Transparenz könnten Zuspruch finden. Es bringt im Wesentlichen die Raffinesse traditioneller Finanz-Matching-Engines auf die Chain, jedoch ohne zentrale Betreiber. Wenn Regulatoren dieses Modell verstehen lernen, könnten sie es als eine geordnetere und fairere Marktstruktur ansehen als das „Jeder-gegen-Jeden“ der Mempools.

• Technische Architektur ( Konsens & Kryptografie ): Die Architektur von Anoma ist komplex und umfasst mehrere Komponenten: Typhon ( Netzwerk, Mempool, Konsens, Ausführung ) und Taiga ( die Zero-Knowledge-Datenschutzschicht ). Der Kern von Typhon ist der Intent-Gossip-Layer und ein neuartiger Ansatz für kombinierten Konsens + Matching. Das Konsensprotokoll von Anoma erweitert den typischen BFT-Konsens um das Konzept der „Validity Predicates“ ( 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 kann es sich wie Smart-Contract-Bedingungen vorstellen, die auf Blockebene gelten, nicht nur auf Transaktionsebene ). Dies ermöglicht die Durchsetzung von Eigenschaften wie Clearing-Preisen für Batch-Auktionen usw., wie beschrieben. Der Konsensalgorithmus selbst baut wahrscheinlich auf BFT im Tendermint- oder HotStuff-Stil auf ( da Anoma im Cosmos-Umfeld angesiedelt ist und IBC unterstützt ). Tatsächlich verwenden das erste Testnet von Anoma ( Feigenbaum im Jahr 2021 ) und Namada einen Konsens im Tendermint-Stil mit Modifikationen. Eine wesentliche Modifikation ist die Integration der Schwellenwert-Verschlüsselung ( Ferveo ) in die Mempool-Pipeline. Normalerweise wählt Tendermint einen Proposer aus, der Transaktionen ordnet. In Anoma würde der Proposer verschlüsselte Intents/Transaktionen ordnen. Ferveo funktioniert wahrscheinlich so, dass sich Validatoren periodisch auf einen gemeinsamen öffentlichen Schwellenwert-Schlüssel einigen und jeder von Solvern übermittelte 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 aus, um sie zu entschlüsseln ( vielleicht enthält der nächste Block die entschlüsselten Ergebnisse oder ein ähnliches Schema ). Dies fügt dem Konsens eine Phase hinzu, gewährleistet aber die Fairness der Reihenfolge. Kryptografisch nutzt dies verteilte Schlüsselerzeugung und Schwellenwert-Entschlüsselung ( es beruht also auf Annahmen wie der, dass mindestens 2/3 der Validatoren ehrlich sind, um Daten nicht preiszugeben oder vorzeitig zu entschlüsseln ). Auf der Datenschutzseite bietet Taiga zkSNARK- oder zk-STARK-Proofs, die es ermöglichen, dass Intents teilweise oder vollständig abgeschirmt bleiben. Beispielsweise könnte ein Benutzer einen Intent zum Tausch übermitteln, ohne den Asset-Typ oder den Betrag preiszugeben; er liefert einen ZK-Proof, dass er über ausreichendes Guthaben verfügt und dass die Transaktion gültig ist, wenn sie gematcht wird, ohne Details zu verraten. Dies ist analog dazu, wie abgeschirmte Transaktionen in Zcash funktionieren, jedoch erweitert auf Intents. Die Verwendung von rekursiven Proofs wird erwähnt, was bedeutet, dass mehrere Schritte einer Transaktion ( oder mehrere Intents ) in einem einzigen prägnanten Proof effizient bewiesen werden können. Das Zusammenspiel von Taiga und Typhon bedeutet, dass einige Solver und Validatoren möglicherweise mit Geheimtexten oder Commitments anstelle von Klartextwerten arbeiten. Beispielsweise könnte ein Solver Intents matchen, die auf vertrauliche Weise ausgedrückt werden, indem er eine Gleichung von Commitments löst. Dies ist modernste Kryptografie und geht über das hinaus, was die meisten aktuellen Blockchains leisten. Ein weiteres wichtiges Element ist die IBC-Integration: Anoma-Instanzen können mit anderen Chains ( insbesondere Cosmos-Chains ) über das Inter-Blockchain Communication Protocol kommunizieren. Dies bedeutet, dass ein Intent auf Anoma potenziell eine Aktion auf einer anderen Chain auslösen ( über eine IBC-Nachricht ) oder Daten aus dem Status einer anderen Chain konsumieren könnte. Die Mainnet Phase 1 in der Roadmap von Anoma erwähnt explizit 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 nutzt, indem er einen Intent entwirft, der bei einem Matching eine Nachricht an Ethereum sendet, um einen Swap auszuführen ( vielleicht über einen Relayer oder über etwas wie eine IBC-Bridge ). Der Konsens muss die Atomarität gewährleisten: Vermutlich könnte das Ergebnis von Anoma eine einzelne Transaktion sein, die sich über mehrere Chains erstreckt ( etwa das Initiieren einer Transaktion auf Chain A und das Erwarten eines Ergebnisses auf Chain B ). Das Erreichen eines atomaren Cross-Chain-Settlements ist schwierig; möglicherweise wird Anoma damit beginnen, jeweils auf einer Chain abzurechnen ( Phase 1 konzentriert sich auf das Ethereum-Ökosystem, was wahrscheinlich bedeutet, dass Anoma-Intents in einem Rutsch auf Ethereum L1 oder L2s abgerechnet werden ). Später könnten „Chimera-Chains“ und On-Demand-Konsens es ermöglichen, dass benutzerdefinierte Sidechains hochfahren, um bestimmte Cross-Chain-Matches zu handhaben. In Bezug auf die Performance könnte der Ansatz von Anoma rechenintensiver sein ( Solver lösen NP-schwere Matching-Probleme, Validatoren betreiben komplexe Kryptografie ). Aber der Trade-off ist eine erheblich verbesserte Benutzererfahrung ( keine fehlgeschlagenen Transaktionen, bessere Preise usw. ). Die Entwicklung von Anoma erfordert den Aufbau dieser neuartigen Komponenten fast von Null an: Heliax hat Juvix entwickelt, eine neue Sprache zum Schreiben von Gültigkeitsprädikaten und Intents, und viel Forschung betrieben ( einige Referenzen auf der Anoma-Website erläutern diese Konzepte im Detail ). Wichtige Meilensteine: Anomas erstes öffentliches Testnet Feigenbaum startete im November 2021 als Demo für grundlegenden Intent-Gossip. Anschließend verlagerte Heliax den Fokus auf den Start von Namada ( eine datenschutzorientierte L1, die als eine Instanz von Anoma mit Fokus auf Asset-Transfers gesehen werden kann ) – Namada ging 2023 live und enthält Features wie abgeschirmte Transfers und Ferveo-Schwellenwert-Verschlüsselung für seinen Mempool. Dies zeigt die Technologie in Aktion bei einem enger gefassten Anwendungsfall. Unterdessen wurden Testnets für die vollständige Anoma-Vision in Etappen ausgerollt ( in der Community wurde auch ein „Sommer 2023 Testnet“ erwähnt ). Die Roadmap sieht vor, dass Phase 1 des Mainnets Ethereum integriert, Phase 2 weitere Chains und fortgeschrittene Kryptografie hinzufügt und schließlich nativer Konsens und Token eingeführt werden. Die Trennung von „Konsens und Token in zukünftiger Phase“ deutet darauf hin, dass das erste Anoma-Mainnet auf Ethereum angewiesen sein könnte ( z. B. durch Nutzung der Ethereum-Sicherheit oder bestehender Token, anstatt vom ersten Tag an eigene zu haben ). Möglicherweise starten sie eine L2 oder Sidechain, die auf Ethereum postet, und fahren später ihr eigenes PoS-Netzwerk mit einem Token hoch. Dieser phasenweise Ansatz ist interessant – er könnte dazu dienen, die Hürde für die Einführung zu senken ( vorhandenes Kapital auf Ethereum nutzen, anstatt initial eine neue Coin zu starten ). Zusammenfassend lässt sich sagen, dass die Architektur von Anoma neuartig und umfassend ist: Sie verbindet kryptografische Fairness ( Schwellenwert-Verschlüsselung, ZK-Proofs ) mit einem neuen Transaktionsparadigma ( intent-basiertes Matching ) und Cross-Chain-Fähigkeiten. Es ist wohl der aggressivste Versuch, traditionelles MEV auf Protokollebene auszumerzen, indem es etwas tut, was keine Legacy-Chain tut: integrierte faire Matching-Engines. Die Komplexität ist hoch, aber bei Erfolg könnte eine Anoma-Chain den Benutzern nahezu CEX-ähnliche Ausführungsgarantien in einer dezentralen Umgebung bieten, was der heilige Gral für Blockchain-UX und Fairness ist.

Skip Protocol ( Souveräne MEV - Kontrolle für Cosmos und Toolkit für faires Ordering )

Skip Protocol ist eine führende MEV - Lösung im Cosmos - Ökosystem , die darauf ausgerichtet ist , jeder Blockchain ( „ App - Chain “ ) die Werkzeuge an die Hand zu geben , um die Transaktionsreihenfolge und die MEV - Erfassung zu ihren eigenen Bedingungen zu verwalten . Im Gegensatz zu Flashbots oder Anoma , die netzwerkübergreifende Systeme vorschlagen , orientiert sich Skip an der Cosmos - Philosophie der Souveränität : Jede Chain kann die Module von Skip integrieren , um benutzerdefinierte Regeln für faires Ordering durchzusetzen , protokollinterne 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 das Protocol - Owned Blockbuilding ( POB ) und eine flexible Transaktionssequenzierung ermöglichen . Es wurde auf Chains wie Osmosis , Juno , Terra und anderen in Cosmos implementiert und arbeitet auch mit Projekten wie der kommenden dYdX - Chain zur MEV - Minderung zusammen . Zu den Schlüsselelementen gehören ein On - Chain - Auktionsmechanismus für Prioritätstransaktionen , eine Logik für die Transaktionsreihenfolge auf Konsensebene und In - App - Mechanismen zum Recycling von MEV ( „ gutes MEV “ ) zugunsten des Protokolls .

• Transaktions - Queuing & Ordering - Algorithmen : In einer typischen Cosmos - Chain ( unter Verwendung des Tendermint / BFT - Konsenses ) ordnet der Mempool Transaktionen grob nach Gebühr und Ankunftszeit , und der Block - Proposer kann beim Erstellen eines Blocks eine beliebige Reihenfolge wählen ( ohne algorithmische Einschränkungen über die Aufnahme gültiger Transaktionen hinaus ) . Skip ändert dies durch die Einführung von konsensbasierten Ordering - Regeln und Multi - Lane - Mempools . Unter Verwendung der neuen ABCI++ Schnittstelle von Cosmos ( die eine Anpassung des Block - Vorschlags und der -verarbeitung ermöglicht ) kann das Protocol - Owned Builder ( POB ) - Modul von Skip den Block in verschiedene Lanes mit unterschiedlichen Ordering - Richtlinien unterteilen . Zum Beispiel könnte eine Lane eine Top - of - Block - Auktions - Lane sein , in der die Transaktionen mit den höchsten Geboten ( etwa von Arbitrage - Bots oder für dringende Trades ) an erster Stelle 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 deren Ordering - Logik modular zu definieren . Entscheidend ist , dass diese Regeln von allen Validatoren erzwungen werden : Wenn ein Proposer einen Block erstellt , verifizieren die anderen Validatoren , dass die Transaktionen des Blocks den vereinbarten Ordering - Regeln entsprechen ( über die ProcessProposal ABCI - Prüfungen ) . Wenn nicht , können sie den Block ablehnen . Das bedeutet , dass selbst ein bösartiger oder profitorientierter Proposer nicht abweichen kann ( z. B. kann er keine eigene Frontrunning - Transaktion vor einem gewinnenden Auktionsbieter einschieben , da dies gegen die Ordering - Regel verstoßen würde ) . Einige Beispiele für Ordering - Regeln , die Skip ermöglicht : ( a ) Transaktionen nach absteigendem Gas - Preis ( 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 eines zufälligen oder zeitbasierten Schemas . ( b ) Mindestens eine Oracle - Preisaktualisierungs - Transaktion vor allen Trades aufnehmen – 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 Top - of - Block – z. B. kann nur ein auktionsgewinnendes Bundle den obersten Platz einnehmen , um Spamming durch viele kleine MEV - Griffe zu verhindern . ( d ) Keine Transaktionen , die eine State - Eigenschaft verletzen – Skip ermöglicht zustandsabhängige Ordering - Regeln , wie „ nach dem Aufbau des Blocks sicherstellen , dass kein DEX - Handel zu einem schlechteren Preis ausgeführt wurde , als wenn er an letzter Stelle im Block stünde “ ( eine Möglichkeit , sicherzustellen , dass keine Sandwich - Attacke stattgefunden hat ) . Eine beschriebene konkrete Regel ist eine „ Zero - Frontrunning - Bedingung über alle DEXs hinweg “ , was bedeuten könnte , dass ein Block ungültig ist , wenn eine Transaktion von späteren Transaktionen in einer Weise beeinflusst wurde , die auf Frontrunning hindeutet . Das ist mächtig : Es macht Fairness im Wesentlichen zu einem Teil der Blockgültigkeit . Cosmos - Chains können solche Regeln implementieren , da sie ihren gesamten Stack kontrollieren . Das Framework von Skip 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 , fehlschlagende Transaktionen herausfiltern usw. , um Proposern zu helfen , die Regeln effizient zu befolgen . Wenn beispielsweise die Auktions - Lane eines Blocks die höchsten Gebote enthalten muss , kann der Mempool für diese Lane nach Geboten sortiert werden . Wenn ein Block nur Transaktionen enthalten darf , die zu einem bestimmten Zustand 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 deterministisches , Chain - definiertes Ordering , anstatt es gänzlich dem Gutdünken des Proposers oder einer einfachen Gas - Preis - Priorität zu überlassen . Chains integrieren das Builder - Modul von Skip , um ihre Transaktions - Ordering - Richtlinie effektiv im 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 Umordnungen für MEV vorzunehmen , es sei denn , dies geschieht innerhalb des erlaubten Mechanismus ( wie der Auktion , wo es transparent und wettbewerbsfähig ist ) . Das Queuing von Transaktionen im Modell von Skip kann separate Queues pro Lane beinhalten . Zum Beispiel könnte eine Auktions - Lane spezielle Gebotstransaktionen in die Queue stellen ( Skip verwendet einen speziellen MsgAuctionBid - Typ für Gebote zur Aufnahme am Top - of - Block ) . Diese Gebote werden in jedem Block gesammelt und das höchste wird ausgewählt . Währenddessen werden normale Transaktionen im Standard - Mempool in die Queue gestellt . Im Wesentlichen führt Skip eine strukturierte Queue ein : eine für Prioritätsgebote , eine für kostenlose oder andere Transaktionen usw. , jeweils mit eigenen Ordering - Kriterien . Dieser modulare Ansatz bedeutet , dass jede Chain individuell anpassen kann , wie sie Fairness und Einnahmen ausbalanciert – z. B. könnte Osmosis sagen : „ Wir wollen gar keine MEV - Auktion , sondern erzwingen Order - Fairness über Threshold - Verschlüsselung “ ( sie haben Threshold - 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 des Orderings ist das Markenzeichen von Skip .

• MEV - Minderung und Extraktionsmechanismen : Der Ansatz von Skip in Bezug auf MEV wird oft als „ Protokolleigenes MEV “ und „ Multiplizität “ beschrieben . Protokolleigenes MEV bedeutet , dass das Blockchain - Protokoll selbst über seinen Code und seine Governance MEV erfasst oder umverteilt , anstatt es einzelnen Validatoren oder Außenstehenden zu überlassen . Multiplizität bezieht sich darauf , sicherzustellen , dass die „ richtigen “ ( multiplen ) Transaktionen aufgenommen werden – im Wesentlichen ohne legitime Nutzertransaktionen zugunsten von reinen MEV - Transaktionen auszuschließen und möglicherweise mehrere MEV - Möglichkeiten in einem Block aufzunehmen , falls möglich ( damit kein einzelner Searcher monopolisiert ) . Konkret bietet Skip Werkzeuge an , um MEV auf eine Weise zu erfassen , die dem Netzwerk zugutekommt : Eines davon ist Skip Select , ein Blockspace - Auktionssystem für die Aufnahme am Top - of - Block . Bei Skip Select reichen Searcher ( wie Arbitrage - Bots ) Bundles mit Tips bei Validatoren ein , ähnlich wie Flashbots - Bundles , außer dass dies nativ On - Chain über die Module von Skip erfolgt . Das am höchsten zahlende Bundle ( oder die Bundles ) wird dann automatisch in der angegebenen Reihenfolge an den Anfang des Blocks eingefügt . Dies garantiert , dass diese Transaktionen wie beabsichtigt ausgeführt werden , und der Validator ( oder die Chain ) kassiert den Tip . Dieser Mechanismus macht aus einem Prozess , der ( in Ethereum ) ein Off - Chain - OTC - Prozess war , eine offene On - Chain - Auktion – was Transparenz und Zugang verbessert . Ein weiterer Mechanismus ist ProtoRev ( Prototype Revenue - Modul ) , das Skip für Osmosis entwickelt hat . ProtoRev ist ein On - Chain - Arbitrage - Modul , das zyklische Arbitragen ( wie solche mit mehreren Pools ) automatisch innerhalb der Blockausführung erkennt und ausführt und den Gewinn an die Treasury der Chain oder den Community - Pool abführt . Im Wesentlichen hat Osmosis entschieden , dass bestimmtes „ gutes MEV “ ( wie Arbitrage , die Preise angeglichen hält ) weiterhin stattfinden sollte ( für die Markteffizienz ) , aber das Protokoll selbst die Arbitrage durchführt und den Gewinn erfasst und ihn später verteilt ( z. B. an Staker oder als Liquidity - Mining - Anreize ) . Dies eliminiert die Notwendigkeit für externe Arbitrage - Bots für diese Möglichkeiten und stellt sicher , dass der Wert im Ökosystem bleibt . ProtoRev war das erste seiner Art auf einer großen Chain und demonstriert , wie eine tiefe Integration die externen Effekte von MEV mildern kann : Nutzer , die auf Osmosis handeln , sind weniger Slippage ausgesetzt , denn wenn nach ihrem Trade eine Arbitrage besteht , wird das Protokoll diese schließen und den Wert im Wesentlichen an Osmosis zurückerstatten ( was den Nutzern indirekt durch niedrigere Gebühren oder Token - Rückkäufe usw. zugutekommen könnte ) . Darüber hinaus befähigt Skip Chains , Anti - MEV - Maßnahmen wie Threshold - 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 festgelegten Zeit offengelegt werden ( ähnlich wie die Idee von Anoma , aber auf Chain - Ebene ) . Obwohl dies kein direktes Skip - Produkt an sich ist , ist die Architektur von Skip kompatibel – die Auktion von Skip kann mit verschlüsselten Transaktionen durchgeführt werden , indem die Auktion auf Basis deklarierter Gebote erfolgt , anstatt den Inhalt der Transaktion zu lesen . In Bezug auf die Unterdrückung von schädlichem MEV : Die Konsensregeln von Skip wie „ kein Frontrunning erlaubt “ ( erzwungen durch State - Checks ) sind eine direkte Maßnahme , um bösartiges Verhalten zu stoppen . Wenn ein Validator versucht , eine Sandwich - Attacke einzubauen , würden andere Validatoren erkennen , dass das Zustandsergebnis gegen die No - Frontrunning - Regel verstößt ( sie könnten zum Beispiel prüfen , ob keinem Handel unmittelbar ein anderer von derselben Adresse vorausging und folgte , und zwar in einer Weise , die einen Vorteil ausnutzte ) . Dieser Block würde abgelehnt . Da sie dies wissen , werden Validatoren gar nicht erst versuchen , solche Muster aufzunehmen , wodurch Nutzer durch das Protokollgesetz geschützt sind . Skip fördert auch das Verbrennen oder Umverteilen von MEV - Einnahmen , um perverse Anreize zu vermeiden . Beispielsweise könnte eine Chain entscheiden , alle Auktionserlöse zu verbrennen oder sie in einen Community - Fonds zu leiten , anstatt sie alle dem Block - Proposer zu geben . Dies verringert den Anreiz für Validatoren , Transaktionen selbst umzuordnen , da sie persönlich möglicherweise nicht davon profitieren ( je nach Wahl der Chain ) . Zusammenfassend lässt sich sagen , dass das Toolkit von Skip es jeder Chain ermöglicht , MEV chirurgisch dort zu extrahieren , wo es vorteilhaft ist ( z. B. Arbitrage zur Aufrechterhaltung der Markteffizienz , Liquidationen zur Gesunderhaltung von Kreditmärkten ) , und sicherzustellen , dass dieser Wert vom Protokoll oder den Nutzern erfasst wird , während bösartiges MEV ( wie nutzerunfreundliches Frontrunning ) streng verboten und verhindert wird . Es ist eine pragmatische Mischung aus Extraktion und Unterdrückung , die durch Governance maßgeschneidert wird : Anstatt einer Einheitslösung befähigt Skip Communities zu entscheiden , welches MEV „ gut “ ist ( und dessen Erfassung zu automatisieren ) und welches „ schlecht „ ist ( und es ü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 der Blogbeiträge von Skip stellt fest , dass eine faire MEV - Erfassung dazu verwendet werden kann , „ Einnahmen fair unter allen Netzwerkteilnehmern zu verteilen “ ) .

• Ökonomische Anreizstruktur : Die Einführung von Skip verschiebt grundlegend die Anreize , 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 umordnet ( da Cosmos standardmäßig keine MEV - Auktion hat ) . Mit Skip erklären sich Validatoren stattdatessen mit einem Protokoll einverstanden , bei dem MEV über Auktionen oder Module erfasst und oft geteilt wird . Validatoren profitieren weiterhin : Sie können einen Anteil an den Auktionserlösen oder zusätzliche Gebühren aus den Mechanismen von Skip erhalten , aber wichtig ist , dass alle Validatoren ( nicht nur der Proposer ) profitieren können , wenn es so konzipiert ist . Beispielsweise 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 erhält ( Winner - takes - all ) . Dies richtet Validatoren kollektiv darauf aus , die Skip - Software auszuführen , da selbst Nicht - Proposer Sicherheit gewinnen ( mit dem Wissen , dass ein ungültiger Block sich nicht auszahlt ) und möglicherweise Einnahmen erzielen . Einige Chains könnten dem Proposer immer noch den Großteil der MEV - Auktionsgebühr überlassen ( um den unmittelbaren Anreiz zur Aufnahme zu maximieren ) , aber selbst dann ist es transparent und wettbewerbsfähig , was wohl die Chance auf geheime Absprachen verringert . Chain / Community : Das Konzept des protokolleigenen MEV bedeutet , dass die Blockchain und ihre Stakeholder das MEV erfassen . Zum Beispiel leitet Osmosis ProtoRev - Gewinne in seinen Community - Pool um , wodurch MEV effektiv in eine zusätzliche Protokolleinnahme umgewandelt wird , die die Entwicklung finanzieren oder an OSMO - Staker verteilt werden könnte . Dies macht die Community im Allgemeinen zum „ Eigentümer “ dieses MEV und richtet das Interesse aller darauf aus , MEV auf gesunde Weise zu extrahieren . Wenn Nutzer wissen , dass das MEV in die Verbesserung der Chain oder der Tokenomics zurückfließt , akzeptieren sie es möglicherweise eher , als wenn es an einen zufälligen Bot geht . Searcher : Im Modell von Skip haben unabhängige Searcher / Bots möglicherweise weniger auf der Chain zu tun , da einige Möglichkeiten durch die Protokolllogik ( wie ProtoRev ) übernommen werden und andere durch Auktionen geleitet werden . Skip eliminiert Searcher jedoch nicht – vielmehr kanalisiert es sie dazu , über die richtigen Wege zu bieten . Ein Searcher kann immer noch versuchen , eine komplexe Strategie umzusetzen , aber um die Aufnahme an einer bestimmten Stelle zu garantieren , sollte er an der Auktion von Skip ( Skip Select ) teilnehmen , indem er sein Bundle mit einem Gebot einreicht . Wenn er dies nicht tut , riskiert er , dass ein Validator ihn zugunsten von jemandem ignoriert , der geboten hat , oder dass der chaineigene Mechanismus die Gelegenheit wahrnimmt . Die Searcher in Cosmos entwickeln sich also dahingehend weiter , mit Skip zusammenzuarbeiten : Z. B. reichen viele Arbitrageure auf Osmosis ihre Arbitragen nun über das System von Skip ein . Sie zahlen einen Teil an die Chain und behalten weniger Gewinn , aber das ist der Preis für die Teilnahme . Im Laufe der Zeit könnten einige „ Searcher “ - Rollen vollständig absorbiert werden ( wie Backrunning - Arbitrage – ProtoRev übernimmt dies , sodass kein externer Searcher konkurrieren kann ) . Dies könnte Spam und verschwendeten Aufwand im Netzwerk reduzieren ( keine konkurrierenden Bots mehr ; nur noch eine Protokollausführung ) . Nutzer : Endnutzer profitieren von einer faireren Umgebung ( keine überraschenden MEV - Angriffe ) . Zudem ermöglichen einige Skip - Konfigurationen explizit Belohnungen für Nutzer : Eine MEV - Umverteilung an Nutzer ist möglich . Beispielsweise könnte eine Chain entscheiden , einen Teil der MEV - Auktionserlöse an die Nutzer zurückzuerstatten , deren Trades dieses MEV erzeugt haben ( ähnlich wie die Refund - Idee von Flashbots ) . Astroport , eine DEX auf Terra , integrierte Skip , um MEV - Einnahmen mit Swappern zu teilen – was bedeutet , dass , wenn der Trade eines Nutzers MEV enthielt , ein Teil dieses Wertes standardmäßig an ihn zurückgegeben wird . Dies entspricht dem Ethos , dass MEV den Nutzern zugutekommen sollte . Obwohl nicht alle Chains dies tun , existiert die Option über die Infrastruktur von Skip , solche Schemata zu implementieren . Skip Protocol selbst ( das Unternehmen / Team ) hat ein Geschäftsmodell , bei dem sie diese Werkzeuge oft kostenlos für Validatoren zur Verfügung stellen ( um die Einführung zu fördern ) , und sie monetarisieren durch Partnerschaften mit Chains ( B2B ) . Zum Beispiel könnte Skip eine kleine Gebühr vom erfassten MEV einbehalten oder Chains für erweiterte Funktionen / Support Gebühren berechnen . Es wird erwähnt , dass Skip für Validatoren kostenlos ist , aber ein B2B - Modell mit Chains nutzt . Das bedeutet , Skip hat einen Anreiz , das von der Chain und der Community erfasste MEV zu maximieren ( damit die Chain zufrieden ist und vielleicht einen Teil gemäß Vereinbarung abgibt ) . Da jedoch Governance involviert ist , wird jede Gebühr , die Skip erhebt , in der Regel von der Community genehmigt . Der ökonomische Effekt ist interessant : Er professionalisiert die MEV - Extraktion als eine Dienstleistung , die für Chains erbracht wird . Dadurch wird unlauteres Verhalten unattraktiv – Validatoren müssen keine individuellen zwielichtigen Deals machen , sie können einfach Skip nutzen und erhalten einen zuverlässigen Fluss an zusätzlichen Einnahmen , der gesellschaftlich akzeptiert ist . Ehrliches Verhalten ( das Befolgen der Protokollregeln ) bringt fast so viel oder sogar 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 sanktioniert werden usw. Governance spielt eine bedeutende Rolle : Die Übernahme des Skip - Moduls oder das Festlegen der Parameter ( wie der Auktionsanteil , die Verteilung der Erlöse ) erfolgt über On - Chain - Vorschläge ( Proposals ) . Das bedeutet , dass die ökonomischen Ergebnisse ( wer das MEV erhält ) letztendlich durch Abstimmung der Community bestimmt werden . Beispielsweise debattiert der Cosmos Hub über die Übernahme des Builder - SDK von Skip , um MEV möglicherweise an die Treasury des Hubs oder an Staker umzuleiten . Diese Ausrichtung über die Governance stellt sicher , dass die Nutzung von MEV von der Community als legitim angesehen wird . Es verwandelt MEV von einem toxischen Nebenprodukt in eine öffentliche Ressource , die zugewiesen werden kann ( für Sicherheit , Nutzer , Entwickler usw. ) . Zusammenfassend lässt sich sagen , dass Skip die Anreize so umgestaltet , dass Validatoren kollektiv sowie Nutzer / Communities profitieren , während opportunistische MEV - Nehmer entweder in das System kooptiert ( als Bieter ) oder durch Design ausgeschlossen werden . In der Theorie stehen alle besser da : Nutzer verlieren weniger Wert an MEV , Validatoren werden weiterhin entschädigt ( möglicherweise sogar 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 der Nullsummen - Extraktion profitierten , ohne einen Wert zurückzugeben .

• Compliance und regulatorische Kompatibilität : Das Framework von Skip erleichtert es Chains durch die Stärkung der Chain - Governance tatsächlich , Compliance oder spezifische Richtlinien sicherzustellen , falls dies gewünscht ist . Da Skip auf Protokollebene arbeitet , könnte eine Chain entscheiden , bestimmte Transaktionsfilterungen oder Ordering - Regeln durchzusetzen , um Regulierungen einzuhalten . Wenn eine Chain zum Beispiel sanktionierte Adressen blockieren möchte , könnte sie eine AnteHandler - oder AuctionDecorator - Regel in das Skip - Modul integrieren , die Blöcke mit Blacklist - Adressen für ungültig erklärt . Dies ist wohl einfacher als bei Ethereum , wo Zensur eine Off - Chain - Entscheidung einzelner Validatoren ist ; bei Cosmos mit Skip könnte es eine chainweite Regel sein ( obwohl dies umstritten wäre und für viele gegen Dezentralisierungsideale verstößt ) . Alternativ könnte eine Chain erzwingen , dass zum Beispiel „ FIAT - Onramp - Transaktionen vor anderen erscheinen müssen „ , falls dies gesetzlich vorgeschrieben ist . Das Skip - Toolkit enthält keine voreingestellten Compliance - Regeln , ist aber 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 den gleichberechtigten Zugang verringert es den Vorteil eines einzelnen Validators , der aus Profitgründen zensieren könnte . Wenn zudem Threshold - Verschlüsselungs - Mempools ( wie der von Osmosis hinzugefügte ) mit Skip zum Standard werden , verdeckt dies Transaktionsinhalte und erschwert Zensur ( ähnlich wie bei Anoma ) . Skip ist eine neutrale Infrastruktur – sie kann entweder zur Compliance oder zum Widerstand genutzt werden , je nach Governance . 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 . Beispielsweise könnte eine zugangsbeschränkte ( Permissioned ) Cosmos - Chain ( wie eine institutionelle Chain ) das Builder - Modul von Skip weiterhin nutzen , aber vielleicht verlangen , dass nur Whitelist - Adressen an Auktionen teilnehmen können usw. , um ihren Regulierungen zu entsprechen . Regulatorische Kompatibilität bedeutet auch Transparenz : Die On - Chain - Auktionen von Skip erzeugen eine öffentliche Aufzeichnung von MEV - Transaktionen und wer was bezahlt hat . Dies könnte tatsächlich einige regulatorische Bedenken hinsichtlich der Fairness ausräumen ( jeder hatte die Chance zu bieten , und es ist prüfbar ) . Es ist transparenter als geheime Zahlungen an Validatoren . Durch die On - Chain - Erfassung von MEV verringert Skip zudem die Wahrscheinlichkeit von Off - Chain - Kartellen oder Dark Pools , die Regulierungsbehörden aufgrund ihrer Undurchsichtigkeit fürchten . Ohne Skip könnten Validatoren zum Beispiel private Deals mit Searchern machen ( wie bei Relay - Zensurproblemen zu sehen war ) . Mit Skip ist die Erwartung , dass man die offizielle Auktion nutzt – die offen und protokolliert ist – um Priorität zu erhalten . Dies fördert einen offenen Markt , der für alle 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 sich mit der Werterfassung befasst , könnten Fragen aufkommen , wenn MEV - Einnahmen in einen Community - Pool oder eine Treasury fließen ( ist es eine Gebühr , ist es steuerpflichtig usw.? ) . Diese sind jedoch ähnlich wie die Handhabung von Transaktionsgebühren , also rechtlich nichts grundlegend Neues . In Cosmos können Chain - Communities auch entscheiden , wie sie diesen Fonds verwenden ( verbrennen , verteilen usw. ) , was sie gegebenenfalls mit rechtlichen Vorgaben in Einklang bringen können ( zum Beispiel könnten sie vermeiden , es an eine Stiftung zu senden , wenn dies steuerliche Probleme auslöst , und es stattdessen verbrennen ) . In Bezug auf Zensurresistenz ein interessanter Hinweis : Durch das Durchsetzen von Regeln für die Blockgültigkeit verhindert Skip , dass Validatoren bestimmte Transaktionen zensieren , wenn dies gegen die Regeln verstößt . Wenn eine Chain zum Beispiel die Regel hätte „ muss mindestens ein Oracle - Update enthalten “ , könnte ein zensierender Validator nicht einfach alle Oracle - Transaktionen weglassen ( die vielleicht aus bestimmten Quellen stammen ) , da sein Block ungültig wäre . Paradoxerweise können Skip - Regeln also die Aufnahme kritischer Transaktionen erzwingen ( Anti - Zensur ) , so wie sie dazu verwendet werden könnten , den Ausschluss unzulässiger Transaktionen zu erzwingen . Es kommt ganz darauf an , was die Community festlegt . Neutralität : Die Standardposition von Skip besteht darin , Chains zu befähigen , „ Nutzer vor negativem 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 Standards 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 in den USA ansässige Chain die OFAC - Konformität implementieren , wenn sie rechtlich unter Druck gesetzt wird , ohne andere Chains zu beeinflussen . Es ist kein einzelner Relay , der über viele Chains hinweg zensiert ; es ist eine Entscheidung pro Chain . Aus Sicht eines Regulierers 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 verringern ( weniger Gas - Kriege ) und eine vorhersehbarere Ausführung schaffen , was ein Pluspunkt sein könnte . Zusammenfassend lässt sich sagen , dass die Architektur von Skip hochgradig anpassbar an Compliance - Anforderungen ist , während sie die Option für maximale Zensurresistenz bewahrt , wenn Communities dies priorisieren . Sie hält MEV im Tageslicht und unter kollektiver Kontrolle , was Blockchain - Ökosysteme wahrscheinlich robuster sowohl gegen böswillige Akteure als auch gegen regulatorische Maßnahmen macht , da die Selbstverwaltung proaktiv gegen schlimmste Missbräuche vorgehen kann .

• Technische Architektur & Implementierung : Skip Protocol ist eng in den Cosmos SDK - Stack integriert . Das Kernprodukt ist eine Reihe von Modulen ( z. B. x / builder ) und Modifikationen wie die BlockBuster - Mempool - Implementierung . Cosmos - Chains führen einen Konsens ( Tendermint / CometBFT ) aus , der ABCI - Hooks zum Vorbereiten und Verarbeiten von Vorschlägen ( Proposals ) bietet . Skip nutzt die ABCI++ Erweiterungen , die das Ausführen von Code zwischen Blockvorschlag und Finalisierung ermöglichen . Auf diese Weise wird das Ordering erzwungen : PrepareProposal kann die Blocktransaktionen gemäß den Lane - Regeln umordnen , bevor der Vorschlag verbreitet wird , und ProcessProposal kann bei den empfangenden Validatoren prüfen , ob das Ordering und die Zustandsgültigkeit den Erwartungen entsprechen . Dies ist ein modernes Feature ( Cosmos SDK v0.47+ ) , und das POB von Skip ist mit aktuellen SDK - Versionen kompatibel . Unter der Haube verwalten die Module von Skip Datenstrukturen für Auktionen ( z. B. ein On - Chain - Orderbuch von Geboten für den Top - of - Block ) . Sie verwenden wahrscheinlich auch Prioritäts - Transaktionstypen . Die README zeigt ein spezielles MsgAuctionBid und eine 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 verarbeiten und in der Blockmontagephase Gewinner ermitteln . Kryptographisch fügt Skip von sich aus keine neuen kryptographischen Anforderungen hinzu ( abgesehen von dem , was die Chain wählt , wie Threshold - Kryptographie für den Mempool , was separat ist ) . Es verlässt sich auf die Ehrlichkeit von mehr als 2 / 3 der Validatoren , um die Regeln durchzusetzen und keine Absprachen zu treffen , um sie zu brechen . Wenn eine Mehrheit gemeinsame Sache machen würde , könnten sie technisch gesehen die Regeln über die Governance ändern oder sie ignorieren , indem sie dies zur neuen De - facto - Regel machen . Das ist jedoch bei jeder Chain - Logik der Fall . Das Design von Skip versucht es mechanisch unmöglich zu machen , dass ein einzelner Validator in geringem Umfang betrügt . Beispielsweise wird jeder Versuch , vom Ordering abzuweichen , von anderen bemerkt , da dies objektiv ist . So verringert es das Vertrauen in einzelne Proposer . In Bezug auf die Performance verursachen Auktionen und zusätzliche Prüfungen Overhead . Cosmos - Blöcke sind jedoch relativ klein und die Zeit zwischen den Blöcken beträgt oft nur wenige Sekunden , was in den meisten Fällen für diese Operationen ausausreicht . Die Simulation ( das Vorausführen von Transaktionen zur Sicherstellung von Erfolg und Ordering - Einschränkungen ) könnte der aufwendigste Teil sein , aber Validatoren führen die Blockausführung ohnehin normalerweise durch , sodass dies ähnlich ist . Das Vorhandensein von Multi - Lanes bedeutet eine Trennung des Mempools : Z. B. muss eine Transaktion möglicherweise angeben , auf welche Lane sie abzielt ( Auktion vs. Kostenlos vs. Standard ) . Das Skip BlockBuster - Design sah in der Tat separate Lanes wie lanes / auction , lanes / free usw. vor , wahrscheinlich separate Mempool - Queues . Dies stellt beispielsweise sicher , dass kostenlose Transaktionen die Auktions - Transaktionen nicht verzögern oder stören . Es ist ein wenig wie verschiedene Prioritätsklassen beim Scheduling . Ein weiterer Aspekt sind Sicherheit und Fehlverhalten : Wenn ein Proposer versucht , die Auktion zu manipulieren ( z. B. seine eigene Transaktion aufzunehmen , aber behauptet , er sei den Regeln gefolgt ) , werden andere Validatoren den Block ablehnen . Der Cosmos - Konsens geht dann wahrscheinlich zum nächsten Proposer über , wobei der vorherige für Double - Signing oder einfach das Verfehlen bestraft wird ( je nach Szenario ) . Das Sicherheitsmodell der Chain übernimmt dies also – kein spezielles Slashing durch Skip über den bestehenden Konsens hinaus erforderlich . Man könnte Skip erweitern , um bösartiges Ordering zu bestrafen , aber das ist wahrscheinlich unnötig , wenn der Block einfach fehlschlägt . Entwicklung und Tooling : Der Code von Skip wurde Open Source zur Verfügung gestellt ( ursprünglich unter skip - mev / pob und nun 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 – geliefert Anfang 2023 . Astroport auf Terra integrierte 2023 das MEV - Sharing mit Skip . Der Cosmos Hub evaluiert das „ Block SDK “ von Skip , 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 untersucht eine Interchain - MEV - Auktion , bei der MEV von vielen Chains auf dem Hub gehandelt werden könnte , und Skip ist an diesen Diskussionen beteiligt ( die Forschung von Zerocap erwähnte den geplanten Interchain - Scheduler von IBC ) . Die Technik von Skip könnte als Rückgrat für solche Cross - Chain - Auktionen dienen , da sie bereits Auktionen auf einzelnen Chains durchführt . Dies wäre analog zum Cross - Domain - Ziel von SUAVE , jedoch innerhalb von Cosmos . Zu den wichtigen Updates : Skip startete etwa Mitte 2022 . Bis Mitte 2023 hatten sie ein stabiles POB - Release für SDK v0.47+ ( auf das viele Chains aktualisierten ) . Sie erhielten zudem eine Seed - Finanzierung , was auf eine aktive Entwicklung hindeutet . Ein weiterer Konkurrent in Cosmos , Mekatek , bietet ähnliche Funktionen an . Dies hat die Roadmap von Skip vielleicht beschleunigt , um an der Spitze zu bleiben . Skip verfeinert weiterhin Funktionen wie private Transaktions - Lanes ( vielleicht um Transaktionen bis zur Aufnahme zu verbergen ) und komplexere Gültigkeitsregeln , wenn Anwendungsfälle auftreten . Da es modular aufgebaut ist , könnte eine Chain wie dYdX ( die ein Orderbuch haben wird ) Skip nutzen , um Fairness beim Order - Matching On - Chain sicherzustellen usw. , sodass sich die Werkzeuge von Skip an verschiedene App - Logiken anpassen können . Technisch gesehen ist die Lösung von Skip einfacher als der Aufbau einer völlig neuen Chain : Es ist ein Upgrade der Fähigkeiten bestehender Chains . Dieser inkrementelle Opt - in - Ansatz hat eine recht schnelle Einführung ermöglicht – zum Beispiel erforderte die Aktivierung von Auktionen auf Osmosis keinen neuen Konsensalgorithmus , sondern lediglich das Hinzufügen eines Moduls und die Koordinierung der Validatoren zur Ausführung der aktualisierten Software ( was sie taten , da es vorteilhaft war und von der Governance verabschiedet wurde ) . Zusammenfassend lässt sich sagen , dass die Architektur von Skip in die Knotensoftware jeder Chain eingebettet ist und den Mempool sowie die Block - Proposal - Pipeline anpasst . Es ist ein pragmatischer technischer Ansatz für faires Ordering : Nutze das , was bereits vorhanden ist ( Tendermint BFT ) , und füge Logik hinzu , um es zu steuern . Die Schwerstarbeit ( wie das Finden von Arbitragen ) kann sogar vom chaineigenen Modul erledigt werden ( ProtoRev nutzt den in Osmosis eingebauten Wasm - und Rust - Code , um Pools zu scannen ) . So verlagert sich ein Großteil der MEV - Handhabung On - Chain . Dieser On - Chain - Ansatz muss sorgfältig auf Effizienz und Sicherheit programmiert werden , steht aber unter der Beobachtung der Community . Wenn eine Regel problematisch ist ( zu streng usw. ) , kann die Governance sie anpassen . Damit verwandelt Skip MEV sowohl technisch als auch gesellschaftlich in einen weiteren Parameter der Chain , der optimiert und verwaltet werden kann , anstatt in einen „ Wilden Westen „ . Dies ist eine einzigartige Position , 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 unterschiedlichen Blickwinkeln an, abgestimmt auf ihre jeweiligen Ökosysteme und Designphilosophien. Flashbots v2 ist eine inkrementelle, pragmatische Lösung für die aktuelle Architektur von Ethereum: Es akzeptiert MEV-Auktionen, versucht jedoch, deren Auswirkungen zu demokratisieren und abzumildern (durch Off-Chain-Koordination, SGX-Privatsphäre und Sharing-Mechanismen). SUAVE ist der zukunftsorientierte Plan von Flashbots, eine inter-chain MEV-Plattform zu schaffen, die den Gesamtwert und den Nutzen für die Anwender maximiert – im Wesentlichen wird das Auktionsmodell auf ein dezentrales, die Privatsphäre schützendes globales Netzwerk ausgeweitet. Anoma ist eine grundlegende Neugestaltung der Art und Weise, wie Transaktionen formuliert und ausgeführt werden. Ziel ist es, die Ursachen für unfaire Reihenfolgen durch den Einsatz von Intents (Absichten), Solver-vermitteltem Matching und kryptografischer Fairness im Konsens zu eliminieren. Skip ist ein Ansatz für souveräne Chains, der Fairness und MEV-Erfassung auf Protokollebene pro Chain integriert, insbesondere im Cosmos-Ökosystem, durch konfigurierbare Regeln und Auktionen.

Jedes Modell hat Stärken und Kompromisse:

• Fairness- und Ordering-Garantien: Anoma bietet die stärkste theoretische Fairness (kein Frontrunning durch Design, verschlüsselte Batches), erfordert aber ein neues Paradigma und komplexe Technologie, die sich erst noch beweisen muss. Skip kann konkrete Fairness-Regeln auf bestehenden Chains erzwingen (Verhinderung von Frontrunning oder Durchsetzung von First-In-First-Out innerhalb von Lanes), ist jedoch darauf beschränkt, was die jeweilige Community erzwingen möchte. SUAVE und Flashbots v2 verbessern die Fairness in Bezug auf den Zugang (offene Auktionen statt geheimer Absprachen, Schutz vor Sniping im öffentlichen Mempool), verhindern jedoch nicht inhärent die Ausführung einer entschlossenen MEV-Strategie – sie stellen lediglich sicher, dass diese die Nutzer bezahlt oder neutral durchgeführt wird.
• MEV-Umverteilung: SUAVE und Flashbots zielen explizit darauf ab, MEV an Nutzer/Validatoren „zurückzugeben“: SUAVE über Nutzergebote/Rückerstattungen, Flashbots über Builder-Wettbewerbe und Rückerstattungen. Skip kann MEV an Nutzer (je nach Konfiguration, z. B. im Fall von Astroport) oder an Community-Fonds leiten. Anoma vermeidet eine explizite Umverteilung, da das Ziel darin besteht, die Extraktion von vornherein zu vermeiden – idealerweise erhalten die Nutzer einfach faire Preise, was gleichbedeutend damit ist, keinen Wert an MEV zu verlieren.
• Umfang (Single- vs. Multi-Domain): Flashbots v2 und Skip konzentrieren sich auf ihre eigenen Domains (Ethereum bzw. einzelne Cosmos-Chains). SUAVE ist von Natur aus multi-domain-fähig – es sieht Cross-Chain-MEV als eine Hauptmotivation. Anoma zieht schließlich auch Multi-Chain-Intents in Betracht, könnte sich aber in der Anfangsphase auf jeweils eine Fraktal-Instanz beschränken und dann über Adapter expandieren. Die Cross-Chain-Auktion von SUAVE könnte Arbitrage und Koordination ermöglichen, die andere nicht so einfach umsetzen können (außer vielleicht ein Interchain Scheduler mit Hilfe von Skip im Cosmos-Bereich).
• Komplexität und Adaption: Flashbots v2 war relativ einfach zu adoptieren (ein Client-Sidecar) und erfasste schnell die Mehrheit der Ethereum-Blöcke. Skip nutzt ebenfalls bestehende Technologien und findet im Cosmos-Ökosystem durch unkomplizierte Governance-Vorschläge Anklang. SUAVE und Anoma sind revolutionärer – sie erfordern neue Netzwerke oder umfassende Änderungen. Die Herausforderung für SUAVE wird darin bestehen, viele Chains und Nutzer zur Teilnahme an einer neuen Ebene zu bewegen; die Herausforderung für Anoma 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 bei der Transparenz. Flashbots v2/SUAVE eliminieren „Dark Forest“-Elemente, mussten sich jedoch mit Zensurproblemen auseinandersetzen – SUAVE wird explizit so gebaut, dass diese zentralen Punkte vermieden werden. Anoma schützt die Nutzer durch standardmäßige Privatsphäre maximal (könnte aber Regulierungsbehörden aufgrund verschlüsselter Aktivitäten beunruhigen). Das Modell von Skip gibt jeder Chain die Autonomie, einen Compliance-Kompromiss zu finden. Wenn ein Regulator „keine MEV-Auktionen“ oder „keine Privatsphäre“ fordern würde, könnte ein Ethereum, das Flashbots nutzt, in einen Konflikt geraten, während eine Cosmos-Chain, die Skip nutzt, diese Funktionen einfach nicht implementieren oder anpassen könnte. In Bezug auf Neutralität: SUAVE und Anoma streben nach glaubwürdiger Neutralität (jeder greift zu gleichen Bedingungen auf ein System zu; beide sind im Wesentlichen Netzwerke für öffentliche Güter). Flashbots v2 ist neutral, indem es offenen Zugang bietet, aber es existiert eine gewisse Zentralisierung im Builder-Markt (die jedoch durch BuilderNet-Bemühungen gemildert wird). Die Neutralität von Skip hängt von der Governance ab – idealerweise sorgt sie dafür, dass MEV keinen einzelnen Insider bevorzugt, aber man könnte es schlecht konfigurieren und die Neutralität beeinträchtigen (was jedoch unwahrscheinlich ist, da dies einen Governance-Konsens erfordern würde).
• Unterschiede in der technischen Architektur: Flashbots v2 und SUAVE sind Off-Chain-Marktplätze, die über die Chain gelegt werden: Sie führen spezialisierte Rollen ein (Builder, Relays, Executoren) und nutzen Hardware oder Kryptografie, um diese abzusichern. Anoma und Skip integrieren sich direkt in den Konsens oder die State Machine. Anoma verändert den Transaktionslebenszyklus und den Konsens selbst (mit Schwellenwert-Verschlüsselung und vereinheitlichten Intents). Skip klinkt sich über ABCI++ in den Konsens von Tendermint ein, ändert aber nicht den grundlegenden Algorithmus – es ist eine Anpassung auf der Anwendungsebene. 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 liegt gewissermaßen in der Mitte: Es ist eine separate Chain, aber um sie effektiv zu nutzen, benötigen andere Chains geringfügige Anpassungen (um von SUAVE erstellte Blöcke zu akzeptieren oder an SUAVE auszugeben). Die kryptografische Komplexität ist bei Anoma am höchsten (ZK, MPC, Threshold Crypto alles in einem), moderat bei SUAVE (Threshold Crypto und SGX, plus normale Kryptografie für das Bridging) und relativ gering bei Flashbots v2 (SGX, Standardsignaturen) und Skip (hauptsächlich Standardsignaturen, plus was auch immer die Chain verwendet, wie Threshold Decryption, falls gewählt).
• Entwicklungsstadium: 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 bereits ausgerollt werden (einige Auktionsfunktionen im Test, Testnet Toliman live). Anoma befindet sich ebenfalls in der Testnet-Phase (ein Vision-Paper, teilweise Implementierungen wie das Namada-Mainnet und wahrscheinlich ein Anoma-Testnet, das 2023 Einladungscodes erforderte). Was reale Daten betrifft: Flashbots v2 und Skip haben Ergebnisse vorzuweisen (z. B. lieferte Flashbots v2 Millionen an Validatoren und senkte die durchschnittlichen Gaspreise während Phasen mit hohem MEV; ProtoRev von Skip generierte beträchtliche Mittel für die Osmosis-Community und verhinderte viele Sandwich-Attacken, als die Schwellenwert-Verschlüsselung begann). SUAVE und Anoma sind vielversprechend, müssen sich aber operativ und ökonomisch erst noch beweisen.

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

Protokoll	Transaktionsreihenfolge	MEV-Mechanismus (Unterdrücken vs. Extrahieren)	Wirtschaftliche Anreize (Alignment)	Compliance & Neutralität	Architektur & Technik	Entwicklungsstand
Flashbots v2 (Ethereum)	Off-Chain-Builder-Auktionen entscheiden über die Blockreihenfolge (PBS über MEV-Boost). Transaktionen im öffentlichen Mempool werden für private Bundles umgangen. Die Reihenfolge ist gewinnorientiert (höchstzahlendes Bundle zuerst).	Extrahiert MEV über Sealed-Bid-Blockauktionen, mildert aber schädliche Nebenwirkungen ab (keine Gas-Wars, kein öffentliches Frontrunning). Ermöglicht private Transaktionsübermittlung (Flashbots Protect), um für Nutzer sichtbares MEV wie direktes Frontrunning zu unterdrücken. Zensurresistenz verbessert sich durch Multi-Relay & Builder-Dezentralisierung.	Validatoren maximieren Einnahmen durch Outsourcing von Blöcken (erhalten höchste Gebote). Searcher konkurrieren Gewinne weg, um Inklusion zu gewinnen (das meiste MEV geht an Validatoren). Builder verdienen eine Marge, falls vorhanden. Aufkommende Refunds teilen MEV mit Nutzern (über BuilderNet). Anreize bevorzugen offenen Wettbewerb gegenüber exklusiven Deals.	Stand anfangs vor OFAC-Zensur (zentrales Relay), wechselte aber zu mehreren Relays und Open-Source-Buildern. Strebt nun glaubwürdige Neutralität an: Das TEE-Netzwerk von BuilderNet stellt sicher, dass kein einzelner Builder zensieren kann. Insgesamt transparenter als der Mempool, aber immer noch abhängig von Off-Chain-Entitäten (Relays).	Off-Chain-Marktplatz, integriert in Ethereum PoS. Nutzt Trusted HW (SGX) für privaten Orderflow in BuilderNet. Keine Konsensänderung auf L1; verwendet Standard-Builder-API. Fokus auf Engineering (Sidecar-Clients, Relays), weniger auf neue Kryptografie.	Produktion im Ethereum-Mainnet (seit Sep. 2022). >90 % der Blöcke über MEV-Boost. Kontinuierliche Upgrades: Open-Source-Builder, BuilderNet Alpha live (Ende 2024). Bewährt stabil, mit laufenden Dezentralisierungsbemühungen.
SUAVE (Flashbots nächste Gen)	Vereinheitlichter Cross-Chain-Mempool von Präferenzen (Nutzer-Intents + Gebote). Executoren bilden daraus optimale Transaktionsbündel. Dezentrales Sequencing – SUAVE gibt geordnete Blockfragmente an Domains aus. Reihenfolge basierend auf Nutzergeboten & globalem Wohlergehen (nicht einfaches FIFO oder Gas). Privatsphäre (Verschlüsselung) verhindert Manipulation der Reihenfolge bis zur Ausführung.	Unterdrückt „schlechtes MEV“, indem MEV an Nutzer zurückgegeben wird: z. B. bezahlen Orderflow-Auktionen Nutzer dafür, dass sie „backrunned“ werden. Aggregiert „gutes MEV“ (wie Cross-Domain-Arbs) für maximale Extraktion, verteilt es aber an Nutzer/Validatoren um. Nutzt verschlüsselten Mempool & kollaboratives Blockbuilding, um Frontrunning und exklusiven Zugang zu verhindern.	Nutzer posten Präferenzen mit zahlbaren Geboten; konkurrierende Executoren verdienen das Gebot, indem sie das Ziel des Nutzers 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. Design verlagert MEV-Gewinne zu Nutzern und Validatoren und minimiert Searcher-Rente. Flashbots möchte lediglich ein Vermittler bleiben.	Gebaut für glaubwürdige Neutralität: eine neutrale öffentliche Plattform, die von keinem einzelnen Akteur kontrolliert wird. Privacy-first (Transaktionen in SGX oder kryptografisch verschlüsselt) bedeutet, dass keine Entität basierend auf Inhalten zensieren kann. Hofft, jede Flashbots-Vertrauensanforderung durch schrittweise Dezentralisierung zu vermeiden. Compliance ist nicht explizit eingebaut, aber Neutralität und globale Reichweite haben Priorität (könnte regulatorische Fragen zur Privatsphäre aufwerfen).	Unabhängige Chain (EVM-kompatibel) für Präferenzen & Auktionen. Nutzt intensiv Intel SGX Enclaves (für privaten Mempool und kollaboratives Blockbuilding). Plant die Einführung von Threshold Encryption und MPC, um Trusted Hardware zu eliminieren. Im Wesentlichen eine Blockchain + Secure Compute-Ebene über anderen Chains.	In Entwicklung – Centauri-Testnet-Phase aktiv (Devnet, Basis-Auktionen). Open-Source SUAVE-Client (Aug. 2023); Toliman Testnet für Community-Tests gestartet. Mainnet noch nicht live (erwartet in Phasen: Andromeda, Helios). Ehrgeizige Roadmap, in großem Maßstab noch unbewiesen.
Anoma (Intent-zentriert)	Kein herkömmlicher Mempool; Nutzer senden Intents (gewünschte Ergebnisse). Solver sammeln Intents und erstellen passende Transaktionen. Nutzt Threshold Encryption von Transaktionen, sodass Validatoren sie ordnen, ohne den Inhalt zu sehen, was reaktives MEV verhindert. Verwendet oft Batch-Processing (z. B. Entschlüsseln und Abgleichen von Intents in Batches alle N Blöcke) für faire Preise. Konsens stellt Order-Commitments vor der Offenlegung sicher und erreicht so Reihenfolge-Fairness.	Starke MEV-Minderung durch Design: Frontrunning unmöglich (Transaktionen werden erst nach finaler Ordnung offengelegt). Batch-Auktionen eliminieren Prioritätsvorteile (z. B. teilen alle Trades im Batch den Clearing-Preis). Solver konkurrieren um die Erfüllung von Intents, was die Preise in Richtung des Nutzer-Optimums treibt und wenig MEV hinterlässt. Im Wesentlichen wird der extrahierbare Wert minimiert – 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 wie DEX-Aggregatoren), aber der Wettbewerb zwingt sie, den Nutzern die besten Deals zu liefern. Validatoren erhalten Gebühren und Staking-Rewards; sie stellen auch eine faire Ausführung sicher (kein extra MEV über Konsens). Nutzer gewinnen durch bessere Ausführung (sie handeln nur zu fairen Preisen und verlieren keinen Wert an MEV). Wert, der MEV wäre, bleibt bei Nutzern oder dem Protokoll (oder wird minimal als Servicegebühr mit Solvern geteilt). Die Architektur richtet Anreize auf ehrliche Teilnahme aus.	Privatsphäre und Fairness sind Kernpunkte – 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 sehen können (verschlüsselte Tx), und müssen algorithmischen Matching-Regeln folgen. Hochgradig neutral – alle Intents werden nach derselben Matching-Logik behandelt. Regulatorische Compliance ist nicht fest eingebaut (starke Privatsphäre könnte für KYC schwierig sein), aber das Intent-Framework könnte konforme Designs auf Anwendungsebene ermöglichen.	Neue Blockchain-Architektur. Nutzt BFT-Konsens mit integrierter Intent-Gossip- & Solver-Ebene. Verlässt sich auf Threshold Cryptography (Ferveo) für Mempool-Privatsphäre und ZK SNARKs (Taiga) für Datenschutz. Die Ausführung wird durch Validity Predicates gesteuert (anwendungsspezifische Logik, die faire Ergebnisse erzwingt). Interoperabel über IBC (Multi-Chain-Intents in Zukunft möglich). Kryptografisch sehr fortschrittlich (Verschlüsselung, ZK, MPC-Konzepte kombiniert).	Testnets und Teil-Launches. Anomas erstes Testnet Feigenbaum (Nov. 2021) demonstrierte grundlegendes Intent-Matching. Viele Konzepte werden in Stufen implementiert; z. B. startete Namada (2023) mit Anomas Privacy-Tech und Ferveo für einen Single-Chain-Use-Case. Das volle Anoma L1 mit Intents befindet sich im Testnet (Invite-only Tests Mitte 2023). Mainnet Phase 1 (geplant) wird auf Ethereum-Integration abzielen; nativer Token und voller Konsens folgen später. Noch stark in der F&E-Phase, noch nicht praxiserprobt.
Skip Protocol (Cosmos)	Protokollinterne Regeln zur Transaktionsreihenfolge und Block-Lanes, konfiguriert durch die Governance jeder Chain. Z. B. entscheiden Auktionen über die Reihenfolge am Blockanfang, danach folgen Standardtransaktionen usw. Konsens-erzwungen: Validatoren lehnen Blöcke ab, die gegen die Reihenfolge verstoßen (wie eine ungültige Tx-Sequenz). Ermöglicht benutzerdefinierte Richtlinien (Reihenfolge nach Gaspreis, Oracle-Tx zuerst einschließen, bestimmte Muster verbieten) – effektiv deterministische Ordering-Algorithmen, die von der Chain gewählt werden.	Hybrider Ansatz – extrahiert MEV auf kontrollierte Weise (über On-Chain-Auktionen und protokolleigene Arbitrage), während böswilliges MEV unterdrückt wird (durch Durchsetzung von Regeln). 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 negatives MEV (Sandwiches etc.) eingedämmt, während „positives MEV“ (Arbs, Liquidationen) zum Vorteil der Chain genutzt wird.	Validatoren gewinnen eine neue Einnahmequelle aus Auktionsgebühren oder vom Protokoll erfasstem MEV, ohne Konsensregeln zu brechen. Das Risiko einzelner „Rogue Validatoren“ wird reduziert (müssen Regeln folgen, sonst ist der Block ungültig), was Validatoren kollektiv ausrichtet. Chain/Community kann MEV-Einnahmen lenken (z. B. an Staker oder Community-Fonds). Searcher müssen über Auktionen konkurrieren und oft einen Teil des Gewinns an die Chain/Validatoren abgeben. Einige MEV-Rollen werden von On-Chain-Modulen übernommen. Nutzer profitieren von weniger Angriffen und können sogar MEV-Rabatte erhalten (z. B. teilt Astroport MEV mit Tradern). Anreize werden Community-orientiert – MEV wird als öffentliches Einkommen behandelt.	Souveräne Compliance: Jede Chain wählt ihre eigene Richtlinie. Das bedeutet, eine Chain könnte über Modulkonfiguration strenge Anti-MEV-Regeln oder KYC-Anforderungen durchsetzen. Skips Transparenz (On-Chain-Gebote) und Governance-Kontrolle verbessern die Legitimität. Es erhöht inhärent die Zensurresistenz innerhalb der gewählten Regeln der Chain – wenn die Regel sagt „Oracle-Tx immer einschließen“, kann ein zensierender Validator sie nicht weglassen. Skip fördert generell Transparenz und Fairness, wie sie von der Community festgelegt werden. Keine einzelne Entität (wie ein Relay) kontrolliert die Reihenfolge – sie ist im Protokoll und Open Source.	Cosmos SDK-Module (Protocol-Owned Builder), die zur Node-Software hinzugefügt werden. Nutzt ABCI++ Hooks für benutzerdefinierte Block-Erstellung und Validierung. Implementiert On-Chain-Auktionen (Verträge oder Module handhaben Gebote und Auszahlungen). Standardmäßig keine spezialisierte Kryptografie (über Standard-Cosmos-Tech hinaus), aber kompatibel mit Threshold Encryption – z. B. fügte Osmosis einen verschlüsselten Mempool mit Blick auf Skip hinzu. Im Wesentlichen eine Erweiterung von Tendermint BFT, die MEV-bewusste Logik in den Block-Vorschlag einbringt. Leichtgewichtig für Chains zu adoptieren.	Live auf mehreren Chains. Skips Auktions- und Builder-Modul wurde auf Osmosis (2023) eingesetzt – das ProtoRev-Modul generierte Protokolleinnahmen und Auktionen für den Blockanfang sind live. Wird auf Terra/Astroport, Juno usw. verwendet und vom Cosmos Hub in Erwägung gezogen. Der Code ist Open Source und entwickelt sich weiter (v1 von POB für SDK 0.47+). In der Produktion bewährt, mit real erfasstem und verteiltem MEV. Kontinuierlicher Rollout von Features (z. B. neue Lane-Typen).

Jede Lösung adressiert das MEV-Problem auf einer anderen Ebene – Flashbots v2 arbeitet um den L1-Konsens herum, SUAVE schlägt eine neue L1.5-Ebene vor, Anoma gestaltet das L1 selbst neu und Skip nutzt modulare L1-Anpassungen. In der Praxis schließen sich diese Ansätze nicht gegenseitig aus und könnten sich sogar ergänzen (beispielsweise könnte eine Cosmos-Chain Skip intern nutzen und zusätzlich Intents an SUAVE für Cross-Chain-MEV senden, oder Ethereum könnte in Zukunft eine Anoma-ähnliche Reihenfolge-Fairness implementieren, während es weiterhin Flashbots für Builder-Märkte nutzt). Die Tabelle verdeutlicht ihre vergleichenden Eigenschaften: Flashbots v2 liefert bereits Verbesserungen für Ethereum, extrahiert aber weiterhin MEV (nur gerechter und effizienter); SUAVE strebt ein maximales Synergie-Ergebnis an, bei dem alle über ein Netzwerk kooperieren – sein Erfolg wird von der breiten Akzeptanz und der technischen Umsetzung der versprochenen Privatsphäre und Dezentralisierung abhängen; Anoma bietet vielleicht die stärkste 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 eine pragmatische Balance für Cosmos, indem es Communities erlaubt, MEV und Fairness aktiv nach ihren eigenen Vorstellungen zu steuern – es ist weniger radikal als Anoma, aber tiefer eingebettet als Flashbots und zeigt bereits greifbare Ergebnisse im Cosmos-Ökosystem.

Fazit und Ausblick

MEV-Unterdrückung und Fair Ordering bleiben eines der „Millennium-Probleme der Krypto-Welt“. Die vier analysierten Protokolle – Flashbots v2, SUAVE, Anoma und Skip – repräsentieren ein Spektrum an Lösungen: von sofortigen Abmilderungen in bestehenden Frameworks bis hin zu totalen Paradigmenwechseln in der Transaktionsverarbeitung. Flashbots v2 hat die Kraft von offenen MEV-Märkten demonstriert, um Chaos zu reduzieren und Werte umzuverteilen, während gleichzeitig Kompromisse wie Zensur navigiert werden, die durch Dezentralisierung angegangen werden. Es zeigt, dass inkrementelle Änderungen (wie PBS-Auktionen und private Mempools) den Schmerz durch MEV kurzfristig erheblich lindern können. SUAVE, der nächste Schritt von Flashbots, führt diesen Ethos in eine vereinheitlichte Cross-Chain-Arena – wenn es erfolgreich ist, könnten wir eine Zukunft sehen, in der Nutzer routinemäßig für den MEV bezahlt werden, den ihre Trades erzeugen, und in der die Block-Erstellung über viele Netzwerke hinweg kollaborativ und für Fairness verschlüsselt ist. Anoma deutet auf eine grundlegendere Entwicklung hin: Durch die Entfernung des Konzepts von Prioritätstransaktionen und deren Ersetzung durch ein Intent-Matchmaking-System könnten ganze Klassen von MEV eliminiert und ausdrucksstärkere Finanz-dApps freigeschaltet werden. Sein Fair Ordering auf der Konsensus-Ebene (via Threshold-Verschlüsselung und Batch-Auktionen) ist ein Ausblick darauf, wie Blockchains selbst Fairness-Garantien bieten können, nicht nur als Off-Chain-Add-ons. Skip Protocol wiederum verkörpert einen Mittelweg im Multi-Chain-Kontext – es gibt einzelnen Chains die Entscheidungsfreiheit darüber, wie sie MEV-Einnahmen und Nutzerschutz ausbalancieren. Die frühe Einführung in Cosmos zeigt, dass viele der negativen Auswirkungen von MEV heute mit durchdachtem Protokoll-Engineering und Community-Zustimmung bewältigt werden können.

In Zukunft können wir eine gegenseitige Befruchtung von Ideen erwarten: Ethereum-Forscher untersuchen Order-Fair-Konsensus und Threshold-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 interagieren (vielleicht sogar via Skip), da es danach strebt, Chain-agnostisch zu sein. Anomas Intent-Konzept könnte das Anwendungsdesign selbst auf traditionellen Plattformen beeinflussen (z. B. nutzt CoW Swap auf Ethereum bereits ein Solver-Modell; man kann es als eine „Anoma-ähnliche“ dApp betrachten). Der Erfolg von Skip könnte andere Ökosysteme (Polkadot, Solana etc.) dazu ermutigen, ähnliche In-Protokoll-MEV-Kontrollen einzuführen. Ein zentrales Thema ist das ökonomische Alignment – all diese Protokolle streben danach, die Anreize derjenigen, die das Netzwerk sichern, mit dem Wohlergehen der Nutzer in Einklang zu bringen, sodass die Ausbeutung von Nutzern weder profitabel noch möglich ist. Dies ist entscheidend für die langfristige Gesundheit von Blockchain-Ökosystemen und zur Vermeidung von Zentralisierung.

In Zusammenfassung lässt sich sagen, dass SUAVE, Anoma, Skip und Flashbots v2 jeweils Puzzleteile zum Fair Ordering und zur MEV-Abmilderung beitragen. Flashbots v2 hat eine Vorlage für MEV-Auktionen geschaffen, die andere nachahmen, Skip hat bewiesen, dass On-Chain-Durchsetzung machbar ist, Anoma hat die Vorstellungskraft dessen erweitert, was möglich ist, indem es das Transaktionsmodell neu aufgebaut hat, und SUAVE versucht, die Gewinne der letzten Jahre zu vereinheitlichen und zu dezentralisieren. Die ultimative Lösung könnte Elemente von allen beinhalten: datenschutzwahrende globale Auktionen, Intent-zentrierte Benutzeroberflächen, Fairness-Regeln auf Chain-Ebene und kollaborative Block-Erstellung. Stand 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 sich dem Ideal der „besten Ausführung für Nutzer mit der dezentralsten Infrastruktur“ annähern.