Stellen Sie sich eine Welt vor, in der Benutzer nahtlos mit Ihrer dApp interagieren können, ohne native Token (SUI) besitzen zu müssen. Dies ist kein ferner Traum mehr. Mit Suis Gas Station (auch bekannt als Paymaster) können Entwickler die Gasgebühren im Namen ihrer Benutzer übernehmen, wodurch eine der größten Hürden für Neueinsteiger in Web3 vollständig beseitigt und ein wirklich reibungsloses On-Chain-Erlebnis ermöglicht wird.

Dieser Artikel bietet einen vollständigen Leitfaden zur Umstellung Ihrer dApp auf Gas-los. Wir werden tief in die Kernkonzepte des Sui Paymasters, seine Architektur, Implementierungsmuster und Best Practices eintauchen.

1. Hintergrund und Kernkonzepte: Was ist eine gesponserte Transaktion?​

In der Welt der Blockchain erfordert jede Transaktion eine Netzwerkgebühr oder „Gas“. Für Benutzer, die an die nahtlosen Erfahrungen von Web2 gewöhnt sind, stellt dies eine erhebliche kognitive und operative Hürde dar. Sui begegnet dieser Herausforderung auf Protokollebene mit gesponserten Transaktionen.

Die Kernidee ist einfach: einer Partei (dem Sponsor) zu erlauben, die SUI-Gasgebühren für die Transaktion einer anderen Partei (des Benutzers) zu bezahlen. Auf diese Weise können Benutzer, selbst wenn sie kein SUI in ihrer Wallet haben, dennoch erfolgreich On-Chain-Aktionen initiieren.

Paymaster ≈ Tankstelle​

Im Sui-Ökosystem wird die Logik für das Sponsern von Transaktionen typischerweise von einem Off-Chain- oder On-Chain-Dienst namens Gas Station oder Paymaster gehandhabt. Zu seinen Hauptaufgaben gehören:

1. Bewertung der Transaktion: Er empfängt die gas-losen Transaktionsdaten eines Benutzers (GasLessTransactionData).
2. Bereitstellung von Gas: Er sperrt und weist die notwendige Gasgebühr für die Transaktion zu. Dies wird normalerweise über einen Gas-Pool verwaltet, der aus vielen SUI-Coin-Objekten besteht.
3. Erzeugung einer Sponsor-Signatur: Nach Genehmigung des Sponsorings signiert die Gas Station die Transaktion mit ihrem privaten Schlüssel (SponsorSig), wodurch ihre Bereitschaft zur Zahlung der Gebühr bestätigt wird.
4. Rückgabe der signierten Transaktion: Er sendet die TransactionData zurück, die nun die Gasdaten und die Signatur des Sponsors enthält, um die endgültige Signatur des Benutzers abzuwarten.

Kurz gesagt, eine Gas Station fungiert als Tankservice für die Benutzer Ihrer dApp und stellt sicher, dass ihre „Fahrzeuge“ (Transaktionen) reibungslos im Sui-Netzwerk fahren können.

2. Hochrangige Architektur und Interaktionsfluss​

Eine typische gas-lose Transaktion erfordert die Koordination zwischen dem Benutzer, dem dApp-Frontend, der Gas Station und einem Sui Full Node. Die Interaktionssequenz ist wie folgt:

Ablaufbeschreibung:

1. Der Benutzer führt eine Aktion in der dApp-Benutzeroberfläche aus, die ein Transaktionsdatenpaket ohne Gasinformationen erstellt.
2. Die dApp sendet diese Daten an ihre zugewiesene Gas Station, um ein Sponsoring anzufordern.
3. Die Gas Station überprüft die Gültigkeit der Anfrage (z. B. ob der Benutzer für ein Sponsoring berechtigt ist), füllt die Transaktion dann mit einem Gas Coin und ihrer Signatur auf und gibt die halbfertige Transaktion an die dApp zurück.
4. Der Benutzer sieht die vollständigen Transaktionsdetails in seiner Wallet (z. B. „Ein NFT kaufen“) und gibt die endgültige Signatur. Dies ist ein entscheidender Schritt, der sicherstellt, dass der Benutzer die Zustimmung und Kontrolle über seine Aktionen behält.
5. Die dApp sendet die vollständige Transaktion, die sowohl die Signaturen des Benutzers als auch des Sponsors enthält, an einen Sui Full Node.
6. Nachdem die Transaktion On-Chain abgeschlossen ist, kann die Gas Station dies durch Abhören von On-Chain-Ereignissen oder -Belegen bestätigen und dann das dApp-Backend über einen Webhook benachrichtigen, um den Geschäftsprozess abzuschließen.

3. Drei Kern-Interaktionsmodelle​

Sie können die folgenden drei Interaktionsmodelle einzeln oder in Kombination verwenden, um Ihren Geschäftsanforderungen gerecht zu werden.

Modell 1: Benutzer-initiiert → Sponsor-genehmigt (Am häufigsten)​

Dies ist das Standardmodell, das für die überwiegende Mehrheit der In-dApp-Interaktionen geeignet ist.

1. Benutzer erstellt GasLessTransactionData: Der Benutzer führt eine Aktion innerhalb der dApp aus.
2. Sponsor fügt GasData hinzu und signiert: Das dApp-Backend sendet die Transaktion an die Gas Station, die sie genehmigt, einen Gas Coin anhängt und ihre Signatur hinzufügt.
3. Benutzer überprüft und gibt endgültige Signatur: Der Benutzer bestätigt die endgültigen Transaktionsdetails in seiner Wallet und signiert sie. Die dApp übermittelt sie dann an das Netzwerk.

Dieses Modell bietet eine hervorragende Balance zwischen Sicherheit und Benutzererfahrung.

Modell 2: Sponsor-initiierte Airdrops/Anreize​

Dieses Modell ist perfekt für Airdrops, Benutzeranreize oder die Verteilung von Vermögenswerten in Batches.

1. Sponsor füllt TransactionData vorab aus + signiert: Der Sponsor (typischerweise das Projektteam) konstruiert den Großteil der Transaktion vorab (z. B. das Airdroppen eines NFT an eine bestimmte Adresse) und fügt seine Sponsoring-Signatur hinzu.
2. Die zweite Signatur des Benutzers macht sie wirksam: Der Benutzer muss diese „vorab genehmigte“ Transaktion nur einmal signieren, damit sie ausgeführt wird.

Dies schafft ein extrem reibungsloses Benutzererlebnis. Mit nur einem Klick zur Bestätigung können Benutzer Belohnungen beanspruchen oder Aufgaben erledigen, was die Konversionsraten von Marketingkampagnen drastisch erhöht.

Modell 3: Wildcard GasData (Kreditlinienmodell)​

Dies ist ein flexibleres und berechtigungsbasiertes Modell.

1. Sponsor überträgt ein GasData-Objekt: Der Sponsor erstellt zunächst ein oder mehrere Gas-Coin-Objekte mit einem bestimmten Budget und überträgt das Eigentum direkt an den Benutzer.
2. Benutzer gibt innerhalb des Budgets frei aus: Der Benutzer kann diese Gas Coins dann frei verwenden, um beliebige Transaktionen zu bezahlen, die er innerhalb der Budgetgrenzen und des Gültigkeitszeitraums initiiert.
3. Gas Coin wird zurückgegeben: Sobald der Gas Coin aufgebraucht oder abgelaufen ist, kann das Gas-Coin-Objekt so konzipiert werden, dass es automatisch zerstört oder an den Sponsor zurückgegeben wird.

Dieses Modell entspricht der Vergabe einer „Gasgebühren-Kreditkarte“ mit begrenzter Laufzeit und begrenztem Budget an den Benutzer, geeignet für Szenarien, die ein hohes Maß an Benutzerautonomie erfordern, wie z. B. das Anbieten eines Free-to-Play-Erlebnisses während einer Spielsaison.

4. Typische Anwendungsszenarien​

Die Stärke des Sui Paymasters liegt nicht nur in der Lösung des Gasgebührenproblems, sondern auch in seiner Fähigkeit, sich tief in die Geschäftslogik zu integrieren, um neue Möglichkeiten zu schaffen.

Szenario 1: Paywalls​

Viele Content-Plattformen oder dApp-Dienste erfordern, dass Benutzer bestimmte Kriterien erfüllen (z. B. ein VIP-NFT besitzen, ein bestimmtes Mitgliedschaftsniveau erreichen), um auf Funktionen zugreifen zu können. Der Paymaster kann diese Logik perfekt implementieren.

• Ablauf: Ein Benutzer fordert eine Aktion an → das dApp-Backend überprüft die Qualifikationen des Benutzers (z. B. NFT-Besitz) → wenn berechtigt, ruft es den Paymaster auf, um die Gasgebühr zu sponsern; wenn nicht, lehnt es die Signaturanfrage einfach ab.
• Vorteil: Dieses Modell ist von Natur aus resistent gegen Bots und Missbrauch. Da die Sponsoring-Entscheidung im Backend getroffen wird, können böswillige Benutzer die Qualifikationsprüfung nicht umgehen, um Gasgelder abzuschöpfen.

Szenario 2: Ein-Klick-Kaufabwicklung​

In E-Commerce- oder In-Game-Kaufszenarien ist die Vereinfachung des Zahlungsprozesses entscheidend.

• Ablauf: Der Benutzer klickt auf einer Checkout-Seite auf „Jetzt kaufen“. Die dApp erstellt eine Transaktion, die die Geschäftslogik (z. B. transfer_nft_to_user) enthält. Der Benutzer muss nur signieren, um die Geschäftstransaktion in seiner Wallet zu genehmigen, ohne sich um Gas kümmern zu müssen. Die Gasgebühr wird vom Sponsor der dApp übernommen.
• Vorteil: Sie können Geschäftsparameter wie eine order_id direkt in den ProgrammableTransactionBlock kodieren, was eine präzise On-Chain-Zuordnung für Backend-Bestellungen ermöglicht.

Szenario 3: Datenzuordnung​

Eine genaue Datenverfolgung ist grundlegend für die Geschäftsoptimierung.

• Ablauf: Beim Erstellen der Transaktion schreiben Sie einen eindeutigen Bezeichner (wie einen order_hash) in die Parameter der Transaktion oder in ein Ereignis, das bei der Ausführung ausgegeben wird.
• Vorteil: Wenn die Gas Station den On-Chain-Beleg für eine erfolgreiche Transaktion erhält, kann sie diesen order_hash leicht extrahieren, indem sie die Ereignis- oder Transaktionsdaten parst. Dies ermöglicht eine präzise Zuordnung zwischen On-Chain-Statusänderungen und spezifischen Backend-Bestellungen oder Benutzeraktionen.

5. Code-Grundgerüst (Basierend auf dem Rust SDK)​

Hier ist ein vereinfachtes Code-Snippet, das die Kerninteraktionsschritte demonstriert.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

Für eine vollständige Implementierung verweisen wir auf das Gas Station Tutorial in der offiziellen Sui-Dokumentation, das sofort einsatzbereite Codebeispiele bietet.

6. Risiken und Schutz​

Obwohl leistungsstark, erfordert der Einsatz einer Gas Station in einer Produktionsumgebung eine sorgfältige Abwägung der folgenden Risiken:

• Äquivokation (Double-Spending): Ein böswilliger Benutzer könnte versuchen, denselben Gas Coin für mehrere Transaktionen parallel zu verwenden, was dazu führen würde, dass der Gas Coin vom Sui-Netzwerk gesperrt wird. Dies kann effektiv gemildert werden, indem jedem Benutzer oder jeder Transaktion ein eindeutiger Gas Coin zugewiesen, eine Blacklist geführt und Signaturanfragen ratenbegrenzt werden.
• Gas-Pool-Management: In Szenarien mit hoher Parallelität kann ein einzelner Gas Coin mit hohem Wert zu einem Leistungsengpass werden. Der Gas Station-Dienst muss in der Lage sein, große SUI-Coins automatisch in viele kleinere Gas Coins aufzuteilen und diese nach Gebrauch effizient zurückzugewinnen. Professionelle Gas Station-Anbieter wie Shinami bieten ausgereifte, verwaltete Lösungen hierfür an.
• Autorisierung und Ratenbegrenzung: Sie müssen strenge Autorisierungs- und Ratenbegrenzungsrichtlinien festlegen. Verwalten Sie beispielsweise Sponsoring-Limits und -Häufigkeiten basierend auf Benutzer-IP, Wallet-Adresse oder API-Tokens, um zu verhindern, dass der Dienst von böswilligen Akteuren geleert wird.

7. Ökosystem-Tools​

Das Sui-Ökosystem bietet bereits eine Vielzahl von Tools, um die Entwicklung und Bereitstellung von Paymastern zu vereinfachen:

• Offizielle SDKs (Rust/TypeScript): Enthalten High-Level-APIs wie sponsor_transaction_block(), was die Integrationskomplexität erheblich reduziert.
• Shinami Gas Station: Bietet einen All-in-One-Managed-Service, einschließlich automatischer Gas-Coin-Aufteilung/-Rückgewinnung, detaillierter Metriküberwachung und Webhook-Benachrichtigungen, sodass sich Entwickler auf die Geschäftslogik konzentrieren können.
• Enoki / Mysten Demos: Die Community und Mysten Labs stellen auch Open-Source-Paymaster-Implementierungen bereit, die als Referenz für den Aufbau Ihres eigenen Dienstes verwendet werden können.

8. Implementierungs-Checkliste​

Bereit, Ihre dApp in die gas-lose Ära zu bringen? Gehen Sie diese Checkliste durch, bevor Sie beginnen:

• Planen Sie Ihren Finanzierungsfluss: Definieren Sie die Finanzierungsquelle, das Budget und die Nachschubstrategie des Sponsors. Richten Sie Überwachung und Warnmeldungen für Schlüsselmetriken (z. B. Gas-Pool-Guthaben, Verbrauchsrate) ein.
• Reservieren Sie Attributionsfelder: Achten Sie bei der Gestaltung Ihrer Transaktionsparameter darauf, Felder für Geschäftsbezeichner wie order_id oder user_id zu reservieren.
• Implementieren Sie Anti-Missbrauchsrichtlinien: Sie müssen strenge Autorisierungs-, Ratenbegrenzungs- und Protokollierungsmechanismen implementieren, bevor Sie live gehen.
• Proben auf dem Testnet: Egal, ob Sie Ihren eigenen Dienst aufbauen oder eine Drittanbieter-Gas Station integrieren, führen Sie immer zuerst gründliche Parallelitäts- und Stresstests auf einem Testnet oder Devnet durch.
• Kontinuierlich optimieren: Verfolgen Sie nach dem Start kontinuierlich die Transaktionserfolgsraten, Fehlerursachen und Gaskosten. Passen Sie Ihr Budget und Ihre Strategien basierend auf den Daten an.

Fazit​

Der Sui Paymaster (Gas Station) ist mehr als nur ein Tool zur Deckung der Gasgebühren von Benutzern. Es ist ein leistungsstarkes Paradigma, das ein „Zero SUI On-Chain“-Benutzererlebnis elegant mit dem geschäftlichen Bedürfnis nach „On-Chain-Attribution auf Bestellebene“ innerhalb einer einzigen, atomaren Transaktion kombiniert. Es ebnet Web2-Benutzern den Weg in Web3 und bietet Entwicklern eine beispiellose Flexibilität für die Geschäftsanpassung.

Mit einem zunehmend ausgereiften Ökosystem von Tools und den derzeit niedrigen Gaskosten im Sui-Netzwerk war es noch nie eine bessere Zeit, die Zahlungs- und Interaktionsflüsse Ihrer dApp in die gas-lose Ära zu bringen.

Wir freuen uns, die Einführung des SUI-Token-Stakings auf BlockEden.xyz bekannt zu geben! Ab heute können Sie Ihre SUI-Token direkt über unsere Plattform staken und einen APY von 2,08 % verdienen, während Sie die Sicherheit und Dezentralisierung des SUI-Netzwerks unterstützen.

Was ist neu: Ein nahtloses SUI-Staking-Erlebnis​

Unsere neue Staking-Funktion macht institutionelles Staking für jedermann zugänglich, mit einer einfachen, intuitiven Benutzeroberfläche, die das Verdienen von Belohnungen mühelos macht.

Hauptmerkmale​

Ein-Klick-Staking SUI zu staken war noch nie so einfach. Verbinden Sie einfach Ihre Suisplash-Wallet, geben Sie den gewünschten SUI-Betrag ein und bestätigen Sie die Transaktion. Sie beginnen fast sofort, Belohnungen zu verdienen, ohne komplexe Prozeduren.

Wettbewerbsfähige Belohnungen Verdienen Sie einen wettbewerbsfähigen APY von 2,08 % auf Ihre gestakten SUI. Unsere 8 % Kommission ist transparent, sodass Sie genau wissen, was Sie erwartet. Belohnungen werden täglich nach Abschluss jeder Epoche ausgeschüttet.

Vertrauenswürdiger Validator Werden Sie Teil einer wachsenden Community, die bereits über 22 Millionen SUI mit dem BlockEden.xyz-Validator gestaket hat. Wir verfügen über eine nachweisliche Erfolgsbilanz zuverlässiger Validierungsdienste, unterstützt durch eine Infrastruktur auf Unternehmensniveau, die eine 99,9 %ige Verfügbarkeit gewährleistet.

Flexibles Management Ihre Assets bleiben flexibel. Staking ist sofortig, was bedeutet, dass Ihre Belohnungen sofort zu akkumulieren beginnen. Sollten Sie auf Ihre Gelder zugreifen müssen, können Sie den Unstaking-Prozess jederzeit einleiten. Ihre SUI werden nach der standardmäßigen SUI-Netzwerk-Unbonding-Periode von 24-48 Stunden verfügbar sein. Sie können Ihre Stakes und Belohnungen in Echtzeit über unser Dashboard verfolgen.

Warum SUI mit BlockEden.xyz staken?​

Die Wahl eines Validators ist eine entscheidende Entscheidung. Hier erfahren Sie, warum BlockEden.xyz eine gute Wahl für Ihre Staking-Bedürfnisse ist.

Zuverlässigkeit, der Sie vertrauen können​

BlockEden.xyz ist seit unserer Gründung ein Eckpfeiler der Blockchain-Infrastruktur. Unsere Validator-Infrastruktur versorgt Unternehmensanwendungen und hat eine außergewöhnliche Verfügbarkeit über mehrere Netzwerke hinweg aufrechterhalten, wodurch eine konsistente Belohnungsgenerierung gewährleistet ist.

Transparent & Fair​

Wir glauben an vollständige Transparenz. Es gibt keine versteckten Gebühren – nur eine klare 8 % Kommission auf die Belohnungen, die Sie verdienen. Sie können Ihre Staking-Performance mit Echtzeit-Berichten überwachen und die Aktivität unseres Validators On-Chain überprüfen.

• Offene Validator-Adresse: 0x3b5664bb0f8bb4a8be77f108180a9603e154711ab866de83c8344ae1f3ed4695

Nahtlose Integration​

Unsere Plattform ist auf Einfachheit ausgelegt. Es ist keine Kontoerstellung erforderlich; Sie können direkt von Ihrer Wallet aus staken. Das Erlebnis ist für die Suisplash-Wallet optimiert, und unsere saubere, intuitive Benutzeroberfläche ist sowohl für Anfänger als auch für Experten konzipiert.

So fangen Sie an​

Der Einstieg ins SUI-Staking auf BlockEden.xyz dauert weniger als zwei Minuten.

Schritt 1: Besuchen Sie die Staking-Seite​

Navigieren Sie zu blockeden.xyz/dash/stake. Sie können den Prozess sofort ohne Registrierung eines Kontos beginnen.

Schritt 2: Verbinden Sie Ihre Wallet​

Falls Sie sie noch nicht haben, installieren Sie die Suisplash-Wallet. Klicken Sie auf der Staking-Seite auf die Schaltfläche "Wallet verbinden" und bestätigen Sie die Verbindung in der Wallet-Erweiterung. Ihr SUI-Guthaben wird automatisch angezeigt.

Schritt 3: Wählen Sie Ihren Stake-Betrag​

Geben Sie den Betrag an SUI ein, den Sie staken möchten (mindestens 1 SUI). Sie können die Schaltfläche "MAX" verwenden, um bequem Ihr gesamtes verfügbares Guthaben zu staken und einen kleinen Betrag für Gasgebühren zu belassen. Eine Zusammenfassung zeigt Ihren Stake-Betrag und die geschätzten jährlichen Belohnungen.

Schritt 4: Bestätigen & Verdienen Sie​

Klicken Sie auf "SUI staken" und bestätigen Sie die finale Transaktion in Ihrer Wallet. Ihr neuer Stake wird in Echtzeit auf dem Dashboard angezeigt, und Sie beginnen sofort, Belohnungen zu akkumulieren.

Staking-Ökonomie: Was Sie wissen müssen​

Das Verständnis der Staking-Mechanismen ist entscheidend für die effektive Verwaltung Ihrer Assets.

Belohnungsstruktur​

• Basis-APY: 2,08 % jährlich
• Belohnungsfrequenz: Jede Epoche (ca. 24 Stunden) ausgeschüttet
• Kommission: 8 % der verdienten Belohnungen
• Zinseszinseffekt: Belohnungen werden Ihrer Wallet hinzugefügt und können erneut gestaket werden, um einen Zinseszinseffekt zu erzielen.

Beispiel-Einnahmen​

Hier ist eine einfache Aufschlüsselung der potenziellen Einnahmen basierend auf einem APY von 2,08 %, nach Abzug der 8 % Kommission.

Hinweis: Dies sind Schätzungen. Die tatsächlichen Belohnungen können je nach Netzwerkbedingungen variieren.

Risikobetrachtungen​

Staking birgt bestimmte Risiken, derer Sie sich bewusst sein sollten:

• Unbonding-Periode: Wenn Sie unstaken, unterliegen Ihre SUI einer 24-48-stündigen Unbonding-Periode, in der sie unzugänglich sind und keine Belohnungen verdienen.
• Validator-Risiko: Obwohl wir hohe Standards aufrechterhalten, birgt jeder Validator operationelle Risiken. Die Wahl eines seriösen Validators wie BlockEden.xyz ist wichtig.
• Netzwerkrisiko: Staking ist eine Form der Netzwerkbeteiligung und unterliegt den inhärenten Risiken des zugrunde liegenden Blockchain-Protokolls.
• Marktrisiko: Der Marktwert des SUI-Tokens kann schwanken, was den Gesamtwert Ihrer gestakten Assets beeinflusst.

Technische Exzellenz​

Unternehmensinfrastruktur​

Unsere Validator-Nodes basieren auf einem Fundament technischer Exzellenz. Wir nutzen redundante Systeme, die über mehrere geografische Regionen verteilt sind, um eine hohe Verfügbarkeit zu gewährleisten. Unsere Infrastruktur wird rund um die Uhr überwacht, verfügt über automatisierte Failover-Funktionen und wird von einem professionellen Betriebsteam Tag und Nacht verwaltet. Wir führen außerdem regelmäßige Sicherheitsaudits und Compliance-Prüfungen durch.

Open Source & Transparenz​

Wir bekennen uns zu den Prinzipien von Open Source. Unsere Staking-Integration ist transparent aufgebaut, sodass Benutzer die zugrunde liegenden Prozesse überprüfen können. Echtzeit-Metriken sind auf SUI-Netzwerk-Explorern öffentlich verfügbar, und unsere Gebührenstruktur ist vollständig offen, ohne versteckte Kosten. Wir beteiligen uns auch aktiv an der Community-Governance, um das SUI-Ökosystem zu unterstützen.

Unterstützung des SUI-Ökosystems​

Indem Sie mit BlockEden.xyz staken, tun Sie mehr als nur Belohnungen zu verdienen. Sie tragen aktiv zur Gesundheit und zum Wachstum des gesamten SUI-Netzwerks bei.

• Netzwerksicherheit: Ihr Stake erhöht den Gesamtbetrag, der das SUI-Netzwerk sichert, und macht es robuster gegen potenzielle Angriffe.
• Dezentralisierung: Die Unterstützung unabhängiger Validatoren wie BlockEden.xyz erhöht die Widerstandsfähigkeit des Netzwerks und verhindert Zentralisierung.
• Ökosystem-Wachstum: Die von uns verdienten Provisionsgebühren werden in die Wartung und Entwicklung kritischer Infrastruktur reinvestiert.
• Innovation: Einnahmen unterstützen unsere Forschung und Entwicklung neuer Tools und Dienste für die Blockchain-Community.

Sicherheit & Best Practices​

Bitte priorisieren Sie die Sicherheit Ihrer Assets.

Wallet-Sicherheit​

• Teilen Sie niemals Ihre privaten Schlüssel oder Seed-Phrase mit jemandem.
• Verwenden Sie eine Hardware-Wallet zum Speichern und Staken großer Beträge.
• Überprüfen Sie immer die Transaktionsdetails in Ihrer Wallet, bevor Sie unterschreiben.
• Halten Sie Ihre Wallet-Software auf dem neuesten Stand.

Staking-Sicherheit​

• Wenn Sie neu im Staking sind, beginnen Sie mit einem kleinen Betrag, um sich mit dem Prozess vertraut zu machen.
• Erwägen Sie, Ihren Stake auf mehrere seriöse Validatoren zu diversifizieren, um das Risiko zu reduzieren.
• Überwachen Sie regelmäßig Ihre gestakten Assets und Belohnungen.
• Stellen Sie sicher, dass Sie die Unbonding-Periode verstehen, bevor Sie Ihre Gelder festlegen.

Werden Sie Teil der Zukunft des SUI-Stakings​

Die Einführung des SUI-Stakings auf BlockEden.xyz ist mehr als nur eine neue Funktion; es ist ein Tor zur aktiven Teilnahme an der dezentralen Wirtschaft. Egal, ob Sie ein erfahrener DeFi-Benutzer sind oder gerade erst Ihre Reise beginnen, unsere Plattform bietet eine einfache und sichere Möglichkeit, Belohnungen zu verdienen und gleichzeitig zur Zukunft des SUI-Netzwerks beizutragen.

Bereit, mit dem Verdienen zu beginnen?

Besuchen Sie blockeden.xyz/dash/stake und staken Sie noch heute Ihre ersten SUI-Token!

Über BlockEden.xyz​

BlockEden.xyz ist ein führender Anbieter von Blockchain-Infrastruktur, der Entwicklern, Unternehmen und der gesamten Web3-Community zuverlässige, skalierbare und sichere Dienste anbietet. Von API-Diensten bis hin zu Validator-Operationen setzen wir uns dafür ein, das Fundament für eine dezentrale Zukunft zu legen.

• Gegründet: 2021
• Unterstützte Netzwerke: Über 15 Blockchain-Netzwerke
• Unternehmenskunden: Über 500 Unternehmen weltweit
• Gesamtwert gesichert: Über 100 Mio. USD über alle Netzwerke hinweg

Folgen Sie uns auf Twitter, treten Sie unserem Discord bei und entdecken Sie unser gesamtes Dienstleistungsangebot auf BlockEden.xyz.

Haftungsausschluss: Dieser Blogbeitrag dient ausschließlich zu Informationszwecken und stellt keine Finanzberatung dar. Das Staking von Kryptowährungen birgt Risiken, einschließlich des potenziellen Verlusts des Kapitals. Bitte führen Sie Ihre eigene Recherche durch und berücksichtigen Sie Ihre Risikobereitschaft, bevor Sie staken.

Einführung​

Dezentrale KI-Inferenz-/Trainingsmärkte zielen darauf ab, globale Rechenressourcen und Community-Modelle auf vertrauenslose Weise zu nutzen. Projekte wie Bittensor, Gensyn und Cuckoo Network (Cuckoo AI) veranschaulichen, wie Blockchain-Technologie offene KI-Marktplätze antreiben kann. Jede Plattform tokenisiert wichtige KI-Assets – Rechenleistung, Machine-Learning-Modelle und manchmal auch Daten – in On-Chain-Wirtschaftseinheiten. Im Folgenden gehen wir auf die technischen Architekturen dieser Netzwerke ein, wie sie Ressourcen tokenisieren, ihre Governance- und Anreizstrukturen, Methoden zur Verfolgung des Modelleigentums, Umsatzbeteiligungsmechanismen und die Angriffsflächen (z. B. Sybil-Angriffe, Kollusion, Trittbrettfahren, Vergiftung), die dabei entstehen. Eine vergleichende Tabelle am Ende fasst alle wichtigen Dimensionen von Bittensor, Gensyn und Cuckoo AI zusammen.

Technische Architekturen​

Bittensor: Dezentrales „Neuronales Internet“ auf Subnetzen​

Bittensor basiert auf einer benutzerdefinierten Layer-1-Blockchain (der Subtensor-Kette, basierend auf Substrate), die ein Netzwerk von KI-Modellknoten über viele spezialisierte Subnetze koordiniert. Jedes Subnetz ist ein unabhängiges Mini-Netzwerk, das sich auf eine bestimmte KI-Aufgabe konzentriert (zum Beispiel ein Subnetz für Sprachgenerierung, ein anderes für Bildgenerierung usw.). Die Teilnehmer in Bittensor übernehmen unterschiedliche Rollen:

