102 Beiträge getaggt mit „Blockchain“

TL;DR​

Ein Krypto-Airdrop ist eine Verteilung von Token an bestimmte Wallet-Adressen – oft kostenlos –, um ein Netzwerk zu starten, das Eigentum zu dezentralisieren oder frühe Community-Mitglieder zu belohnen. Beliebte Methoden umfassen retrospektive Belohnungen für vergangene Aktionen, Punkte-zu-Token-Umwandlungen, Drops für NFT- oder Token-Inhaber und interaktive „Quest“-Kampagnen. Der Teufel steckt im Detail: Snapshot-Regeln, Claim-Mechanismen wie Merkle-Proofs, Sybil-Resistenz, klare Kommunikation und rechtliche Compliance sind entscheidend für den Erfolg. Für Nutzer ist der Wert an Tokenomics und Sicherheit gebunden. Für Teams muss ein erfolgreicher Airdrop mit den Kernproduktzielen übereinstimmen und nicht nur vorübergehenden Hype erzeugen.

Was ist ein Airdrop – wirklich?​

Im Kern ist ein Krypto-Airdrop eine Marketing- und Distributionsstrategie, bei der ein Projekt seinen nativen Token an die Wallets einer bestimmten Nutzergruppe sendet. Dies ist nicht nur ein Giveaway; es ist ein kalkulierter Schritt, um spezifische Ziele zu erreichen. Wie von Bildungsressourcen von Coinbase und Binance Academy definiert, werden Airdrops häufig verwendet, wenn ein neues Netzwerk, DeFi-Protokoll oder eine dApp schnell eine Nutzerbasis aufbauen möchte. Indem Projekte potenziellen Nutzern Token geben, können sie diese dazu anregen, an der Governance teilzunehmen, Liquidität bereitzustellen, neue Funktionen zu testen oder einfach aktive Mitglieder der Community zu werden, wodurch der Netzwerkeffekt in Gang gesetzt wird.

Wo Airdrops in der Praxis auftauchen​

Airdrops gibt es in verschiedenen Ausprägungen, jede mit einem anderen strategischen Zweck. Hier sind die gängigsten Modelle, die heute in der Praxis zu finden sind.

Retrospektiv (belohnt früheres Verhalten)​

Dies ist das klassische Modell, das darauf abzielt, frühe Anwender zu belohnen, die ein Protokoll nutzten, bevor es einen Token hatte. Uniswaps Airdrop von 2020 ist das definitive Beispiel, das die moderne Vorlage setzte, indem es 400 $UNI-Token an jede Adresse verteilte, die jemals mit dem Protokoll interagiert hatte. Es war ein mächtiges „Dankeschön“, das Nutzer über Nacht zu Eigentümern machte.

Punkte → Token (Anreize zuerst, Token später)​

Ein dominanter Trend in den Jahren 2024 und 2025 ist das Punkte-Modell, das die Teilnahme gamifiziert. Projekte verfolgen Nutzeraktionen – wie Bridging, Swapping oder Staking – und vergeben Off-Chain-„Punkte“. Später werden diese Punkte in eine Token-Zuteilung umgewandelt. Dieser Ansatz ermöglicht es Teams, gewünschte Verhaltensweisen über einen längeren Zeitraum zu messen und zu incentivieren, bevor sie sich zu einem Token-Launch verpflichten.

Inhaber-/NFT-Drops​

Diese Art von Airdrop richtet sich an Nutzer, die bereits einen bestimmten Token oder NFT halten. Es ist eine Möglichkeit, die Loyalität innerhalb eines bestehenden Ökosystems zu belohnen oder ein neues Projekt mit einer engagierten Community zu starten. Ein berühmter Fall ist ApeCoin, das bei seinem Start im Jahr 2022 den Inhabern von Bored Ape und Mutant Ape Yacht Club NFTs Anspruchsrechte auf seinen $APE-Token gewährte.

Ökosystem-/Governance-Programme​

Einige Projekte nutzen eine Reihe von Airdrops als Teil einer langfristigen Strategie zur Dezentralisierung und zum Community-Wachstum. Optimism hat beispielsweise mehrere Airdrops für Nutzer durchgeführt und gleichzeitig einen erheblichen Teil seines Token-Angebots für die Finanzierung öffentlicher Güter durch sein RetroPGF-Programm reserviert. Dies zeigt ein Engagement für den Aufbau eines nachhaltigen und werteorientierten Ökosystems.

Wie ein Airdrop funktioniert (Mechanismen, die zählen)​

Der Unterschied zwischen einem erfolgreichen und einem chaotischen Airdrop liegt oft in der technischen und strategischen Ausführung. Hier sind die Mechanismen, die wirklich zählen.

Snapshot & Berechtigung​

Zuerst muss ein Projekt entscheiden, wer qualifiziert ist. Dies beinhaltet die Wahl eines Snapshots – einer bestimmten Blockhöhe oder eines Datums –, nach dem die Nutzeraktivität nicht mehr gezählt wird. Die Berechtigungskriterien werden dann basierend auf Verhaltensweisen definiert, die das Projekt belohnen möchte, wie z. B. das Überbrücken von Geldern, das Ausführen von Swaps, das Bereitstellen von Liquidität, die Teilnahme an der Governance oder sogar das Beitragen von Code. Für seinen Airdrop arbeitete Arbitrum mit dem Analyseunternehmen Nansen zusammen, um ein ausgeklügeltes Verteilungsmodell zu entwickeln, das auf einem Snapshot basiert, der am 6. Februar 2023 zu einem bestimmten Blockzeitpunkt erstellt wurde.

Claim vs. Direktsendung​