• Miner – Sie betreiben Machine-Learning-Modelle auf ihrer Hardware und liefern Inferenzantworten (oder führen sogar Trainings durch) für die Aufgabe des Subnetzes. Im Wesentlichen ist ein Miner ein Knoten, der ein KI-Modell hostet, das Anfragen beantwortet.
• Validatoren – Sie fragen die Modelle der Miner mit Prompts ab und bewerten die Qualität der Antworten, um eine Meinung darüber zu bilden, welche Miner wertvolle Ergebnisse liefern. Validatoren bewerten effektiv die Leistung der Miner.
• Subnetz-Besitzer – Sie erstellen und definieren Subnetze und legen die Regeln fest, welche Aufgaben erledigt werden und wie die Validierung in diesem Subnetz durchgeführt wird. Ein Subnetz-Besitzer könnte zum Beispiel festlegen, dass ein Subnetz für einen bestimmten Datensatz oder eine bestimmte Modalität bestimmt ist und das Validierungsverfahren definieren.
• Delegatoren – Token-Inhaber, die keine Knoten betreiben, können ihre Bittensor-Tokens (TAO) an Miner oder Validatoren delegieren (staken), um die besten Performer zu unterstützen und einen Anteil an den Belohnungen zu verdienen (ähnlich dem Staking in Proof-of-Stake-Netzwerken).

Der Konsensmechanismus von Bittensor ist neuartig: Anstelle der traditionellen Blockvalidierung verwendet Bittensor den Yuma-Konsens, eine Form des „Proof-of-Intelligence“. Im Yuma-Konsens werden die Bewertungen der Miner durch Validatoren On-Chain aggregiert, um die Belohnungsverteilung zu bestimmen. Alle 12 Sekunden prägt das Netzwerk neue TAO-Tokens und verteilt sie gemäß dem Konsens der Validatoren darüber, welche Miner nützliche Arbeit geleistet haben. Die Bewertungen der Validatoren werden in einem stake-gewichteten Median-Schema kombiniert: Ausreißermeinungen werden beschnitten und die ehrliche Mehrheitsmeinung setzt sich durch. Das bedeutet, wenn die meisten Validatoren zustimmen, dass ein Miner qualitativ hochwertig war, erhält dieser Miner eine hohe Belohnung; weicht ein Validator stark von anderen ab (möglicherweise aufgrund von Kollusion oder Fehler), wird dieser Validator bestraft, indem er weniger verdient. Auf diese Weise koordiniert die Blockchain von Bittensor eine Miner-Validator-Feedbackschleife: Miner konkurrieren darum, die besten KI-Outputs zu produzieren, und Validatoren kuratieren und bewerten diese Outputs, wobei beide Seiten Tokens proportional zum von ihnen hinzugefügten Wert verdienen. Diese Architektur wird oft als „dezentrales neuronales Netzwerk“ oder „globales Gehirn“ beschrieben, in dem Modelle voneinander lernen und sich kollektiv entwickeln. Bemerkenswert ist, dass Bittensor kürzlich seine Kette aktualisiert hat, um EVM-Kompatibilität (für Smart Contracts) zu unterstützen, und dTAO eingeführt hat, ein System von Subnetz-spezifischen Tokens und Staking (später erklärt), um die Kontrolle über die Ressourcenzuweisung weiter zu dezentralisieren.

Gensyn: Vertrauensloses verteiltes Rechenprotokoll​

Gensyn nähert sich dezentraler KI aus dem Blickwinkel eines verteilten Rechenprotokolls für Machine Learning. Seine Architektur verbindet Entwickler (Submitter), die KI-Aufgaben haben (wie das Trainieren eines Modells oder das Ausführen eines Inferenz-Jobs), mit Rechenanbietern (Solver) weltweit, die über freie GPU-/TPU-Ressourcen verfügen. Ursprünglich plante Gensyn eine Substrate L1-Kette, schwenkte aber auf den Bau auf Ethereum als Rollup um, um stärkere Sicherheit und Liquidität zu gewährleisten. Das Gensyn-Netzwerk ist somit ein Ethereum Layer-2 (ein Ethereum-Rollup), das Job-Anzeigen und Zahlungen koordiniert, während die Berechnung Off-Chain auf der Hardware der Anbieter stattfindet.

Eine Kerninnovation des Gensyn-Designs ist sein Verifizierungssystem für Off-Chain-Arbeit. Gensyn verwendet eine Kombination aus optimistischer Verifizierung (Fraud Proofs) und kryptografischen Techniken, um sicherzustellen, dass das Ergebnis korrekt ist, wenn ein Solver behauptet, eine Trainings-/Inferenzaufgabe ausgeführt zu haben. In der Praxis umfasst das Protokoll mehrere Teilnehmerrollen:

• Submitter – die Partei, die einen Job anfordert (zum Beispiel jemand, der ein Modell trainieren lassen muss). Sie zahlen die Netzwerkgebühr und stellen das Modell/die Daten oder die Spezifikation der Aufgabe bereit.
• Solver – ein Knoten, der für die ML-Aufgabe auf seiner Hardware bietet und diese ausführt. Er trainiert das Modell oder führt die Inferenz wie angefordert aus und übermittelt dann die Ergebnisse und einen Berechnungsnachweis.
• Verifier/Challenger – Knoten, die die Arbeit des Solvers prüfen oder stichprobenartig überprüfen können. Gensyn implementiert ein Truebit-ähnliches Schema, bei dem das Ergebnis eines Solvers standardmäßig akzeptiert wird, ein Verifier es jedoch innerhalb eines Zeitfensters anfechten kann, wenn er eine falsche Berechnung vermutet. Bei einer Anfechtung wird eine interaktive „binäre Suche“ durch die Berechnungsschritte (ein Fraud-Proof-Protokoll) verwendet, um jede Diskrepanz zu lokalisieren. Dies ermöglicht es der Kette, Streitigkeiten zu lösen, indem nur ein minimaler kritischer Teil der Berechnung On-Chain durchgeführt wird, anstatt die gesamte teure Aufgabe zu wiederholen.

Entscheidend ist, dass Gensyn so konzipiert ist, dass die massive Redundanz naiver Ansätze vermieden wird. Anstatt dass viele Knoten alle denselben ML-Job wiederholen (was Kosteneinsparungen zunichte machen würde), verwendet Gensyns „Proof-of-Learning“-Ansatz Trainingsmetadaten, um zu überprüfen, ob Lernfortschritte erzielt wurden. Zum Beispiel könnte ein Solver kryptografische Hashes oder Checkpoints von Zwischenmodellgewichten und einen prägnanten Nachweis liefern, dass diese gemäß den Trainingsaktualisierungen fortgeschritten sind. Dieser probabilistische Proof-of-Learning kann viel kostengünstiger überprüft werden als das erneute Ausführen des gesamten Trainings, was eine vertrauenslose Verifizierung ohne vollständige Replikation ermöglicht. Nur wenn ein Verifier eine Anomalie feststellt, würde als letztes Mittel eine aufwändigere On-Chain-Berechnung ausgelöst. Dieser Ansatz reduziert den Overhead im Vergleich zur Brute-Force-Verifizierung drastisch, wodurch dezentrales ML-Training praktikabler wird. Gensyns Architektur betont daher stark das kryptoökonomische Spieldesign: Solver hinterlegen einen Stake oder eine Anleihe, und wenn sie betrügen (falsche Ergebnisse einreichen), verlieren sie diesen Stake an ehrliche Verifier, die sie erwischen. Durch die Kombination von Blockchain-Koordination (für Zahlungen und Streitbeilegung) mit Off-Chain-Compute und cleverer Verifizierung schafft Gensyn einen Marktplatz für ML-Compute, der ungenutzte GPUs überall nutzen kann, während die Vertrauenslosigkeit erhalten bleibt. Das Ergebnis ist ein Hyperscale-„Compute-Protokoll“, bei dem jeder Entwickler bei Bedarf auf erschwingliche, global verteilte Trainingsleistung zugreifen kann.

Cuckoo AI: Full-Stack dezentrale KI-Serviceplattform​

Cuckoo Network (oder Cuckoo AI) verfolgt einen stärker vertikal integrierten Ansatz und zielt darauf ab, End-to-End dezentrale KI-Dienste anstatt nur rohe Rechenleistung bereitzustellen. Cuckoo baute seine eigene Blockchain (ursprünglich eine Layer-1 namens Cuckoo Chain auf Arbitrum Orbit, einem Ethereum-kompatiblen Rollup-Framework), um alles zu orchestrieren: Sie gleicht nicht nur Jobs mit GPUs ab, sondern hostet auch KI-Anwendungen und wickelt Zahlungen in einem System ab. Das Design ist Full-Stack: Es kombiniert eine Blockchain für Transaktionen und Governance, eine dezentrale GPU-/CPU-Ressourcenschicht und benutzerorientierte KI-Anwendungen und APIs darüber. Mit anderen Worten, Cuckoo integriert alle drei Schichten – Blockchain, Compute und KI-Anwendung – innerhalb einer einzigen Plattform.

Die Teilnehmer in Cuckoo lassen sich in vier Gruppen einteilen:

• KI-App-Entwickler (Koordinatoren) – Dies sind Entwickler, die KI-Modelle oder -Dienste auf Cuckoo bereitstellen. Zum Beispiel könnte ein Entwickler einen Stable Diffusion Bildgenerator oder einen LLM-Chatbot als Dienst hosten. Sie betreiben Koordinator-Knoten, die für die Verwaltung ihres Dienstes verantwortlich sind: Benutzeranfragen annehmen, diese in Aufgaben aufteilen und diese Aufgaben den Minern zuweisen. Koordinatoren staken den nativen Token ($CAI), um dem Netzwerk beizutreten und das Recht zu erhalten, Miner zu nutzen. Sie fungieren im Wesentlichen als Layer-2-Orchestratoren, die zwischen Benutzern und den GPU-Anbietern vermitteln.
• GPU-/CPU-Miner (Aufgabenknoten) – Dies sind die Ressourcenanbieter. Miner betreiben den Cuckoo-Aufgabenclient und stellen ihre Hardware zur Verfügung, um Inferenzaufgaben für die KI-Apps auszuführen. Zum Beispiel könnte einem Miner von einem Koordinator eine Bildgenerierungsanfrage (mit einem bestimmten Modell und Prompt) zugewiesen werden, und er verwendet seine GPU, um das Ergebnis zu berechnen. Miner müssen ebenfalls $CAI staken, um Engagement und gutes Verhalten zu gewährleisten. Sie verdienen Token-Belohnungen für jede korrekt abgeschlossene Aufgabe.
• Endbenutzer – die Konsumenten der KI-Anwendungen. Sie interagieren über Cuckoos Webportal oder APIs (zum Beispiel Kunst generieren über CooVerse oder mit KI-Persönlichkeiten chatten). Benutzer können entweder mit Krypto für jede Nutzung bezahlen oder möglicherweise ihre eigene Rechenleistung (oder ihren Stake) beisteuern, um die Nutzungskosten auszugleichen. Ein wichtiger Aspekt ist die Zensurresistenz: Wenn ein Koordinator (Dienstanbieter) blockiert wird oder ausfällt, können Benutzer zu einem anderen wechseln, der dieselbe Anwendung bereitstellt, da mehrere Koordinatoren ähnliche Modelle im dezentralen Netzwerk hosten könnten.
• Staker (Delegatoren) – Community-Mitglieder, die keine KI-Dienste oder Mining-Hardware betreiben, können dennoch teilnehmen, indem sie $CAI auf diejenigen staken, die dies tun. Indem sie mit ihrem Stake auf vertrauenswürdige Koordinatoren oder Miner stimmen, helfen sie, Reputation zu signalisieren und verdienen im Gegenzug einen Anteil an den Netzwerkbelohnungen. Dieses Design baut eine Web3-Reputationsschicht auf: Gute Akteure ziehen mehr Stake an (und damit Vertrauen und Belohnungen), während schlechte Akteure Stake und Reputation verlieren. Sogar Endbenutzer können in einigen Fällen staken, wodurch sie mit dem Erfolg des Netzwerks in Einklang gebracht werden.

Die Cuckoo-Kette (die sich derzeit im Übergang von einer eigenständigen Kette zu einem Shared-Security-Rollup befindet) verfolgt all diese Interaktionen. Wenn ein Benutzer einen KI-Dienst aufruft, erstellt der Koordinator-Knoten On-Chain-Aufgabenzuweisungen für Miner. Die Miner führen die Aufgaben Off-Chain aus und senden die Ergebnisse an den Koordinator zurück, der sie validiert (z. B. überprüft, ob das Ausgabebild oder der Text kein Kauderwelsch ist) und das Endergebnis an den Benutzer liefert. Die Blockchain wickelt die Zahlungsabwicklung ab: Für jede Aufgabe zahlt der Smart Contract des Koordinators den Miner in $CAI (oft werden Mikrozahlungen zu täglichen Auszahlungen aggregiert). Cuckoo betont Vertrauenslosigkeit und Transparenz – alle Teilnehmer staken Tokens und alle Aufgabenzuweisungen und -abschlüsse werden aufgezeichnet, sodass Betrug durch die Androhung des Verlusts des Stakes und durch die öffentliche Sichtbarkeit der Leistung entmutigt wird. Das modulare Design des Netzwerks bedeutet, dass neue KI-Modelle oder Anwendungsfälle einfach hinzugefügt werden können: Obwohl es mit der Text-zu-Bild-Generierung als Proof of Concept begann, ist seine Architektur allgemein genug, um andere KI-Workloads (z. B. Sprachmodell-Inferenz, Audiotranskription usw.) zu unterstützen.

Ein bemerkenswerter Aspekt der Cuckoo-Architektur ist, dass sie ursprünglich eine eigene Layer-1-Blockchain startete, um den Durchsatz für KI-Transaktionen zu maximieren (während der Tests erreichte sie Spitzenwerte von 300.000 täglichen Transaktionen). Dies ermöglichte benutzerdefinierte Optimierungen für die KI-Aufgabenplanung. Das Team stellte jedoch fest, dass die Wartung einer eigenständigen L1 kostspielig und komplex war, und beschloss Mitte 2025, die benutzerdefinierte Kette einzustellen und zu einem Rollup-/AVS-Modell (Active Validated Service) auf Ethereum zu migrieren. Dies bedeutet, dass Cuckoo die Sicherheit von Ethereum oder einem L2 wie Arbitrum erben wird, anstatt einen eigenen Konsens zu betreiben, aber seinen dezentralen KI-Marktplatz auf dieser gemeinsamen Sicherheitsschicht weiter betreiben wird. Die Änderung soll die wirtschaftliche Sicherheit verbessern (durch Nutzung der Robustheit von Ethereum) und dem Cuckoo-Team ermöglichen, sich auf das Produkt statt auf die Wartung der Low-Level-Kette zu konzentrieren. Zusammenfassend schafft Cuckoos Architektur eine dezentrale KI-Bereitstellungsplattform, auf der jeder Hardware anschließen oder einen KI-Modell-Dienst bereitstellen kann und Benutzer weltweit auf KI-Apps mit geringeren Kosten und weniger Abhängigkeit von der Big-Tech-Infrastruktur zugreifen können.

Mechanismen zur Asset-Tokenisierung​

Ein gemeinsames Thema dieser Netzwerke ist die Umwandlung von Rechenleistung, Modellen und Daten in On-Chain-Assets oder Wirtschaftseinheiten, die gehandelt oder monetarisiert werden können. Jedes Projekt konzentriert sich jedoch auf unterschiedliche Weisen der Tokenisierung dieser Ressourcen:

• Rechenleistung: Alle drei Plattformen wandeln Rechenarbeit in Belohnungs-Tokens um. In Bittensor wird nützliche Berechnung (Inferenz oder Training durch einen Miner) über Validatoren-Scores quantifiziert und mit TAO-Tokens pro Block belohnt. Im Wesentlichen „misst“ Bittensor die beigesteuerte Intelligenz und prägt TAO als Ware, die diesen Beitrag repräsentiert. Gensyn behandelt Rechenleistung explizit als Ware – sein Protokoll schafft einen Marktplatz, auf dem GPU-Zeit das Produkt ist und der Preis durch Angebot und Nachfrage in Token-Begriffen festgelegt wird. Entwickler kaufen Rechenleistung mit dem Token, und Anbieter verdienen Tokens, indem sie ihre Hardware-Zyklen verkaufen. Das Gensyn-Team bemerkt, dass jede digitale Ressource (Rechenleistung, Daten, Algorithmen) in einem ähnlichen vertrauenslosen Markt dargestellt und gehandelt werden kann. Cuckoo tokenisiert Rechenleistung über einen ERC-20-Token $CAI, der als Zahlung für abgeschlossene Aufgaben ausgegeben wird. GPU-Anbieter „minen“ im Wesentlichen CAI, indem sie KI-Inferenzarbeit leisten. Cuckoos System erstellt On-Chain-Aufzeichnungen von Aufgaben, sodass man jede abgeschlossene GPU-Aufgabe als eine atomare Arbeitseinheit betrachten kann, die in Tokens bezahlt wird. Die Prämisse bei allen dreien ist, dass ansonsten ungenutzte oder unzugängliche Rechenleistung zu einem tokenisierten, liquiden Asset wird – entweder durch Token-Emissionen auf Protokollebene (wie bei Bittensor und frühem Cuckoo) oder durch einen offenen Markt von Kauf-/Verkaufsaufträgen für Rechenjobs (wie bei Gensyn).

• KI-Modelle: Die Darstellung von KI-Modellen als On-Chain-Assets (z. B. NFTs oder Tokens) steckt noch in den Kinderschuhen. Bittensor tokenisiert die Modelle selbst nicht – die Modelle bleiben Off-Chain im Besitz der Miner. Stattdessen bewertet Bittensor Modelle indirekt, indem es diejenigen belohnt, die gut funktionieren. Im Grunde wird die „Intelligenz“ eines Modells in TAO-Einnahmen umgewandelt, aber es gibt kein NFT, das die Modellgewichte repräsentiert oder anderen die Nutzung des Modells erlaubt. Gensyns Fokus liegt auf Rechen-Transaktionen, nicht explizit auf der Erstellung von Tokens für Modelle. Ein Modell in Gensyn wird typischerweise von einem Entwickler Off-Chain bereitgestellt (vielleicht Open-Source oder proprietär), von Solvern trainiert und zurückgegeben – es gibt keinen eingebauten Mechanismus, um einen Token zu erstellen, der das Modell oder sein IP besitzt. (Allerdings könnte der Gensyn-Marktplatz potenziell den Handel mit Modellartefakten oder Checkpoints erleichtern, wenn die Parteien dies wünschen, aber das Protokoll selbst betrachtet Modelle als Inhalt der Berechnung und nicht als tokenisiertes Asset.) Cuckoo liegt irgendwo dazwischen: Es spricht von „KI-Agenten“ und in das Netzwerk integrierten Modellen, aber derzeit gibt es keinen nicht-fungiblen Token, der jedes Modell repräsentiert. Stattdessen wird ein Modell von einem App-Entwickler bereitgestellt und dann über das Netzwerk bedient. Die Nutzungsrechte an diesem Modell sind implizit tokenisiert, da das Modell $CAI verdienen kann, wenn es verwendet wird (über den Koordinator, der es bereitstellt). Alle drei Plattformen erkennen das Konzept der Modell-Tokenisierung an – zum Beispiel, Gemeinschaften über Tokens Eigentum an Modellen zu geben – aber praktische Implementierungen sind begrenzt. Als Branche wird die Tokenisierung von KI-Modellen (z. B. als NFTs mit Eigentumsrechten und Gewinnbeteiligung) noch erforscht. Bittensors Ansatz, bei dem Modelle Werte miteinander austauschen, ist eine Form eines „Modell-Marktplatzes“ ohne expliziten Token pro Modell. Das Cuckoo-Team merkt an, dass dezentrales Modelleigentum vielversprechend ist, um Barrieren im Vergleich zu zentralisierter KI abzubauen, aber es erfordert effektive Methoden zur Überprüfung von Modellausgaben und -nutzung On-Chain. Zusammenfassend lässt sich sagen, dass Rechenleistung sofort tokenisiert wird (es ist unkompliziert, Tokens für geleistete Arbeit zu bezahlen), während Modelle indirekt oder aspirativ tokenisiert werden (für ihre Outputs belohnt, möglicherweise durch Stake oder Reputation repräsentiert, aber auf diesen Plattformen noch nicht als übertragbare NFTs behandelt werden).

• Daten: Die Daten-Tokenisierung bleibt am schwierigsten. Keines der Projekte Bittensor, Gensyn oder Cuckoo hat vollständig verallgemeinerte On-Chain-Datenmarktplätze integriert (wo Datensätze mit durchsetzbaren Nutzungsrechten gehandelt werden). Bittensor-Knoten könnten auf verschiedenen Datensätzen trainieren, aber diese Datensätze sind nicht Teil des On-Chain-Systems. Gensyn könnte einem Entwickler erlauben, einen Datensatz für das Training bereitzustellen, aber das Protokoll tokenisiert diese Daten nicht – sie werden einfach Off-Chain für den Solver bereitgestellt. Cuckoo tokenisiert ebenfalls keine Benutzerdaten; es verarbeitet Daten (wie Benutzer-Prompts oder Outputs) hauptsächlich transient für Inferenzaufgaben. Der Cuckoo-Blog stellt explizit fest, dass „dezentrale Daten trotz ihrer kritischen Bedeutung schwer zu tokenisieren bleiben“. Daten sind sensibel (Datenschutz- und Eigentumsfragen) und mit der aktuellen Blockchain-Technologie schwer zu handhaben. Während Rechenleistung und Modelle zunehmend zu Commodities werden, bleiben Daten weitgehend Off-Chain, außer in Sonderfällen (einige Projekte außerhalb dieser drei experimentieren mit Daten-Unions und Token-Belohnungen für Datenbeiträge, aber das liegt außerhalb unseres aktuellen Umfangs). Zusammenfassend lässt sich sagen, dass Rechenleistung in diesen Netzwerken jetzt eine On-Chain-Ware ist, Modelle durch Tokens bewertet, aber noch nicht individuell als Assets tokenisiert werden, und die Daten-Tokenisierung immer noch ein offenes Problem ist (abgesehen von der Anerkennung ihrer Bedeutung).

Governance und Anreize​

Ein robustes Governance- und Anreizdesign ist entscheidend, damit diese dezentralen KI-Netzwerke autonom und fair funktionieren können. Hier untersuchen wir, wie sich jede Plattform selbst regiert (wer Entscheidungen trifft, wie Upgrades oder Parameteränderungen erfolgen) und wie sie die Anreize der Teilnehmer durch Token-Ökonomie aufeinander abstimmt.

• Bittensor Governance: In seinen frühen Phasen wurden Bittensors Entwicklung und Subnetzparameter weitgehend vom Kernteam und einer Gruppe von 64 „Root“-Validatoren im Haupt-Subnetz kontrolliert. Dies war ein Punkt der Zentralisierung – einige mächtige Validatoren hatten einen überproportionalen Einfluss auf die Belohnungszuweisungen, was zu dem führte, was einige als „oligarchisches Wahlsystem“ bezeichneten. Um dies zu beheben, führte Bittensor 2025 die dTAO (dezentrale TAO)-Governance ein. Das dTAO-System verlagerte die Ressourcenzuweisung auf eine marktorientierte und gemeinschaftlich kontrollierte Basis. Konkret können TAO-Inhaber ihre Tokens in Subnetz-spezifische Liquiditätspools staken (im Wesentlichen „stimmen“ sie darüber ab, welche Subnetze mehr Netzwerkemissionen erhalten sollen) und erhalten Alpha-Tokens, die das Eigentum an diesen Subnetz-Pools repräsentieren. Subnetze, die mehr Stake anziehen, werden einen höheren Alpha-Token-Preis haben und einen größeren Anteil an der täglichen TAO-Emission erhalten, während unpopuläre oder leistungsschwache Subnetze Kapital (und damit Emissionen) abfließen sehen werden. Dies schafft eine Rückkopplungsschleife: Wenn ein Subnetz wertvolle KI-Dienste produziert, staken mehr Leute TAO darauf (auf der Suche nach Belohnungen), was diesem Subnetz mehr TAO gibt, um seine Teilnehmer zu belohnen, was das Wachstum fördert. Wenn ein Subnetz stagniert, ziehen Staker zu lukrativeren Subnetzen ab. Im Effekt regieren TAO-Inhaber kollektiv den Fokus des Netzwerks, indem sie finanziell signalisieren, welche KI-Domänen mehr Ressourcen verdienen. Dies ist eine Form der On-Chain-Governance nach Token-Gewichtung, ausgerichtet auf wirtschaftliche Ergebnisse. Abgesehen von der Ressourcenzuweisung erfolgen größere Protokoll-Upgrades oder Parameteränderungen wahrscheinlich immer noch über Governance-Vorschläge, über die TAO-Inhaber abstimmen (Bittensor verfügt über einen Mechanismus für On-Chain-Vorschläge und Referenden, die von der Bittensor Foundation und einem gewählten Rat verwaltet werden, ähnlich der Governance von Polkadot). Im Laufe der Zeit ist zu erwarten, dass Bittensors Governance zunehmend dezentralisiert wird, wobei die Stiftung zurücktritt, während die Community (über TAO-Stake) Dinge wie Inflationsrate, Genehmigung neuer Subnetze usw. steuert. Der Übergang zu dTAO ist ein großer Schritt in diese Richtung, der zentralisierte Entscheidungsträger durch einen anreizorientierten Markt von Token-Stakeholdern ersetzt.

• Bittensor-Anreize: Bittensors Anreizstruktur ist eng mit seinem Konsens verknüpft. Bei jedem Block (12 Sekunden) wird genau 1 TAO neu geprägt und basierend auf der Leistung unter den Mitwirkenden jedes Subnetzes aufgeteilt. Die Standardaufteilung für die Blockbelohnung jedes Subnetzes beträgt 41 % für Miner, 41 % für Validatoren und 18 % für den Subnetz-Besitzer. Dies stellt sicher, dass alle Rollen belohnt werden: Miner verdienen für Inferenzarbeit, Validatoren für ihre Bewertungsbemühungen und Subnetz-Besitzer (die möglicherweise die Daten/Aufgabe für dieses Subnetz gebootstrappt haben) erhalten einen Restbetrag für die Bereitstellung des „Marktplatzes“ oder des Aufgabendesigns. Diese Prozentsätze sind im Protokoll festgelegt und zielen darauf ab, die Anreize aller auf eine qualitativ hochwertige KI-Ausgabe auszurichten. Der Yuma-Konsensmechanismus verfeinert die Anreize weiter, indem er Belohnungen nach Qualitätsbewertungen gewichtet – ein Miner, der bessere Antworten liefert (gemäß Validatoren-Konsens), erhält einen höheren Anteil dieser 41 %, und ein Validator, der dem ehrlichen Konsens genau folgt, erhält mehr vom Validatorenanteil. Schlechte Performer werden wirtschaftlich aussortiert. Zusätzlich erhalten Delegatoren (Staker), die einen Miner oder Validator unterstützen, typischerweise einen Anteil an den Einnahmen dieses Knotens (Knoten legen oft eine Provision fest und geben den Rest an ihre Delegatoren weiter, ähnlich dem Staking in PoS-Netzwerken). Dies ermöglicht passiven TAO-Inhabern, die besten Mitwirkenden zu unterstützen und Erträge zu erzielen, was die Meritokratie weiter stärkt. Bittensors Token (TAO) ist somit ein Utility-Token: Er ist für die Registrierung neuer Miner erforderlich (Miner müssen einen kleinen Betrag an TAO ausgeben, um beizutreten, was Sybil-Spam bekämpft) und kann gestaked werden, um den Einfluss zu erhöhen oder über Delegation zu verdienen. Er ist auch als Zahlungstoken vorgesehen, wenn externe Benutzer Dienste aus Bittensors Netzwerk nutzen möchten (zum Beispiel TAO zahlen, um ein Sprachmodell auf Bittensor abzufragen), obwohl der interne Belohnungsmechanismus bisher die primäre „Ökonomie“ war. Die allgemeine Anreizphilosophie besteht darin, „wertvolle Intelligenz“ zu belohnen – d. h. Modelle, die gute KI-Ergebnisse liefern – und einen Wettbewerb zu schaffen, der die Qualität der Modelle im Netzwerk kontinuierlich verbessert.

• Gensyn Governance: Gensyns Governance-Modell ist so strukturiert, dass es sich mit der Reifung des Netzwerks von der Kontrolle durch das Kernteam zur Kontrolle durch die Community entwickelt. Zunächst wird Gensyn eine Gensyn Foundation und einen gewählten Rat haben, die Protokoll-Upgrades und Treasury-Entscheidungen überwachen. Dieser Rat wird voraussichtlich zunächst aus Kernteammitgliedern und frühen Community-Führern bestehen. Gensyn plant ein Token Generation Event (TGE) für seinen nativen Token (oft als GENS bezeichnet), wonach die Governance-Macht zunehmend über On-Chain-Abstimmungen in den Händen der Token-Inhaber liegen würde. Die Rolle der Stiftung ist es, die Interessen des Protokolls zu vertreten und einen reibungslosen Übergang zur vollständigen Dezentralisierung zu gewährleisten. In der Praxis wird Gensyn wahrscheinlich On-Chain-Vorschlagsmechanismen haben, bei denen über Änderungen von Parametern (z. B. Verifizierungsspieldauer, Gebührensätze) oder Upgrades von der Community abgestimmt wird. Da Gensyn als Ethereum-Rollup implementiert wird, könnte die Governance auch an die Sicherheit von Ethereum gebunden sein (zum Beispiel die Verwendung von Upgrade-Schlüsseln für den Rollup-Vertrag, die schließlich an eine DAO von Token-Inhabern übergehen). Der Abschnitt Dezentralisierung und Governance des Gensyn-Litepapers betont, dass das Protokoll letztendlich global im Besitz sein muss, im Einklang mit dem Ethos, dass das „Netzwerk für maschinelle Intelligenz“ seinen Benutzern und Mitwirkenden gehören sollte. Zusammenfassend beginnt Gensyns Governance semi-zentralisiert, ist aber so konzipiert, dass sie zu einer DAO wird, in der GENS-Token-Inhaber (potenziell nach Stake oder Beteiligung gewichtet) kollektiv Entscheidungen treffen.