Während das direkte Senden von Token an Wallets einfacher erscheint, verwenden die meisten ausgereiften Projekte einen Claim-basierten Flow. Dies verhindert, dass Token an verlorene oder kompromittierte Adressen gesendet werden, und erfordert, dass Nutzer aktiv werden. Das gängigste Muster ist ein Merkle Distributor. Ein Projekt veröffentlicht einen kryptografischen Fingerabdruck (einen Merkle-Root) der berechtigten Adressen On-Chain. Jeder Nutzer kann dann einen eindeutigen „Proof“ generieren, um seine Berechtigung zu überprüfen und seine Token einzufordern. Diese Methode, die durch Uniswaps Open-Source-Implementierung populär wurde, ist gas-effizient und sicher.

Sybil-Resistenz​

Airdrops sind ein Hauptziel für „Farmer“ – Einzelpersonen, die Hunderte oder Tausende von Wallets (einen „Sybil-Angriff“) verwenden, um ihre Belohnungen zu maximieren. Teams setzen verschiedene Methoden ein, um dies zu bekämpfen. Dazu gehören die Verwendung von Analysen zur Clusterbildung von Wallets, die von einer einzigen Entität kontrolliert werden, die Anwendung von Heuristiken (wie Wallet-Alter oder Aktivitätsvielfalt) und in jüngerer Zeit die Implementierung von Selbstmelde-Programmen. LayerZeros Kampagne von 2024 führte ein viel diskutiertes Modell ein, bei dem Nutzern die Möglichkeit gegeben wurde, Sybil-Aktivitäten selbst zu melden, um eine 15 %ige Zuteilung zu erhalten; diejenigen, die dies nicht taten und später erwischt wurden, wurden ausgeschlossen.

Freigabeplan & Governance​

Nicht alle Token aus einem Airdrop sind sofort verfügbar. Viele Projekte implementieren einen schrittweisen Freigabeplan (oder eine Vesting-Periode) für Zuteilungen an das Team, Investoren und Ökosystemfonds. Das Verständnis dieses Plans ist für Nutzer entscheidend, um den zukünftigen Angebotsdruck auf dem Markt einzuschätzen. Plattformen wie TokenUnlocks bieten öffentliche Dashboards, die diese Freigabezeitpläne für Hunderte von Assets verfolgen.

Fallstudien (Kurzfakten)​

• Uniswap (2020): Verteilt 400 $UNI pro berechtigter Adresse, mit größeren Zuteilungen für Liquiditätsanbieter. Es etablierte das Claim-basierte Merkle-Proof-Modell als Industriestandard und demonstrierte die Kraft, eine Community retrospektiv zu belohnen.
• Arbitrum (2023): Startete seinen L2-Governance-Token $ARB mit einem anfänglichen Angebot von 10 Milliarden. Der Airdrop verwendete ein Punktesystem, das auf On-Chain-Aktivitäten vor einem Snapshot vom 6. Februar 2023 basierte und fortschrittliche Analysen und Sybil-Filter von Nansen integrierte.
• Starknet (2024): Brandete seinen Airdrop als „Provisions Program“, wobei die Claims am 20. Februar 2024 eröffnet wurden. Es richtete sich an eine breite Palette von Mitwirkenden, darunter frühe Nutzer, Netzwerkentwickler und sogar Ethereum-Staker, und bot ein mehrmonatiges Fenster zum Claimen.
• ZKsync (2024): Am 11. Juni 2024 angekündigt, war dies eine der größten Layer-2-Nutzerverteilungen bis dato. Ein einmaliger Airdrop verteilte 17,5 % des gesamten Token-Angebots an fast 700.000 Wallets und belohnte die frühe Community des Protokolls.

Warum Teams Airdrops durchführen (und wann nicht)​

Teams nutzen Airdrops aus mehreren strategischen Gründen:

• Start eines zweiseitigen Netzwerks: Airdrops können ein Netzwerk mit den notwendigen Teilnehmern versorgen, seien es Liquiditätsanbieter, Trader, Creator oder Restaker.
• Dezentralisierung der Governance: Die Verteilung von Token an eine breite Basis aktiver Nutzer ist ein grundlegender Schritt zu glaubwürdiger Dezentralisierung und einer von der Community geführten Governance.
• Belohnung früher Mitwirkender: Für Projekte, die kein ICO oder Token-Verkauf durchgeführt haben, ist ein Airdrop der primäre Weg, frühe Unterstützer zu belohnen, die Wert lieferten, als das Ergebnis unsicher war.
• Werte signalisieren: Das Design eines Airdrops kann die Kernprinzipien eines Projekts kommunizieren. Optimisms Fokus auf die Finanzierung öffentlicher Güter ist ein Paradebeispiel dafür.

Airdrops sind jedoch kein Allheilmittel. Teams sollten keinen Airdrop durchführen, wenn das Produkt eine schlechte Bindung aufweist, die Community schwach ist oder der Nutzen des Tokens schlecht definiert ist. Ein Airdrop verstärkt bestehende positive Rückkopplungsschleifen; er kann kein defektes Produkt reparieren.

Für Nutzer: Wie man sicher bewertet und teilnimmt​

Airdrops können lukrativ sein, bergen aber auch erhebliche Risiken. Hier erfahren Sie, wie Sie sich sicher in der Landschaft bewegen.

Bevor Sie einem Drop nachjagen​

• Überprüfen Sie die Legitimität: Verifizieren Sie Airdrop-Ankündigungen immer über die offiziellen Kanäle des Projekts (Website, X-Konto, Discord). Seien Sie äußerst vorsichtig bei „Claim“-Links, die über DMs gesendet, in Anzeigen gefunden oder von unbestätigten Konten beworben werden.
• Analysieren Sie die Ökonomie: Verstehen Sie die Tokenomics. Was ist das Gesamtangebot? Welcher Prozentsatz ist für Nutzer vorgesehen? Was ist der Vesting-Zeitplan für Insider? Tools wie TokenUnlocks können Ihnen helfen, zukünftige Angebotsfreigaben zu verfolgen.
• Kennen Sie den Stil: Ist es ein retrospektiver Drop, der früheres Verhalten belohnt, oder ein Punkteprogramm, das eine kontinuierliche Teilnahme erfordert? Die Regeln für jedes sind unterschiedlich, und Punkteprogramme können ihre Kriterien im Laufe der Zeit ändern.

Wallet-Hygiene​

• Verwenden Sie eine neue Wallet: Verwenden Sie, wenn möglich, eine dedizierte „Burner“-Wallet mit geringem Wert, um Airdrops zu claimen. Dies isoliert das Risiko von Ihren Hauptbeständen.
• Lesen Sie, was Sie signieren: Genehmigen Sie Transaktionen niemals blind. Bösartige Websites können Sie dazu verleiten, Berechtigungen zu unterzeichnen, die es ihnen ermöglichen, Ihre Assets zu leeren. Verwenden Sie Wallet-Simulatoren, um eine Transaktion zu verstehen, bevor Sie sie signieren. Überprüfen und widerrufen Sie regelmäßig veraltete Genehmigungen mit Tools wie Revoke.cash.
• Seien Sie vorsichtig bei Off-Chain-Signaturen: Betrüger missbrauchen zunehmend Permit- und Permit2-Signaturen, bei denen es sich um Off-Chain-Genehmigungen handelt, die verwendet werden können, um Ihre Assets ohne eine On-Chain-Transaktion zu bewegen. Seien Sie bei diesen genauso vorsichtig wie bei On-Chain-Genehmigungen.

Häufige Risiken​

• Phishing & Drainer: Das häufigste Risiko ist die Interaktion mit einer gefälschten „Claim“-Website, die darauf ausgelegt ist, Ihre Wallet zu leeren. Untersuchungen von Firmen wie Scam Sniffer zeigen, dass ausgeklügelte Drainer-Kits für massive Verluste in den Jahren 2023–2025 verantwortlich waren.
• Geofencing & KYC: Einige Airdrops können geografische Beschränkungen haben oder eine Know Your Customer (KYC)-Verifizierung erfordern. Lesen Sie immer die Geschäftsbedingungen, da Einwohner bestimmter Länder ausgeschlossen sein können.
• Steuern (Kurzorientierung, keine Beratung): Die steuerliche Behandlung variiert je nach Gerichtsbarkeit. In den USA behandelt der IRS Airdrop-Token im Allgemeinen als steuerpflichtiges Einkommen zum fairen Marktwert an dem Datum, an dem Sie die Kontrolle über sie erlangen. Im Vereinigten Königreich kann HMRC einen Airdrop als Einkommen betrachten, wenn Sie eine Handlung ausgeführt haben, um ihn zu erhalten. Die spätere Veräußerung der Token kann die Kapitalertragssteuer auslösen. Konsultieren Sie einen qualifizierten Fachmann.

Für Teams: Eine pragmatische Checkliste für das Airdrop-Design​

Planen Sie einen Airdrop? Hier ist eine Checkliste, die Sie bei Ihrem Designprozess unterstützt.

1. Klären Sie das Ziel: Was wollen Sie erreichen? Echte Nutzung belohnen, Governance dezentralisieren, Liquidität bereitstellen oder Entwickler finanzieren? Definieren Sie Ihr primäres Ziel und machen Sie das Zielverhalten explizit.
2. Legen Sie Berechtigungskriterien fest, die Ihr Produkt widerspiegeln: Entwerfen Sie Kriterien, die beständige, hochwertige Nutzer belohnen. Gewichten Sie Aktionen, die mit der Bindung korrelieren (z. B. zeitgewichtete Salden, konsistenter Handel), gegenüber einfachem Volumen und erwägen Sie eine Begrenzung der Belohnungen für Wale. Studieren Sie öffentliche Post-Mortems von großen Airdrops auf Plattformen wie Nansen.
3. Bauen Sie Sybil-Resistenz ein: Verlassen Sie sich nicht auf eine einzige Methode. Kombinieren Sie On-Chain-Heuristiken (Wallet-Alter, Aktivitätsvielfalt) mit Cluster-Analysen. Erwägen Sie neuartige Ansätze wie das von LayerZero entwickelte Community-unterstützte Meldesystem.
4. Implementieren Sie einen robusten Claim-Pfad: Verwenden Sie einen bewährten Merkle-Distributor-Vertrag. Veröffentlichen Sie den vollständigen Datensatz und den Merkle-Baum, damit jeder den Root und seine eigene Berechtigung unabhängig überprüfen kann. Halten Sie die Claim-Benutzeroberfläche minimalistisch, auditiert und ratenbegrenzt, um Verkehrsspitzen zu bewältigen, ohne Ihre RPC-Endpunkte zu überlasten.
5. Kommunizieren Sie den Freigabeplan: Seien Sie transparent über das gesamte Token-Angebot, die Zuteilungen für verschiedene Empfängergruppen (Community, Team, Investoren) und zukünftige Freigabeereignisse. Öffentliche Dashboards schaffen Vertrauen und unterstützen gesündere Marktdynamiken.
6. Berücksichtigen Sie Governance, Rechtliches und Steuern: Stimmen Sie die On-Chain-Fähigkeiten des Tokens (Abstimmung, Gebührenteilung, Staking) mit Ihrer langfristigen Roadmap ab. Holen Sie rechtlichen Rat bezüglich gerichtlicher Beschränkungen und notwendiger Offenlegungen ein. Wie die Richtlinien von IRS und HMRC zeigen, sind Details wichtig.