• Gensyn-Anreize: Die wirtschaftlichen Anreize in Gensyn sind unkomplizierte Marktdynamiken, ergänzt durch kryptoökonomische Sicherheit. Entwickler (Clients) bezahlen ML-Aufgaben mit dem Gensyn-Token, und Solver verdienen Tokens, indem sie diese Aufgaben korrekt erledigen. Der Preis für Rechenzyklen wird durch einen offenen Markt bestimmt – vermutlich können Entwickler Aufgaben mit einer Belohnung ausschreiben, und Solver können bieten oder sie einfach annehmen, wenn der Preis ihren Erwartungen entspricht. Dies stellt sicher, dass, solange ein Angebot an ungenutzten GPUs vorhanden ist, der Wettbewerb die Kosten auf einen fairen Satz senkt (Gensyns Team prognostiziert eine Kostenreduzierung von bis zu 80 % im Vergleich zu Cloud-Preisen, da das Netzwerk die günstigste verfügbare Hardware weltweit findet). Auf der anderen Seite haben Solver den Anreiz, Tokens für Arbeit zu verdienen; ihre Hardware, die sonst ungenutzt bleiben könnte, generiert nun Einnahmen. Um die Qualität zu gewährleisten, verlangt Gensyn von Solvern, dass sie Sicherheiten staken, wenn sie einen Job annehmen – wenn sie betrügen oder ein falsches Ergebnis produzieren und erwischt werden, verlieren sie diesen Stake (er kann „geslasht“ und dem ehrlichen Verifier zugesprochen werden). Verifier werden durch die Chance motiviert, eine „Jackpot“-Belohnung zu verdienen, wenn sie einen betrügerischen Solver erwischen, ähnlich dem Truebit-Design, das Verifier, die erfolgreich falsche Berechnungen identifizieren, periodisch belohnt. Dies hält Solver ehrlich und motiviert einige Knoten, als Wächter zu fungieren. In einem optimalen Szenario (kein Betrug) verdienen Solver einfach die Aufgaben-Gebühr, und die Rolle des Verifiers ist größtenteils untätig (oder einer der teilnehmenden Solver könnte auch als Verifier für andere fungieren). Gensyns Token dient somit sowohl als Gas-Währung für den Kauf von Rechenleistung als auch als Stake-Sicherheit, die das Protokoll sichert. Das Litepaper erwähnt ein Testnetz mit nicht-permanenten Tokens und dass frühe Testnetz-Teilnehmer beim TGE mit echten Tokens belohnt werden. Dies deutet darauf hin, dass Gensyn einen Teil des Token-Angebots für das Bootstrapping bereitgestellt hat – zur Belohnung von Early Adopters, Test-Solvern und Community-Mitgliedern. Langfristig sollten Gebühren aus echten Jobs das Netzwerk aufrechterhalten. Es kann auch eine kleine Protokollgebühr (ein Prozentsatz jeder Aufgaben-Zahlung) geben, die in eine Treasury fließt oder verbrannt wird; dieses Detail ist noch nicht bestätigt, aber viele Marktplatzprotokolle enthalten eine Gebühr zur Finanzierung der Entwicklung oder des Token-Kaufs und -Verbrennens. Zusammenfassend richten sich Gensyns Anreize an der ehrlichen Erledigung von ML-Jobs aus: Arbeit leisten, bezahlt werden; versuchen zu betrügen, Stake verlieren; andere überprüfen, verdienen, wenn man Betrüger erwischt. Dies schafft ein sich selbst regulierendes Wirtschaftssystem, das darauf abzielt, zuverlässige verteilte Berechnungen zu erreichen.

• Cuckoo Governance: Cuckoo Network hat die Governance von Anfang an in sein Ökosystem integriert, obwohl es sich noch in einer Entwicklungsphase befindet. Der $CAI-Token ist neben seinen Utility-Rollen explizit ein Governance-Token. Cuckoos Philosophie ist, dass GPU-Knotenbetreiber, App-Entwickler und sogar Endbenutzer ein Mitspracherecht bei der Entwicklung des Netzwerks haben sollten – was seine gemeinschaftsgetriebene Vision widerspiegelt. In der Praxis würden wichtige Entscheidungen (wie Protokoll-Upgrades oder wirtschaftliche Änderungen) durch Token-gewichtete Abstimmungen entschieden, vermutlich über einen DAO-Mechanismus. Zum Beispiel könnte Cuckoo On-Chain-Abstimmungen über die Änderung der Belohnungsverteilung oder die Einführung einer neuen Funktion abhalten, und $CAI-Inhaber (einschließlich Miner, Entwickler und Benutzer) würden abstimmen. Bereits jetzt wird On-Chain-Abstimmung als Reputationssystem verwendet: Cuckoo verlangt von jeder Rolle, Tokens zu staken, und dann können Community-Mitglieder (vielleicht durch Delegation von Stake oder über Governance-Module) darüber abstimmen, welche Koordinatoren oder Miner vertrauenswürdig sind. Dies beeinflusst Reputationswerte und könnte die Aufgabenplanung beeinflussen (z. B. könnte ein Koordinator mit mehr Stimmen mehr Benutzer anziehen, oder ein Miner mit mehr Stimmen könnte mehr Aufgaben zugewiesen bekommen). Es ist eine Mischung aus Governance und Anreiz – die Verwendung von Governance-Tokens zur Etablierung von Vertrauen. Die Cuckoo Foundation oder das Kernteam hat die Richtung des Projekts bisher geleitet (zum Beispiel die jüngste Entscheidung, die L1-Kette einzustellen), aber ihr Blog deutet auf ein Engagement hin, sich in Richtung dezentraler Eigentümerschaft zu bewegen. Sie stellten fest, dass der Betrieb einer eigenen Kette hohe Gemeinkosten verursachte und dass der Wechsel zu einem Rollup eine offenere Entwicklung und Integration mit bestehenden Ökosystemen ermöglichen wird. Es ist wahrscheinlich, dass Cuckoo, sobald es auf einer gemeinsamen Schicht (wie Ethereum) ist, eine traditionellere DAO für Upgrades implementieren wird, wobei die Community mit CAI abstimmt.

• Cuckoo-Anreize: Das Anreizdesign für Cuckoo hat zwei Phasen: die anfängliche Bootstrapping-Phase mit festen Token-Zuweisungen und einen zukünftigen Zustand mit nutzungsbasierter Umsatzbeteiligung. Beim Start führte Cuckoo eine „Fair Launch“-Verteilung von 1 Milliarde CAI-Tokens durch. 51 % des Angebots wurden für die Community reserviert, aufgeteilt als:

  • Mining-Belohnungen: 30 % des Gesamtangebots reserviert, um GPU-Miner für die Ausführung von KI-Aufgaben zu bezahlen.
  • Staking-Belohnungen: 11 % des Angebots für diejenigen, die staken und zur Sicherung des Netzwerks beitragen.
  • Airdrops: 5 % an frühe Benutzer und Community-Mitglieder als Anreiz zur Adoption.
  • (Weitere 5 % waren für Entwicklerzuschüsse zur Förderung des Aufbaus auf Cuckoo.)

  Diese große Zuweisung bedeutet, dass im frühen Netzwerk Miner und Staker aus einem Emissionspool belohnt wurden, selbst wenn die tatsächliche Benutzernachfrage gering war. Tatsächlich bot Cuckoos Anfangsphase hohe APY-Renditen für Staking und Mining, was erfolgreich Teilnehmer anzog, aber auch „Yield Farmer“, die nur wegen der Tokens da waren. Das Team stellte fest, dass viele Benutzer das Netzwerk verließen, sobald die Belohnungsraten sanken, was darauf hindeutet, dass diese Anreize nicht an die tatsächliche Nutzung gebunden waren. Aus diesen Erfahrungen lernend, wechselt Cuckoo zu einem Modell, bei dem Belohnungen direkt mit der tatsächlichen KI-Arbeitslast korrelieren. Zukünftig (und teilweise bereits jetzt), wenn ein Endbenutzer für eine KI-Inferenz bezahlt, wird diese Zahlung (in CAI oder möglicherweise einem anderen akzeptierten Token, der in CAI umgewandelt wird) unter den Mitwirkenden aufgeteilt:

  • GPU-Miner erhalten den Großteil des Anteils für die von ihnen bereitgestellte Rechenleistung.
  • Koordinator (App-Entwickler) erhält einen Anteil als Dienstanbieter, der das Modell bereitgestellt und die Anfrage bearbeitet hat.
  • Staker, die an diese Miner oder Koordinatoren delegiert haben, könnten einen kleinen Anteil oder eine inflationäre Belohnung erhalten, um die Unterstützung zuverlässiger Knoten weiterhin zu fördern.
  • Netzwerk/Treasury könnte eine Gebühr für die laufende Entwicklung einbehalten oder zukünftige Anreize finanzieren (oder die Gebühr könnte null/nominal sein, um die Benutzerfreundlichkeit zu maximieren).

  Im Wesentlichen bewegt sich Cuckoo auf ein Umsatzbeteiligungsmodell zu: Wenn eine KI-App auf Cuckoo Einnahmen generiert, werden diese Einnahmen fair an alle Mitwirkenden dieses Dienstes verteilt. Dies stimmt die Anreize so ab, dass die Teilnehmer von der tatsächlichen Nutzung profitieren und nicht nur von der Inflation. Bereits jetzt verlangte das Netzwerk von allen Parteien, CAI zu staken – das bedeutet, dass Miner und Koordinatoren nicht nur eine pauschale Belohnung verdienen, sondern möglicherweise auch stake-basierte Belohnungen (zum Beispiel könnte ein Koordinator höhere Belohnungen verdienen, wenn viele Benutzer auf ihn staken oder wenn er selbst mehr stakt, ähnlich wie Proof-of-Stake-Validatoren verdienen). Was die Benutzeranreize betrifft, führte Cuckoo auch Dinge wie ein Airdrop-Portal und Faucets ein (die einige Benutzer ausnutzten), um die anfängliche Aktivität anzukurbeln. Zukünftig könnten Benutzer über Token-Rabatte für die Nutzung der Dienste oder über Governance-Belohnungen für die Teilnahme an der Kuration (z. B. kleine Tokens für die Bewertung von Outputs oder die Bereitstellung von Daten) incentiviert werden. Das Fazit ist, dass Cuckoos Token ($CAI) vielseitig einsetzbar ist: Es ist der Gas-/Gebühren-Token auf der Kette (alle Transaktionen und Zahlungen verwenden ihn), er wird für Staking und Abstimmungen verwendet und ist die Einheit der Belohnung für geleistete Arbeit. Cuckoo erwähnt explizit, dass es Token-Belohnungen an Service-Level-KPIs (Key Performance Indicators) binden möchte – zum Beispiel Verfügbarkeit, Abfragedurchsatz, Benutzerzufriedenheit – um rein spekulative Anreize zu vermeiden. Dies spiegelt eine Reifung der Token-Ökonomie von einfachem Liquiditäts-Mining zu einem nachhaltigeren, nutzungsgetriebenen Modell wider.

Modelleigentum und IP-Zuordnung​

Der Umgang mit geistigem Eigentum (IP) und Eigentumsrechten an KI-Modellen ist ein komplexer Aspekt dezentraler KI-Netzwerke. Jede Plattform hat eine etwas andere Haltung eingenommen, und im Allgemeinen ist dies ein sich entwickelnder Bereich ohne vollständige Lösung bisher:

• Bittensor: Modelle in Bittensor werden von den Miner-Knoten bereitgestellt, und diese Miner behalten die volle Kontrolle über ihre Modellgewichte (die niemals On-Chain veröffentlicht werden). Bittensor verfolgt nicht explizit, wer ein Modell „besitzt“, außer der Tatsache, dass es unter einer bestimmten Wallet-Adresse läuft. Wenn ein Miner geht, geht sein Modell mit ihm. Daher erfolgt die IP-Zuordnung in Bittensor Off-Chain: Wenn ein Miner ein proprietäres Modell verwendet, gibt es nichts On-Chain, das dies durchsetzt oder gar weiß. Bittensors Philosophie fördert offene Beiträge (viele Miner könnten Open-Source-Modelle wie GPT-J oder andere verwenden) und das Netzwerk belohnt die Leistung dieser Modelle. Man könnte sagen, Bittensor erstellt einen Reputations-Score für Modelle (über die Validatoren-Rankings), und das ist eine Form der Anerkennung des Modellwerts, aber die Rechte am Modell selbst werden nicht tokenisiert oder verteilt. Bemerkenswert ist, dass Subnetz-Besitzer in Bittensor als Eigentümer eines Teils des IP angesehen werden könnten: Sie definieren eine Aufgabe (die einen Datensatz oder eine Methode umfassen könnte). Der Subnetz-Besitzer prägt ein NFT (genannt Subnetz-UID) bei der Erstellung eines Subnetzes, und dieses NFT berechtigt ihn zu 18 % der Belohnungen in diesem Subnetz. Dies tokenisiert effektiv die Schaffung eines Modell-Marktplatzes (das Subnetz), wenn auch nicht die Modellinstanzen. Wenn man die Definition des Subnetzes (sagen wir eine Spracherkennungsaufgabe mit einem bestimmten Datensatz) als IP betrachtet, wird dies zumindest aufgezeichnet und belohnt. Aber individuelle Modellgewichte, die Miner trainieren – davon gibt es keine On-Chain-Eigentumsaufzeichnung. Die Zuordnung erfolgt in Form von Belohnungen, die an die Adresse des Miners gezahlt werden. Bittensor implementiert derzeit kein System, bei dem zum Beispiel mehrere Personen gemeinsam ein Modell besitzen und eine automatische Umsatzbeteiligung erhalten könnten – die Person, die das Modell betreibt (Miner), erhält die Belohnung, und es liegt an ihr Off-Chain, alle IP-Lizenzen des von ihr verwendeten Modells einzuhalten.

• Gensyn: In Gensyn ist das Modelleigentum unkompliziert, da der Submitter (derjenige, der ein Modell trainieren lassen möchte) die Modellarchitektur und Daten bereitstellt, und nach dem Training das resultierende Modellartefakt erhält. Die Solver, die die Arbeit ausführen, haben keine Rechte am Modell; sie sind wie Auftragnehmer, die für Dienstleistungen bezahlt werden. Gensyns Protokoll geht also vom traditionellen IP-Modell aus: Wenn Sie rechtliche Rechte an dem von Ihnen eingereichten Modell und den Daten hatten, haben Sie diese auch nach dem Training noch – das Rechennetzwerk beansprucht kein Eigentum. Gensyn erwähnt, dass der Marktplatz auch Algorithmen und Daten wie jede andere Ressource handeln könnte. Dies deutet auf ein Szenario hin, in dem jemand ein Modell oder einen Algorithmus zur Nutzung im Netzwerk anbieten könnte, möglicherweise gegen eine Gebühr, wodurch der Zugang zu diesem Modell tokenisiert würde. Zum Beispiel könnte ein Modellersteller sein vorab trainiertes Modell auf Gensyn platzieren und anderen erlauben, es über das Netzwerk gegen eine Gebühr feinabzustimmen (dies würde das Modell-IP effektiv monetarisieren). Während das Protokoll keine Lizenzbedingungen durchsetzt, könnte man Zahlungsanforderungen kodieren: Ein Smart Contract könnte eine Gebühr verlangen, um die Modellgewichte für einen Solver freizuschalten. Dies sind jedoch spekulative Anwendungsfälle – Gensyns primäres Design dreht sich um die Ermöglichung von Trainingsjobs. Was die Zuordnung betrifft, so würde, wenn mehrere Parteien zu einem Modell beitragen (sagen wir, einer stellt Daten bereit, ein anderer Rechenleistung), dies wahrscheinlich durch den Vertrag oder die Vereinbarung geregelt, die sie vor der Nutzung von Gensyn getroffen haben (z. B. könnte ein Smart Contract die Zahlung zwischen Datenanbieter und Rechenanbieter aufteilen). Gensyn selbst verfolgt On-Chain nicht, „dieses Modell wurde von X, Y, Z erstellt“, außer der Aufzeichnung, welche Adressen für den Job bezahlt wurden. Zusammenfassend lässt sich sagen, dass Modell-IP in Gensyn beim Submitter verbleibt, und jede Zuordnung oder Lizenzierung muss über die rechtlichen Vereinbarungen außerhalb des Protokolls oder über darauf aufbauende benutzerdefinierte Smart Contracts gehandhabt werden.

• Cuckoo: Im Cuckoo-Ökosystem sind Modellersteller (KI-App-Entwickler) erstklassige Teilnehmer – sie stellen den KI-Dienst bereit. Wenn ein App-Entwickler ein Sprachmodell feinabstimmt oder ein benutzerdefiniertes Modell entwickelt und es auf Cuckoo hostet, ist dieses Modell im Wesentlichen sein Eigentum, und er fungiert als Dienstbesitzer. Cuckoo beansprucht kein Eigentum; stattdessen bietet es die Infrastruktur, damit sie die Nutzung monetarisieren können. Wenn zum Beispiel ein Entwickler einen Chatbot-KI bereitstellt, können Benutzer damit interagieren, und der Entwickler (plus Miner) verdienen CAI aus jeder Interaktion. Die Plattform ordnet somit Nutzungseinnahmen dem Modellersteller zu, veröffentlicht aber nicht explizit die Modellgewichte oder wandelt sie in ein NFT um. Tatsächlich muss der Koordinator-Knoten, um das Modell auf den GPUs der Miner auszuführen, das Modell (oder die Laufzeitumgebung) in irgendeiner Form an den Miner senden. Dies wirft IP-Fragen auf: Könnte ein böswilliger Miner die Modellgewichte kopieren und verteilen? In einem dezentralen Netzwerk besteht dieses Risiko, wenn proprietäre Modelle verwendet werden. Cuckoos aktueller Fokus lag auf ziemlich offenen Modellen (Stable Diffusion, LLaMA-abgeleitete Modelle usw.) und dem Aufbau einer Community, sodass wir noch keine Durchsetzung von IP-Rechten über Smart Contracts gesehen haben. Die Plattform könnte potenziell Tools wie verschlüsselte Modellausführung oder sichere Enklaven in Zukunft zum IP-Schutz integrieren, aber in der Dokumentation wird nichts Spezifisches erwähnt. Was es tut, ist die Verfolgung, wer den Modell-Dienst für jede Aufgabe bereitgestellt hat – da der Koordinator eine On-Chain-Identität ist, wird jede Nutzung seines Modells ihm zugerechnet, und er erhält automatisch seinen Anteil an den Belohnungen. Wenn man ein Modell an jemand anderen weitergeben oder verkaufen würde, würde man effektiv die Kontrolle über den Koordinator-Knoten übertragen (vielleicht sogar nur den privaten Schlüssel oder das NFT geben, wenn die Koordinator-Rolle tokenisiert wäre). Derzeit ist die Gemeinschaftseigentümerschaft von Modellen (über Token-Anteile) nicht implementiert, aber Cuckoos Vision deutet auf dezentrale, gemeinschaftsgetriebene KI hin, sodass sie möglicherweise erforschen werden, wie Menschen gemeinsam ein KI-Modell finanzieren oder regieren können. Die Tokenisierung von Modellen über das individuelle Eigentum hinaus ist in diesen Netzwerken immer noch ein offenes Feld – es wird als Ziel anerkannt (um Gemeinschaften KI-Modelle statt Unternehmen zu ermöglichen), aber praktisch erfordert es Lösungen für die oben genannten IP- und Verifizierungsherausforderungen.

Zusammenfassend lässt sich sagen, dass das Modelleigentum in Bittensor, Gensyn und Cuckoo Off-Chain auf traditionelle Weise gehandhabt wird: Die Person oder Entität, die das Modell betreibt oder einreicht, ist effektiv der Eigentümer. Die Netzwerke bieten eine Zuordnung in Form von wirtschaftlichen Belohnungen (Bezahlung des Modell-Beitragenden für sein IP oder seine Bemühungen). Keines der drei hat bisher eine integrierte Lizenz- oder Lizenzgebühren-Durchsetzung für die Modellnutzung auf Smart-Contract-Ebene. Die Zuordnung erfolgt durch Reputation und Belohnung: z. B. erhalten Bittensors beste Modelle hohe Reputationswerte (die öffentlich aufgezeichnet werden) und mehr TAO, was eine implizite Anerkennung ihrer Ersteller ist. Im Laufe der Zeit könnten wir Funktionen wie NFT-gebundene Modellgewichte oder dezentrale Lizenzen sehen, um IP besser zu verfolgen, aber derzeit lag die Priorität darauf, die Netzwerke funktionsfähig zu machen und Beiträge zu incentivieren. Alle sind sich einig, dass die Überprüfung der Modellherkunft und -ausgaben der Schlüssel zur Ermöglichung echter Modell-Asset-Märkte ist, und die Forschung in dieser Richtung ist im Gange.

Umsatzbeteiligungsstrukturen​

Alle drei Plattformen müssen entscheiden, wie der wirtschaftliche Kuchen aufgeteilt wird, wenn mehrere Parteien zusammenarbeiten, um eine wertvolle KI-Ausgabe zu produzieren. Wer wird bezahlt und wie viel, wenn ein KI-Dienst genutzt wird oder wenn Tokens emittiert werden? Jede hat ein eigenes Umsatzbeteiligungsmodell:

• Bittensor: Wie unter Anreize erwähnt, ist Bittensors Umsatzverteilung auf Blockebene protokoll-definiert: 41 % an Miner, 41 % an Validatoren, 18 % an den Subnetz-Besitzer für jede TAO-Ausgabe eines Blocks. Dies ist effektiv eine eingebaute Umsatzaufteilung für den in jedem Subnetz generierten Wert. Der Anteil des Subnetz-Besitzers (18 %) fungiert als Lizenzgebühr für das „Modell-/Aufgabendesign“ oder für das Bootstrapping des Ökosystems dieses Subnetzes. Miner und Validatoren erhalten gleiche Anteile, um sicherzustellen, dass Miner ohne Validierung nicht belohnt werden (und umgekehrt) – sie sind symbiotisch und jeder erhält einen gleichen Anteil an den geprägten Belohnungen. Wenn wir einen externen Benutzer betrachten, der TAO zahlt, um ein Modell abzufragen, sieht das Bittensor-Whitepaper vor, dass diese Zahlung ebenfalls ähnlich zwischen dem Miner, der antwortet, und den Validatoren, die bei der Überprüfung der Antwort geholfen haben, aufgeteilt wird (die genaue Aufteilung könnte durch das Protokoll oder Marktkräfte bestimmt werden). Zusätzlich sind Delegatoren, die auf Miner/Validatoren staken, effektiv Partner – typischerweise teilt ein Miner/Validator einen Prozentsatz seiner verdienten TAO mit seinen Delegatoren (dies ist konfigurierbar, aber oft der Großteil an Delegatoren). Wenn also ein Miner 1 TAO aus einem Block verdient hat, könnte dieser beispielsweise basierend auf dem Stake 80/20 zwischen seinen Delegatoren und sich selbst aufgeteilt werden. Das bedeutet, dass auch Nicht-Betreiber einen Anteil am Umsatz des Netzwerks proportional zu ihrer Unterstützung erhalten. Mit der Einführung von dTAO wurde eine weitere Ebene der Aufteilung hinzugefügt: Diejenigen, die in den Pool eines Subnetzes staken, erhalten Alpha-Tokens, die sie zu einem Teil der Emissionen dieses Subnetzes berechtigen (wie Yield Farming). Im Effekt kann jeder einen Anteil am Erfolg eines bestimmten Subnetzes nehmen und einen Bruchteil der Miner-/Validatoren-Belohnungen durch das Halten von Alpha-Tokens erhalten (Alpha-Tokens steigen im Wert, wenn das Subnetz mehr Nutzung und Emissionen anzieht). Zusammenfassend lässt sich sagen, dass Bittensors Umsatzbeteiligung für die Hauptrollen durch Code festgelegt ist und durch soziale/Staking-Vereinbarungen weiter aufgeteilt wird. Es ist eine relativ transparente, regelbasierte Aufteilung – bei jedem Block wissen die Teilnehmer genau, wie der 1 TAO zugewiesen wird, und kennen somit ihre „Einnahmen“ pro Beitrag. Diese Klarheit ist ein Grund, warum Bittensor manchmal als Bitcoin für KI bezeichnet wird – eine deterministische Geldausgabe, bei der die Belohnung der Teilnehmer mathematisch festgelegt ist.

• Gensyn: Die Umsatzbeteiligung in Gensyn ist dynamischer und marktorientierter, da Aufgaben individuell bepreist werden. Wenn ein Submitter einen Job erstellt, fügt er eine Belohnung (sagen wir X Tokens) hinzu, die er zu zahlen bereit ist. Ein Solver, der den Job abschließt, erhält dieses X (abzüglich etwaiger Netzwerkgebühren). Wenn ein Verifier beteiligt ist, gibt es typischerweise eine Regel wie: Wenn kein Betrug entdeckt wird, behält der Solver die volle Zahlung; wenn Betrug entdeckt wird, wird der Solver „geslasht“ – er verliert einen Teil oder seinen gesamten Stake – und dieser „geslashte“ Betrag wird dem Verifier als Belohnung gegeben. Verifier verdienen also nicht an jeder Aufgabe, sondern nur, wenn sie ein schlechtes Ergebnis erwischen (plus möglicherweise eine kleine Grundgebühr für die Teilnahme, je nach Implementierung). Es gibt hier kein eingebautes Konzept der Bezahlung eines Modelleigentümers, da davon ausgegangen wird, dass der Submitter entweder der Modelleigentümer ist oder die Rechte zur Nutzung des Modells besitzt. Man könnte sich ein Szenario vorstellen, in dem ein Submitter das vortrainierte Modell eines anderen feinabstimmt und ein Teil der Zahlung an den ursprünglichen Modellersteller geht – dies müsste jedoch außerhalb des Protokolls gehandhabt werden (z. B. durch eine Vereinbarung oder einen separaten Smart Contract, der die Token-Zahlung entsprechend aufteilt). Gensyns protokollseitige Aufteilung ist im Wesentlichen Client -> Solver (-> Verifier). Das Token-Modell beinhaltet wahrscheinlich eine Zuweisung für die Protokoll-Treasury oder -Stiftung; zum Beispiel könnte ein kleiner Prozentsatz der Zahlung jeder Aufgabe an eine Treasury gehen, die zur Finanzierung von Entwicklung oder Versicherungs-Pools verwendet werden könnte (dies ist in den verfügbaren Dokumenten nicht explizit angegeben, aber viele Protokolle tun dies). Auch könnte Gensyn anfangs Solver über Inflation subventionieren: Testnet-Benutzern werden Belohnungen beim TGE versprochen, was effektiv eine Umsatzbeteiligung aus der anfänglichen Token-Verteilung ist (frühe Solver und Unterstützer erhalten einen Teil der Tokens, um beim Bootstrapping zu helfen, ähnlich einem Airdrop oder einer Mining-Belohnung). Im Laufe der Zeit, wenn echte Jobs dominieren, würden inflationäre Belohnungen abnehmen, und das Einkommen der Solver würde hauptsächlich aus Benutzerzahlungen stammen. Gensyns Ansatz lässt sich als Gebühren-für-Service-Umsatzmodell zusammenfassen: Das Netzwerk ermöglicht eine direkte Zahlung von denen, die Arbeit erledigt haben möchten, an diejenigen, die die Arbeit erledigen, wobei Verifier und möglicherweise Token-Staker nur dann Anteile erhalten, wenn sie eine Rolle bei der Sicherung dieses Dienstes spielen.