Kurzes Glossar​

• Snapshot: Ein spezifischer Block oder Zeitpunkt, der als Stichtag verwendet wird, um zu bestimmen, wer für einen Airdrop berechtigt ist.
• Claim (Merkle): Eine gas-effiziente, beweisbasierte Methode, die es berechtigten Nutzern ermöglicht, ihre Token-Zuteilung von einem Smart Contract abzurufen.
• Sybil: Ein Szenario, in dem ein Akteur viele Wallets verwendet, um eine Verteilung zu manipulieren. Teams verwenden Filtertechniken, um sie zu erkennen und zu entfernen.
• Punkte: Off-Chain- oder On-Chain-Zählungen, die die Nutzerbindung verfolgen. Sie werden oft später in Token umgewandelt, aber die Kriterien können sich ändern.
• Freigabeplan: Der Zeitplan, der detailliert beschreibt, wie und wann nicht zirkulierende Token (z. B. Team- oder Investorenzuteilungen) auf den Markt gelangen.

Builder’s Corner: Wie BlockEden helfen kann​

Die Einführung eines Airdrops ist ein gewaltiges Unterfangen. BlockEden bietet die Infrastruktur, um sicherzustellen, dass Sie ihn verantwortungsvoll und effektiv umsetzen.

• Zuverlässige Snapshots: Nutzen Sie unsere Hochdurchsatz-RPC- und Indexierungsdienste, um die Berechtigung über Millionen von Adressen und komplexe Kriterien auf jeder Chain zu berechnen.
• Claim-Infrastruktur: Erhalten Sie fachkundige Beratung bei der Gestaltung und Implementierung von Merkle-Claim-Flows und gas-effizienten Verteilungsverträgen.
• Sybil-Operationen: Nutzen Sie unsere Datenpipelines, um Heuristiken auszuführen, Cluster-Analysen durchzuführen und Ihre Ausschlussliste zu iterieren, bevor Sie Ihre Verteilung finalisieren.
• Launch-Support: Unsere Infrastruktur ist für Skalierbarkeit ausgelegt. Mit integrierten Ratenbegrenzungen, automatischen Wiederholungsversuchen und Echtzeitüberwachung können Sie sicherstellen, dass der Claim-Tag Ihre Endpunkte nicht überlastet.

Häufig gestellte Fragen (Kurzantworten)​

Ist ein Airdrop „kostenloses Geld“? Nein. Es ist eine Verteilung, die an spezifische Verhaltensweisen, Marktrisiken, potenzielle Steuerschulden und Sicherheitsaspekte gebunden ist. Es ist ein Anreiz, kein Geschenk.

Warum habe ich keinen bekommen? Höchstwahrscheinlich haben Sie entweder das Snapshot-Datum verpasst, die Mindestaktivitätsschwellen nicht erreicht oder wurden von den Sybil-Erkennungsregeln des Projekts herausgefiltert. Legitime Projekte veröffentlichen in der Regel ihre Kriterien; lesen Sie diese genau.

Sollten Teams Claims für immer offen lassen? Das variiert. Uniswaps Claim-Vertrag bleibt Jahre später offen, aber viele moderne Projekte setzen eine Frist (z. B. 3–6 Monate), um die Buchhaltung zu vereinfachen, nicht beanspruchte Token für die Schatzkammer zurückzugewinnen und den langfristigen Sicherheitswartungsaufwand zu reduzieren. Wählen Sie eine Richtlinie und dokumentieren Sie diese klar.

Weiterführende Lektüre (Primärquellen)​

• Coinbase Learn: Definition & Punkteprogramme
• Uniswap: UNI-Launch-Beitrag & MerkleDistributor-Repo
• Arbitrum: Offizielle Airdrop-Berechtigung & Snapshot
• Starknet: Ankündigung des Provisions Program
• ZKsync: Details zum ZK-Token-Airdrop
• LayerZero: Anti-Sybil-Selbstmelde-Programm
• Token-Freigabekalender: TokenUnlocks
• Steuern: IRS (US) & HMRC (UK)

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

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

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

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

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

• Ökonomische Anreizstruktur: Flashbots v2 richtet die Anreize zwischen Validatoren, Buildern und Searchern über die PBS-Auktion aus. Validatoren profitieren von der Auslagerung der Blockproduktion – sie akzeptieren einfach das höchste Gebot und erhalten den Gebotsbetrag (zusätzlich zu den Konsens-Belohnungen), was den Anteil des MEV, der an die Validatoren geht, im Vergleich zur Ära, in der Miner keine solchen Auktionen hatten, drastisch erhöht hat. Builder sind motiviert, einander zu übertreffen, indem sie die profitabelste Transaktionsreihenfolge finden (oft unter Einbeziehung von Searcher-Strategien), und sie behalten jeglichen MEV-Gewinn, der nach Zahlung des Validator-Gebots übrig bleibt. In der Praxis zwingt der Wettbewerb die Builder dazu, den Großteil des MEV an die Validatoren zu zahlen (oft > 90 % des Gewinns), sodass ihnen nur eine geringe Marge verbleibt. Searcher (die nun über Bundles oder direkte Transaktionen mit Buildern interagieren) verdienen weiterhin durch das Entdecken von MEV-Möglichkeiten (Arbitrage, Liquidation etc.), müssen aber den Großteil ihres Gewinns bieten, um aufgenommen zu werden – effektiv werden Searcher-Gewinne über Builder-Gebote an Validatoren transferiert. Dieses Wettbewerbsgleichgewicht maximiert den Gesamtumsatz des Netzwerks (wovon Validatoren / Staker profitieren), drückt jedoch die Margen der einzelnen Searcher. Flashbots v2 entmutigt somit exklusive Deals: Jeder Searcher oder Builder mit einer privaten MEV-Strategie hat einen Anreiz, diese über das offene Relay anzubieten, um nicht unterboten zu werden, was zu einem offeneren Markt führt. Die Einführung von BuilderNet fügt einen Anreiz für Orderflow-Urheber (wie DEXs oder Wallets) hinzu – indem ihnen Rückerstattungen für das durch ihre Transaktionen erzeugte MEV gewährt werden, werden Nutzer und Apps ermutigt, den Orderflow an das BuilderNet-Ökosystem zu senden. Dieser Mechanismus bringt die Nutzer mit dem System in Einklang: Anstatt gegeneinander zu arbeiten (Nutzer gegen MEV-Extraktoren), partizipieren die Nutzer am MEV, weshalb sie eher bereit sind, fair an der Auktion teilzunehmen. Insgesamt begünstigt die Ökonomik von Flashbots v2 die Zusammenarbeit gegenüber dem Wettbewerb beim Blockaufbau: Validatoren erhalten maximale Einnahmen ohne Risiko, Builder konkurrieren über die Ausführungsqualität, Searcher innovieren, um MEV zu finden, geben aber die meisten Gewinne ab, um Gebote zu gewinnen, während Nutzer Schutz und möglicherweise Rabatte erhalten.

• Compliance und Zensurresistenz: Regulatorische Compliance wurde für Flashbots nach dem Ethereum-Merge zu einem umstrittenen Thema. Das Standard-Relay von Flashbots implementierte anfänglich die Einhaltung von OFAC-Sanktionen (Zensur bestimmter Transaktionen wie Tornado Cash) – was dazu führte, dass Ende 2022 ca. 80 % der Ethereum-Blöcke „OFAC-konform“ waren, was Bedenken hinsichtlich Zentralisierung und Zensur in der Community auslöste. Flashbots v2 begegnete dem durch die Förderung eines Ökosystems mit mehreren Relays, in dem Validatoren nicht-zensierende Relays (z. B. UltraSound, Agnostic) wählen oder sogar eigene betreiben können. Flashbots stellte seinen Relay-Code Mitte 2022 als Open Source zur Verfügung, um den globalen Wettbewerb und die Transparenz unter den Relays zu fördern. Zusätzlich führte MEV-Boost v1.4 Funktionen wie eine Mindestgebots-Einstellung (Min-Bid) ein, damit Proposer niedrige Gebote von zensierenden Buildern ablehnen und auf lokale Blöcke zurückgreifen konnten, wobei sie etwas Gewinn für die Aufnahme aller Transaktionen opferten. Diese Funktion gab Validatoren explizit eine Möglichkeit, die Zensurresistenz von Ethereum zu geringen Kosten zu verbessern. Bis Ende 2024 ging Flashbots einen weiteren Schritt und stellte seinen eigenen zentralisierten Builder zugunsten von BuilderNet ein – einem kollaborativen Netzwerk, das darauf abzielt, „unzensierbar und neutral“ zu sein. BuilderNet verwendet TEEs (Intel SGX), um den Transaktions-Orderflow verschlüsselt zu halten und verpflichtet sich verifizierbar zu einer Ordnungsregel, was verhindern kann, dass einzelne Builder spezifische Transaktionen zensieren. Wenn mehrere Teilnehmer gemeinsam Blöcke innerhalb sicherer Enklaven bauen, kann keine einzelne Partei eine Transaktion ohne Entdeckung ausschließen. Kurz gesagt: Flashbots v2 hat sich von einem einzelnen (und anfangs zensierenden) Relay zu einer dezentraleren Infrastruktur mit offener Teilnahme und expliziten Neutralitätszielen entwickelt. Compliance wird den Richtlinien einzelner Relays / Builder überlassen (und Validatoren können wählen), anstatt vom Protokoll erzwungen zu werden. Die Entwicklung geht in Richtung glaubwürdiger Neutralität: Eliminierung aller von Flashbots kontrollierten Engpässe, die von Regulierungsbehörden unter Druck gesetzt werden könnten. Flashbots hat sich öffentlich dazu verpflichtet, sich als zentraler Betreiber zurückzuziehen und alle Aspekte der MEV-Lieferkette langfristig zu dezentralisieren.