• Cuckoo: Cuckoos Umsatzbeteiligung hat sich weiterentwickelt. Anfangs, da es nicht viele zahlende Endbenutzer gab, war die Umsatzbeteiligung im Wesentlichen Inflationsbeteiligung: Die 30 % Mining- und 11 % Staking-Zuweisungen aus dem Token-Angebot bedeuteten, dass Miner und Staker die vom Fair-Launch-Pool des Netzwerks ausgegebenen Tokens teilten. In der Praxis führte Cuckoo Dinge wie tägliche CAI-Auszahlungen an Miner proportional zu den abgeschlossenen Aufgaben durch. Diese Auszahlungen stammten größtenteils aus der Mining-Belohnungszuweisung (die Teil des fest reservierten Angebots ist). Dies ähnelt der Art und Weise, wie viele Layer-1-Blockchains Blockbelohnungen an Miner/Validatoren verteilen – es war nicht an die tatsächliche Nutzung durch externe Benutzer gebunden, sondern sollte eher die Teilnahme und das Wachstum fördern. Wie jedoch in ihrem Blog vom Juli 2025 hervorgehoben, führte dies zu einer Nutzung, die eher durch Token-Farming als durch echte Nachfrage motiviert war. Die nächste Phase für Cuckoo ist ein echtes Umsatzbeteiligungsmodell basierend auf Servicegebühren. In diesem Modell, wenn ein Endbenutzer beispielsweise den Bildgenerierungsdienst nutzt und 1 $ (in Krypto-Begriffen) bezahlt, würde dieser Token-Wert von 1 $ vielleicht aufgeteilt wie folgt: 0,70 an den Miner, der die GPU-Arbeit geleistet hat, 0,20 an den App-Entwickler (Koordinator), der das Modell und die Schnittstelle bereitgestellt hat, und 0,10 an Staker oder die Netzwerk-Treasury. (Hinweis: Die genauen Verhältnisse sind hypothetisch; Cuckoo hat sie noch nicht öffentlich spezifiziert, aber dies veranschaulicht das Konzept.) Auf diese Weise erhalten alle Mitwirkenden an der Bereitstellung des Dienstes einen Anteil am Umsatz. Dies ist analog zu, zum Beispiel, einer Fahrgemeinschafts-Wirtschaft, aber für KI: Das Fahrzeug (GPU-Miner) erhält den Großteil, der Fahrer oder die Plattform (Koordinator, der den Modell-Dienst erstellt hat) erhält einen Anteil, und vielleicht erhalten die Governance/Staker der Plattform eine kleine Gebühr. Cuckoos Erwähnung von „Umsatzbeteiligungsmodellen und Token-Belohnungen, die direkt an Nutzungsmetriken gebunden sind“ deutet darauf hin, dass wenn ein bestimmter Dienst oder Knoten ein hohes Volumen verarbeitet, seine Betreiber und Unterstützer mehr verdienen werden. Sie entfernen sich von pauschalen Renditen für das bloße Sperren von Tokens (was bei ihrem anfänglichen Staking-APY der Fall war). Konkret: Wenn Sie auf einen Koordinator staken, der letztendlich eine sehr beliebte KI-App antreibt, könnten Sie einen Teil der Gebühren dieser App verdienen – ein echtes Staking-als-Investition-in-Utility-Szenario, anstatt nur für die Inflation zu staken. Dies stimmt die Anreize aller darauf ab, echte Benutzer anzuziehen, die für KI-Dienste bezahlen, was wiederum Wert an die Token-Inhaber zurückführt. Es ist erwähnenswert, dass Cuckoos Kette auch Gebühren für Transaktionen (Gas) hatte, sodass Miner, die Blöcke produzierten (anfangs trugen GPU-Miner auch zur Blockproduktion auf der Cuckoo-Kette bei), auch Gasgebühren erhielten. Mit der Abschaltung der Kette und der Migration zu einem Rollup werden die Gasgebühren wahrscheinlich minimal sein (oder auf Ethereum liegen), sodass die Haupteinnahmen die KI-Servicegebühren selbst werden. Zusammenfassend wechselt Cuckoo von einem subventionsgetriebenen Modell (Netzwerk zahlt Teilnehmer aus seinem Token-Pool) zu einem nachfragegetriebenen Modell (Teilnehmer verdienen an tatsächlichen Benutzerzahlungen). Der Token wird weiterhin eine Rolle beim Staking und der Governance spielen, aber die täglichen Einnahmen von Minern und App-Entwicklern sollten zunehmend von Benutzern stammen, die KI-Dienste kaufen. Dieses Modell ist langfristig nachhaltiger und spiegelt die Umsatzbeteiligung von Web2-SaaS wider, jedoch über Smart Contracts und Tokens für Transparenz implementiert.

Angriffsflächen und Schwachstellen​

Die Dezentralisierung von KI bringt mehrere Anreiz- und Sicherheitsherausforderungen mit sich. Wir analysieren nun die wichtigsten Angriffsvektoren – Sybil-Angriffe, Kollusion, Trittbrettfahren und Daten-/Modellvergiftung – und wie jede Plattform diese mindert oder ihnen gegenüber anfällig bleibt:

• Sybil-Angriffe (gefälschte Identitäten): In einem offenen Netzwerk könnte ein Angreifer viele Identitäten (Knoten) erstellen, um unverhältnismäßige Belohnungen oder Einfluss zu erlangen.

  • Bittensor: Sybil-Resistenz wird hauptsächlich durch die Eintrittskosten gewährleistet. Um einen neuen Miner oder Validator auf Bittensor zu registrieren, muss man TAO ausgeben oder staken – dies könnte eine Burn- oder Bonding-Anforderung sein. Das bedeutet, dass die Erstellung von N gefälschten Knoten N-mal die Kosten verursacht, was große Sybil-Schwärme teuer macht. Zusätzlich bindet Bittensors Konsens den Einfluss an Stake und Leistung; ein Sybil ohne Stake oder mit schlechter Leistung verdient wenig. Ein Angreifer müsste stark investieren und seine Sybil-Knoten tatsächlich nützliche Arbeit leisten lassen, um eine signifikante Belohnung zu erhalten (was keine typische Sybil-Strategie ist). Wenn ein Angreifer jedoch viel Kapital besitzt, könnte er eine Mehrheit der TAO erwerben und viele Validatoren oder Miner registrieren – effektiv ein Sybil durch Reichtum. Dies überschneidet sich mit dem 51%-Angriffsszenario: Wenn eine einzelne Entität >50 % der gestakten TAO in einem Subnetz kontrolliert, kann sie den Konsens stark beeinflussen. Bittensors Einführung von dTAO hilft hier ein wenig: Es verteilt den Einfluss auf mehrere Subnetze und erfordert die Unterstützung der Community beim Staking, damit Subnetze gedeihen können, was es für eine Entität schwieriger macht, alles zu kontrollieren. Dennoch bleiben Sybil-Angriffe durch einen gut finanzierten Gegner ein Problem – die Arxiv-Analyse weist explizit darauf hin, dass der Stake derzeit ziemlich konzentriert ist, sodass die Barriere für einen Mehrheitsangriff nicht so hoch ist wie gewünscht. Um dies zu mindern, wurden Vorschläge wie Stake-Obergrenzen pro Wallet (z. B. Begrenzung des effektiven Stakes auf das 88. Perzentil, um die Dominanz einer Wallet zu verhindern) gemacht. Zusammenfassend verlässt sich Bittensor auf Stake-gewichtete Identität (man kann Identitäten nicht billig ohne proportionalen Stake erzeugen), um Sybils zu handhaben; es ist einigermaßen effektiv, außer bei einem sehr ressourcenstarken Angreifer.
  • Gensyn: Sybil-Angriffe in Gensyn würden sich darin äußern, dass ein Angreifer viele Solver- oder Verifier-Knoten hochfährt, um das System zu manipulieren. Gensyns Verteidigung ist rein wirtschaftlich und kryptografisch – Identitäten an sich spielen keine Rolle, aber das Erledigen von Arbeit oder das Hinterlegen von Sicherheiten schon. Wenn ein Angreifer 100 gefälschte Solver-Knoten erstellt, diese aber keine Jobs oder keinen Stake haben, erreichen sie nichts. Um Aufgaben zu gewinnen, müsste ein Sybil-Knoten wettbewerbsfähig bieten und die Hardware haben, um die Arbeit zu erledigen. Wenn sie ohne Kapazität unterbieten, werden sie scheitern und Stake verlieren. Ähnlich könnte ein Angreifer viele Verifier-Identitäten erstellen, in der Hoffnung, zur Verifizierung ausgewählt zu werden (wenn das Protokoll Verifier zufällig auswählt). Aber wenn es zu viele gibt, könnte das Netzwerk oder der Job-Poster die Anzahl der aktiven Verifier begrenzen. Außerdem müssen Verifier möglicherweise die Berechnung durchführen, um sie zu überprüfen, was kostspielig ist; viele gefälschte Verifier helfen nicht, es sei denn, man kann tatsächlich Ergebnisse verifizieren. Ein relevanterer Sybil-Aspekt in Gensyn ist, wenn ein Angreifer versucht, das Netzwerk mit gefälschten Jobs oder Antworten zu füllen, um die Zeit anderer zu verschwenden. Dies wird durch die Anforderung einer Einzahlung von Submittern gemildert (ein böswilliger Submitter, der gefälschte Jobs postet, verliert seine Zahlung oder Einzahlung). Insgesamt bedeutet Gensyns Verwendung von erforderlichen Stakes/Bonds und zufälliger Auswahl zur Verifizierung, dass ein Angreifer wenig gewinnt, indem er mehrere Identitäten hat, es sei denn, er bringt auch proportionale Ressourcen mit. Es wird zu einem kostspieligeren Angriff statt zu einem billigen. Das optimistische Sicherheitsmodell geht davon aus, dass mindestens ein ehrlicher Verifier vorhanden ist – Sybils müssten alle Verifier überwältigen und sein, um konsequent zu betrügen, was wiederum auf den Besitz einer Mehrheit des Stakes oder der Rechenleistung zurückführt. Gensyns Sybil-Resistenz ist daher vergleichbar mit der eines optimistischen Rollups: Solange es einen ehrlichen Akteur gibt, können Sybils keinen systemischen Schaden leicht verursachen.
  • Cuckoo: Die Prävention von Sybil-Angriffen in Cuckoo basiert auf Staking und Community-Überprüfung. Jede Rolle in Cuckoo (Miner, Koordinator, in einigen Fällen sogar Benutzer) erfordert das Staking von $CAI. Dies erhöht sofort die Kosten für Sybil-Identitäten – ein Angreifer, der 100 Dummy-Miner erstellt, müsste für jeden Stake erwerben und sperren. Darüber hinaus hat Cuckoos Design ein menschliches/gemeinschaftliches Element: Neue Knoten müssen Reputation durch On-Chain-Abstimmung verdienen. Eine Sybil-Armee von neuen Knoten ohne Reputation wird wahrscheinlich nicht viele Aufgaben zugewiesen bekommen oder von Benutzern vertraut werden. Koordinatoren müssen insbesondere Benutzer anziehen; ein gefälschter Koordinator ohne Erfolgsbilanz würde keine Nutzung erhalten. Für Miner können Koordinatoren ihre Leistungsstatistiken (erfolgreiche Aufgaben usw.) auf Cuckoo Scan sehen und werden zuverlässige Miner bevorzugen. Cuckoo hatte auch eine relativ kleine Anzahl von Minern (zu einem Zeitpunkt in der Beta 40 GPUs), sodass jeder ungewöhnliche Zustrom vieler Knoten auffallen würde. Der potenzielle Schwachpunkt ist, wenn der Angreifer auch das Reputationssystem ausnutzt – z. B. staken sie viel CAI auf ihre Sybil-Knoten, um sie seriös aussehen zu lassen, oder erstellen gefälschte „Benutzer“-Konten, um sich selbst hochzustimmen. Dies ist theoretisch möglich, aber da alles Token-kuratiert ist, kostet es Tokens, dies zu tun (man würde im Wesentlichen mit dem eigenen Stake auf die eigenen Knoten stimmen). Das Cuckoo-Team kann auch die Staking- und Belohnungsparameter anpassen, wenn Sybil-Verhalten beobachtet wird (insbesondere jetzt, da es zu einem stärker zentralisierten Rollup-Dienst wird; sie können schlechte Akteure pausieren oder „slashen“). Alles in allem werden Sybils durch die Anforderung von „Skin in the Game“ (Stake) und die Notwendigkeit der Community-Zustimmung in Schach gehalten. Niemand kann einfach mit Hunderten von gefälschten GPUs hereinspazieren und Belohnungen ernten, ohne eine erhebliche Investition zu tätigen, die ehrliche Teilnehmer besser für echte Hardware und Stake ausgeben könnten.

• Kollusion: Hier betrachten wir mehrere Teilnehmer, die kolludieren, um das System zu manipulieren – zum Beispiel Validatoren und Miner, die in Bittensor kolludieren, oder Solver und Verifier, die in Gensyn kolludieren usw.

  • Bittensor: Kollusion wurde als echtes Problem identifiziert. Im ursprünglichen Design konnte eine Handvoll Validatoren kolludieren, um bestimmte Miner oder sich selbst immer hochzustufen, wodurch die Belohnungsverteilung unfair verzerrt wurde (dies wurde als Machtkonzentration im Root-Subnetz beobachtet). Der Yuma-Konsens bietet eine gewisse Verteidigung: Indem er einen Median der Validatoren-Scores nimmt und diejenigen bestraft, die abweichen, verhindert er, dass eine kleine kolludierende Gruppe ein Ziel dramatisch aufwertet, es sei denn, sie bilden die Mehrheit. Mit anderen Worten, wenn 3 von 10 Validatoren kolludieren, um einem Miner einen super hohen Score zu geben, die anderen 7 dies aber nicht tun, werden die Ausreißer-Scores der Kolludierenden beschnitten und die Belohnung des Miners basiert auf dem Median-Score (so scheitert die Kollusion daran, signifikant zu helfen). Wenn die Kolludierenden jedoch >50 % der Validatoren (oder >50 % des Stakes unter den Validatoren) bilden, sind sie effektiv der Konsens – sie können sich auf falsche hohe Scores einigen, und der Median wird ihre Ansicht widerspiegeln. Dies ist das klassische 51%-Angriffsszenario. Leider ergab die Arxiv-Studie, dass in einigen Bittensor-Subnetzen eine Koalition von nur 1–2 % der Teilnehmer (nach Anzahl) eine Mehrheit des Stakes kontrollierte, aufgrund einer starken Token-Konzentration. Dies bedeutet, dass Kollusion durch einige wenige Großinhaber eine glaubwürdige Bedrohung darstellte. Die Minderung, die Bittensor über dTAO verfolgt, ist die Demokratisierung des Einflusses: Indem jeder TAO-Inhaber Stake an Subnetze lenken kann, wird die Macht geschlossener Validatoren-Gruppen verwässert. Auch Vorschläge wie konkaves Staking (abnehmende Erträge für übermäßigen Stake) und Stake-Obergrenzen zielen darauf ab, die Fähigkeit einer kolludierenden Entität zu brechen, zu viel Stimmrecht zu sammeln. Bittensors Sicherheitsannahme ähnelt nun Proof-of-Stake: keine einzelne Entität (oder Kartell) kontrolliert >50 % des aktiven Stakes. Solange dies gilt, ist Kollusion begrenzt, da ehrliche Validatoren schlechte Bewertungen überschreiben werden und kolludierende Subnetz-Besitzer ihre eigenen Belohnungen nicht willkürlich erhöhen können. Schließlich, bei Kollusion zwischen Subnetz-Besitzern und Validatoren (z. B. ein Subnetz-Besitzer besticht Validatoren, um die Miner seines Subnetzes hoch zu bewerten), entfernt dTAO die direkte Validatoren-Kontrolle und ersetzt sie durch Token-Inhaber-Entscheidungen. Es ist schwieriger, mit „dem Markt“ zu kolludieren, es sei denn, man kauft das Token-Angebot auf – in diesem Fall ist es keine Kollusion, sondern eine Übernahme. Bittensors Haupttechnik gegen Kollusion ist also algorithmischer Konsens (Median-Clipping) und breite Token-Verteilung.

  • Gensyn: Kollusion in Gensyn würde wahrscheinlich einen Solver und einen Verifier (oder mehrere Verifier) umfassen, die kolludieren, um das System zu betrügen. Zum Beispiel könnte ein Solver ein gefälschtes Ergebnis produzieren, und ein kolludierender Verifier könnte es absichtlich nicht anfechten (oder sogar bestätigen, dass es korrekt ist, wenn das Protokoll Verifier auffordert, dies zu unterschreiben). Um dies zu mindern, erfordert Gensyns Sicherheitsmodell mindestens einen ehrlichen Verifier. Wenn alle Verifier mit dem Solver kolludieren, bleibt ein schlechtes Ergebnis unangefochten. Gensyn begegnet dem, indem es viele unabhängige Verifier fördert (jeder kann verifizieren) und durch die Spieltheorie, dass ein Verifier eine große Belohnung verdienen könnte, indem er die Kollusion bricht und anfechtet (weil er den Stake des Solvers erhalten würde). Im Wesentlichen hat jedes Mitglied, selbst wenn eine Gruppe sich zur Kollusion bereit erklärt, einen Anreiz, abtrünnig zu werden und die Belohnung für sich selbst zu beanspruchen – dies ist ein klassisches Gefangenendilemma. Die Hoffnung ist, dass dies Kollusionsgruppen klein oder ineffektiv hält. Eine weitere potenzielle Kollusion besteht zwischen mehreren Solvern, um Preise in die Höhe zu treiben oder Aufgaben zu monopolisieren. Da Entwickler jedoch wählen können, wo sie Aufgaben posten (und Aufgaben keine identischen Einheiten sind, die leicht monopolisiert werden können), wäre eine Solver-Kollusion bei der Preisgestaltung global schwer zu koordinieren – jeder nicht-kolludierende Solver könnte unterbieten, um die Arbeit zu gewinnen. Die Dynamik des offenen Marktes wirkt der Preiskollusion entgegen, vorausgesetzt, es gibt zumindest einige wettbewerbsfähige Teilnehmer. Ein weiterer Aspekt: Verifier-Kollusion, um Solver zu schädigen – z. B. Verifier, die ehrliche Solver fälschlicherweise beschuldigen, um deren Stake zu stehlen. Gensyns Fraud Proof ist binär und On-Chain; eine falsche Anschuldigung würde fehlschlagen, wenn die On-Chain-Neuberechnung keinen Fehler findet, und presumably würde der böswillige Verifier dann etwas verlieren (vielleicht eine Einzahlung oder Reputation). Eine Kollusion von Verifiern, die versuchen, Solver zu sabotieren, würde also durch den Verifizierungsprozess des Protokolls aufgedeckt. Zusammenfassend ist Gensyns Architektur robust, solange mindestens eine Partei in jedem kolludierenden Set einen Anreiz hat, ehrlich zu sein – eine Eigenschaft der optimistischen Verifizierung, ähnlich der Anforderung eines ehrlichen Miners in Bitcoin, um schließlich einen Betrug aufzudecken. Kollusion ist theoretisch möglich, wenn ein Angreifer alle Verifier und Solver in einer Aufgabe kontrollieren könnte (wie eine Mehrheit des Netzwerks), aber dann könnten sie einfach betrügen, ohne Kollusion an sich zu benötigen. Die kryptoökonomischen Anreize sind so angeordnet, dass die Aufrechterhaltung von Kollusion irrational ist.

  • Cuckoo: Kollusion in Cuckoo könnte auf verschiedene Weisen geschehen:

    1. Ein Koordinator kolludiert mit Minern – zum Beispiel könnte ein Koordinator Aufgaben immer einer Gruppe befreundeter Miner zuweisen und Belohnungen aufteilen, während er andere ehrliche Miner ignoriert. Da Koordinatoren bei der Aufgabenplanung Ermessensspielraum haben, kann dies geschehen. Wenn die befreundeten Miner jedoch unterdurchschnittlich sind, könnten die Endbenutzer einen langsamen oder schlechten Dienst bemerken und abwandern, sodass der Koordinator von reinem Favoritismus, der die Qualität beeinträchtigt, abgeschreckt wird. Wenn die Kollusion darauf abzielt, Belohnungen zu manipulieren (z. B. das Einreichen gefälschter Aufgaben, um Minern Tokens zu geben), würde dies On-Chain entdeckt werden (viele Aufgaben mit vielleicht identischen Eingaben oder ohne tatsächlichen Benutzer) und kann bestraft werden. Cuckoos On-Chain-Transparenz bedeutet, dass ungewöhnliche Muster von der Community oder dem Kernteam gemeldet werden könnten. Da alle Teilnehmer staken, riskiert ein kolludierender Koordinator-Miner-Ring den Verlust seines Stakes, wenn er beim Missbrauch des Systems erwischt wird (z. B. wenn die Governance beschließt, sie wegen Betrugs zu „slashen“).
    2. Miner kolludieren untereinander – sie könnten Informationen teilen oder ein Kartell bilden, um sich beispielsweise gegenseitig bei der Reputation zu wählen oder alle weigern, einem bestimmten Koordinator zu dienen, um höhere Gebühren zu erzielen. Diese Szenarien sind weniger wahrscheinlich: Die Reputationsabstimmung erfolgt durch Staker (einschließlich Benutzer), nicht durch die Miner selbst, die sich gegenseitig wählen. Und die Verweigerung des Dienstes würde Koordinatoren nur dazu bringen, andere Miner zu finden oder Alarm zu schlagen. Angesichts des derzeit relativ kleinen Umfangs wäre jede Kollusion schwer zu verbergen.
    3. Kollusion zur Manipulation der Governance – große CAI-Inhaber könnten kolludieren, um Vorschläge zu ihren Gunsten durchzusetzen (wie die Festlegung einer exorbitanten Gebühr oder die Umleitung der Treasury). Dies ist ein Risiko in jeder Token-Governance. Die beste Minderung ist eine breite Verteilung des Tokens (Cuckoos Fair Launch gab 51 % an die Community) und eine aktive Community-Aufsicht. Da Cuckoo auch von L1 abgewichen ist, könnte die sofortige On-Chain-Governance begrenzt sein, bis sie sich auf einer neuen Kette niedergelassen haben; das Team behält wahrscheinlich in der Zwischenzeit eine Multisig-Kontrolle, was ironischerweise Kollusion durch böswillige Außenseiter auf Kosten einer vorübergehenden Zentralisierung verhindert.

  Insgesamt stützt sich Cuckoo auf Transparenz und Staking, um Kollusion zu handhaben. Es gibt ein Element des Vertrauens in Koordinatoren, sich korrekt zu verhalten, da sie in einem wettbewerbsintensiven Umfeld Benutzer anziehen wollen. Wenn Kollusion zu schlechterem Service oder offensichtlicher Belohnungsmanipulation führt, können Stakeholder schlechte Akteure abwählen oder das Staking auf sie einstellen, und das Netzwerk kann sie „slashen“ oder blockieren. Die ziemlich offene Natur (jeder kann Koordinator oder Miner werden, wenn er stakt) bedeutet, dass Kollusion eine große koordinierte Anstrengung erfordern würde, die offensichtlich wäre. Es ist nicht so mathematisch verhindert wie in Bittensor oder Gensyn, aber die Kombination aus wirtschaftlichem Stake und Community-Governance bietet eine Kontrolle.

• Trittbrettfahren (Free-Rider-Probleme): Dies bezieht sich auf Teilnehmer, die versuchen, Belohnungen zu ernten, ohne einen gleichwertigen Beitrag zu leisten – z. B. ein Validator, der nicht tatsächlich evaluiert, aber trotzdem verdient, oder ein Miner, der die Antworten anderer kopiert, anstatt zu rechnen, oder Benutzer, die Belohnungen farmen, ohne nützliche Eingaben zu liefern.

  • Bittensor: Ein bekanntes Trittbrettfahrerproblem in Bittensor ist das „Gewichtskopieren“ durch faule Validatoren. Ein Validator könnte einfach die Mehrheitsmeinung (oder die Bewertungen eines anderen Validators) kopieren, anstatt Miner unabhängig zu bewerten. Dadurch vermeiden sie die Kosten für die Ausführung von KI-Abfragen, erhalten aber dennoch Belohnungen, wenn ihre eingereichten Bewertungen konsenskonform aussehen. Bittensor bekämpft dies, indem es die Konsensausrichtung und den informatorischen Beitrag jedes Validators misst. Wenn ein Validator immer nur andere kopiert, mag er gut ausgerichtet sein (so dass er nicht stark bestraft wird), aber er fügt keinen einzigartigen Wert hinzu. Die Protokollentwickler haben diskutiert, Validatoren, die genaue, aber nicht rein redundante Bewertungen liefern, höhere Belohnungen zu geben. Techniken wie die Rauschinfusion (absichtliches Geben von leicht unterschiedlichen Abfragen an Validatoren) könnten sie zwingen, tatsächlich zu arbeiten, anstatt zu kopieren – obwohl unklar ist, ob dies implementiert ist. Der Arxiv schlägt leistungsgewichtete Emissions- und zusammengesetzte Bewertungsmethoden vor, um den Aufwand des Validators besser mit der Belohnung zu verknüpfen. Was Miner betrifft, so wäre ein mögliches Trittbrettfahrer-Verhalten, wenn ein Miner andere Miner abfragt und die Antwort weiterleitet (eine Form von Plagiat). Bittensors Design (mit dezentralen Abfragen) könnte es einem Miner-Modell ermöglichen, andere über seinen eigenen Dendriten aufzurufen. Wenn ein Miner nur die Antwort eines anderen weiterleitet, könnte ein guter Validator dies erkennen, da die Antwort möglicherweise nicht konsistent mit den vom Miner beanspruchten Modellfähigkeiten übereinstimmt. Es ist algorithmisch schwierig zu erkennen, aber ein Miner, der niemals originelle Ergebnisse berechnet, sollte schließlich bei einigen Abfragen schlecht abschneiden und an Reputation verlieren. Ein weiteres Trittbrettfahrer-Szenario waren Delegatoren, die Belohnungen verdienten, ohne KI-Arbeit zu leisten. Das ist beabsichtigt (um Token-Inhaber einzubeziehen), also kein Angriff – aber es bedeutet, dass einige Token-Emissionen an Personen gehen, die nur gestakt haben. Bittensor rechtfertigt dies als Ausrichtung der Anreize, nicht als verschwendete Belohnungen. Kurz gesagt, Bittensor erkennt das Trittbrettfahrerproblem der Validatoren an und stimmt die Anreize ab (z. B. durch die Vergabe von Validatoren-Vertrauens-Scores, die diejenigen fördern, die nicht abweichen oder kopieren). Ihre Lösung besteht im Wesentlichen darin, Aufwand und Korrektheit expliziter zu belohnen, so dass Nichtstun oder blindes Kopieren im Laufe der Zeit weniger TAO einbringt.
  • Gensyn: In Gensyn hätten Trittbrettfahrer es schwer, zu verdienen, da man entweder Rechenleistung bereitstellen oder jemanden beim Betrug erwischen muss, um Tokens zu erhalten. Ein Solver kann Arbeit nicht „fälschen“ – er muss entweder einen gültigen Nachweis einreichen oder das Risiko des „Slashing“ eingehen. Es gibt keinen Mechanismus, um bezahlt zu werden, ohne die Aufgabe zu erledigen. Ein Verifier könnte theoretisch untätig bleiben und hoffen, dass andere Betrug aufdecken – aber dann verdient er nichts (weil nur derjenige, der den Fraud Proof vorlegt, die Belohnung erhält). Wenn zu viele Verifier versuchen, Trittbrett zu fahren (Aufgaben nicht tatsächlich neu berechnen), könnte ein betrügerischer Solver durchrutschen, weil niemand prüft. Gensyns Anreizdesign begegnet dem durch die Jackpot-Belohnung: Es braucht nur einen aktiven Verifier, um einen Betrug zu erwischen und eine große Auszahlung zu erhalten, daher ist es rational, dass mindestens einer immer die Arbeit erledigt. Andere, die keine Arbeit leisten, schaden dem Netzwerk nicht, außer dass sie nutzlos sind; sie erhalten auch keine Belohnung. Das System filtert Trittbrettfahrer also natürlich heraus: Nur diejenigen Verifier, die tatsächlich verifizieren, werden langfristig Gewinn machen (andere verschwenden Ressourcen für Knoten umsonst oder ergattern sehr selten zufällig eine Belohnung). Das Protokoll könnte auch zufällig auswählen, welcher Verifier die Möglichkeit erhält, eine Anfechtung vorzunehmen, um alle Verifier davon abzuhalten, anzunehmen, „jemand anderes wird es tun“. Da Aufgaben einzeln bezahlt werden, gibt es kein Analogon zu „Staking-Belohnungen ohne Arbeit“, abgesehen von Testnet-Anreizen, die temporär sind. Ein Bereich, den man beobachten sollte, ist die Multi-Task-Optimierung: Ein Solver könnte versuchen, Arbeit zwischen Aufgaben wiederzuverwenden oder sie heimlich an jemanden billigeren auszulagern (z. B. eine zentralisierte Cloud nutzen) – aber das ist kein wirklich schädliches Trittbrettfahren; wenn sie korrekte Ergebnisse pünktlich liefern, spielt es keine Rolle, wie sie es getan haben. Das ist eher Arbitrage als ein Angriff. Zusammenfassend lässt Gensyns Mechanismusdesign wenig Raum für Trittbrettfahrer, um zu gewinnen, da jeder verteilte Token einer erledigten Aufgabe oder einem bestraften Betrug entspricht.
  • Cuckoo: Cuckoos Anfangsphase schuf unbeabsichtigt ein Trittbrettfahrerproblem: Der Airdrop und das High-Yield-Staking zogen Benutzer an, die nur da waren, um Tokens zu farmen. Diese Benutzer würden Tokens durch Faucets zirkulieren lassen oder die Airdrop-Aufgaben manipulieren (zum Beispiel kontinuierlich kostenlose Test-Prompts verwenden oder viele Konten erstellen, um Belohnungen zu beanspruchen), ohne zum langfristigen Netzwerkwert beizutragen. Cuckoo erkannte dies als Problem – im Wesentlichen nutzten die Leute das Netzwerk nicht für KI-Outputs, sondern für spekulative Belohnungsgewinne. Die Entscheidung, die L1-Kette zu beenden und sich neu zu konzentrieren, diente teilweise dazu, diese Fehlausrichtungen der Anreize zu beseitigen. Indem zukünftige Token-Belohnungen an die tatsächliche Nutzung gebunden werden (d. h., man verdient, weil der Dienst tatsächlich von zahlenden Kunden genutzt wird), nimmt die Attraktivität des Trittbrettfahrens ab. Es gibt auch ein minerseitiges Trittbrettfahrer-Szenario: Ein Miner könnte beitreten, Aufgaben zugewiesen bekommen und diese irgendwie nicht ausführen, aber trotzdem Belohnungen beanspruchen. Der Koordinator überprüft jedoch die Ergebnisse – wenn ein Miner keine oder schlechte Outputs zurückgibt, wird der Koordinator dies nicht als abgeschlossene Aufgabe zählen, sodass der Miner nicht bezahlt würde. Miner könnten auch versuchen, einfache Aufgaben auszuwählen und schwierige fallen zu lassen (zum Beispiel, wenn einige Prompts langsamer sind, könnte ein Miner die Verbindung trennen, um sie zu vermeiden). Dies könnte ein Problem sein, aber Koordinatoren können die Zuverlässigkeit eines Miners beachten. Wenn ein Miner häufig ausfällt, kann der Koordinator aufhören, ihm Aufgaben zuzuweisen, oder seinen Stake „slashen“ (falls ein solcher Mechanismus existiert oder ihn einfach nicht belohnen). Benutzer-Trittbrettfahren – da viele KI-Dienste kostenlose Testphasen haben, könnte ein Benutzer Anfragen spammen, um Outputs ohne Bezahlung zu erhalten (wenn es ein subventioniertes Modell gibt). Das ist weniger ein Protokoll- als ein Dienstleistungsproblem; jeder Koordinator kann entscheiden, wie er mit kostenloser Nutzung umgeht (z. B. eine kleine Zahlung oder Drosselung verlangen). Da Cuckoo anfangs Werbegeschenke (wie kostenlose KI-Bildgenerierungen, um Benutzer anzuziehen) verteilte, nutzten einige dies aus, aber das war Teil des erwarteten Wachstumsmarketings. Wenn diese Aktionen enden, müssen Benutzer bezahlen, sodass es kein kostenloses Mittagessen mehr zu nutzen gibt. Insgesamt zielt Cuckoos neue Strategie, die Token-Verteilung an den tatsächlichen Nutzen zu koppeln, explizit darauf ab, das Trittbrettfahrerproblem des „Mining von Tokens für sinnlose Schleifen“ zu eliminieren.