• Technische Architektur & Kryptographie: Flashbots v2 operiert als Hybrid aus Off-Chain und protokollinternen Elementen. Die Kernauktion (MEV-Boost) findet Off-Chain über das Builder- und Relay-Netzwerk statt, ist aber direkt in den Konsens von Ethereum eingebunden: Validatoren führen einen Sidecar-Client (mev-boost) aus, der über die standardisierte Builder-API mit Relays kommuniziert. Konsensseitig nutzt Ethereum weiterhin Standard-PoS (Casper / Hotstuff) – MEV-Boost ändert die L1-Konsensregeln nicht; es ändert nur, wer den Block zusammenstellt. Anfangs erforderte die Flashbots-Auktion Vertrauen in das Relay und den Builder, Transaktionen nicht zu stehlen oder zu zensieren – es gab keine kryptographischen Garantien (das System verließ sich auf den ökonomischen Anreiz, dass Builder eine gültige Payload liefern müssen, die ihrem Gebot entspricht, sonst verlieren sie den Slot). Im Laufe der Zeit hat Flashbots v2 mehr Sicherheitstechnologie integriert. Die Einführung von Trusted Execution Environments (TEE) über BuilderNet ist ein bemerkenswerter architektonischer Wandel: Builder laufen innerhalb von SGX-Enklaven, sodass selbst der Builder-Betreiber den rohen Transaktions-Orderflow nicht sehen kann (was ihn daran hindert, Informationen preiszugeben oder Frontrunning zu betreiben). Diese Enklaven folgen gemeinsam einem Protokoll zur Blockproduktion, was eine verifizierbare Fairness ermöglichen kann (z. B. der Beweis, dass Transaktionen nach einer festgelegten Regel geordnet wurden oder dass keine unbefugte Entität sie vor der Aufnahme gesehen hat). Während SGX verwendet wird (ein hardwarebasierter Ansatz), erforscht die Flashbots-Forschung auch rein kryptographische Primitive – z. B. Threshold Encryption für Mempool-Privatsphäre und Secure Multi-Party Computation –, um TEEs eventuell zu ersetzen oder zu ergänzen und das Vertrauen weiter zu reduzieren. Der Software-Stack von Flashbots v2 umfasst angepasste Clients wie MEV-geth (jetzt veraltet) und Rust-basierte Builder (z. B. rbuilder) und hält sich an die Ethereum-Builder-Spezifikationen für Interoperabilität. Zusammenfassend ist die Architektur modular: Ein Netzwerk aus Relays, Buildern und nun Enklaven, das zwischen Nutzern und Ethereum-Proposern angesiedelt ist. Sie priorisiert Performance (schnelles Bieten, Blockbereitstellung) und fügt schrittweise kryptographische Zusicherungen für Privatsphäre und faire Ordnung hinzu. Es wird kein neuer Konsensalgorithmus eingeführt; stattdessen arbeitet Flashbots v2 neben dem Konsens von Ethereum und entwickelt die Blockproduktions-Pipeline weiter, anstatt die Konsensregeln selbst zu verändern.

• Entwicklungs-Roadmap & Meilensteine: Flashbots hat sich durch iterative Phasen entwickelt. Flashbots v1 (2020–2021) beinhaltete den Start von MEV-geth und die ersten Off-Chain-Bundle-Auktionen mit Minern. Bis Mitte 2021 nutzten über 80 % der Hashrate von Ethereum MEV-geth von Flashbots, was die Akzeptanz des Ansatzes bestätigte. Flashbots v2 (2022) wurde im Vorfeld von „The Merge“ konzipiert: Im November 2021 veröffentlichte Flashbots die MEV-Boost-Architektur für PoS-Ethereum. Nachdem Ethereum auf PoS umgestellt hatte (15. Sept. 2022), wurde MEV-Boost innerhalb weniger Tage aktiviert und erreichte schnell eine Mehrheitsbeteiligung durch die Validatoren. Weitere Meilensteine waren die Offenlegung des Relay-Codes (Aug. 2022) und des internen Block-Builders von Flashbots (Nov. 2022), um den Wettbewerb anzukurbeln. Ende 2022 fügte Flashbots zudem Funktionen mit Fokus auf Zensurresistenz und Resilienz hinzu (z. B. Min-Bid für Proposer) und thematisierte die „Kosten der Resilienz“, um Validatoren zu ermutigen, gelegentlich die Inklusion dem Gewinn vorzuziehen. Im Laufe des Jahres 2023 wurde die Verbesserung der Builder-Dezentralisierung zu einem Schwerpunkt: Flashbots veröffentlichte „rbuilder“ (einen Hochleistungs-Rust-Builder) im Juli 2024 als Referenzimplementierung, um die Hürde für neue Builder zu senken. Schließlich startete Flashbots Ende 2024 BuilderNet (Alpha) in Zusammenarbeit mit Partnern (Beaverbuild, Nethermind). Bis Dezember 2024 stellte Flashbots seinen zentralisierten Builder ein und migrierte den gesamten Orderflow zu BuilderNet – ein bedeutender Schritt in Richtung Dezentralisierung. Anfang 2025 wurde BuilderNet v1.2 mit Verbesserungen bei Sicherheit und Onboarding (einschließlich reproduzierbarer Enklaven-Builds) veröffentlicht. Diese Meilensteine markieren den Übergang von Flashbots von einer zweckmäßigen zentralisierten Lösung zu einem offeneren, von der Community betriebenen Protokoll. Mit Blick in die Zukunft verschmilzt Flashbots mit seiner Vision der nächsten Generation (SUAVE), um die Blockaufbauschicht vollständig zu dezentralisieren und fortschrittliche Privatsphäre-Technologien zu integrieren. Viele Lehren aus Flashbots v2 (z. B. die Notwendigkeit von Neutralität, Multi-Chain-Scope und die Einbeziehung der Nutzer in MEV-Belohnungen) fließen direkt in die SUAVE-Roadmap ein.

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

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

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

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

• Ökonomische Anreizstruktur: SUAVE führt neue Rollen und Anreizflüsse in die MEV-Lieferkette ein. Die Hauptteilnehmer sind Benutzer, Executoren, Block-Builder/Validatoren und die SUAVE-Netzwerkbetreiber (Validatoren der SUAVE-Kette). Benutzer legen in ihrer Präferenz ein Gebot (Zahlung) fest, das ausgezahlt wird, wenn ihre Bedingungen erfüllt sind. Dieses Gebot ist der Anreiz für Executoren: Ein Executor, der die Absicht des Benutzers erfüllt (z. B. seinen Handel backrunned, um ihm einen besseren Preis zu verschaffen), kann das Gebot als Belohnung beanspruchen. Benutzer zahlen daher direkt für die Qualität der Ausführung, ähnlich wie beim Aussetzen eines Kopfgeldes. Executoren (Searcher) sind motiviert, Benutzerpräferenzen aus dem SUAVE-Mempool aufzugreifen und zu optimieren, da sie das Gebot des Benutzers plus etwaige zusätzliche Arbitrage-Gewinne aus der Transaktion verdienen. Executoren werden konkurrieren, um dem Benutzer das beste Ergebnis zu bieten, da der Benutzer sein Gebot so gestalten kann, dass er nur zahlt, wenn der Executor tatsächlich das gewünschte Ergebnis erzielt (das Gebot kann über Orakel von On-Chain-Ergebnissen abhängig gemacht werden). Beispielsweise könnte ein Benutzer sagen: „Ich zahle 0,5 ETH an denjenigen, der diese Transaktion so ausführt, dass ich mindestens X Output erhalte; wenn nicht, erfolgt keine Zahlung.“ Dies bringt die Anreize der Executoren mit dem Erfolg des Benutzers in Einklang. SUAVE-Validatoren/Builder: Die SUAVE-Kette selbst wird wahrscheinlich ein Proof-of-Stake-Netzwerk sein (Design noch offen), sodass Validatoren (die Blöcke auf SUAVE produzieren) Transaktionsgebühren auf SUAVE verdienen (die von Benutzern stammen, die Gebote abgeben). Da SUAVE eine EVM-kompatible Kette ist, kann es auch ein natives Token- oder Gasgebührensystem für diese Transaktionen geben. Diese Validatoren spielen auch eine Rolle bei der Sequenzierung von Cross-Domain-Blöcken; die endgültige Block-Inklusion auf jedem L1 erfolgt jedoch weiterhin durch den Validator dieses L1. In vielen Fällen wird SUAVE ein teilweises oder vollständiges Block-Template produzieren, das ein Ethereum- oder ein anderer Chain-Proposer übernehmen kann. Dieser Builder könnte SUAVE (oder den SUAVE-Executoren) einen Teil des MEV zahlen. Flashbots hat erwähnt, dass SUAVE-Validatoren durch normale Netzwerkgebühren incentiviert werden, während Executoren durch Gebote (Bids) incentiviert werden. Wertverteilung: Der Ansatz von SUAVE neigt dazu, den Wert an die Ränder zu verlagern: Benutzer erfassen Wert (durch bessere Preise oder direkte Rückerstattungen) und Validatoren erfassen Wert (durch erhöhte Gebühren/Gebote). Wenn SUAVE seine Mission erfüllt, wird theoretisch das meiste MEV entweder an die Benutzer zurückgegeben oder zur Entschädigung der Validatoren für die Sicherung des Netzwerks verwendet, anstatt sich bei Searchern zu konzentrieren. Flashbots selbst hat angedeutet, dass es kein Rent-Seeking bei SUAVE plant und keinen Anteil über das hinaus nehmen wird, was für den Systemstart erforderlich ist – sie wollen den Marktplatz gestalten, nicht monopolisieren. Ein weiterer Anreizfaktor sind Cross-Chain-Builder: SUAVE ermöglicht Block-Buildern den Zugriff auf Cross-Domain MEV, was bedeutet, dass ein Builder auf einer Kette zusätzliche Gebühren verdienen kann, indem er Transaktionen einschließt, die eine Arbitrage mit einer anderen Kette vervollständigen. Dies ermutigt Builder/Validatoren verschiedener Ketten, an SUAVE teilzunehmen, da ein Opt-out den Verzicht auf Einnahmen bedeutet. Im Wesentlichen versucht das ökonomische Design von SUAVE, alle Teilnehmer zur Teilnahme an der gemeinsamen Auktion zu bewegen: Benutzer, weil sie eine bessere Ausführung erhalten (und vielleicht MEV-Rabatte), Validatoren, weil sie maximale Einnahmen erzielen, und Searcher, weil dort der Orderflow aggregiert wird. Durch die Konzentration des Orderflows gewinnt SUAVE auch einen Informationsvorteil gegenüber jedem isolierten Akteur (alle Präferenzen an einem Ort), was ökonomischen Druck auf alle ausübt, innerhalb von SUAVE zu kooperieren, anstatt sich abzuspalten. Zusammenfassend fördern die Anreize von SUAVE einen positiven Kreislauf: mehr Orderflow → bessere kombinierte MEV-Möglichkeiten → höhere Gebote für Benutzer/Validatoren → mehr Orderflow. Dies steht im Gegensatz zum Nullsummenspiel und den exklusiven Deals der Vergangenheit und zielt stattdessen auf eine „Koopetition“ (Coopetition) ab, bei der MEV ein gemeinsamer Wert ist, der wachsen und verteilt werden soll.