• Daten- oder Modellvergiftung: Dies bezieht sich auf das böswillige Einführen schlechter Daten oder Verhaltensweisen, sodass die KI-Modelle sich verschlechtern oder Outputs manipuliert werden, sowie auf Probleme mit schädlichen oder voreingenommenen Inhalten, die beigesteuert werden.

  • Bittensor: Datenvergiftung in Bittensor würde bedeuten, dass ein Miner absichtlich falsche oder schädliche Antworten gibt oder Validatoren gute Antworten absichtlich falsch bewerten. Wenn ein Miner konsistent Müll oder bösartigen Inhalt ausgibt, werden Validatoren niedrige Bewertungen vergeben, und dieser Miner wird wenig verdienen und schließlich ausscheiden – der wirtschaftliche Anreiz ist, Qualität zu liefern, sodass das „Vergiften“ anderer dem Angreifer keinen Nutzen bringt (es sei denn, sein Ziel ist reine Sabotage auf eigene Kosten). Könnte ein bösartiger Miner andere vergiften? In Bittensor trainieren Miner sich nicht direkt gegenseitig (zumindest nicht von Natur aus – es gibt kein globales Modell, das aktualisiert wird und vergiftet werden könnte). Das Modell jedes Miners ist separat. Sie lernen in dem Sinne, dass ein Miner interessante Beispiele von anderen nehmen könnte, um sich selbst feinabzustimmen, aber das ist völlig optional und jedem selbst überlassen. Wenn ein böswilliger Akteur unsinnige Antworten spammen würde, würden ehrliche Validatoren dies herausfiltern (sie würden es niedrig bewerten), sodass es den Trainingsprozess eines ehrlichen Miners nicht wesentlich beeinflussen würde (außerdem würde ein Miner wahrscheinlich das Wissen von hoch bewerteten Peers nutzen, nicht von niedrig bewerteten). Klassische Datenvergiftung (Einspeisung schlechter Trainingsdaten zur Korruption eines Modells) ist in Bittensors aktueller Konfiguration minimal. Das relevantere Risiko ist die Manipulation von Modellantworten: z. B. ein Miner, der subtil voreingenommene oder gefährliche Inhalte ausgibt, die für Validatoren nicht offensichtlich sind. Da Validatoren jedoch auch von Menschen entworfen oder zumindest algorithmische Agenten sind, wird offensichtliche Toxizität oder Fehler wahrscheinlich erkannt (einige Subnetze könnten sogar KI-Validatoren haben, die auf unsichere Inhalte prüfen). Ein Worst-Case-Szenario wäre, wenn ein Angreifer irgendwie eine Mehrheit der Validatoren und Miner dazu bringen könnte, eine bestimmte falsche Ausgabe als „korrekt“ durchzusetzen – sie könnten dann den Konsens des Netzwerks über Antworten verzerren (wie alle kolludierenden Validatoren eine bösartige Antwort hochstufen). Aber damit ein externer Benutzer dadurch geschädigt wird, müsste er das Netzwerk tatsächlich abfragen und der Ausgabe vertrauen. Bittensor befindet sich noch in einer Phase, in der es Fähigkeiten aufbaut, und wird von Endbenutzern nicht weit verbreitet für kritische Abfragen verwendet. Bis dahin hofft man, dass es Inhaltsfilterung und eine Vielfalt von Validatoren haben wird, um solche Risiken zu mindern. Auf der Validatorenseite könnte ein bösartiger Validator vergiftete Bewertungen einspeisen – z. B. einen bestimmten ehrlichen Miner konsequent herabstufen, um den Wettbewerb zu eliminieren. Mit genügend Stake könnten sie erfolgreich sein, diesen Miner zu verdrängen (wenn die Belohnungen des Miners so stark sinken, dass er geht). Dies ist ein Angriff auf den Anreizmechanismus. Auch hier gilt: Wenn sie nicht die Mehrheit sind, wird das Median-Clipping einen Ausreißer-Validator vereiteln. Wenn sie die Mehrheit sind, verschmilzt es mit dem Kollusions-/51%-Szenario – jede Mehrheit kann Regeln umschreiben. Die Lösung kehrt zur Dezentralisierung zurück: verhindern, dass eine einzelne Entität dominiert. Zusammenfassend bestraft Bittensors Design vergiftete Daten-/Modellbeiträge über sein Bewertungssystem – schlechte Beiträge erhalten geringes Gewicht und somit geringe Belohnung. Es gibt kein permanentes Modell-Repository zum Vergiften; alles ist dynamisch und wird kontinuierlich bewertet. Dies bietet Resilienz: Das Netzwerk kann schlechte Akteure allmählich „vergessen“ oder ignorieren, da ihre Beiträge von Validatoren herausgefiltert werden.
  • Gensyn: Wenn ein Solver ein zu trainierendes Modell vergiften wollte (z. B. eine Hintertür oder eine Verzerrung während des Trainings einführen), könnte er versuchen, dies heimlich zu tun. Das Gensyn-Protokoll würde überprüfen, ob das Training gemäß dem angegebenen Algorithmus (stochastische Gradientenabstiegs-Schritte usw.) verlief, würde aber nicht unbedingt erkennen, ob der Solver einen subtilen Hintertür-Trigger eingeführt hat, der in normalen Validierungsmetriken nicht auftaucht. Dies ist ein heimtückischeres Problem – es ist kein Fehler der Berechnung, sondern eine Manipulation innerhalb der zulässigen Freiheitsgrade des Trainings (wie das Anpassen von Gewichten an eine Triggerphrase). Die Erkennung dessen ist ein aktives Forschungsproblem in der ML-Sicherheit. Gensyn hat keinen speziellen Mechanismus zur Modellvergiftung, abgesehen davon, dass der Submitter das endgültige Modell auf einem Testset seiner Wahl bewerten könnte. Ein versierter Submitter sollte das zurückgegebene Modell immer testen; wenn er feststellt, dass es bei einigen Eingaben fehlschlägt oder ein seltsames Verhalten aufweist, kann er das Ergebnis anfechten oder die Zahlung verweigern. Vielleicht könnte das Protokoll einem Submitter erlauben, bestimmte Akzeptanzkriterien festzulegen (wie „Modell muss mindestens X Genauigkeit auf diesem geheimen Testset erreichen“), und wenn das Ergebnis des Solvers fehlschlägt, wird der Solver nicht vollständig bezahlt. Dies würde eine Vergiftung abschrecken, da der Angreifer die Bewertungskriterien nicht erfüllen würde. Wenn das Gift jedoch die Genauigkeit bei normalen Tests nicht beeinträchtigt, könnte es durchrutschen. Verifier in Gensyn überprüfen nur die Berechnungsintegrität, nicht die Modellqualität, sodass sie absichtliches Overfitting oder Trojaner nicht erkennen würden, solange die Trainingsprotokolle gültig aussehen. Dies bleibt also ein Vertrauensproblem auf Aufgabenebene: Der Submitter muss entweder darauf vertrauen, dass der Solver das Modell nicht vergiften wird, oder Methoden wie das Ensembling mehrerer Trainingsergebnisse von verschiedenen Solvern verwenden, um den Einfluss eines einzelnen Solvers zu verwässern. Ein weiterer Aspekt ist die Datenvergiftung: Wenn der Submitter Trainingsdaten bereitstellt, könnte ein böswilliger Solver diese Daten ignorieren und auf etwas anderem trainieren oder Mülldaten hinzufügen. Dies würde jedoch wahrscheinlich die Genauigkeit verringern, was der Submitter an der Leistung des Ausgabemodells bemerken würde. Der Solver würde dann keine volle Zahlung erhalten (da er vermutlich ein Leistungsziel erreichen möchte). Eine Vergiftung, die die Leistung beeinträchtigt, ist also für die Belohnung des Solvers selbstzerstörerisch. Nur ein Gift, das leistungsneutral, aber bösartig ist (eine Hintertür), ist eine echte Gefahr, und das liegt außerhalb des Bereichs der typischen Blockchain-Verifizierung – es ist eine Herausforderung der Machine-Learning-Sicherheit. Gensyns beste Minderung ist wahrscheinlich sozial: bekannte, seriöse Modelle verwenden, mehrere Trainingsläufe durchführen, Open-Source-Tools verwenden. Bei Inferenzaufgaben (wenn Gensyn auch für Inferenzjobs verwendet wird) könnte ein kolludierender Solver falsche Outputs zurückgeben, die eine bestimmte Antwort verzerren. Aber Verifier würden falsche Outputs erkennen, wenn sie dasselbe Modell ausführen, sodass dies weniger eine Vergiftung als vielmehr Betrug ist, den die Fraud Proofs adressieren. Zusammenfassend lässt sich sagen, dass Gensyn den Prozess, nicht die Absicht, sichert. Es stellt sicher, dass das Training/die Inferenz korrekt durchgeführt wurde, aber nicht, dass das Ergebnis gut oder frei von versteckten Gemeinheiten ist. Das bleibt ein offenes Problem, und Gensyns Whitepaper löst dies wahrscheinlich noch nicht vollständig (nur wenige tun dies).
  • Cuckoo: Da Cuckoo derzeit auf Inferenz (Bereitstellung bestehender Modelle) fokussiert ist, ist das Risiko von Daten-/Modellvergiftung relativ begrenzt auf Output-Manipulation oder Inhaltsvergiftung. Ein böswilliger Miner könnte versuchen, das Modell, das er ausführen soll, zu manipulieren – z. B. wenn er einen Stable Diffusion Checkpoint erhält, könnte er ihn durch ein anderes Modell ersetzen, das vielleicht ein subtiles Wasserzeichen oder eine Werbung in jedes Bild einfügt. Der Koordinator (der der Modelleigentümer ist) sendet Aufgaben jedoch typischerweise mit einer Erwartung an das Ausgabeformat; wenn ein Miner konsistent nicht-spezifikationsgerechte Outputs zurückgibt, wird der Koordinator diesen Miner kennzeichnen und sperren. Außerdem können Miner ein Modell nicht einfach ändern, ohne dessen Outputs merklich zu beeinflussen. Ein weiteres Szenario ist, wenn Cuckoo von der Community trainierte Modelle einführt: Dann könnten Miner oder Datenanbieter versuchen, die Trainingsdaten zu vergiften (zum Beispiel viele falsche Labels oder voreingenommenen Text einzugeben). Cuckoo müsste eine Validierung von Crowd-sourced-Daten oder eine Gewichtung der Mitwirkenden implementieren. Dies ist noch keine Funktion, aber das Interesse des Teams an personalisierter KI (wie ihre Erwähnung von KI-Life-Coaches oder Lern-Apps) bedeutet, dass sie möglicherweise irgendwann benutzerbereitgestellte Trainingsdaten verarbeiten werden, was sorgfältige Überprüfungen erfordert. Was die Inhaltssicherheit betrifft, so könnte man sich, da Cuckoo-Miner Inferenz durchführen, Sorgen machen, dass sie schädliche Inhalte ausgeben, selbst wenn das Modell dies normalerweise nicht tun würde. Miner haben jedoch keinen Anreiz, Outputs willkürlich zu ändern – sie werden für korrekte Berechnung bezahlt, nicht für Kreativität. Wenn überhaupt, könnte ein böswilliger Miner die vollständige Berechnung überspringen, um Zeit zu sparen (z. B. ein unscharfes Bild oder eine generische Antwort zurückgeben). Der Koordinator oder Benutzer würde dies sehen und diesen Miner herabstufen (und wahrscheinlich nicht für diese Aufgabe bezahlen). Datenschutz ist ein weiterer Aspekt: Ein böswilliger Miner könnte Benutzerdaten leaken oder protokollieren (z. B. wenn ein Benutzer sensible Texte oder Bilder eingibt). Dies ist keine Vergiftung, sondern ein Angriff auf die Vertraulichkeit. Cuckoos Datenschutzhaltung ist, dass es datenschutzfreundliche Methoden erforscht (die Erwähnung eines datenschutzfreundlichen VPN im Ökosystem deutet auf einen zukünftigen Fokus hin). Sie könnten Techniken wie sichere Enklaven oder geteilte Inferenz integrieren, um Daten vor Minern privat zu halten. Noch nicht implementiert, aber eine bekannte Überlegung. Schließlich betont Cuckoos Blog die effektive Überprüfung von Modellausgaben und die Sicherstellung eines sicheren dezentralen Modellbetriebs als Schlüssel zur Realisierung der Modell-Tokenisierung. Dies deutet darauf hin, dass sie sich bewusst sind, dass man, um KI wirklich zu dezentralisieren, sich gegen Dinge wie vergiftete Outputs oder fehlerhafte Modelle schützen muss. Möglicherweise beabsichtigen sie, eine Kombination aus kryptoökonomischen Anreizen (Stake-Slashing für schlechte Akteure) und Benutzerbewertungssystemen (Benutzer können schlechte Outputs kennzeichnen, und diese Miner verlieren Reputation) zu verwenden. Das Reputationssystem kann hier helfen: Wenn ein Miner auch nur ein offensichtlich bösartiges oder falsches Ergebnis zurückgibt, können Benutzer/Koordinatoren ihn herabstufen, was seine zukünftige Verdienstfähigkeit stark beeinträchtigt. In dem Wissen darum sind Miner motiviert, konsistent

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jedes hat Stärken und Kompromisse:

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

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

| Protokoll | Transaktionsreihenfolge Flash to the German translation:

Summary of differences in the German translation:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jedes hat Stärken und Kompromisse:

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

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

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

Fazit und Ausblick​

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

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

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

Hier ist eine zusammenfassende Übersicht des Berichts über Innovationen in der Web3-Entwicklererfahrung (DevEx).

Zusammenfassung​

Die Web3-Entwicklererfahrung hat sich in den Jahren 2024-2025 erheblich weiterentwickelt, angetrieben durch Innovationen bei Programmiersprachen, Toolchains und der Bereitstellungsinfrastruktur. Entwickler berichten von höherer Produktivität und Zufriedenheit dank schnellerer Tools, sichererer Sprachen und optimierter Arbeitsabläufe. Diese Zusammenfassung konsolidiert Erkenntnisse zu fünf Schlüssel-Toolchains (Solidity, Move, Sway, Foundry und Cairo 1.0) und zwei wichtigen Trends: der „One-Click“-Rollup-Bereitstellung und dem Smart Contract Hot-Reloading.

Vergleich von Web3-Entwickler-Toolchains​

Jede Toolchain bietet unterschiedliche Vorteile und richtet sich an verschiedene Ökosysteme und Entwicklungsphilosophien.

• Solidity (EVM): Bleibt die dominierendste Sprache aufgrund ihres riesigen Ökosystems, umfangreicher Bibliotheken (z. B. OpenZeppelin) und ausgereifter Frameworks wie Hardhat und Foundry. Obwohl ihr native Funktionen wie Makros fehlen, machen ihre weite Verbreitung und starke Community-Unterstützung sie zur Standardwahl für Ethereum und die meisten EVM-kompatiblen L2s.
• Move (Aptos/Sui): Priorisiert Sicherheit und formale Verifikation. Sein ressourcenbasiertes Modell und das Tool Move Prover helfen, gängige Fehler wie Reentrancy von Grund auf zu verhindern. Dies macht es ideal für hochsichere Finanzanwendungen, obwohl sein Ökosystem kleiner ist und sich auf die Aptos- und Sui-Blockchains konzentriert.
• Sway (FuelVM): Entwickelt für maximale Entwicklerproduktivität, indem es Entwicklern ermöglicht, Verträge, Skripte und Tests in einer einzigen Rust-ähnlichen Sprache zu schreiben. Es nutzt die hochdurchsatzfähige, UTXO-basierte Architektur der Fuel Virtual Machine und ist damit eine leistungsstarke Wahl für performanceintensive Anwendungen im Fuel-Netzwerk.
• Foundry (EVM-Toolkit): Ein transformatives Toolkit für Solidity, das die EVM-Entwicklung revolutioniert hat. Es bietet extrem schnelle Kompilierung und Tests, wodurch Entwickler Tests direkt in Solidity schreiben können. Funktionen wie Fuzz-Testing, Mainnet-Forking und „Cheatcodes“ haben es zur ersten Wahl für über die Hälfte der Ethereum-Entwickler gemacht.
• Cairo 1.0 (Starknet): Stellt eine wesentliche DevEx-Verbesserung für das Starknet-Ökosystem dar. Der Übergang zu einer hochrangigen, von Rust inspirierten Syntax und modernen Tools (wie dem Scarb Paketmanager und Starknet Foundry) hat die Entwicklung für ZK-Rollups erheblich schneller und intuitiver gemacht. Während einige Tools wie Debugger noch in der Reifung sind, ist die Entwicklerzufriedenheit stark gestiegen.

Wichtige DevEx-Innovationen​

Zwei wichtige Trends verändern die Art und Weise, wie Entwickler dezentrale Anwendungen erstellen und bereitstellen.

„One-Click“-Rollup-Bereitstellung​

Die Einführung einer benutzerdefinierten Blockchain (L2/Appchain) ist radikal einfacher geworden.

• Grundlage: Frameworks wie Optimism’s OP Stack bieten einen modularen, Open-Source-Bauplan für die Erstellung von Rollups.
• Plattformen: Dienste wie Caldera und Conduit haben Rollup-as-a-Service (RaaS)-Plattformen geschaffen. Sie bieten Web-Dashboards, die es Entwicklern ermöglichen, ein angepasstes Mainnet- oder Testnet-Rollup in wenigen Minuten bereitzustellen, mit minimalem Blockchain-Engineering-Know-how.
• Auswirkungen: Dies ermöglicht schnelle Experimente, senkt die Hürde für die Erstellung anwendungsspezifischer Chains und vereinfacht DevOps, sodass Teams sich auf ihre Anwendung statt auf die Infrastruktur konzentrieren können.

Hot-Reloading für Smart Contracts​

Diese Innovation bringt die sofortige Feedback-Schleife der modernen Webentwicklung in den Blockchain-Bereich.

• Konzept: Tools wie Scaffold-ETH 2 automatisieren den Entwicklungszyklus. Wenn ein Entwickler eine Änderung an einem Smart Contract speichert, kompiliert das Tool automatisch neu, stellt es in einem lokalen Netzwerk bereit und aktualisiert das Frontend, um die neue Logik widerzuspiegeln.
• Auswirkungen: Hot-Reloading eliminiert wiederholende manuelle Schritte und verkürzt die Iterationsschleife drastisch. Dies macht den Entwicklungsprozess ansprechender, senkt die Lernkurve für neue Entwickler und fördert häufiges Testen, was zu qualitativ hochwertigerem Code führt.

Fazit​

Die Web3-Entwicklungslandschaft reift rasant. Die Konvergenz sichererer Sprachen, schnellerer Tools wie Foundry und vereinfachter Infrastrukturbereitstellung über RaaS-Plattformen schließt die Lücke zwischen Blockchain- und traditioneller Softwareentwicklung. Diese DevEx-Verbesserungen sind ebenso entscheidend wie Innovationen auf Protokollebene, da sie Entwickler befähigen, komplexere und sicherere Anwendungen schneller zu erstellen. Dies wiederum fördert das Wachstum und die Akzeptanz des gesamten Blockchain-Ökosystems.

Quellen:

• Solidity Developer Survey 2024 – Soliditylang (2025)
• Moncayo Labs on Aptos Move vs Solidity (2024)
• Aptos Move Prover intro – Monethic (2025)
• Fuel Labs – Fuel & Sway Documentation (2024); Fuel Book (2024)
• Spearmanrigoberto – Foundry vs Hardhat (2023)
• Medium (Rosario Borgesi) – Building Dapps with Scaffold-ETH 2 (2024)
• Starknet/Cairo developer survey – Cairo-lang.org (2024)
• Starknet Dev Updates – Starknet.io (2024–2025)
• Solidity forum – Macro preprocessor discussion (2023)
• Optimism OP Stack overview – CoinDesk (2025)
• Caldera rollup platform overview – Medium (2024)
• Conduit platform recap – Conduit Blog (2025)
• Blockchain DevEx literature review – arXiv (2025)

Einführung​

Das schnelle Wachstum von Layer-1- und Layer-2-Blockchains hat die Web3-Benutzererfahrung fragmentiert. Nutzer jonglieren heute mit mehreren Wallets, Netzwerken und Token-Brücken, nur um komplexe, kettenübergreifende Aufgaben zu erledigen. Kettenabstraktion und Intent-zentrierte Architektur haben sich als Schlüsselparadigmen zur Vereinfachung dieser Landschaft herauskristallisiert. Indem sie kättenspezifische Details abstrahieren und es Nutzern ermöglichen, auf Intents (gewünschte Ergebnisse) zu reagieren, anstatt explizite kettenbezogene Transaktionen zu erstellen, versprechen diese Ansätze eine vereinheitlichte, nahtlose Cross-Chain-Erfahrung. Dieser Bericht befasst sich mit den Kernprinzipien der Kettenabstraktion, dem Design Intent-fokussierter Ausführungsmodelle, realen Implementierungen (wie Wormhole und Etherspot), technischen Grundlagen (Relayer, Smart Wallets usw.) und den UX-Vorteilen für Entwickler und Endnutzer. Wir fassen auch Erkenntnisse der EthCC 2025 zusammen – wo Kettenabstraktion und Intents heiße Themen waren – und stellen eine Vergleichstabelle verschiedener Protokollansätze bereit.

Prinzipien der Kettenabstraktion​

Kettenabstraktion bezieht sich auf jede Technologie oder jedes Framework, das Nutzern und Entwicklern mehrere Blockchains so präsentiert, als wären sie eine einzige, vereinheitlichte Umgebung. Die Motivation besteht darin, die durch Kettenheterogenität verursachte Reibung zu eliminieren. In der Praxis bedeutet Kettenabstraktion:

• Vereinheitlichte Schnittstellen: Anstatt separate Wallets und RPC-Endpunkte für jede Blockchain zu verwalten, interagieren Nutzer über eine einzige Schnittstelle, die Netzwerkdetails verbirgt. Entwickler können dApps erstellen, ohne separate Verträge auf jeder Kette bereitzustellen oder eine benutzerdefinierte Brückenlogik für jedes Netzwerk zu schreiben.
• Kein manuelles Bridging: Das Verschieben von Assets oder Daten zwischen Ketten geschieht im Hintergrund. Nutzer führen keine manuellen Sperr-/Prägebrückentransaktionen aus oder tauschen keine Brückentoken; die Abstraktionsschicht erledigt dies automatisch. Ein Nutzer könnte beispielsweise Liquidität in einem Protokoll bereitstellen, unabhängig davon, auf welcher Kette sich die Liquidität befindet, und das System leitet die Gelder entsprechend weiter.
• Gasgebühren-Abstraktion: Nutzer müssen nicht mehr den nativen Token jeder Kette halten, um Gas auf dieser Kette zu bezahlen. Die Abstraktionsschicht kann Gasgebühren sponsern oder die Zahlung von Gas in einem vom Nutzer gewählten Asset ermöglichen. Dies senkt die Eintrittsbarriere, da man ETH, MATIC, SOL usw. nicht separat erwerben muss.
• Netzwerkagnostische Logik: Die Anwendungslogik wird kettenagnostisch. Smart Contracts oder Off-Chain-Dienste koordinieren die Ausführung von Nutzeraktionen auf den jeweils erforderlichen Ketten, ohne dass der Nutzer manuell Netzwerke wechseln oder mehrere Transaktionen signieren muss. Im Wesentlichen erlebt der Nutzer eine „Meta-Kette“ oder eine Blockchain-agnostische Anwendungsschicht.

Die Kernidee ist, dass sich Nutzer darauf konzentrieren, was sie erreichen wollen, nicht welche Kette oder wie sie es erreichen. Eine bekannte Analogie sind Webanwendungen, die den Serverstandort abstrahieren – so wie ein Nutzer nicht wissen muss, welchen Server oder welche Datenbank seine Anfrage berührt, sollte ein Web3-Nutzer nicht wissen müssen, welche Kette oder Brücke für eine Aktion verwendet wird. Durch das Routing von Transaktionen über eine vereinheitlichte Schicht reduziert die Kettenabstraktion die Fragmentierung des heutigen Multi-Chain-Ökosystems.

Motivation: Der Drang zur Kettenabstraktion resultiert aus den Schwachstellen aktueller Cross-Chain-Workflows. Die Verwaltung separater Wallets pro Kette und die Durchführung mehrstufiger Cross-Chain-Operationen (Swap auf Kette A, Bridge zu Kette B, erneuter Swap auf Kette B usw.) ist mühsam und fehleranfällig. Fragmentierte Liquidität und inkompatible Wallets begrenzen auch das dApp-Wachstum über Ökosysteme hinweg. Die Kettenabstraktion begegnet diesen Problemen, indem sie Ökosysteme kohärent verbindet. Wichtig ist, dass sie Ethereum und seine vielen L2s und Sidechains als Teil einer einzigen Benutzererfahrung behandelt. Die EthCC 2025 betonte, dass dies für die Mainstream-Adoption entscheidend ist – Redner argumentierten, dass eine wirklich nutzerzentrierte Web3-Zukunft „Blockchains abstrahieren muss“, um die Multi-Chain-Welt so einfach wie ein einzelnes Netzwerk erscheinen zu lassen.

Intent-zentrierte Architektur: Von Transaktionen zu Intents​

Traditionelle Blockchain-Interaktionen sind transaktionszentriert: Ein Nutzer erstellt und signiert explizit eine Transaktion, die spezifische Operationen (Aufruf einer Vertragsfunktion, Übertragung eines Tokens usw.) auf einer ausgewählten Kette ausführt. In einem Multi-Chain-Kontext könnte das Erreichen eines komplexen Ziels viele solcher Transaktionen über verschiedene Netzwerke erfordern, die jeweils vom Nutzer manuell in der richtigen Reihenfolge initiiert werden. Die Intent-zentrierte Architektur kehrt dieses Modell um. Anstatt Transaktionen mikromanagend zu steuern, deklariert der Nutzer einen Intent – ein übergeordnetes Ziel oder gewünschtes Ergebnis – und lässt ein automatisiertes System die zur Erfüllung erforderlichen Transaktionen ermitteln.

Bei einem Intent-basierten Design könnte ein Nutzer sagen: „Tausche 100 USDC auf Base gegen 100 USDT auf Arbitrum“. Dieser Intent fasst das Was (Tausch eines Assets gegen ein anderes auf einer Zielkette) zusammen, ohne das Wie vorzuschreiben. Ein spezialisierter Agent (oft als Solver bezeichnet) übernimmt dann die Aufgabe, dies zu erledigen. Der Solver ermittelt, wie der Tausch am besten kettenübergreifend ausgeführt werden kann – zum Beispiel könnte er die USDC von Base über eine schnelle Brücke nach Arbitrum überbrücken und dann einen Tausch in USDT durchführen, oder ein direktes Cross-Chain-Swap-Protokoll verwenden – was auch immer das beste Ergebnis liefert. Der Nutzer signiert eine einzige Autorisierung, und der Solver wickelt die komplexe Sequenz im Backend ab, einschließlich der Suche nach der optimalen Route, der Übermittlung der notwendigen Transaktionen auf jeder Kette und sogar der Vorfinanzierung eventuell erforderlicher Gasgebühren oder der Übernahme von Zwischenrisiken.

Wie Intents eine flexible Ausführung ermöglichen: Indem das System die Freiheit erhält zu entscheiden, wie eine Anfrage erfüllt werden soll, ermöglicht ein Intent-zentriertes Design wesentlich intelligentere und flexiblere Ausführungsschichten als feste Benutzertransaktionen. Einige Vorteile:

• Optimales Routing: Solver können Kosten, Geschwindigkeit oder Zuverlässigkeit optimieren. Beispielsweise könnten mehrere Solver darum konkurrieren, den Intent eines Nutzers zu erfüllen, und eine On-Chain-Auktion kann denjenigen auswählen, der den besten Preis (z. B. den besten Wechselkurs oder die niedrigsten Gebühren) anbietet. Dieser Wettbewerb senkt die Kosten für den Nutzer. Wormholes Mayan Swift-Protokoll ist ein Beispiel, das für jeden Intent eine On-Chain-Englische Auktion auf Solana einbettet und den Wettbewerb von einem „Wer zuerst kommt“-Rennen zu einem preisbasierten Bieten für bessere Nutzerergebnisse verlagert. Der Solver, der den Swap für den Nutzer am profitabelsten ausführen kann, gewinnt das Gebot und führt den Plan aus, wodurch sichergestellt wird, dass der Nutzer den größten Wert erhält. Diese Art der dynamischen Preisfindung ist nicht möglich, wenn ein Nutzer in einer regulären Transaktion einen einzigen Pfad vordefiniert.
• Resilienz und Flexibilität: Wenn eine Brücke oder ein DEX im Moment nicht verfügbar oder suboptimal ist, kann ein Solver einen alternativen Pfad wählen. Der Intent bleibt derselbe, aber die Ausführungsschicht kann sich an die Netzwerkbedingungen anpassen. Intents ermöglichen somit programmierbare Ausführungsstrategien – z. B. das Aufteilen einer Order oder das Wiederholen über eine andere Route – alles unsichtbar für den Endnutzer, dem es nur darum geht, dass sein Ziel erreicht wird.
• Atomare Multi-Chain-Aktionen: Intents können das umfassen, was traditionell mehrere Transaktionen auf verschiedenen Ketten wären. Ausführungs-Frameworks bemühen sich, die gesamte Sequenz atomar oder zumindest fehlerverwaltet erscheinen zu lassen. Zum Beispiel könnte der Solver den Intent nur dann als erfüllt betrachten, wenn alle Untertransaktionen (Bridge, Swap usw.) bestätigt sind, und bei einem Fehler zurückrollen oder kompensieren. Dies stellt sicher, dass die übergeordnete Aktion des Nutzers entweder vollständig abgeschlossen oder gar nicht ausgeführt wird, was die Zuverlässigkeit verbessert.
• Komplexitätsverlagerung: Intents vereinfachen die Rolle des Nutzers dramatisch. Der Nutzer muss nicht verstehen, welche Brücken oder Börsen zu verwenden sind, wie Liquidität aufgeteilt oder Operationen geplant werden – all das wird auf die Infrastruktur ausgelagert. Wie ein Bericht es ausdrückt: „Nutzer konzentrieren sich auf das Was, nicht auf das Wie“. Ein direkter Vorteil ist die Benutzererfahrung: Die Interaktion mit Blockchain-Anwendungen wird eher wie die Nutzung einer Web2-App (wo ein Nutzer einfach ein Ergebnis anfordert und der Dienst den Prozess abwickelt).

Im Wesentlichen erhöht eine Intent-zentrierte Architektur das Abstraktionsniveau von Low-Level-Transaktionen zu High-Level-Zielen. Die Ethereum-Community ist so begeistert von diesem Modell, dass die Ethereum Foundation das Open Intents Framework (OIF) eingeführt hat, einen offenen Standard und eine Referenzarchitektur für den Aufbau von Cross-Chain-Intent-Systemen. Das OIF definiert Standardschnittstellen (wie das ERC-7683 Intent-Format) dafür, wie Intents über Ketten hinweg erstellt, kommuniziert und abgewickelt werden, sodass viele verschiedene Lösungen (Brücken, Relayer, Auktionsmechanismen) modular angeschlossen werden können. Dies fördert ein ganzes Ökosystem von Solvern und Settlement-Protokollen, die interoperabel sein können. Der Aufstieg von Intents basiert auf der Notwendigkeit, Ethereum und seine Rollups aus UX-Sicht „wie eine einzige Kette“ erscheinen zu lassen – schnell und reibungslos genug, dass das Bewegen über L2s oder Sidechains in Sekunden ohne Benutzerprobleme geschieht. Frühe Standards wie ERC-7683 (für standardisiertes Intent-Format und Lebenszyklus) haben sogar Unterstützung von Führungspersönlichkeiten wie Vitalik Buterin erhalten, was die Dynamik hinter Intent-zentrierten Designs unterstreicht.

Zusammenfassung der Hauptvorteile: Zusammenfassend bieten Intent-zentrierte Architekturen mehrere entscheidende Vorteile: (1) Vereinfachte UX – Nutzer geben an, was sie wollen, und das System erledigt den Rest; (2) Cross-Chain-Fluidität – Operationen, die mehrere Netzwerke umfassen, werden nahtlos abgewickelt, wodurch viele Ketten effektiv als eine behandelt werden; (3) Entwickler-Skalierbarkeit – dApp-Entwickler können Nutzer und Liquidität über viele Ketten hinweg erreichen, ohne das Rad für jede neu erfinden zu müssen, da die Intent-Schicht standardisierte Schnittstellen zur Cross-Chain-Ausführung bietet. Indem das Was getan werden muss vom Wie/Wo es getan wird entkoppelt wird, fungieren Intents als Brücke zwischen nutzerfreundlicher Innovation und der komplexen Interoperabilität im Hintergrund.

Technische Bausteine der Cross-Chain-Abstraktion​

Die Implementierung von Kettenabstraktion und Intent-basierter Ausführung erfordert einen Stack technischer Mechanismen, die im Zusammenspiel arbeiten. Zu den Schlüsselkomponenten gehören:

• Cross-Chain Messaging Relayer: Im Kern jedes Multi-Chain-Systems befindet sich eine Messaging-Schicht, die Daten und Werte zuverlässig zwischen Blockchains übertragen kann. Protokolle wie Wormhole, Hyperlane, Axelar, LayerZero und andere bieten diese Fähigkeit, indem sie Nachrichten (oft mit Proofs oder Validator-Bestätigungen) von einer Quellkette zu einer oder mehreren Zielketten weiterleiten. Diese Nachrichten können Befehle wie „diesen Intent ausführen“ oder „dieses Asset prägen“ auf der Zielkette enthalten. Ein robustes Relayer-Netzwerk ist entscheidend für einheitliches Transaktions-Routing – es dient als „Postdienst“ zwischen den Ketten. Zum Beispiel beobachtet Wormholes Netzwerk von 19 Guardian-Knoten Ereignisse auf verbundenen Ketten und signiert eine VAA (verifiable action approval), die an jede andere Kette übermittelt werden kann, um ein Ereignis zu beweisen. Dies entkoppelt die Aktion von einer einzelnen Kette und ermöglicht kettenagnostisches Verhalten. Moderne Relayer konzentrieren sich darauf, kettenagnostisch (viele Kettentypen unterstützend) und zur Sicherheit dezentralisiert zu sein. Wormhole beispielsweise geht über EVM-basierte Ketten hinaus, um Solana, Cosmos-Ketten usw. zu unterstützen, was es zu einer vielseitigen Wahl für die Cross-Chain-Kommunikation macht. Die Messaging-Schicht übernimmt oft auch die Reihenfolge, Wiederholungen und Finalitätsgarantien für Cross-Chain-Transaktionen.

• Smart Contract Wallets (Account Abstraction): Account Abstraction (z. B. Ethereums ERC-4337) ersetzt extern verwaltete Konten durch Smart Contract Konten, die mit benutzerdefinierter Validierungslogik und mehrstufigen Transaktionsfunktionen programmiert werden können. Dies ist eine Grundlage für die Kettenabstraktion, da ein Smart Wallet als einziges Meta-Konto des Nutzers dienen kann, das Assets auf allen Ketten kontrolliert. Projekte wie Etherspot verwenden Smart Contract Wallets, um Funktionen wie Transaktions-Batching und Session Keys über Ketten hinweg zu ermöglichen. Ein Intent eines Nutzers könnte als einzelne User Operation (im Sinne von 4337) verpackt werden, die der Wallet-Vertrag dann in mehrere Untertransaktionen auf verschiedenen Netzwerken erweitert. Smart Wallets können auch Paymaster (Sponsoren) integrieren, um Gasgebühren im Namen des Nutzers zu bezahlen, was eine echte Gasabstraktion ermöglicht (der Nutzer könnte in einem Stablecoin bezahlen oder gar nicht). Sicherheitsmechanismen wie Session Keys (temporäre Schlüssel mit begrenzten Berechtigungen) ermöglichen es Nutzern, Intents, die mehrere Aktionen umfassen, ohne mehrere Aufforderungen zu genehmigen, während das Risiko begrenzt wird. Kurz gesagt, Account Abstraction bietet den programmierbaren Ausführungscontainer, der einen übergeordneten Intent interpretieren und die notwendigen Schritte als eine Reihe von Transaktionen (oft über die Relayer) orchestrieren kann.

• Intent-Orchestrierung und Solver: Oberhalb der Messaging- und Wallet-Schicht befindet sich das Intent-Solver-Netzwerk – das Gehirn, das herausfindet, wie Intents erfüllt werden. In einigen Architekturen ist diese Logik On-Chain (z. B. ein On-Chain-Auktionsvertrag, der Intent-Orders mit Solvern abgleicht, wie bei Wormholes Solana-Auktion für Mayan Swift). In anderen Fällen sind es Off-Chain-Agenten, die einen Intent-Mempool oder ein Orderbuch überwachen (zum Beispiel bietet das Open Intents Framework einen Referenz-TypeScript-Solver, der auf neue Intent-Ereignisse lauscht und dann Transaktionen zur Erfüllung übermittelt). Solver müssen typischerweise Folgendes handhaben: das Finden von Liquiditätsrouten (über DEXes, Brücken), Preisfindung (Sicherstellung, dass der Nutzer einen fairen Kurs erhält) und manchmal die Deckung von Zwischenkosten (wie das Stellen von Sicherheiten oder die Übernahme von Finalitätsrisiken – die Bereitstellung von Geldern an den Nutzer, bevor die Cross-Chain-Übertragung vollständig finalisiert ist, wodurch die UX auf Kosten des Solvers beschleunigt wird). Ein gut konzipiertes Intent-zentriertes System beinhaltet oft einen Wettbewerb unter Solvern, um sicherzustellen, dass der Intent des Nutzers optimal ausgeführt wird. Solver können wirtschaftlich Anreize erhalten (z. B. verdienen sie eine Gebühr oder einen Arbitrage-Gewinn für die Erfüllung des Intents). Mechanismen wie Solver-Auktionen oder Batching können verwendet werden, um die Effizienz zu maximieren. Wenn beispielsweise mehrere Nutzer ähnliche Intents haben, könnte ein Solver diese bündeln, um die Brückengebühren pro Nutzer zu minimieren.

• Vereinheitlichte Liquidität und Token-Abstraktion: Das Verschieben von Assets über Ketten hinweg führt zum klassischen Problem fragmentierter Liquidität und Wrapped Tokens. Kettenabstraktionsschichten abstrahieren oft die Tokens selbst – mit dem Ziel, dem Nutzer die Erfahrung eines einzelnen Assets zu vermitteln, das auf vielen Ketten verwendet werden kann. Ein Ansatz sind Omnichain-Tokens (wobei ein Token nativ auf mehreren Ketten unter einer Gesamtversorgung existieren kann, anstatt vieler inkompatibler Wrapped-Versionen). Wormhole führte Native Token Transfers (NTT) als Weiterentwicklung traditioneller Lock-and-Mint-Brücken ein: Anstatt unendlicher „gebrückter“ IOU-Tokens behandelt das NTT-Framework Tokens, die über Ketten hinweg bereitgestellt werden, als ein Asset mit gemeinsamen Mint-/Burn-Kontrollen. In der Praxis bedeutet das Bridging eines Assets unter NTT das Brennen auf der Quelle und das Prägen auf dem Ziel, wodurch eine einzige zirkulierende Versorgung aufrechterhalten wird. Diese Art der Liquiditätsvereinheitlichung ist entscheidend, damit die Kettenabstraktion Assets „teleportieren“ kann, ohne den Nutzer mit mehreren Token-Darstellungen zu verwirren. Andere Projekte verwenden Liquiditätsnetzwerke oder -pools (z. B. Connext oder Axelar), wo Liquiditätsanbieter auf jeder Kette Kapital bereitstellen, um Assets ein- und auszutauschen, sodass Nutzer effektiv ein Asset gegen sein Äquivalent auf einer anderen Kette in einem Schritt tauschen können. Das Beispiel des Securitize SCOPE Fonds ist anschaulich: Ein institutioneller Fondstoken wurde Multichain gemacht, sodass Investoren auf Ethereum oder Optimism zeichnen oder einlösen können, und im Hintergrund verschiebt Wormholes Protokoll den Token und wandelt ihn sogar in ertragsbringende Formen um, wodurch die Notwendigkeit manueller Brücken oder mehrerer Wallets für die Nutzer entfällt.

• Programmierbare Ausführungsschichten: Schließlich ermöglichen bestimmte On-Chain-Innovationen komplexere Cross-Chain-Workflows. Atomare Multi-Call-Unterstützung und Transaktionsplanung helfen bei der Koordination mehrstufiger Intents. Zum Beispiel ermöglichen die Programmable Transaction Blocks (PTBs) der Sui-Blockchain das Bündeln mehrerer Aktionen (wie Swaps, Transfers, Aufrufe) in einer atomaren Transaktion. Dies kann die Cross-Chain-Intent-Erfüllung auf Sui vereinfachen, indem sichergestellt wird, dass entweder alle Schritte ausgeführt werden oder keiner, mit einer einzigen Benutzersignatur. In Ethereum erweitern Vorschläge wie EIP-7702 (Smart Contract Code für EOAs) die Fähigkeiten von Benutzerkonten, um Dinge wie gesponsertes Gas und mehrstufige Logik selbst auf der Basisschicht zu unterstützen. Darüber hinaus können spezialisierte Ausführungsumgebungen oder Cross-Chain-Router eingesetzt werden – z. B. leiten einige Systeme alle Intents über ein bestimmtes L2 oder einen Hub, der die Cross-Chain-Aktionen koordiniert (der Nutzer interagiert möglicherweise nur mit diesem Hub). Beispiele hierfür sind Projekte wie Push Protocol’s L1 (Push Chain), das als dedizierte Settlement-Schicht für kettenagnostische Operationen konzipiert wird und universelle Smart Contracts sowie Sub-Sekunden-Finalität bietet, um Cross-Chain-Interaktionen zu beschleunigen. Obwohl nicht universell angenommen, illustrieren diese Ansätze das Spektrum der Techniken, die zur Realisierung der Kettenabstraktion verwendet werden: von rein Off-Chain-Orchestrierung bis zur Bereitstellung neuer On-Chain-Infrastruktur, die speziell für die Cross-Chain-Intent-Ausführung entwickelt wurde.

Zusammenfassend wird Kettenabstraktion durch die Schichtung dieser Komponenten erreicht: eine Routing-Schicht (Relayer, die Nachrichten über Ketten hinweg senden), eine Konto-Schicht (Smart Wallets, die Aktionen auf jeder Kette initiieren können) und eine Ausführungsschicht (Solver, Liquidität und Verträge, die die Intents ausführen). Jedes Element ist notwendig, um sicherzustellen, dass aus Nutzersicht die Interaktion mit einer dApp über mehrere Blockchains so reibungslos ist wie die Nutzung einer Single-Chain-Anwendung.

Fallstudie 1: Wormhole – Intent-basiertes, kettenagnostisches Routing​

Wormhole ist ein führendes Cross-Chain-Interoperabilitätsprotokoll, das sich von einer Token-Brücke zu einem umfassenden Nachrichtenübertragungsnetzwerk mit Intent-basierter Funktionalität entwickelt hat. Sein Ansatz zur Kettenabstraktion besteht darin, eine einheitliche Nachrichten-Routing-Schicht bereitzustellen, die über 20 Ketten (einschließlich EVM-Ketten und Nicht-EVM-Ketten wie Solana) verbindet, und darauf aufbauend kettenagnostische Anwendungsprotokolle zu entwickeln. Zu den Schlüsselelementen der Wormhole-Architektur gehören:

• Generische Nachrichtenschicht: Im Kern ist Wormhole eine generische Publish/Subscribe-Brücke. Validatoren (Guardians) beobachten Ereignisse auf jeder verbundenen Kette und signieren eine VAA (verifiable action), die auf jeder anderen Kette eingereicht werden kann, um das Ereignis zu reproduzieren oder einen Zielvertrag aufzurufen. Dieses generische Design bedeutet, dass Entwickler beliebige Anweisungen oder Daten Cross-Chain senden können, nicht nur Token-Transfers. Wormhole stellt sicher, dass Nachrichten konsistent zugestellt und verifiziert werden, wobei abstrahiert wird, ob die Quelle Ethereum, Solana oder eine andere Kette war.

• Kettenagnostische Token-Transfers: Wormholes ursprüngliche Token-Brücke (Portal) verwendete einen Lock-and-Mint-Ansatz. Kürzlich führte Wormhole Native Token Transfers (NTT) ein, ein verbessertes Framework für Multichain-Tokens. Mit NTT können Assets nativ auf jeder Kette ausgegeben werden (wodurch fragmentierte Wrapped Tokens vermieden werden), während Wormhole die Buchhaltung von Burns und Mints über Ketten hinweg verwaltet, um das Angebot synchron zu halten. Für Nutzer fühlt es sich an, als ob ein Token über Ketten „teleportiert“ wird – sie zahlen auf einer Kette ein und ziehen dasselbe Asset auf einer anderen ab, wobei Wormhole die Mint-/Burn-Buchhaltung verwaltet. Dies ist eine Form der Token-Abstraktion, die die Komplexität verschiedener Token-Standards und Adressen auf jeder Kette verbirgt.

• Intent-basierte xApp-Protokolle: In der Erkenntnis, dass das Bridging von Tokens nur ein Teil der Cross-Chain-UX ist, hat Wormhole höherstufige Protokolle entwickelt, um Nutzer-Intents wie Swaps oder Transfers mit Gasgebührenverwaltung zu erfüllen. In den Jahren 2023–2024 arbeitete Wormhole mit dem Cross-Chain-DEX-Aggregator Mayan zusammen, um zwei Intent-fokussierte Protokolle zu starten, die im Wormhole-Ökosystem oft als xApps (Cross-Chain-Apps) bezeichnet werden: Mayan Swift und Mayan MCTP (Multichain Transfer Protocol).

  • Mayan Swift wird als „flexibles Cross-Chain-Intent-Protokoll“ beschrieben, das es einem Nutzer im Wesentlichen ermöglicht, einen Token-Swap von Kette A zu Kette B anzufordern. Der Nutzer signiert eine einzige Transaktion auf der Quellkette, sperrt seine Gelder und gibt sein gewünschtes Ergebnis an (z. B. „Ich möchte mindestens X Menge an Token Y auf der Zielkette bis Zeitpunkt T“). Dieser Intent (die Order) wird dann von Solvern aufgenommen. Einzigartig ist, dass Wormhole Swift eine On-Chain-Auktion auf Solana nutzt, um eine kompetitive Preisfindung für den Intent durchzuführen. Solver überwachen einen speziellen Solana-Vertrag; wenn eine neue Intent-Order erstellt wird, bieten sie, indem sie festlegen, wie viel des Output-Tokens sie liefern können. Über einen kurzen Auktionszeitraum (z. B. 3 Sekunden) konkurrieren die Gebote um den Preis. Der Höchstbietende (der dem Nutzer den günstigsten Kurs anbietet) gewinnt und erhält das Recht, den Swap auszuführen. Wormhole übermittelt dann eine Nachricht an die Zielkette, die diesen Solver autorisiert, die Tokens an den Nutzer zu liefern, und eine weitere Nachricht zurück, um die gesperrten Gelder des Nutzers als Zahlung an den Solver freizugeben. Dieses Design stellt sicher, dass der Intent des Nutzers zum bestmöglichen Preis auf dezentrale Weise erfüllt wird, während der Nutzer nur mit seiner Quellkette interagieren musste. Es entkoppelt auch den Cross-Chain-Swap in zwei Schritte (Gelder sperren, dann auf dem Ziel erfüllen), um das Risiko zu minimieren. Das Intent-zentrierte Design zeigt hier, wie Abstraktion eine intelligente Ausführung ermöglicht: Anstatt dass ein Nutzer eine bestimmte Brücke oder einen DEX auswählt, findet das System automatisch den optimalen Pfad und Preis.

  • Mayan MCTP konzentriert sich auf Cross-Chain-Asset-Transfers mit Gas- und Gebührenverwaltung. Es nutzt Circles CCTP (Cross-Chain Transfer Protocol) – das es ermöglicht, native USDC auf einer Kette zu verbrennen und auf einer anderen zu prägen – als Basis für den Werttransfer und verwendet Wormhole-Messaging zur Koordination. Bei einem MCTP-Transfer könnte der Intent eines Nutzers einfach sein: „Verschiebe meine USDC von Kette A zu Kette B (und optional tausche sie auf B gegen einen anderen Token)“. Der Quellkettenvertrag akzeptiert die Tokens und ein gewünschtes Ziel, initiiert dann einen Burn über CCTP und veröffentlicht gleichzeitig eine Wormhole-Nachricht, die Metadaten wie die Zieladresse des Nutzers, den gewünschten Token am Zielort und sogar einen Gas-Drop (einen Betrag der gebrückten Gelder, der in natives Gas am Zielort umgewandelt werden soll) enthält. Auf der Zielkette, sobald Circle die USDC prägt, stellt ein Wormhole-Relayer sicher, dass die Intent-Metadaten geliefert und verifiziert werden. Das Protokoll kann dann automatisch z. B. einen Teil der USDC in den nativen Token tauschen, um Gas zu bezahlen, und den Rest an die Wallet des Nutzers (oder an einen bestimmten Vertrag) liefern. Dies bietet eine einstufige, Gas-inklusive Brücke: Der Nutzer muss kein Gas auf der neuen Kette erwerben oder einen separaten Swap für Gas durchführen. Alles ist im Intent kodiert und wird vom Netzwerk abgewickelt. MCTP demonstriert somit, wie Kettenabstraktion die Gebührenabstraktion und zuverlässige Transfers in einem Fluss handhaben kann. Wormholes Rolle besteht darin, den Intent und den Nachweis, dass Gelder bewegt wurden (über CCTP), sicher zu übertragen, damit die Anfrage des Nutzers End-to-End erfüllt wird.

Illustration der Intent-zentrierten Swap-Architektur von Wormhole (Mayan Swift). In diesem Design sperrt der Nutzer Assets auf der Quellkette und definiert ein Ergebnis (Intent). Solver bieten in einer On-Chain-Auktion um das Recht, diesen Intent zu erfüllen. Der gewinnende Solver verwendet Wormhole-Nachrichten, um das Entsperren von Geldern und die Bereitstellung des Ergebnisses auf der Zielkette zu koordinieren, während gleichzeitig sichergestellt wird, dass der Nutzer den besten Preis für seinen Swap erhält.

• Vereinheitlichte UX und One-Click-Flows: Wormhole-basierte Anwendungen bieten zunehmend One-Click-Cross-Chain-Aktionen an. Zum Beispiel ist Wormhole Connect ein Frontend-SDK, das dApps und Wallets integrieren, um Nutzern das Bridging von Assets mit einem einzigen Klick zu ermöglichen – im Hintergrund ruft es Wormhole-Token-Bridging und (optional) Relayer auf, die Gas auf der Zielkette einzahlen. Im Anwendungsfall des Securitize SCOPE Fonds kann ein Investor auf Optimism Fondstoken kaufen, die ursprünglich auf Ethereum leben, ohne manuell etwas zu bridgen; Wormholes Liquiditätsschicht verschiebt die Tokens automatisch und wandelt sie sogar in ertragsbringende Formen um, sodass der Nutzer nur ein vereinheitlichtes Anlageprodukt sieht. Solche Beispiele unterstreichen das Ethos der Kettenabstraktion: Der Nutzer führt eine übergeordnete Aktion aus (in Fonds investieren, X gegen Y tauschen) und die Plattform wickelt die Cross-Chain-Mechanik stillschweigend ab. Wormholes standardmäßige Nachrichtenweiterleitung und automatische Gaslieferung (über Dienste wie Wormholes Automatic Relayer oder Axelars Gas Service, die in einigen Flows integriert sind) bedeuten, dass der Nutzer oft nur eine Transaktion auf seiner Ursprungskette signiert und das Ergebnis auf der Zielkette ohne weiteres Eingreifen erhält. Aus Entwicklersicht bietet Wormhole eine einheitliche Schnittstelle zum Aufrufen von Verträgen über Ketten hinweg, wodurch der Aufbau von Cross-Chain-Logik einfacher wird.

Zusammenfassend besteht Wormholes Ansatz zur Kettenabstraktion darin, die Infrastruktur bereitzustellen (dezentrale Relayer + standardisierte Verträge auf jeder Kette), auf der andere aufbauen können, um kettenagnostische Erfahrungen zu schaffen. Durch die Unterstützung einer Vielzahl von Ketten und das Angebot höherstufiger Protokolle (wie die Intent-Auktion und den Gas-verwalteten Transfer) ermöglicht Wormhole Anwendungen, das Blockchain-Ökosystem als ein verbundenes Ganzes zu behandeln. Nutzer profitieren davon, dass sie sich keine Sorgen mehr machen müssen, auf welcher Kette sie sich befinden oder wie sie bridgen – ob es sich um das Verschieben von Liquidität oder einen Multi-Chain-Swap handelt, Wormholes Intent-zentrierte xApps zielen darauf ab, dies so einfach wie eine Single-Chain-Interaktion zu gestalten. Wormholes Mitbegründer Robinson Burkey bemerkte, dass diese Art von Infrastruktur „institutionelle Reife“ erreicht hat, wodurch selbst regulierte Asset-Emittenten nahtlos über Netzwerke hinweg agieren und kettenspezifische Einschränkungen für ihre Nutzer abstrahieren können.

Fallstudie 2: Etherspot – Account Abstraction trifft auf Intents​

Etherspot nähert sich dem Cross-Chain-UX-Problem aus der Perspektive von Wallets und Entwickler-Tools. Es bietet ein Account Abstraction SDK und einen Intent-Protokoll-Stack, den Entwickler integrieren können, um ihren Nutzern eine vereinheitlichte Multi-Chain-Erfahrung zu bieten. Im Grunde kombiniert Etherspot Smart Contract Wallets mit Kettenabstraktionslogik, sodass ein einziges Smart Account eines Nutzers mit minimaler Reibung über viele Netzwerke hinweg agieren kann. Zu den Hauptmerkmalen der Etherspot-Architektur gehören:

• Modulares Smart Wallet (Account Abstraction): Jeder Nutzer von Etherspot erhält ein Smart Contract Wallet (im ERC-4337-Stil), das auf mehreren Ketten bereitgestellt werden kann. Etherspot hat zu Standards wie ERC-7579 (minimale modulare Smart Accounts Schnittstelle) beigetragen, um sicherzustellen, dass diese Wallets interoperabel und upgradefähig sind. Der Wallet-Vertrag fungiert als Agent des Nutzers und kann mit Modulen angepasst werden. Zum Beispiel könnte ein Modul eine vereinheitlichte Saldenansicht ermöglichen – das Wallet kann die Summe der Gelder eines Nutzers über alle Ketten hinweg anzeigen. Ein weiteres Modul könnte Session Keys ermöglichen, sodass der Nutzer eine Reihe von Aktionen mit einer einzigen Signatur genehmigen kann. Da das Wallet auf jeder Kette vorhanden ist, kann es bei Bedarf direkt lokale Transaktionen initiieren (wobei Etherspots Backend-Bundler und Relayer die Cross-Chain-Koordination orchestrieren).

• Transaktions-Bundler und Paymaster: Etherspot betreibt einen Bundler-Dienst (genannt Skandha), der User Operations von den Smart Wallets sammelt, und einen Paymaster-Dienst (Arka), der Gasgebühren sponsern kann. Wenn ein Nutzer einen Intent über Etherspot auslöst, signiert er effektiv eine Nachricht an seinen Wallet-Vertrag. Die Etherspot-Infrastruktur (der Bundler) übersetzt dies dann in tatsächliche Transaktionen auf den relevanten Ketten. Entscheidend ist, dass sie mehrere Aktionen bündeln kann – z. B. einen DEX-Swap auf einer Kette und einen Brückentransfer zu einer anderen Kette – in eine Meta-Transaktion, die der Wallet-Vertrag des Nutzers Schritt für Schritt ausführt. Der Paymaster bedeutet, dass der Nutzer möglicherweise kein L1-Gas bezahlen muss; stattdessen könnte die dApp oder ein Dritter dies übernehmen, oder die Gebühr könnte in einem anderen Token erhoben werden. Dies realisiert die Gasabstraktion in der Praxis (ein großer Usability-Gewinn). Tatsächlich betont Etherspot, dass mit kommenden Ethereum-Funktionen wie EIP-7702 sogar Externally Owned Accounts gaslose Funktionen ähnlich wie Contract Wallets erhalten könnten – aber Etherspots Smart Accounts ermöglichen bereits heute gaslose Intents über Paymaster.

• Intent-API und Solver (Pulse): Zusätzlich zur Konto-Schicht bietet Etherspot eine hochstufige Intent-API, bekannt als Etherspot Pulse. Pulse ist Etherspots Kettenabstraktions-Engine, die Entwickler nutzen können, um Cross-Chain-Intents in ihren dApps zu ermöglichen. In einer Demo von Etherspot Pulse Ende 2024 zeigten sie, wie ein Nutzer einen Token-Swap von Ethereum zu einem Asset auf Base mit einer einfachen React-App-Oberfläche und einem Klick durchführen konnte. Im Hintergrund wickelte Pulse die Multi-Chain-Transaktion sicher und effizient ab. Die Hauptmerkmale von Pulse umfassen Vereinheitlichte Salden (der Nutzer sieht alle Assets als ein Portfolio, unabhängig von der Kette), Session Key Security (begrenzte Privilegien für bestimmte Aktionen, um ständige Genehmigungen zu vermeiden), Intent-basierte Swaps und Solver-Integration. Mit anderen Worten, der Entwickler ruft einfach einen Intent wie swap(tokenA auf Kette1 -> tokenB auf Kette2 für Nutzer) über das Etherspot SDK auf, und Pulse findet heraus, wie es geht – sei es durch Routing über ein Liquiditätsnetzwerk wie Socket oder durch Aufruf eines Cross-Chain-DEX. Etherspot hat sich mit verschiedenen Brücken und DEX-Aggregatoren integriert, um optimale Routen zu finden (es verwendet wahrscheinlich auch einige Konzepte des Open Intents Framework, angesichts Etherspots Beteiligung an der Ethereum-Intent-Community).

• Bildung und Standards: Etherspot ist ein lautstarker Befürworter von Kettenabstraktionsstandards. Es hat Bildungsinhalte veröffentlicht, die Intents erklären und wie „Nutzer ihr gewünschtes Ergebnis deklarieren, während Solver den Backend-Prozess abwickeln“, wobei die vereinfachte UX und Cross-Chain-Fluidität betont werden. Sie listen Vorteile auf, wie dass Nutzer sich keine Sorgen um Bridging oder Gas machen müssen und dApps Skalierbarkeit gewinnen, indem sie problemlos auf mehrere Ketten zugreifen können. Etherspot arbeitet auch aktiv mit Ökosystemprojekten zusammen: Zum Beispiel verweist es auf das Open Intents Framework der Ethereum Foundation und erforscht die Integration neuer Cross-Chain-Messaging-Standards (ERC-7786, 7787 usw.), sobald diese entstehen. Durch die Ausrichtung an gemeinsamen Standards stellt Etherspot sicher, dass sein Intent-Format oder seine Wallet-Schnittstelle mit anderen vom Entwickler gewählten Lösungen (wie Hyperlane, Connext, Axelar usw.) zusammenarbeiten kann.

• Anwendungsfälle und Entwickler-UX: Für Entwickler bedeutet die Nutzung von Etherspot, dass sie Cross-Chain-Funktionen hinzufügen können, ohne das Rad neu erfinden zu müssen. Eine DeFi-dApp kann einem Nutzer erlauben, Gelder auf jeder Kette einzuzahlen, auf der er Assets besitzt, und Etherspot abstrahiert die Kettenunterschiede. Eine Gaming-App könnte Nutzern erlauben, eine Transaktion zu signieren, um ein NFT auf einem L2 zu beanspruchen und es bei Bedarf für den Handel automatisch zu Ethereum zu bridgen. Etherspots SDK bietet im Wesentlichen kettenagnostische Funktionsaufrufe – Entwickler rufen hochstufige Methoden (wie ein vereinheitlichtes transfer() oder swap()) auf, und das SDK kümmert sich um das Auffinden von Nutzergeldern, deren Verschiebung bei Bedarf und die Aktualisierung des Status über Ketten hinweg. Dies reduziert die Entwicklungszeit für Multi-Chain-Unterstützung erheblich (das Team behauptet eine Reduzierung der Entwicklungszeit um bis zu 90 % bei Verwendung ihrer Kettenabstraktionsplattform). Ein weiterer Aspekt sind RPC Playground und Debugging-Tools, die Etherspot für AA-Flows entwickelt hat, die das Testen komplexer User Operations, die mehrere Netzwerke umfassen können, erleichtern. All dies zielt darauf ab, die Integration von Kettenabstraktion so unkompliziert zu gestalten wie die Integration einer Zahlungs-API in Web2.

Aus der Endnutzerperspektive kann eine Etherspot-betriebene Anwendung ein wesentlich reibungsloseres Onboarding und eine bessere tägliche Erfahrung bieten. Neue Nutzer können sich mit Social Login oder E-Mail anmelden (wenn die dApp Etherspots Social Account Modul verwendet) und erhalten automatisch ein Smart Account – ohne Seed-Phrasen für jede Kette verwalten zu müssen. Sie können Tokens von jeder Kette an ihre eine Adresse (die Adresse des Smart Wallets ist auf allen unterstützten Ketten dieselbe) empfangen und diese in einer Liste sehen. Wenn sie eine Aktion (Swap, Verleihen usw.) auf einer Kette durchführen möchten, auf der sie das Asset oder Gas nicht haben, leitet das Intent-Protokoll ihre Gelder und Aktionen automatisch weiter, um dies zu ermöglichen. Zum Beispiel könnte ein Nutzer, der USDC auf Polygon hält und an einem Ethereum DeFi-Pool teilnehmen möchte, einfach auf „In Pool investieren“ klicken – die App (über Etherspot) tauscht die USDC in das erforderliche Asset, bridged sie zu Ethereum, zahlt sie in den Pool-Vertrag ein und wickelt sogar Gasgebühren ab, indem sie einen winzigen Teil der USDC nimmt, alles in einem einzigen Flow. Der Nutzer wird niemals mit Fehlern wie „Bitte wechseln Sie zu Netzwerk X“ oder „Sie benötigen ETH für Gas“ konfrontiert – diese werden im Hintergrund abgewickelt. Diese One-Click-Erfahrung ist genau das, was Kettenabstraktion anstrebt.

Etherspots CEO, Michael Messele, sprach auf der EthCC 2025 über „fortgeschrittene Kettenabstraktion“ und betonte, dass die Gestaltung von Web3 als wirklich Blockchain-agnostisch sowohl Nutzer als auch Entwickler stärken kann, indem Interoperabilität, Skalierbarkeit und UX verbessert werden. Etherspots eigene Beiträge, wie die Pulse-Demo von Single-Intent Cross-Chain-Swaps, zeigen, dass die Technologie bereits vorhanden ist, um Cross-Chain-Interaktionen drastisch zu vereinfachen. Wie Etherspot es darstellt, sind Intents die Brücke zwischen den innovativen Möglichkeiten eines Multi-Chain-Ökosystems und der Benutzerfreundlichkeit, die Endnutzer erwarten. Mit Lösungen wie ihren können dApps „reibungslose“ Erfahrungen liefern, bei denen Kettenunterschiede in den Hintergrund treten, was die Mainstream-Adoption von Web3 beschleunigt.

Verbesserungen der Benutzer- und Entwicklererfahrung​

Sowohl Kettenabstraktion als auch Intent-zentrierte Architekturen dienen letztendlich einer besseren Benutzererfahrung (UX) und Entwicklererfahrung (DX) in einer Multi-Chain-Welt. Zu den bemerkenswerten Verbesserungen gehören:

• Nahtloses Onboarding: Neue Nutzer können onboarded werden, ohne sich Gedanken darüber machen zu müssen, auf welcher Blockchain sie sich befinden. Zum Beispiel könnte einem Nutzer ein einziges Smart Account gegeben werden, das überall funktioniert, möglicherweise erstellt mit einem Social Login. Sie können jeden Token oder NFT von jeder Kette ohne Verwirrung an dieses Konto empfangen. Ein Neuling muss nicht mehr lernen, Netzwerke in MetaMask zu wechseln oder mehrere Seed-Phrasen zu sichern. Dies senkt die Eintrittsbarriere erheblich, da die Nutzung einer dApp sich näher an einer Web2-App-Registrierung anfühlt. Projekte, die Account Abstraction implementieren, erlauben oft die Erstellung von Wallets per E-Mail oder OAuth, wobei das resultierende Smart Account kettenagnostisch ist.

• One-Click Cross-Chain-Aktionen: Der vielleicht sichtbarste UX-Gewinn ist die Verdichtung von ehemals mehrstufigen, Multi-App-Workflows auf ein oder zwei Klicks. Zum Beispiel erforderte ein Cross-Chain-Token-Swap früher möglicherweise: Tausch von Token A gegen ein bridgefähiges Asset auf Kette 1, Wechsel zu einer Bridge-UI, um es an Kette 2 zu senden, dann Tausch gegen Token B auf Kette 2 – und die Verwaltung von Gasgebühren auf beiden Ketten. Mit Intent-zentrierten Systemen fordert der Nutzer einfach „Tausche A auf Kette1 gegen B auf Kette2“ an und bestätigt einmal. Alle Zwischenschritte (einschließlich des Erwerbs von Gas auf Kette2 bei Bedarf) werden automatisiert. Dies spart nicht nur Zeit, sondern reduziert auch die Wahrscheinlichkeit von Benutzerfehlern (Verwendung der falschen Brücke, Senden an die falsche Adresse usw.). Es ist vergleichbar mit dem Komfort, einen Flug mit mehreren Etappen über eine einzige Reise-Website zu buchen, anstatt jede Etappe separat manuell zu kaufen.

• Keine Angst vor nativem Gas: Nutzer müssen nicht ständig kleine Mengen ETH, MATIC, AVAX usw. tauschen, nur um Transaktionen zu bezahlen. Gasgebühren-Abstraktion bedeutet, dass entweder die dApp das Gas übernimmt (und möglicherweise eine Gebühr im gehandelten Token oder über ein Abonnementmodell erhebt) oder das System einen Teil des Nutzer-Assets automatisch umwandelt, um Gebühren zu bezahlen. Dies hat eine enorme psychologische Wirkung – es eliminiert eine Kategorie verwirrender Aufforderungen (keine „unzureichendes Gas“-Fehler mehr) und lässt Nutzer sich auf die Aktionen konzentrieren, die ihnen wichtig sind. Mehrere EthCC 2025-Vorträge nannten Gasabstraktion als Priorität, z. B. wird Ethereums EIP-7702 in Zukunft sogar EOA-Konten ermöglichen, Gas sponsern zu lassen. In der heutigen Praxis hinterlegen viele Intent-Protokolle einen kleinen Betrag des Output-Assets als Gas auf der Zielkette für den Nutzer oder nutzen Paymaster, die mit User Operations verbunden sind. Das Ergebnis: Ein Nutzer kann beispielsweise USDC von Arbitrum nach Polygon verschieben, ohne jemals ETH auf einer Seite zu berühren, und seine Polygon-Wallet kann sofort nach Ankunft Transaktionen durchführen.

• Vereinheitlichte Asset-Verwaltung: Für Endnutzer ist eine vereinheitlichte Ansicht von Assets und Aktivitäten über Ketten hinweg eine erhebliche Verbesserung der Lebensqualität. Kettenabstraktion kann ein kombiniertes Portfolio präsentieren – so könnten Ihre 1 ETH auf Mainnet und 2 ETH im Wert von gebrücktem stETH auf Optimism beide einfach als „ETH-Guthaben“ angezeigt werden. Wenn Sie USD-Stablecoins auf fünf verschiedenen Ketten haben, könnte ein kettenagnostisches Wallet Ihren gesamten USD-Wert anzeigen und Ausgaben davon ermöglichen, ohne dass Sie manuell bridgen müssen. Dies fühlt sich eher wie eine traditionelle Bank-App an, die einen einzigen Saldo anzeigt (auch wenn Gelder im Hintergrund auf Konten verteilt sind). Nutzer können Präferenzen wie „standardmäßig das günstigste Netzwerk verwenden“ oder „Rendite maximieren“ festlegen, und das System könnte Transaktionen automatisch der entsprechenden Kette zuweisen. Gleichzeitig könnte ihre gesamte Transaktionshistorie in einer einzigen Zeitleiste angezeigt werden, unabhängig von der Kette. Eine solche Kohärenz ist wichtig für eine breitere Akzeptanz – sie verbirgt die Blockchain-Komplexität unter vertrauten Metaphern.

• Verbesserte Entwicklerproduktivität: Aus Entwicklersicht bedeuten Kettenabstraktionsplattformen, dass kein kättenspezifischer Code mehr für jede Integration geschrieben werden muss. Anstatt fünf verschiedene Brücken und sechs Börsen zu integrieren, um die Abdeckung von Assets und Netzwerken zu gewährleisten, kann ein Entwickler eine Intent-Protokoll-API integrieren, die diese abstrahiert. Dies spart nicht nur Entwicklungsaufwand, sondern reduziert auch den Wartungsaufwand – wenn neue Ketten oder Brücken hinzukommen, übernehmen die Betreuer der Abstraktionsschicht die Integration, und die dApp profitiert einfach davon. Der wöchentliche Digest von Etherspot hob hervor, dass Lösungen wie Oktos Kettenabstraktionsplattform behaupten, die Entwicklungszeit für Multi-Chain-dApps um bis zu 90 % zu reduzieren, indem sie Out-of-the-Box-Unterstützung für wichtige Ketten und Funktionen wie Liquiditätsoptimierung bieten. Im Wesentlichen können sich Entwickler auf die Anwendungslogik (z. B. ein Kreditprodukt, ein Spiel) konzentrieren, anstatt auf die Feinheiten von Cross-Chain-Transfers oder Gasmanagement. Dies öffnet die Tür für mehr Web2-Entwickler, in Web3 einzusteigen, da sie höherstufige SDKs verwenden können, anstatt tiefe Blockchain-Expertise für jede Kette zu benötigen.

• Neue Komponierbare Erfahrungen: Mit Intents und Kettenabstraktion können Entwickler Erfahrungen schaffen, die zuvor zu komplex waren, um sie zu versuchen. Zum Beispiel können Cross-Chain-Yield-Farming-Strategien automatisiert werden: Ein Nutzer könnte auf „Rendite meiner Assets maximieren“ klicken, und ein Intent-Protokoll könnte Assets zwischen Ketten zu den besten Yield Farms verschieben, sogar kontinuierlich, wenn sich die Raten ändern. Spiele können Assets und Quests haben, die sich über mehrere Ketten erstrecken, ohne dass Spieler Gegenstände manuell bridgen müssen – das Backend des Spiels (unter Verwendung eines Intent-Frameworks) übernimmt die Teleportation von Gegenständen oder die Statussynchronisation. Sogar die Governance kann profitieren: Eine DAO könnte einem Nutzer erlauben, einmal abzustimmen und diese Stimme über Cross-Chain-Nachrichten auf die Governance-Verträge aller relevanten Ketten anzuwenden. Der Gesamteffekt ist Komponierbarkeit: So wie DeFi auf einer einzelnen Kette eine Lego-ähnliche Komposition von Protokollen ermöglichte, erlauben Cross-Chain-Intent-Schichten Protokollen auf verschiedenen Ketten, sich zu komponieren. Ein Nutzer-Intent könnte Aktionen auf mehreren dApps über Ketten hinweg auslösen (z. B. ein NFT auf einer Kette entpacken und es auf einem Marktplatz auf einer anderen verkaufen), was reichere Workflows schafft als isolierte Single-Chain-Operationen.

• Sicherheitsnetze und Zuverlässigkeit: Ein oft unterschätzter UX-Aspekt ist die Fehlerbehandlung. Bei frühen Cross-Chain-Interaktionen, wenn etwas schiefging (feststeckende Gelder in einer Brücke, eine fehlgeschlagene Transaktion nach dem Senden von Geldern usw.), standen Nutzer vor einem Albtraum der Fehlerbehebung über mehrere Plattformen hinweg. Intent-Frameworks können Wiederholungslogik, Versicherungen oder Benutzerschutzmechanismen einbauen. Zum Beispiel könnte ein Solver das Finalitätsrisiko übernehmen – die Gelder des Nutzers sofort (innerhalb von Sekunden) am Zielort liefern und selbst auf die langsamere Finalität der Quellkette warten. Das bedeutet, dass der Nutzer nicht minuten- oder stundenlang auf Bestätigung warten muss. Wenn ein Intent teilweise fehlschlägt, kann das System automatisch zurückrollen oder erstatten. Da der gesamte Ablauf mit bekannten Schritten orchestriert wird, gibt es mehr Spielraum, den Nutzer schadlos zu halten, wenn etwas schiefgeht. Einige Protokolle erforschen Treuhand und Versicherungen für Cross-Chain-Operationen als Teil der Intent-Ausführung, was unmöglich wäre, wenn der Nutzer manuell Hürden überwinden müsste – er würde dieses Risiko allein tragen. Kurz gesagt, Abstraktion kann die Gesamterfahrung nicht nur reibungsloser, sondern auch sicherer und vertrauenswürdiger für den durchschnittlichen Nutzer machen.

All diese Verbesserungen deuten auf einen einzigen Trend hin: die Reduzierung der kognitiven Belastung für Nutzer und die Abstraktion der Blockchain-Infrastruktur in den Hintergrund. Richtig umgesetzt, merken Nutzer möglicherweise nicht einmal, welche Ketten sie verwenden – sie greifen einfach auf Funktionen und Dienste zu. Entwickler hingegen können Apps erstellen, die Liquidität und Nutzerbasen über viele Netzwerke hinweg aus einer einzigen Codebasis nutzen. Es ist eine Verlagerung der Komplexität von den Rändern (Nutzer-Apps) zur Mitte (Infrastrukturprotokolle), was ein natürlicher Fortschritt ist, wenn Technologie reift. Der Ton der EthCC 2025 spiegelte diese Stimmung wider, wobei „nahtlose, komponierbare Infrastruktur“ als übergeordnetes Ziel für die Ethereum-Community genannt wurde.

Erkenntnisse der EthCC 2025​

Die EthCC 2025 Konferenz (im Juli 2025 in Cannes abgehalten) unterstrich, wie zentral Kettenabstraktion und Intent-basiertes Design im Ethereum-Ökosystem geworden sind. Ein dedizierter Block von Sessions konzentrierte sich auf die Vereinheitlichung von Benutzererfahrungen über Netzwerke hinweg. Zu den wichtigsten Erkenntnissen der Veranstaltung gehören:

• Community-Konsens zur Abstraktion: Mehrere Vorträge von Branchenführern wiederholten dieselbe Botschaft – die Vereinfachung der Multi-Chain-Erfahrung ist entscheidend für die nächste Welle der Web3-Adoption. Michael Messele (Etherspot) sprach über den Weg „in eine Blockchain-agnostische Zukunft“, Alex Bash (Zerion Wallet) diskutierte die „Vereinheitlichung der Ethereum-UX mit Abstraktion und Intents“, und andere stellten konkrete Standards wie ERC-7811 für die Stablecoin-Kettenabstraktion vor. Der Titel eines Vortrags, „Es gibt keine Web3-Zukunft ohne Kettenabstraktion“, fasste die Stimmung der Community zusammen. Mit anderen Worten, es besteht breite Übereinstimmung, dass Web3 ohne die Lösung der Cross-Chain-Usability sein volles Potenzial nicht erreichen wird. Dies stellt eine Verschiebung gegenüber früheren Jahren dar, in denen die Skalierung von L1 oder L2 der Hauptfokus war – jetzt, da viele L2s live sind, ist deren Verbindung für Nutzer die neue Grenze.

• Ethereums Rolle als Hub: EthCC-Panels hoben hervor, dass Ethereum sich nicht nur als eine Kette unter vielen positioniert, sondern als die Grundlage eines Multi-Chain-Ökosystems. Ethereums Sicherheit und seine 4337 Account Abstraction auf dem Mainnet können als gemeinsame Basis dienen, die Aktivitäten auf verschiedenen L2s und Sidechains untermauert. Anstatt mit seinen Rollups zu konkurrieren, investiert Ethereum (und damit die Ethereum-Community) in Protokolle, die das gesamte Netzwerk von Ketten vereinheitlicht erscheinen lassen. Dies wird durch die Unterstützung der Ethereum Foundation für Projekte wie das Open Intents Framework veranschaulicht, das viele Ketten und Rollups umfasst. Die Stimmung auf der EthCC war, dass Ethereums Reife sich darin zeigt, ein „Ökosystem von Ökosystemen“ zu umarmen, in dem nutzerzentriertes Design (unabhängig von der Kette) von größter Bedeutung ist.

• Stablecoins & Real-World Assets als Katalysatoren: Ein interessantes Thema war die Schnittstelle von Kettenabstraktion mit Stablecoins und RWAs (Real-World Assets). Stablecoins wurden wiederholt als „Grundkraft“ im DeFi bezeichnet, und mehrere Vorträge (z. B. über ERC-7811 Stablecoin-Kettenabstraktion) befassten sich damit, die Stablecoin-Nutzung kettenagnostisch zu gestalten. Die Idee ist, dass ein durchschnittlicher Nutzer sich nicht darum kümmern muss, auf welcher Kette seine USDC oder DAI liegen – sie sollten denselben Wert haben und überall nahtlos nutzbar sein. Wir sahen dies bei Securitize’s Fonds, der Wormhole nutzte, um Multichain zu werden, wodurch ein institutionelles Produkt effektiv über Ketten hinweg abstrahiert wurde. EthCC-Diskussionen deuteten darauf hin, dass die Lösung der Cross-Chain-UX für Stablecoins und RWAs ein großer Schritt in Richtung einer breiteren Blockchain-basierten Finanzierung ist, da diese Assets reibungslose Benutzererfahrungen für die Akzeptanz durch Institutionen und Mainstream-Nutzer erfordern.

• Entwicklerbegeisterung und Tooling: Workshops und Side-Events (wie der Multichain Day) führten Entwickler in die neuen verfügbaren Tools ein. Hackathon-Projekte und Demos zeigten, wie Intent-APIs und Kettenabstraktions-SDKs (von verschiedenen Teams) verwendet werden könnten, um Cross-Chain-dApps in Tagen zu erstellen. Es herrschte eine spürbare Begeisterung, dass der „Heilige Gral“ der Web3-UX – die Nutzung mehrerer Netzwerke, ohne es zu merken – in Reichweite ist. Das Open Intents Framework Team veranstaltete einen Anfänger-Workshop, der erklärte, wie man eine Intent-fähige App erstellt, wahrscheinlich unter Verwendung ihres Referenz-Solvers und ihrer Verträge. Entwickler, die in der Vergangenheit mit Bridging und Multi-Chain-Bereitstellung zu kämpfen hatten, waren von diesen Lösungen begeistert, wie die Q&A-Sitzungen (informell in den sozialen Medien während der Konferenz berichtet) belegten.

• Ankündigungen und Zusammenarbeit: Die EthCC 2025 diente auch als Bühne für die Ankündigung von Kooperationen zwischen Projekten in diesem Bereich. Zum Beispiel wurden Partnerschaften zwischen einem Wallet-Anbieter und einem Intent-Protokoll oder zwischen einem Bridge-Projekt und einem Account Abstraction Projekt angedeutet. Eine konkrete Ankündigung war die Integration von Wormhole in das Stacks-Ökosystem (wodurch Bitcoin-Liquidität in Cross-Chain-Flows gebracht wird), was nicht direkt eine Kettenabstraktion für Ethereum war, aber die wachsende Konnektivität über traditionell getrennte Krypto-Ökosysteme hinweg veranschaulichte. Die Präsenz von Projekten wie Zerion (Wallet), Safe (Smart Accounts), Connext, Socket, Axelar usw., die alle über Interoperabilität diskutierten, signalisierte, dass viele Puzzleteile zusammenkommen.

Insgesamt zeichnete die EthCC 2025 das Bild einer Community, die sich um nutzerzentrierte Cross-Chain-Innovationen schart. Der Ausdruck „komponierbare Infrastruktur“ wurde verwendet, um das Ziel zu beschreiben: All diese L1s, L2s und Protokolle sollen ein kohärentes Gefüge bilden, auf dem Anwendungen aufbauen können, ohne Dinge ad-hoc zusammenfügen zu müssen. Die Konferenz machte deutlich, dass Kettenabstraktion und Intents nicht nur Schlagworte sind, sondern aktive Entwicklungsbereiche, die ernsthaftes Talent und Investitionen anziehen. Ethereums Führungsrolle dabei – durch Finanzierung, Festlegung von Standards und Bereitstellung einer robusten Basisschicht – wurde auf der Veranstaltung bekräftigt.

Vergleich der Ansätze zur Kettenabstraktion und Intents​

Die folgende Tabelle vergleicht mehrere prominente Protokolle und Frameworks, die sich der Cross-Chain-Benutzer-/Entwicklererfahrung widmen, und hebt deren Ansatz und Hauptmerkmale hervor:

(Tabellenlegende: AA = Account Abstraction, ChA = Kettenabstraktion, AMB = Arbitrary Messaging Bridge)

Jeder der oben genannten Ansätze begegnet der Cross-Chain-UX-Herausforderung aus einem etwas anderen Blickwinkel – einige konzentrieren sich auf das Wallet/Konto des Nutzers, andere auf das Netzwerk-Messaging und wieder andere auf die Entwickler-API-Schicht – aber alle teilen das Ziel, Blockchain-Interaktionen kettenagnostisch und Intent-gesteuert zu gestalten. Bemerkenswerterweise schließen sich diese Lösungen nicht gegenseitig aus; tatsächlich ergänzen sie sich oft. Zum Beispiel könnte eine Anwendung Etherspots Smart Wallet + Paymaster verwenden, mit dem Open Intents Standard, um den Intent des Nutzers zu formatieren, und dann Axelar oder Connext im Hintergrund als Ausführungsschicht nutzen, um Aktionen tatsächlich zu bridgen und durchzuführen. Der aufkommende Trend ist die Komponierbarkeit zwischen den Kettenabstraktions-Tools selbst, die letztendlich auf ein Internet der Blockchains hinarbeitet, in dem Nutzer sich frei bewegen können.

Fazit​

Die Blockchain-Technologie durchläuft einen Paradigmenwechsel von isolierten Netzwerken und manuellen Operationen zu einer vereinheitlichten, Intent-gesteuerten Erfahrung. Kettenabstraktion und Intent-zentrierte Architektur stehen im Mittelpunkt dieser Transformation. Indem sie die Komplexitäten mehrerer Ketten abstrahieren, ermöglichen sie ein nutzerzentriertes Web3, in dem Menschen mit dezentralen Anwendungen interagieren, ohne verstehen zu müssen, welche Kette sie verwenden, wie Assets gebrückt werden oder wie Gas auf jedem Netzwerk erworben wird. Die Infrastruktur – Relayer, Smart Accounts, Solver und Brücken – kümmert sich kollaborativ um diese Details, ähnlich wie die zugrunde liegenden Protokolle des Internets Pakete routen, ohne dass Nutzer die Route kennen.

Die Vorteile für die Benutzererfahrung sind bereits spürbar: reibungsloseres Onboarding, One-Click-Cross-Chain-Swaps und wirklich nahtlose dApp-Interaktionen über Ökosysteme hinweg. Auch Entwickler werden durch höherstufige SDKs und Standards gestärkt, die den Aufbau für eine Multi-Chain-Welt dramatisch vereinfachen. Wie auf der EthCC 2025 zu sehen war, besteht ein starker Konsens in der Community, dass diese Entwicklungen nicht nur spannende Verbesserungen, sondern grundlegende Anforderungen für die nächste Phase des Web3-Wachstums sind. Projekte wie Wormhole und Etherspot zeigen, dass es möglich ist, Dezentralisierung und Vertrauenslosigkeit zu bewahren und gleichzeitig eine Web2-ähnliche Benutzerfreundlichkeit zu bieten.

Mit Blick in die Zukunft können wir eine weitere Konvergenz dieser Ansätze erwarten. Standards wie ERC-7683 Intents und ERC-4337 Account Abstraction werden wahrscheinlich weit verbreitet sein und die Kompatibilität über Plattformen hinweg gewährleisten. Mehr Brücken und Netzwerke werden sich in offene Intent-Frameworks integrieren, wodurch Liquidität und Optionen für Solver zur Erfüllung von Nutzer-Intents erhöht werden. Letztendlich könnte der Begriff „Cross-Chain“ verschwinden, da Interaktionen überhaupt nicht mehr in Bezug auf einzelne Ketten gedacht werden – ähnlich wie Nutzer des Webs nicht darüber nachdenken, welches Rechenzentrum ihre Anfrage erreicht hat. Stattdessen werden Nutzer einfach Dienste aufrufen und Assets in einem vereinheitlichten Blockchain-Ökosystem verwalten.

Zusammenfassend lässt sich sagen, dass Kettenabstraktion und Intent-zentriertes Design den Multi-Chain-Traum Wirklichkeit werden lassen: Sie liefern die Vorteile vielfältiger Blockchain-Innovationen ohne die Fragmentierung. Indem Designs auf Nutzer-Intents zentriert und der Rest abstrahiert wird, macht die Branche einen großen Schritt, um dezentrale Anwendungen so intuitiv und leistungsfähig wie die heutigen zentralisierten Dienste zu gestalten und das Versprechen von Web3 für ein breiteres Publikum zu erfüllen. Die Infrastruktur entwickelt sich noch weiter, aber ihre Trajektorie ist klar – eine nahtlose, Intent-gesteuerte Web3-Erfahrung steht bevor, und sie wird neu definieren, wie wir Blockchains wahrnehmen und mit ihnen interagieren.

Quellen: Die Informationen in diesem Bericht wurden aus einer Reihe aktueller Ressourcen gesammelt, darunter Protokolldokumentationen, Entwickler-Blogbeiträge und Vorträge der EthCC 2025. Zu den wichtigsten Referenzen gehören die offiziellen Wormhole-Dokumente zu ihren Cross-Chain-Intent-Protokollen, Etherspots technische Blog-Serie zu Account- und Kettenabstraktion sowie die Release Notes des Open Intents Framework der Ethereum Foundation, unter anderem, wie im gesamten Text zitiert. Jede Zitation ist im Format 【Quelle†Zeilen】 gekennzeichnet, um das ursprüngliche Quellmaterial zu identifizieren, das die gemachten Aussagen stützt.

Einleitung​

Die Sui-Blockchain, die nach einem umfangreichen dreistufigen Testnet am 3. Mai 2023 öffentlich gestartet wurde, führte ein innovatives Gaspreissystem ein, das sowohl Benutzern als auch Validatoren zugutekommen soll. Im Mittelpunkt steht der Referenz-Gaspreis (RGP), eine netzwerkweite Basis-Gasgebühr, auf die sich die Validatoren zu Beginn jeder Epoche (ca. 24 Stunden) einigen.

Dieses System zielt darauf ab, ein für SUI-Token-Inhaber, Validatoren und Endbenutzer gleichermaßen vorteilhaftes Ökosystem zu schaffen, indem es niedrige, vorhersehbare Transaktionskosten bietet und gleichzeitig Validatoren für leistungsstarkes und zuverlässiges Verhalten belohnt. Dieser Bericht bietet einen tiefen Einblick in die Bestimmung des RGP, die Berechnungen der Validatoren, seine Auswirkungen auf die Netzwerkökonomie, seine Entwicklung durch Governance und seinen Vergleich mit anderen Blockchain-Gasmodellen.