• Compliance und regulatorische Überlegungen: SUAVE wird mit glaubwürdiger Neutralität und Zensurresistenz als Kernprinzipien entwickelt. Bauartbedingt entfernt SUAVE zentrale Vermittler – es gibt keinen einzelnen Mempool oder Builder, den man angreifen oder regulieren könnte. Transaktionen (Präferenzen) in SUAVE können vollständig verschlüsselt und privat sein, bis sie ausgeführt werden, wobei sichere Enklaven und später kryptografische Techniken zum Einsatz kommen. Dies bedeutet, dass Zensur auf Ebene des Transaktionsinhalts unpraktikabel ist, da Validatoren/Builder die Transaktionsdetails nicht einmal lesen können, bevor die Reihenfolge festgelegt ist. SUAVE erzwingt im Grunde einen „Don’t trust, verify“-Ansatz: Teilnehmer müssen keiner einzelnen Instanz vertrauen, dass sie nicht zensiert, da die Systemarchitektur selbst (dezentrales Netzwerk + Verschlüsselung) sicherstellt, dass die Präferenzen aller fair berücksichtigt werden. Darüber hinaus soll SUAVE ein offenes, erlaubnisloses Netzwerk sein – Flashbots lädt explizit alle Parteien (Benutzer, Searcher, Wallets, andere Blockchains) zur Teilnahme ein. Es gibt kein KYC oder eine Zugangsbeschränkung im Design. Dies könnte Fragen bei Regulierungsbehörden aufwerfen (z. B. könnte das Protokoll die MEV-Extraktion bei sanktionierten Transaktionen erleichtern), aber da SUAVE nur eine dezentrale Plattform ist, wäre eine Durchsetzung schwierig und analog zum Versuch, den Mempool einer Blockchain zu regulieren. Der Fokus von SUAVE auf Privatsphäre (über SGX und später Kryptografie) schützt zudem Benutzerdaten und Orderflow vor unerwünschter Überwachung, was positiv für die Benutzersicherheit ist, aber mit regulatorischen Wünschen nach Transparenz in Konflikt geraten könnte. Andererseits könnte der Ansatz von SUAVE als fairer und konformer mit dem Geist offener Märkte angesehen werden: Durch die Schaffung gleicher Wettbewerbsbedingungen und die Rückgabe von Werten an die Benutzer reduziert es die ausbeuterischen Aspekte von MEV, die regulatorischen Zorn auf sich ziehen könnten (wie das Backrunning von Benutzern ohne deren Zustimmung). SUAVE kann auch dazu beitragen, unregulierte Dark Pools zu eliminieren – ein Grund, warum Regulierungsbehörden über MEV besorgt sein könnten, sind exklusive Orderflow-Verkäufe (die Insiderhandel ähneln). SUAVE ersetzt diese durch eine transparente öffentliche Auktion, was wohl eine konformere Marktstruktur darstellt. In Bezug auf explizite Compliance-Funktionen könnte SUAVE mehrere Sortierrichtlinien zulassen: Beispielsweise könnten Communities oder Gerichtsbarkeiten ihre eigenen Executoren mit bestimmten Filtern oder Präferenzen einsetzen. Die Basislinie ist jedoch, dass SUAVE versuchen wird, maximal neutral zu sein: „alle zentralen Kontrollpunkte, einschließlich Flashbots, zu eliminieren“ und zu vermeiden, Richtlinienentscheidungen auf Protokollebene einzubetten. Flashbots hat betont, dass es den Marktplatz von SUAVE mit zunehmender Reife nicht selbst kontrollieren wird – was bedeutet, dass es keinen zentralen Kill-Switch oder Zensurschalter gibt. Die Governance (sofern vorhanden) von SUAVE ist öffentlich noch nicht definiert, es ist jedoch zu erwarten, dass sie die breitere Community und möglicherweise einen Token einbezieht, anstatt das Machtwort eines Unternehmens. Zusammenfassend ist SUAVE darauf ausgelegt, mit dezentralen Prinzipien in Einklang zu stehen, was von Natur aus bestimmten regulatorischen Kontrollen (Zensur) widersteht, während es potenziell einige regulatorische Bedenken mildert, indem es die MEV-Extraktion gerechter und transparenter macht.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Diese vier Protokolle nähern sich dem MEV- und Fair-Ordering-Problem aus unterschiedlichen Blickwinkeln an, abgestimmt auf ihre jeweiligen Ökosysteme und Designphilosophien. Flashbots v2 ist eine inkrementelle, pragmatische Lösung für die aktuelle Architektur von Ethereum: Es akzeptiert MEV-Auktionen, versucht jedoch, deren Auswirkungen zu demokratisieren und abzumildern (durch Off-Chain-Koordination, SGX-Privatsphäre und Sharing-Mechanismen). SUAVE ist der zukunftsorientierte Plan von Flashbots, eine inter-chain MEV-Plattform zu schaffen, die den Gesamtwert und den Nutzen für die Anwender maximiert – im Wesentlichen wird das Auktionsmodell auf ein dezentrales, die Privatsphäre schützendes globales Netzwerk ausgeweitet. Anoma ist eine grundlegende Neugestaltung der Art und Weise, wie Transaktionen formuliert und ausgeführt werden. Ziel ist es, die Ursachen für unfaire Reihenfolgen durch den Einsatz von Intents (Absichten), Solver-vermitteltem Matching und kryptografischer Fairness im Konsens zu eliminieren. Skip ist ein Ansatz für souveräne Chains, der Fairness und MEV-Erfassung auf Protokollebene pro Chain integriert, insbesondere im Cosmos-Ökosystem, durch konfigurierbare Regeln und Auktionen.

Jedes Modell hat Stärken und Kompromisse:

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

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

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

Fazit und Ausblick​

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

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

In Zusammenfassung lässt sich sagen, dass SUAVE, Anoma, Skip und Flashbots v2 jeweils Puzzleteile zum Fair Ordering und zur MEV-Abmilderung beitragen. Flashbots v2 hat eine Vorlage für MEV-Auktionen geschaffen, die andere nachahmen, Skip hat bewiesen, dass On-Chain-Durchsetzung machbar ist, Anoma hat die Vorstellungskraft dessen erweitert, was möglich ist, indem es das Transaktionsmodell neu aufgebaut hat, und SUAVE versucht, die Gewinne der letzten Jahre zu vereinheitlichen und zu dezentralisieren. Die ultimative Lösung könnte Elemente von allen beinhalten: datenschutzwahrende globale Auktionen, Intent-zentrierte Benutzeroberflächen, Fairness-Regeln auf Chain-Ebene und kollaborative Block-Erstellung. Stand 2025 ist der Kampf gegen MEV-induzierte Ungerechtigkeit in vollem Gange – diese Protokolle verwandeln MEV von einer dunklen Unvermeidlichkeit in einen verwalteten, sogar produktiven Teil der Krypto-Ökonomie, während sie sich dem Ideal der „besten Ausführung für Nutzer mit der dezentralsten Infrastruktur“ annähern.

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.