Der Referenz-Gaspreis (RGP) Mechanismus​

Sui’s RGP ist kein statischer Wert, sondern wird in jeder Epoche durch einen dynamischen, von Validatoren gesteuerten Prozess neu festgelegt.

• Die Gaspreis-Umfrage: Zu Beginn jeder Epoche übermittelt jeder Validator seinen „Reservierungspreis“ – den Mindestgaspreis, den er für die Verarbeitung von Transaktionen zu akzeptieren bereit ist. Das Protokoll ordnet diese Einreichungen dann nach Stake und legt den RGP für diese Epoche auf das Stake-gewichtete 2/3 Perzentil fest. Dieses Design stellt sicher, dass Validatoren, die eine Supermajorität (mindestens zwei Drittel) des gesamten Stakes repräsentieren, bereit sind, Transaktionen zu diesem Preis zu verarbeiten, wodurch ein zuverlässiges Serviceniveau gewährleistet wird.

• Update-Kadenz und Anforderungen: Obwohl der RGP jede Epoche festgelegt wird, müssen Validatoren ihre Angebote aktiv verwalten. Gemäß den offiziellen Richtlinien müssen Validatoren ihr Gaspreisangebot mindestens einmal pro Woche aktualisieren. Wenn es außerdem eine signifikante Änderung des Wertes des SUI-Tokens gibt, wie z. B. eine Schwankung von 20% oder mehr, müssen Validatoren ihr Angebot sofort aktualisieren, um sicherzustellen, dass der RGP die aktuellen Marktbedingungen genau widerspiegelt.

• Die Zählregel und Belohnungsverteilung: Um sicherzustellen, dass Validatoren den vereinbarten RGP einhalten, verwendet Sui eine „Zählregel“. Während einer Epoche überwachen Validatoren die Leistung der anderen und verfolgen, ob ihre Peers RGP-bepreiste Transaktionen umgehend verarbeiten. Diese Überwachung führt zu einer Leistungsbewertung für jeden Validator. Am Ende der Epoche werden diese Bewertungen verwendet, um einen Belohnungsmultiplikator zu berechnen, der den Anteil jedes Validators an den Stake-Belohnungen anpasst.

  • Validatoren, die gut abgeschnitten haben, erhalten einen Multiplikator von ≥1, was ihre Belohnungen erhöht.
  • Validatoren, die Transaktionen zum RGP verzögert, blockiert oder nicht verarbeitet haben, erhalten einen Multiplikator von <1, wodurch ein Teil ihrer Einnahmen effektiv gekürzt wird (Slashing).

Dieses zweiteilige System schafft eine leistungsstarke Anreizstruktur. Es hält Validatoren davon ab, einen unrealistisch niedrigen Preis anzubieten, den sie nicht unterstützen können, da die finanzielle Strafe für Minderleistung schwerwiegend wäre. Stattdessen sind Validatoren motiviert, den niedrigsten Preis anzubieten, den sie nachhaltig und effizient handhaben können.

Validatoren-Operationen: Berechnung des Gaspreis-Angebots​

Aus Sicht eines Validators ist die Festlegung des RGP-Angebots eine kritische operative Aufgabe, die sich direkt auf die Rentabilität auswirkt. Sie erfordert den Aufbau von Datenpipelines und Automatisierungsebenen, um eine Reihe von Eingaben aus On-Chain- und Off-Chain-Quellen zu verarbeiten. Zu den wichtigsten Eingaben gehören:

• Ausgeführte Gaseinheiten pro Epoche
• Staking-Belohnungen und Subventionen pro Epoche
• Beiträge zum Speicherfonds
• Der Marktpreis des SUI-Tokens
• Betriebskosten (Hardware, Cloud-Hosting, Wartung)

Das Ziel ist es, ein Angebot zu berechnen, das positive Nettobelohnungen gewährleistet. Der Prozess umfasst mehrere Schlüsselformeln:

1. Gesamtbetriebskosten berechnen: Dies bestimmt die Ausgaben des Validators in Fiat-Währung für eine bestimmte Epoche.

   $$\text{Kosten}_{\text{Epoche}} = (\text{Gesamte ausgeführte Gaseinheiten}_{\text{Epoche}}) \times (\text{Kosten in \$ pro Gaseinheit}_{\text{Epoche}})$$

2. Gesamtbelohnungen berechnen: Dies bestimmt die Gesamteinnahmen des Validators in Fiat-Währung, die sowohl aus Protokollsubventionen als auch aus Transaktionsgebühren stammen.

   $$\text{\$Belohnungen}_{\text{Epoche}} = (\text{Gesamte Stake-Belohnungen in SUI}_{\text{Epoche}}) \times (\text{SUI Token-Preis})$$

   Wobei Gesamte Stake-Belohnungen die Summe aller vom Protokoll bereitgestellten Stake-Subventionen und der aus Transaktionen gesammelten Gasgebühren ist.

3. Nettobelohnungen berechnen: Dies ist das ultimative Maß für die Rentabilität eines Validators.

   $$\text{\$Nettobelohnungen}_{\text{Epoche}} = \text{\$Belohnungen}_{\text{Epoche}} - \text{\$Kosten}_{\text{Epoche}}$$

   Durch die Modellierung ihrer erwarteten Kosten und Belohnungen bei verschiedenen RGP-Niveaus können Validatoren ein optimales Angebot bestimmen, das sie der Gaspreis-Umfrage unterbreiten.

Beim Mainnet-Start legte Sui den anfänglichen RGP für die ersten ein bis zwei Wochen auf feste 1.000 MIST (1 SUI = 10⁹ MIST) fest. Dies bot den Validatoren eine stabile Betriebsphase, um ausreichende Netzwerkaktivitätsdaten zu sammeln und ihre Berechnungsprozesse zu etablieren, bevor der dynamische Umfragemechanismus voll wirksam wurde.

Auswirkungen auf das Sui-Ökosystem​

Der RGP-Mechanismus prägt die Wirtschaftlichkeit und das Benutzererlebnis des gesamten Netzwerks maßgeblich.

• Für Benutzer: Vorhersehbare und stabile Gebühren: Der RGP dient als glaubwürdiger Anker für Benutzer. Die Gasgebühr für eine Transaktion folgt einer einfachen Formel: Benutzer-Gaspreis = RGP + Trinkgeld. Unter normalen Bedingungen ist kein Trinkgeld erforderlich. Bei Netzwerküberlastung können Benutzer ein Trinkgeld hinzufügen, um Priorität zu erhalten, wodurch ein Gebührenmarkt entsteht, ohne den stabilen Basispreis innerhalb der Epoche zu ändern. Dieses Modell bietet eine deutlich höhere Gebührenstabilität als Systeme, bei denen sich die Basisgebühr mit jedem Block ändert.

• Für Validatoren: Ein Wettlauf um Effizienz: Das System fördert einen gesunden Wettbewerb. Validatoren werden dazu angeregt, ihre Betriebskosten (durch Hardware- und Softwareoptimierung) zu senken, um einen niedrigeren RGP profitabel anbieten zu können. Dieser „Wettlauf um Effizienz“ kommt dem gesamten Netzwerk zugute, indem er die Transaktionskosten senkt. Der Mechanismus drängt Validatoren auch zu ausgewogenen Gewinnmargen; ein zu hohes Angebot birgt das Risiko, aus der RGP-Berechnung herausgepreist zu werden, während ein zu niedriges Angebot zu Betriebsverlusten und Leistungsstrafen führt.

• Für das Netzwerk: Dezentralisierung und Nachhaltigkeit: Der RGP-Mechanismus trägt zur langfristigen Gesundheit des Netzwerks bei. Die „Eintrittsbedrohung“ durch neue, effizientere Validatoren verhindert, dass bestehende Validatoren kolludieren, um die Preise hoch zu halten. Darüber hinaus stellen Validatoren durch die Anpassung ihrer Angebote an den Marktpreis des SUI-Tokens gemeinsam sicher, dass ihre Operationen in realwirtschaftlicher Hinsicht nachhaltig bleiben, wodurch die Gebührenökonomie des Netzwerks vor Token-Preisvolatilität geschützt wird.

Governance und Systementwicklung: SIP-45​

Sui’s Gasmechanismus ist nicht statisch und entwickelt sich durch Governance weiter. Ein prominentes Beispiel ist SIP-45 (Priorisierte Transaktionsübermittlung), das vorgeschlagen wurde, um die gebührenbasierte Priorisierung zu verfeinern.

• Behandeltes Problem: Analysen zeigten, dass die einfache Zahlung eines hohen Gaspreises nicht immer eine schnellere Transaktionsaufnahme garantierte.
• Vorgeschlagene Änderungen: Der Vorschlag umfasste die Erhöhung des maximal zulässigen Gaspreises und die Einführung einer „verstärkten Übertragung“ für Transaktionen, die deutlich über dem RGP liegen (z. B. ≥5x RGP), um deren schnelle Verbreitung im Netzwerk für eine prioritäre Aufnahme zu gewährleisten.

Dies zeigt das Engagement, das Gasmodell auf der Grundlage empirischer Daten zu iterieren, um seine Wirksamkeit zu verbessern.

Vergleich mit anderen Blockchain-Gasmodellen​

Sui’s RGP-Modell ist einzigartig, insbesondere im Vergleich zu Ethereums EIP-1559.

Potenzielle Kritikpunkte und Herausforderungen​

Trotz seines innovativen Designs steht der RGP-Mechanismus vor potenziellen Herausforderungen:

• Komplexität: Das System aus Umfragen, Zählregeln und Off-Chain-Berechnungen ist komplex und kann für neue Validatoren eine Lernkurve darstellen.
• Langsame Reaktion auf Spitzen: Der RGP ist für eine Epoche festgelegt und kann nicht auf plötzliche Nachfragespitzen mitten in der Epoche reagieren, was zu vorübergehender Überlastung führen könnte, bis Benutzer beginnen, Trinkgelder hinzuzufügen.
• Potenzial für Kollusion: Theoretisch könnten Validatoren kolludieren, um einen hohen RGP festzulegen. Dieses Risiko wird hauptsächlich durch die Wettbewerbsnatur des permissionless Validatoren-Sets gemindert.
• Kein Gebühren-Burn: Im Gegensatz zu Ethereum recycelt Sui alle Gasgebühren an Validatoren und den Speicherfonds. Dies belohnt Netzwerkbetreiber, erzeugt aber keinen deflationären Druck auf den SUI-Token, ein Merkmal, das einige Token-Inhaber schätzen.

Häufig gestellte Fragen (FAQ)​

Warum SUI staken? Das Staking von SUI sichert das Netzwerk und bringt Belohnungen ein. Anfangs werden diese Belohnungen von der Sui Foundation stark subventioniert, um die geringe Netzwerkaktivität auszugleichen. Diese Subventionen sinken alle 90 Tage um 10%, wobei erwartet wird, dass die Belohnungen aus Transaktionsgebühren zur primären Ertragsquelle werden. Gestaktes SUI gewährt auch Stimmrechte in der On-Chain-Governance.

Kann mein gestaktes SUI geslasht werden? Ja. Während die Parameter noch finalisiert werden, gilt das „Tally Rule Slashing“. Ein Validator, der von 2/3 seiner Peers eine Null-Leistungsbewertung erhält (aufgrund geringer Leistung, böswilligen Verhaltens usw.), wird seine Belohnungen um einen noch festzulegenden Betrag gekürzt sehen. Staker können auch Belohnungen verpassen, wenn ihr gewählter Validator Ausfallzeiten hat oder einen suboptimalen RGP anbietet.

Werden Staking-Belohnungen automatisch zusammengesetzt? Ja, Staking-Belohnungen auf Sui werden jede Epoche automatisch verteilt und erneut gestaked (zusammengesetzt). Um auf Belohnungen zuzugreifen, müssen Sie diese explizit entstaken.

Was ist die Sui Unbonding-Periode? Anfangs können Staker ihre Token sofort entstaken. Es wird erwartet, dass eine Unbonding-Periode, in der Token nach dem Entstaken für eine festgelegte Zeit gesperrt sind, implementiert wird und der Governance unterliegen wird.

Behalte ich die Verwahrung meiner SUI-Token beim Staking? Ja. Wenn Sie SUI staken, delegieren Sie Ihren Stake, behalten aber die volle Kontrolle über Ihre Token. Sie übertragen niemals die Verwahrung an den Validator.

In den sich schnell annähernden Welten der künstlichen Intelligenz und der Blockchain war die Nachfrage nach Vertrauen und Transparenz noch nie so hoch. Wie können wir sicher sein, dass die Ausgabe eines KI-Modells genau und unverfälscht ist? Wie können wir komplexe Berechnungen an riesigen On-Chain-Datensätzen durchführen, ohne die Sicherheit oder Skalierbarkeit zu beeinträchtigen? Lagrange Labs stellt sich diesen Fragen direkt mit seiner Suite von Zero-Knowledge (ZK)-Infrastruktur, um eine Zukunft der "nachweisbaren KI" aufzubauen. Dieser Beitrag bietet einen objektiven Überblick über ihre Mission, Technologie und jüngsten Durchbrüche, die in ihrem neuesten Paper über dynamische zk-SNARKs gipfeln.

1. Das Team und seine Mission​

Lagrange Labs baut die grundlegende Infrastruktur auf, um kryptografische Proofs für jede KI-Inferenz oder On-Chain-Anwendung zu generieren. Ihr Ziel ist es, Berechnungen verifizierbar zu machen und der digitalen Welt eine neue Vertrauensebene hinzuzufügen. Ihr Ökosystem basiert auf drei Kernproduktlinien:

• ZK Prover Network: Ein dezentrales Netzwerk von über 85 Proving-Knoten, das die Rechenleistung für eine Vielzahl von Proving-Aufgaben liefert, von KI und Rollups bis hin zu dezentralen Anwendungen (dApps).
• DeepProve (zkML): Ein spezialisiertes System zur Generierung von ZK-Proofs für neuronale Netzwerkinferenzen. Lagrange behauptet, es sei bis zu 158-mal schneller als konkurrierende Lösungen, was verifizierbare KI zu einer praktischen Realität macht.
• ZK Coprocessor 1.0: Der erste SQL-basierte ZK-Koprozessor, der es Entwicklern ermöglicht, benutzerdefinierte Abfragen auf massiven On-Chain-Datensätzen auszuführen und verifizierbar genaue Ergebnisse zu erhalten.

2. Eine Roadmap zur verifizierbaren KI​

Lagrange hat methodisch eine Roadmap umgesetzt, die darauf abzielt, die Herausforderungen der KI-Verifizierbarkeit Schritt für Schritt zu lösen.

• Q3 2024: ZK Coprocessor 1.0 Launch: Diese Veröffentlichung führte hyper-parallele rekursive Schaltkreise ein, die eine durchschnittliche Geschwindigkeitssteigerung von etwa 2x lieferten. Projekte wie Azuki und Gearbox nutzen den Koprozessor bereits für ihre On-Chain-Datenanforderungen.
• Q1 2025: DeepProve vorgestellt: Lagrange kündigte DeepProve an, seine Lösung für Zero-Knowledge Machine Learning (zkML). Es unterstützt gängige neuronale Netzwerkarchitekturen wie Multi-Layer Perceptrons (MLPs) und Convolutional Neural Networks (CNNs). Das System erreicht eine signifikante Beschleunigung um Größenordnungen in allen drei kritischen Phasen: einmalige Einrichtung, Proof-Generierung und Verifizierung, mit Beschleunigungen von bis zu 158x.
• Q2 2025: Das Dynamic zk-SNARKs Paper (Jüngster Meilenstein): Dieses Paper stellt einen bahnbrechenden "Update"-Algorithmus vor. Anstatt jedes Mal, wenn sich die zugrunde liegenden Daten oder Berechnungen ändern, einen Proof von Grund auf neu zu generieren, kann diese Methode einen alten Proof (π) in einen neuen Proof (π') einfügen. Dieses Update kann mit einer Komplexität von nur O(√n log³n) durchgeführt werden, eine dramatische Verbesserung gegenüber einer vollständigen Neuberechnung. Diese Innovation eignet sich besonders für dynamische Systeme wie kontinuierlich lernende KI-Modelle, Echtzeit-Spiellogik und sich entwickelnde Smart Contracts.

3. Warum dynamische zk-SNARKs wichtig sind​

Die Einführung aktualisierbarer Proofs stellt eine grundlegende Verschiebung im Kostenmodell der Zero-Knowledge-Technologie dar.

• Ein neues Kostenparadigma: Die Branche bewegt sich von einem Modell der "vollständigen Neuberechnung für jeden Proof" zu einem "inkrementellen Proofing basierend auf der Größe der Änderung". Dies senkt die Rechen- und Finanzkosten für Anwendungen, die häufigen, kleineren Updates unterliegen, drastisch.

• Implikationen für KI:

  • Kontinuierliches Fine-Tuning: Beim Fine-Tuning von weniger als 1 % der Parameter eines Modells wächst die Proof-Generierungszeit fast linear mit der Anzahl der geänderten Parameter (Δ Parameter) und nicht mit der Gesamtgröße des Modells.
  • Streaming-Inferenz: Dies ermöglicht die Generierung von Proofs gleichzeitig mit dem Inferenzprozess selbst. Dies reduziert die Latenz zwischen einer KI-Entscheidung und deren On-Chain-Settlement und -Verifizierung drastisch, was Anwendungsfälle wie On-Chain-KI-Dienste und komprimierte Proofs für Rollups ermöglicht.

• Implikationen für On-Chain-Anwendungen:

  • Dynamische zk-SNARKs bieten massive Gas- und Zeitoptimierungen für Anwendungen, die durch häufige, kleine Zustandsänderungen gekennzeichnet sind. Dazu gehören Orderbücher dezentraler Börsen (DEX), sich entwickelnde Spielzustände und Ledger-Updates, die häufige Ergänzungen oder Löschungen beinhalten.

4. Ein Einblick in den Tech-Stack​

Die leistungsstarke Infrastruktur von Lagrange basiert auf einem ausgeklügelten und integrierten Technologie-Stack:

• Schaltkreisdesign: Das System ist flexibel und unterstützt das direkte Einbetten von ONNX (Open Neural Network Exchange)-Modellen, SQL-Parsern und benutzerdefinierten Operatoren in seine Schaltkreise.
• Rekursion & Parallelität: Das ZK Prover Network ermöglicht verteilte rekursive Proofs, während der ZK Coprocessor die Aufteilung von "Mikroschaltkreisen" nutzt, um Aufgaben parallel auszuführen und die Effizienz zu maximieren.
• Wirtschaftliche Anreize: Lagrange plant die Einführung eines nativen Tokens, LA, der in ein Double-Auction-for-Recursive-Auction (DARA)-System integriert wird. Dies wird einen robusten Marktplatz für Gebote auf Prover-Berechnungen schaffen, komplett mit Anreizen und Strafen, um die Netzwerkintegrität zu gewährleisten.

5. Ökosystem und reale Akzeptanz​

Lagrange baut nicht nur im Vakuum; seine Technologie wird bereits von einer wachsenden Anzahl von Projekten in verschiedenen Sektoren integriert:

• KI & ML: Projekte wie 0G Labs und Story Protocol verwenden DeepProve, um die Ausgaben ihrer KI-Modelle zu verifizieren und so Herkunft und Vertrauen zu gewährleisten.
• Rollups & Infrastruktur: Schlüsselakteure wie EigenLayer, Base und Arbitrum beteiligen sich am ZK Prover Network als Validierungsknoten oder Integrationspartner und tragen zu dessen Sicherheit und Rechenleistung bei.
• NFT & DeFi-Anwendungen: Marken wie Azuki und DeFi-Protokolle wie Gearbox nutzen den ZK Coprocessor, um die Glaubwürdigkeit ihrer Datenabfragen und Belohnungsverteilungsmechanismen zu verbessern.

6. Herausforderungen und der Weg nach vorn​

Trotz seiner beeindruckenden Fortschritte stehen Lagrange Labs und das breitere ZK-Feld vor mehreren Hürden:

• Hardware-Engpässe: Selbst mit einem verteilten Netzwerk erfordern aktualisierbare SNARKs immer noch eine hohe Bandbreite und verlassen sich auf GPU-freundliche kryptografische Kurven, um effizient zu arbeiten.
• Mangelnde Standardisierung: Der Prozess der Abbildung von KI-Frameworks wie ONNX und PyTorch auf ZK-Schaltkreise entbehrt immer noch einer universellen, standardisierten Schnittstelle, was Reibung für Entwickler erzeugt.
• Eine wettbewerbsintensive Landschaft: Das Rennen um den Bau von zkVMs und generalisierten zkCompute-Plattformen heizt sich auf. Konkurrenten wie Risc-Zero und Succinct machen ebenfalls erhebliche Fortschritte. Der ultimative Gewinner könnte derjenige sein, der zuerst eine entwicklerfreundliche, gemeinschaftsgetriebene Toolchain kommerzialisieren kann.

7. Fazit​

Lagrange Labs gestaltet die Schnittstelle von KI und Blockchain durch die Linse der Verifizierbarkeit methodisch neu. Ihr Ansatz bietet eine umfassende Lösung:

• DeepProve adressiert die Herausforderung der vertrauenswürdigen Inferenz.
• Der ZK Coprocessor löst das Problem der vertrauenswürdigen Daten.
• Dynamische zk-SNARKs integrieren die reale Notwendigkeit kontinuierlicher Updates direkt in das Proof-System.

Wenn Lagrange seinen Leistungsvorsprung beibehalten, die kritische Herausforderung der Standardisierung lösen und sein robustes Netzwerk weiter ausbauen kann, ist es gut positioniert, ein Eckpfeiler-Akteur im aufstrebenden Sektor der "KI + ZK-Infrastruktur" zu werden.

Wenn Sie Krypto senden, wie sieht Ihre Routine aus? Für die meisten von uns beinhaltet sie das Kopieren der Empfängeradresse aus unserer Transaktionshistorie. Schließlich kann sich niemand eine 40-stellige Zeichenfolge wie 0x1A2b...8f9E merken. Es ist eine bequeme Abkürzung, die wir alle nutzen.

Doch was, wenn diese Bequemlichkeit eine sorgfältig ausgelegte Falle ist?

Ein verheerend effektiver Betrug namens Blockchain-Adressvergiftung nutzt genau diese Gewohnheit aus. Jüngste Forschungen der Carnegie Mellon University haben das schockierende Ausmaß dieser Bedrohung aufgedeckt. Allein in zwei Jahren haben Betrüger auf den Netzwerken Ethereum und Binance Smart Chain (BSC) über 270 Millionen Angriffsversuche unternommen, 17 Millionen Opfer ins Visier genommen und erfolgreich mindestens 83,8 Millionen US-Dollar gestohlen.

Dies ist keine Nischenbedrohung; es ist eine der größten und erfolgreichsten Krypto-Phishing-Maschen, die heute aktiv sind. So funktioniert dieser Betrug und das können Sie tun, um sich zu schützen.

So funktioniert die Täuschung 🤔​

Adressvergiftung ist ein Spiel der visuellen Täuschung. Die Strategie des Angreifers ist einfach, aber brillant:

1. Eine ähnlich aussehende Adresse generieren: Der Angreifer identifiziert eine häufig von Ihnen verwendete Adresse, an die Sie Gelder senden. Anschließend nutzen sie leistungsstarke Computer, um eine neue Krypto-Adresse zu generieren, die die exakt gleichen Start- und Endzeichen aufweist. Da die meisten Wallets und Block-Explorer Adressen zur Anzeige kürzen (z. B. 0x1A2b...8f9E), sieht ihre betrügerische Adresse auf den ersten Blick identisch mit der echten aus.

2. Ihre Transaktionshistorie „vergiften“: Als Nächstes muss der Angreifer seine ähnlich aussehende Adresse in die Historie Ihrer Wallet bringen. Dies geschieht, indem er eine „Gift“-Transaktion sendet. Dies kann sein:

   • Eine winzige Überweisung: Sie senden Ihnen einen winzigen Betrag Krypto (z. B. 0,001 US-Dollar) von ihrer ähnlich aussehenden Adresse. Diese erscheint nun in Ihrer Liste der letzten Transaktionen.
   • Eine Nullwert-Überweisung: In einem raffinierteren Schachzug nutzen sie eine Funktion in vielen Token-Kontrakten aus, um eine gefälschte Überweisung ohne Wert zu erstellen, die so aussieht, als käme sie von Ihnen an ihre ähnlich aussehende Adresse. Dies lässt die gefälschte Adresse noch legitimer erscheinen, da es so aussieht, als hätten Sie bereits zuvor Gelder dorthin gesendet.
   • Eine gefälschte Token-Überweisung: Sie erstellen einen wertlosen, gefälschten Token (z. B. „USDTT“ anstelle von USDT) und fälschen eine Transaktion an ihre ähnlich aussehende Adresse, oft indem sie den Betrag einer früheren echten Transaktion nachahmen, die Sie getätigt haben.

3. Auf den Fehler warten: Die Falle ist nun gestellt. Wenn Sie das nächste Mal einen legitimen Kontakt bezahlen möchten, durchsuchen Sie Ihre Transaktionshistorie, sehen die Adresse, die Sie für die richtige halten, kopieren sie und klicken auf Senden. Bis Sie Ihren Fehler bemerken, sind die Gelder verschwunden. Und dank der Unumkehrbarkeit der Blockchain gibt es keine Bank, die Sie anrufen könnten, und keine Möglichkeit, sie zurückzubekommen.

Ein Einblick in ein kriminelles Unternehmen 🕵️‍♂️​

Dies ist nicht das Werk einzelner Hacker. Die Forschung zeigt, dass diese Angriffe von großen, organisierten und hochprofitablen kriminellen Gruppen durchgeführt werden.

Wen sie ins Visier nehmen​

Angreifer verschwenden ihre Zeit nicht mit kleinen Konten. Sie zielen systematisch auf Nutzer ab, die:

• Vermögend sind: Erhebliche Guthaben in Stablecoins halten.
• Aktiv sind: Häufige Transaktionen durchführen.
• Hochwertige Transaktionen durchführen: Große Geldsummen bewegen.

Ein Hardware-Wettrüsten​

Das Generieren einer ähnlich aussehenden Adresse ist eine Brute-Force-Rechenaufgabe. Je mehr Zeichen Sie abgleichen möchten, desto exponentiell schwieriger wird es. Forscher fanden heraus, dass die meisten Angreifer Standard-CPUs verwenden, um mäßig überzeugende Fälschungen zu erstellen, die raffinierteste kriminelle Gruppe es jedoch auf eine andere Ebene gebracht hat.

Dieser Top-Tier-Gruppe ist es gelungen, Adressen zu generieren, die bis zu 20 Zeichen einer Zieladresse abgleichen. Diese Leistung ist mit Standardcomputern nahezu unmöglich, was die Forscher zu dem Schluss führt, dass sie massive GPU-Farmen verwenden – die gleiche Art von leistungsstarker Hardware, die für High-End-Gaming oder KI-Forschung eingesetzt wird. Dies zeigt eine erhebliche finanzielle Investition, die sie leicht von ihren Opfern zurückgewinnen. Diese organisierten Gruppen betreiben ein Geschäft, und das Geschäft boomt leider.

So schützen Sie Ihre Gelder 🛡️​

Obwohl die Bedrohung raffiniert ist, sind die Abwehrmaßnahmen unkompliziert. Es geht darum, schlechte Gewohnheiten abzulegen und eine wachsamere Denkweise anzunehmen.

1. Für jeden Nutzer (Dies ist der wichtigste Teil):

   • ÜBERPRÜFEN SIE DIE VOLLSTÄNDIGE ADRESSE. Bevor Sie auf „Bestätigen“ klicken, nehmen Sie sich fünf zusätzliche Sekunden Zeit, um die gesamte Adresse manuell Zeichen für Zeichen zu überprüfen. Werfen Sie nicht nur einen Blick auf die ersten und letzten Ziffern.
   • VERWENDEN SIE EIN ADRESSBUCH. Speichern Sie vertrauenswürdige, verifizierte Adressen im Adressbuch oder in der Kontaktliste Ihrer Wallet. Wählen Sie beim Senden von Geldern den Empfänger immer aus dieser gespeicherten Liste aus, nicht aus Ihrer dynamischen Transaktionshistorie.
   • SENDEN SIE EINE TESTTRANSAKTION. Senden Sie bei großen oder wichtigen Zahlungen zuerst einen winzigen Betrag. Bestätigen Sie mit dem Empfänger, dass er ihn erhalten hat, bevor Sie den vollen Betrag senden.

2. Ein Aufruf für bessere Wallets:

   • Wallet-Entwickler können helfen, indem sie die Benutzeroberflächen verbessern. Dazu gehört, standardmäßig mehr von der Adresse anzuzeigen oder starke, explizite Warnungen hinzuzufügen, wenn ein Nutzer im Begriff ist, Gelder an eine Adresse zu senden, mit der er nur über eine winzige oder Nullwert-Überweisung interagiert hat.

3. Die langfristige Lösung:

   • Systeme wie der Ethereum Name Service (ENS), die es Ihnen ermöglichen, einen menschenlesbaren Namen wie ihrname.eth Ihrer Adresse zuzuordnen, können dieses Problem vollständig beseitigen. Eine breitere Akzeptanz ist entscheidend.

In der dezentralen Welt sind Sie Ihre eigene Bank, was auch bedeutet, dass Sie Ihr eigener Sicherheitschef sind. Adressvergiftung ist eine stille, aber mächtige Bedrohung, die Bequemlichkeit und Unaufmerksamkeit ausnutzt. Indem Sie bewusst vorgehen und Ihre Arbeit doppelt überprüfen, können Sie sicherstellen, dass Ihre hart verdienten Vermögenswerte nicht in der Falle eines Betrügers landen.