102 Beiträge getaggt mit „Blockchain“

Überblick​

Aptos und Sui stehen als nächste Generation von Layer-1 Blockchains, beide basierend auf der Move-Sprache, die ursprünglich im Rahmen des Libra/Diem-Projekts von Meta konzipiert wurde. Obwohl sie eine gemeinsame Abstammung teilen, haben sich ihre Teamhintergründe, Kernziele, Ökosystemstrategien und Entwicklungspfade erheblich auseinanderentwickelt.

Aptos legt Wert auf Vielseitigkeit und Performance auf Unternehmensniveau, wobei sowohl DeFi- als auch institutionelle Anwendungsfälle im Fokus stehen. Im Gegensatz dazu konzentriert sich Sui auf die Optimierung seines einzigartigen Objektmodells, um Massenmarkt-Verbraucheranwendungen, insbesondere in den Bereichen Gaming, NFTs und soziale Medien, zu unterstützen. Welche Kette sich letztendlich durchsetzen wird, hängt von ihrer Fähigkeit ab, ihre Technologie weiterzuentwickeln, um den Anforderungen ihrer gewählten Marktnische gerecht zu werden, und gleichzeitig einen klaren Vorteil in Bezug auf Benutzererfahrung und Entwicklerfreundlichkeit zu etablieren.

1. Entwicklungsreise​

Aptos​

Aptos, entstanden aus Aptos Labs – einem Team ehemaliger Meta Libra/Diem-Mitarbeiter – begann Ende 2021 mit geschlossenen Tests und startete sein Mainnet am 19. Oktober 2022. Die anfängliche Mainnet-Performance stieß mit unter 20 TPS auf Skepsis in der Community, wie von WIRED angemerkt, aber nachfolgende Iterationen an den Konsens- und Ausführungsschichten haben den Durchsatz stetig auf Zehntausende von TPS erhöht.

Bis zum 2. Quartal 2025 erreichte Aptos einen Höchststand von 44,7 Millionen Transaktionen in einer einzigen Woche, wobei die wöchentlich aktiven Adressen 4 Millionen überschritten. Das Netzwerk ist auf über 83 Millionen kumulierte Konten angewachsen, mit einem täglichen DeFi-Handelsvolumen, das konstant über 200 Millionen US-Dollar liegt (Quelle: Aptos Forum).

Sui​

Sui, initiiert von Mysten Labs, dessen Gründer Kernmitglieder des Novi Wallet-Teams von Meta waren, startete sein incentiviertes Testnet im August 2022 und ging am 3. Mai 2023 mit seinem Mainnet live. Von den frühesten Testnets an priorisierte das Team die Verfeinerung seines „Objektmodells“, das Assets als Objekte mit spezifischen Eigentums- und Zugriffskontrollen behandelt, um die parallele Transaktionsverarbeitung zu verbessern (Quelle: Ledger).

Mitte Juli 2025 erreichte der Total Value Locked (TVL) des Sui-Ökosystems 2,326 Milliarden US-Dollar. Die Plattform verzeichnete ein schnelles Wachstum des monatlichen Transaktionsvolumens und der Anzahl aktiver Ingenieure, was sich besonders im Gaming- und NFT-Sektor als beliebt erwies (Quelle: AInvest, Tangem).

2. Technischer Architekturvergleich​

3. On-Chain Ökosystem und Anwendungsfälle​

3.1 Ökosystem-Größe und Wachstum​

Aptos Im 1. Quartal 2025 verzeichnete Aptos fast 15 Millionen monatlich aktive Nutzer und näherte sich 1 Million täglich aktiver Wallets. Das DeFi-Handelsvolumen stieg im Jahresvergleich um 1000 %, wobei sich die Plattform als Drehscheibe für Stablecoins und Derivate auf Finanzniveau etablierte (Quelle: Coinspeaker). Zu den wichtigsten strategischen Schritten gehören die Integration von USDT über Upbit, um die Penetration in asiatischen Märkten voranzutreiben, und die Anziehung zahlreicher führender DEXs, Lending-Protokolle und Derivateplattformen (Quelle: Aptos Forum).

Sui Im Juni 2025 erreichte der TVL des Sui-Ökosystems einen neuen Höchststand von 2,326 Milliarden US-Dollar, hauptsächlich angetrieben durch interaktionsreiche soziale, Gaming- und NFT-Projekte (Quelle: AInvest). Das Ökosystem ist durch Kernprojekte wie Objekt-Marktplätze, Layer-2-Brücken, soziale Wallets und Game-Engine-SDKs definiert, die eine große Anzahl von Web3-Spieleentwicklern und IP-Inhabern angezogen haben.

3.2 Dominante Anwendungsfälle​

• DeFi & Unternehmensintegration (Aptos): Mit seiner ausgereiften BFT-Finalität und einer Vielzahl von Finanztools ist Aptos besser für Stablecoins, Lending und Derivate geeignet – Szenarien, die ein hohes Maß an Konsistenz und Sicherheit erfordern.
• Gaming & NFTs (Sui): Suis Vorteil bei der parallelen Ausführung ist hier offensichtlich. Seine geringe Transaktionslatenz und nahezu null Gebühren sind ideal für hochfrequente, geringwertige Interaktionen, die im Gaming üblich sind, wie das Öffnen von Lootboxen oder das Übertragen von In-Game-Gegenständen.

4. Entwicklung & Strategie​

Aptos

• Performance-Optimierung: Fortsetzung der Sharding-Forschung, Planung von Multi-Region-Cross-Chain-Liquidität und Upgrade der AptosVM zur Verbesserung der Effizienz des Zustandszugriffs.
• Ökosystem-Anreize: Ein Ökosystemfonds in Höhe von mehreren Hundert Millionen US-Dollar wurde eingerichtet, um DeFi-Infrastruktur, Cross-Chain-Brücken und konforme Unternehmensanwendungen zu unterstützen.
• Cross-Chain Interoperabilität: Stärkung der Integrationen mit Brücken wie Wormhole und Aufbau von Verbindungen zu Cosmos (über IBC) und Ethereum.

Sui

• Objektmodell-Iteration: Erweiterung der Move-Syntax zur Unterstützung benutzerdefinierter Objekttypen und komplexer Berechtigungsverwaltung bei gleichzeitiger Optimierung des parallelen Scheduling-Algorithmus.
• Förderung der Verbraucherakzeptanz: Vertiefung der Integrationen mit großen Game-Engines wie Unreal und Unity, um die Hürde für die Web3-Spieleentwicklung zu senken, und Einführung von Social Plugins und SDKs.
• Community-Governance: Förderung der SuiDAO, um Kernprojekt-Communities mit Governance-Fähigkeiten auszustatten und eine schnelle Iteration von Funktionen und Gebührenmodellen zu ermöglichen.

5. Kernunterschiede & Herausforderungen​

• Sicherheit vs. Parallelität: Aptos' strenge Ressourcensemantik und konsistenter Konsens bieten DeFi-taugliche Sicherheit, können aber die Parallelität einschränken. Suis hochparalleles Transaktionsmodell muss seine Widerstandsfähigkeit gegenüber groß angelegten Sicherheitsbedrohungen kontinuierlich unter Beweis stellen.
• Ökosystemtiefe vs. -breite: Aptos hat tiefe Wurzeln im Finanzsektor mit starken institutionellen Bindungen kultiviert. Sui hat schnell eine breite Palette von verbraucherorientierten Projekten akkumuliert, muss aber noch einen entscheidenden Durchbruch im groß angelegten DeFi erzielen.
• Theoretische Performance vs. realer Durchsatz: Während Sui einen höheren theoretischen TPS aufweist, ist sein tatsächlicher Durchsatz immer noch durch die Ökosystemaktivität begrenzt. Aptos hat auch während Spitzenzeiten Überlastungen erlebt, was auf die Notwendigkeit effektiverer Sharding- oder Layer-2-Lösungen hindeutet.
• Marktnarrativ & Positionierung: Aptos vermarktet sich mit Sicherheit und Stabilität auf Unternehmensniveau und zielt auf traditionelle Finanzen und regulierte Industrien ab. Sui nutzt den Reiz einer „Web2-ähnlichen Erfahrung“ und eines „reibungslosen Onboardings“, um ein breiteres Verbraucherpublikum anzuziehen.

6. Der Weg zur Massenadoption​

Letztendlich ist dies kein Nullsummenspiel.

Mittel- bis langfristig könnte Suis parallele Ausführung und die niedrige Einstiegshürde bei anhaltendem explosivem Wachstum des Verbrauchermarktes (Gaming, Social, NFTs) eine schnelle Adoption bei zig Millionen Mainstream-Nutzern ermöglichen.

Kurz- bis mittelfristig bieten Aptos' ausgereifte BFT-Finalität, niedrige Gebühren und strategische Partnerschaften ein überzeugenderes Angebot für institutionelle Finanzen, compliance-orientiertes DeFi und grenzüberschreitende Zahlungen.

Die Zukunft ist wahrscheinlich eine symbiotische, in der die beiden Ketten koexistieren und einen geschichteten Markt schaffen: Aptos treibt die Finanz- und Unternehmensinfrastruktur an, während Sui hochfrequente Verbraucherinteraktionen dominiert. Die Kette, die letztendlich die Massenadoption erreicht, wird diejenige sein, die Leistung und Benutzererfahrung in ihrem gewählten Bereich unermüdlich optimiert.

Einführung​

Rollups-as-a-Service (RaaS) und modulare Blockchain-Frameworks sind im Jahr 2025 entscheidend für die Skalierung von Ethereum und den Aufbau benutzerdefinierter Blockchains geworden. Führende Frameworks – Optimism’s OP Stack, zkSync’s ZK Stack (Hyperchains), Arbitrum Orbit, Polygon’s Chain Development Kit (CDK) und verwandte Lösungen – ermöglichen es Entwicklern, ihre eigenen Layer-2- (L2) oder Layer-3- (L3) Chains mit unterschiedlichen Ansätzen (optimistisch vs. Zero-Knowledge) zu starten. Diese Frameworks teilen eine Philosophie der Modularität: Sie trennen Belange wie Ausführung, Abwicklung, Datenverfügbarkeit und Konsens, was die Anpassung jeder Komponente ermöglicht. Dieser Bericht vergleicht die Frameworks anhand wichtiger Dimensionen – Datenverfügbarkeitsoptionen, Sequenzer-Design, Gebührenmodelle, Ökosystem-Unterstützung – und untersucht ihre Architektur, Tools, Entwicklererfahrung und aktuelle Akzeptanz sowohl im öffentlichen als auch im Unternehmenskontext.

Vergleichsübersicht​

Die folgende Tabelle fasst mehrere Kernfunktionen jedes Frameworks zusammen:

Tabelle: High-Level-Vergleich der wichtigsten technischen Merkmale von OP Stack, zkSync’s ZK Stack, Arbitrum Orbit und Polygon CDK.

Datenverfügbarkeitsschichten​

Die Datenverfügbarkeit (DA) ist der Ort, an dem Rollups ihre Transaktionsdaten speichern, damit jeder den Zustand der Chain rekonstruieren kann. Alle diese Frameworks unterstützen die Verwendung von Ethereum L1 als DA (Bereitstellung von Calldata oder Blob-Daten auf Ethereum für maximale Sicherheit). Um jedoch Kosten zu senken, ermöglichen sie auch alternative DA-Lösungen:

• OP Stack: Standardmäßig veröffentlichen OP-Chains Daten auf Ethereum (als Calldata oder Blobs). Dank einer modularen „Alt-DA“-Schnittstelle können OP Stack Chains problemlos an andere DA-Schichten angeschlossen werden. Zum Beispiel könnte eine OP-Chain Celestia (eine dedizierte DA-Blockchain) anstelle von Ethereum verwenden. Im Jahr 2023 veröffentlichten OP Labs und Celestia eine Beta, bei der ein OP Stack Rollup auf Ethereum abgewickelt wird, aber Bulk-Daten auf Celestia speichert. Dies reduziert die Gebühren, während die Datenverfügbarkeitsgarantien von Celestia geerbt werden. Im Allgemeinen kann jede EVM- oder Nicht-EVM-Chain – sogar Bitcoin oder ein zentralisierter Speicher – als DA-Schicht im OP Stack konfiguriert werden. (Natürlich tauscht die Verwendung einer weniger sicheren DA einen Teil der Sicherheit gegen Kosten ein.) Ethereum bleibt die vorherrschende Wahl für Produktions-OP-Chains, aber Projekte wie Caldera’s Taro Testnet haben OP Stack mit Celestia DA demonstriert.

• ZK Stack (zkSync Hyperchains): Der ZK Stack bietet sowohl Rollup- als auch Validium-Modi. Im Rollup-Modus sind alle Daten On-Chain (Ethereum). Im Validium-Modus werden Daten Off-Chain gehalten (wobei nur Gültigkeitsnachweise On-Chain sind). Matter Labs integriert Avail, Celestia und EigenDA als erstklassige DA-Optionen für ZK Stack Chains. Dies bedeutet, dass eine zkSync Hyperchain Transaktionsdaten an Celestia oder ein EigenLayer-gestütztes Netzwerk anstelle von L1 senden könnte, was den Durchsatz massiv erhöht. Sie skizzieren sogar Volition, bei der eine Chain pro Transaktion entscheiden kann, ob sie diese als Rollup (On-Chain-Daten) oder Validium (Off-Chain-Daten) behandeln möchte. Diese Flexibilität ermöglicht es Entwicklern, Sicherheit und Kosten abzuwägen. Zum Beispiel könnte eine Gaming-Hyperchain Celestia verwenden, um Daten kostengünstig zu speichern, während sie sich für periodische Beweise auf Ethereum verlässt. Das Design des ZK Stacks macht DA über eine DA-Client/Dispatcher-Komponente in der Node-Software steckbar. Insgesamt bleibt Ethereum Standard, aber das zkSync-Ökosystem betont stark die modulare DA, um einen „Hyperscale“-Durchsatz zu erreichen.

• Arbitrum Orbit: Orbit Chains können zwischen Arbitrums zwei Datenmodi wählen: Rollup (Daten auf Ethereum veröffentlicht) oder AnyTrust (Datenverfügbarkeitskomitee). In der Rollup-Konfiguration wird ein Orbit L3 seine Calldata an den L2 (Arbitrum One oder Nova) oder L1 senden, wodurch die volle Sicherheit zu höheren Kosten geerbt wird. Im AnyTrust-Modus werden Daten von einem Komitee Off-Chain gehalten (wie in Arbitrum Nova verwendet, das ein Datenverfügbarkeitskomitee nutzt). Dies senkt die Gebühren für Apps mit hohem Volumen (Gaming, Social) erheblich, auf Kosten des Vertrauens in ein Komitee (wenn alle Komiteemitglieder kolludieren, um Daten zurückzuhalten, könnte die Chain zum Stillstand kommen). Darüber hinaus integriert Arbitrum auch neue modulare DA-Netzwerke. Insbesondere werden Celestia und Polygon Avail für Orbit Chains als alternative DA-Schichten unterstützt. Projekte wie AltLayer haben an Orbit Rollups gearbeitet, die auch EigenDA (EigenLayer’s DA-Dienst) verwenden. Zusammenfassend bietet Arbitrum Orbit flexible Datenverfügbarkeit: On-Chain über Ethereum, Off-Chain über DACs oder spezialisierte DA-Chains oder Hybride. Viele Orbit-Nutzer wählen AnyTrust aus Kostengründen, insbesondere wenn sie einen bekannten Satz von Validatoren oder Partnern haben, die die Datenverfügbarkeit sicherstellen.

• Polygon CDK: Polygon’s CDK ist von Natur aus modular in Bezug auf DA. Eine Polygon CDK Chain kann als Rollup (alle Daten auf Ethereum) oder als Validium (Daten auf einem separaten Netzwerk) betrieben werden. Polygon hat seine eigene DA-Lösung namens Avail (eine Blockchain für Datenverfügbarkeit), und CDK Chains können Avail oder jeden ähnlichen Dienst nutzen. Ende 2024 kündigte Polygon die direkte Integration von Celestia in CDK an – was Celestia zu einer „leicht steckbaren“ DA-Option im Toolkit macht. Diese Integration wird für Anfang 2024 erwartet und ermöglicht es CDK Chains, komprimierte Daten nahtlos auf Celestia zu speichern. Polygon zitiert, dass die Verwendung von Celestia die Transaktionsgebühren um >100x im Vergleich zur Veröffentlichung aller Daten auf Ethereum reduzieren könnte. Somit kann ein CDK-Chain-Ersteller das DA-Modul einfach auf Celestia (oder Avail) anstatt auf Ethereum umschalten. Einige Polygon Chains (z. B. Polygon zkEVM) veröffentlichen derzeit alle Daten auf Ethereum (für maximale Sicherheit), während andere (vielleicht bestimmte Unternehmens-Chains) als Validiums mit externer DA laufen. Das CDK unterstützt auch „Hybrid“-Modi – zum Beispiel könnten kritische Transaktionen auf Ethereum gehen, während andere zu Avail gehen. Dieser modulare DA-Ansatz stimmt mit Polygons breiterer Polygon 2.0-Vision von mehreren ZK-gestützten Chains mit vereinheitlichter Liquidität, aber unterschiedlichen Daten-Backends überein.

Zusammenfassend lässt sich sagen, dass alle Frameworks mehrere DA-Schichten in unterschiedlichem Maße unterstützen. Ethereum bleibt der Goldstandard für DA (insbesondere mit Blob-Space von EIP-4844, der On-Chain-Daten billiger macht), aber neue spezialisierte DA-Netzwerke (Celestia, Avail) und Schemata (EigenLayer’s EigenDA, Datenkomitees) werden durchweg angenommen. Diese Modularität ermöglicht es Rollup-Erstellern im Jahr 2025, Kompromisse zwischen Kosten und Sicherheit einzugehen, indem sie einfach ein anderes DA-Modul konfigurieren, anstatt eine neue Chain von Grund auf neu zu bauen.

Sequenzer-Design und Dezentralisierung​

Der Sequenzer ist der Node (oder Satz von Nodes), der Transaktionen ordnet und Blöcke für einen Rollup produziert. Wie der Sequenzer entworfen ist – zentralisiert vs. dezentralisiert, permissionless vs. permissioned – beeinflusst den Durchsatz der Chain und die Vertrauensannahmen:

• OP Stack (Optimism): Heute betreiben die meisten OP Stack Chains einen einzelnen Sequenzer, der vom Kernteam oder Sponsor der Chain betrieben wird. Zum Beispiel wird der Sequenzer des Optimism Mainnets von OP Labs betrieben, und der Sequenzer von Base wird von Coinbase betrieben. Dies führt zu geringer Latenz und Einfachheit auf Kosten der Zentralisierung (Benutzer müssen dem Sequenzer vertrauen, ihre Transaktionen fair einzuschließen). Optimism hat jedoch Mechanismen zur Vertrauensminimierung eingebaut: Es gibt einen L1-Transaktionswarteschlangenvertrag, in dem Benutzer Transaktionen auf Ethereum einreichen können, die der Sequenzer in die L2-Chain aufnehmen muss. Wenn der Sequenzer ausfällt oder Transaktionen zensiert, können sich Benutzer auf L1 verlassen, um schließlich aufgenommen zu werden (wenn auch mit einiger Verzögerung). Dies bietet ein Sicherheitsventil gegen einen bösartigen oder ausgefallenen Sequenzer. In Bezug auf die Dezentralisierung ist OP Stack modular und ermöglicht theoretisch mehrere Sequenzer – z. B. könnte man ein Round-Robin- oder Proof-of-Stake-basiertes Block-Proposer-Set unter Verwendung des OP Stack-Codes implementieren. In der Praxis erfordert dies eine Anpassung und ist nicht die Out-of-the-Box-Konfiguration. Die langfristige Superchain-Roadmap sieht einen Shared Sequencer für alle OP Chains vor, der ein Satz von Validatoren wäre, die Transaktionen für viele Chains gleichzeitig sequenzieren. Ein Shared Sequencer könnte Cross-Chain-Atomarität ermöglichen und MEV über die Superchain hinweg reduzieren. Er befindet sich im Jahr 2025 noch in der Entwicklung, aber das Design des OP Stacks schließt das Anschließen eines solchen Konsenses nicht aus. Vorerst bleiben die Sequenzer-Operationen permissioned (von Whitelist-Entitäten betrieben), aber die Optimism-Governance plant, dies zu dezentralisieren (möglicherweise über Staking oder Komitee-Rotation), sobald die Technologie und die Wirtschaftlichkeit bereit sind. Kurz gesagt: OP Stack Chains beginnen mit zentralisierter Sequenzierung (mit L1 als Fallback), und ein Weg zur graduellen Dezentralisierung ist vorgezeichnet (Übergang von „Stage 0“ zu „Stage 2“ Reife ohne Stützräder).

• ZK Stack (zkSync Hyperchains): zkSync Era (der L2) verwendet derzeit einen zentralisierten Sequenzer, der von Matter Labs betrieben wird. Der ZK Stack ist jedoch so konzipiert, dass er verschiedene Sequenzierungsmodi für neue Chains ermöglicht. Optionen umfassen einen zentralisierten Sequenzer (einfacher Start), ein dezentralisiertes Sequenzer-Set (z. B. mehrere Nodes, die einen Konsens über die Reihenfolge erzielen), eine priorisierte Transaktionswarteschlange von L1 oder sogar einen externen Sequenzer-Dienst. In Matter Labs’ Vision der Elastic Chains bleiben die Chains unabhängig, aber die Interoperabilität wird durch die L1-Verträge und einen „ZK Router/Gateway“ gehandhabt – dies impliziert, dass jede Chain ihr eigenes Sequenzer-Modell wählen kann, solange sie die Protokolle zur Einreichung von State Roots und Beweisen erfüllt. Da ZK-Rollups für die Sicherheit keinen Konsens auf L2 benötigen (Gültigkeitsnachweise gewährleisten die Korrektheit), geht es bei der Dezentralisierung des Sequenzers mehr um Liveness und Zensurresistenz. Eine Hyperchain könnte einen Round-Robin-Blockproduzenten implementieren oder bei Bedarf sogar einen Hochleistungs-BFT-Konsens für ihre Sequenzer nutzen. Allerdings ist der Betrieb eines einzelnen Sequenzers weitaus einfacher und bleibt zunächst die Norm. Die ZK Stack-Dokumentation erwähnt, dass eine Chain ein „externes Protokoll“ für die Sequenzierung verwenden könnte – zum Beispiel könnte man sich vorstellen, Tendermint- oder SU-Konsens als Blockproduzenten zu verwenden und dann ZK-Beweise für die Blöcke zu generieren. Auch wie andere verfügt zkSync über einen L1-Prioritätswarteschlangenmechanismus: Benutzer können Transaktionen mit einer Prioritätsgebühr an den zkSync-Vertrag senden, um die L1->L2-Aufnahme zeitnah zu gewährleisten (Zensur zu mildern). Insgesamt ist die permissionless Teilnahme an der Sequenzierung auf zkSync-Chains noch nicht realisiert (keine öffentliche Slot-Auktion oder Staking-basierte Sequenzer-Auswahl in Produktion), aber die Architektur lässt Raum dafür. Wenn Gültigkeitsnachweise ausgereift sind, könnten wir zkSync-Chains mit von der Community betriebenen Sequenzer-Nodes sehen, die gemeinsam die Reihenfolge festlegen (sobald die Leistung dies zulässt).

• Arbitrum Orbit: Auf Arbitrum One (dem Haupt-L2) ist der Sequenzer zentralisiert (wird von Offchain Labs betrieben), obwohl der Fortschritt des Chain-Zustands letztendlich von den Arbitrum-Validatoren und Betrugsbeweisen gesteuert wird. Arbitrum hat ebenfalls eine L1-Warteschlange für Benutzer als Absicherung gegen Sequenzer-Probleme bereitgestellt. In Orbit (dem L3-Framework) kann jede Orbit Chain ihren eigenen Sequenzer oder Validatoren-Set haben. Arbitrums Nitro-Technologie beinhaltet die Option, einen Rollup mit einem dezentralisierten Sequenzer zu betreiben: Im Wesentlichen könnten mehrere Parteien die Arbitrum-Node-Software betreiben und eine Leader-Wahl verwenden (möglicherweise über die Arbitrum permissionless Proof-of-Stake-Chain in der Zukunft oder einen benutzerdefinierten Mechanismus). Out-of-the-Box wurden die bisher gestarteten Orbit Chains größtenteils zentralisiert betrieben (z. B. wird die Xai-Gaming-Chain von einer Stiftung in Zusammenarbeit mit Offchain Labs betrieben) – dies ist jedoch eine Frage der Konfiguration und Governance. Eine bemerkenswerte Entwicklung ist die Einführung von BoLD (Bounded Liquidity Delay) Anfang 2025, einem neuen Protokoll, das die Validierung von Arbitrum permissionlesser machen soll. BoLD ermöglicht es jedem, ein Validator (Prover) für die Chain zu werden und Betrugsherausforderungen in einem festen Zeitrahmen ohne Whitelist zu lösen. Dies bringt Arbitrum näher an den vertrauenslosen Betrieb, obwohl die Sequenzer-Rolle (tägliche Transaktionsordnung) immer noch zugewiesen oder gewählt werden könnte. Offchain Labs hat sich auf die Förderung der Dezentralisierung in 2024-2025 für Arbitrum konzentriert. Wir sehen auch Multi-Sequenzer-Bemühungen: Zum Beispiel könnte eine Orbit Chain ein kleines Komitee bekannter Sequenzer verwenden, um eine gewisse Fehlertoleranz zu erreichen (einer fällt aus, ein anderer fährt fort). Ein weiterer Ansatz ist die Idee eines Shared Sequencers für Orbit Chains, obwohl Arbitrum dies nicht so stark betont hat wie Optimism. Stattdessen wird Interoperabilität durch L3s erreicht, die auf Arbitrum L2 abgewickelt werden und Standard-Bridges verwenden. Zusammenfassend bietet Arbitrum Orbit Flexibilität im Sequenzer-Design (von einer Entität bis zu vielen), und der Trend geht dahin, das Validatoren-/Sequenzer-Set zu öffnen, wenn die Technologie und die Community-Governance ausgereift sind. Heute kann man sagen, dass Orbit Chains zentralisiert starten, aber eine Roadmap für permissionless Validierung haben.

• Polygon CDK: Polygon CDK Chains (manchmal Ende 2024 unter dem Oberbegriff „AggLayer“ zusammengefasst) können ebenfalls ihr Sequenzer-/Konsens-Setup wählen. Polygons zkEVM-Chain (betrieben von Polygon Labs) begann mit einem einzelnen Sequenzer und zentralisierten Prover, mit Plänen zur schrittweisen Dezentralisierung beider. Das CDK, modular aufgebaut, ermöglicht es einer Chain, ein Konsensmodul anzuschließen – zum Beispiel könnte man eine CDK Chain mit einem Proof-of-Stake-Validatoren-Set starten, das Blöcke produziert, wodurch die Sequenzierung vom ersten Tag an dezentralisiert wird. Tatsächlich wurde Polygons früheres Framework (Polygon Edge) für permissioned Unternehmens-Chains mit IBFT-Konsens verwendet; CDK Chains könnten einen hybriden Ansatz wählen (Polygons zkProver betreiben, aber ein Komitee von Nodes Blöcke vorschlagen lassen). Standardmäßig könnten viele CDK Chains aus Einfachheitsgründen mit einem einzelnen Operator betrieben werden und später einen Konsens annehmen, wenn sie skalieren. Polygon erforscht auch ein Shared Sequencer oder Aggregator-Konzept über den AggLayer-Hub, der alle Polygon Chains verbinden soll. Während AggLayer hauptsächlich Cross-Chain-Messaging und Liquidität handhabt, könnte es sich in Zukunft zu einem Shared Sequencing Service entwickeln (Polygon-Mitbegründer hat die Sequenzer-Dezentralisierung als Teil von Polygon 2.0 diskutiert). Im Allgemeinen ist Permissionlessness noch nicht vorhanden – man kann nicht spontan Sequenzer für die CDK Chain eines anderen werden, es sei denn, dieses Projekt erlaubt es. Aber Projekte wie dYdX V4 (das eine eigenständige Chain mit einer Form von dezentralem Konsens aufbaut) und andere zeigen den Appetit auf Validatoren-basierte L2s. Polygon CDK macht es technisch machbar, viele Blockproduzenten zu haben, aber die genaue Implementierung bleibt dem Chain-Deployer überlassen. Es wird erwartet, dass Polygon weitere Leitlinien oder sogar Infrastruktur für dezentralisierte Sequenzer bereitstellen wird, wenn mehr Unternehmen und Communities CDK Chains starten.

Um den Sequenzer-Vergleich zusammenzufassen: Alle Frameworks verlassen sich derzeit in ihren Live-Implementierungen auf ein relativ zentralisiertes Sequenzer-Modell, um Effizienz zu gewährleisten. Jedes bietet jedoch einen Weg zur Dezentralisierung – sei es über Shared Sequencing Networks (OP Stack), steckbaren Konsens (CDK, ZK Stack) oder permissionless Validatoren (Arbitrums BoLD). Die folgende Tabelle hebt die Sequenzer-Designs hervor:

Wie zu sehen ist, umfassen Optimism und Arbitrum On-Chain-Fallback-Warteschlangen, was ein starkes Zensurresistenz-Merkmal ist. ZK-basierte Chains verlassen sich darauf, dass ein Sequenzer den Zustand nicht fälschen kann (dank ZK-Beweisen), aber wenn er zensiert, könnte ein neuer Sequenzer von der Governance ernannt werden – ein Bereich, der noch verfeinert wird. Der Trend im Jahr 2025 ist, dass wir wahrscheinlich dezentralere Sequenzer-Pools und möglicherweise Shared Sequencer Networks online gehen sehen werden, die diese RaaS-Frameworks ergänzen. Jedes Projekt forscht aktiv daran: z. B. bauen Astria und andere allgemeine Shared Sequencing Services auf, und OP Labs, Polygon und Offchain haben alle Pläne zur Dezentralisierung der Sequenzer-Rolle erwähnt.

Gebührenmodelle und Ökonomie​

Gebührenmodelle bestimmen, wer was in diesen Rollup-Frameworks zahlt und wie die wirtschaftlichen Anreize für Betreiber und das Ökosystem ausgerichtet sind. Wichtige Überlegungen sind: In welchem Token werden Gebühren gezahlt? Wer sammelt die Gebühren? Welche Kosten (L1-Posting, Proving) müssen gedeckt werden? Gibt es Umsatzbeteiligungs- oder Kickback-Vereinbarungen? Wie anpassbar sind die Gebührenparameter?

• Gas-Token und Gebührenanpassung: Alle verglichenen Frameworks ermöglichen die Anpassung des nativen Gas-Tokens, was bedeutet, dass eine neue Chain entscheiden kann, welche Währung Benutzer für Gebühren zahlen. Standardmäßig wählen Rollups auf Ethereum oft ETH als Gas-Token zur Benutzerfreundlichkeit (Benutzer benötigen keinen neuen Token, um die Chain zu verwenden). Zum Beispiel verwendet Base (OP Stack) ETH für Gas, ebenso wie zkSync Era und Polygon zkEVM. OP Stack unterstützt technisch den Ersatz von ETH durch einen anderen ERC-20, aber im Kontext der OP Superchain gibt es einen Vorstoß, einen Standard beizubehalten (um die Interoperabilität reibungsloser zu gestalten). Tatsächlich entschieden sich einige OP Stack Chains, die ursprünglich einen benutzerdefinierten Token in Betracht zogen, für ETH – z. B. verwendet Worldcoins OP-Chain ETH für Gebühren, obwohl das Projekt seinen eigenen Token WLD hat. Andererseits wurde Arbitrum Orbit ohne Unterstützung für benutzerdefinierte Token gestartet, fügte diese aber aufgrund der Nachfrage schnell hinzu. Jetzt können Orbit Chains ARB oder jeden ERC-20 als Gas verwenden. Die Ape Chain L3 wählte APE Coin als ihre Gaswährung, was diese Flexibilität demonstriert. Polygon CDK lässt Sie ebenfalls den Token definieren; viele Projekte neigen dazu, MATIC zu verwenden, um sich an Polygons Ökosystem anzupassen (und MATIC wird unter Polygon 2.0 auf POL Token aktualisiert), aber es ist nicht erzwungen. zkSync’s ZK Stack unterstützt ebenfalls explizit benutzerdefinierte Basis-Token (die Dokumentation enthält sogar ein Tutorial „Benutzerdefinierter Basis-Token“). Dies ist nützlich für Unternehmens-Chains, die beispielsweise einen Stablecoin oder ihre eigene Coin für Gebühren wünschen. Es ist auch entscheidend für App-Chains, die ihre eigene Token-Ökonomie haben – sie können die Nachfrage nach ihrem Token steigern, indem sie ihn zum Gas-Token machen. Zusammenfassend lässt sich sagen, dass der Gebühren-Token in allen Frameworks vollständig konfigurierbar ist, obwohl die Verwendung eines weit verbreiteten Tokens wie ETH die Benutzerreibung verringern kann.

• Gebührenerhebung und -verteilung: Im Allgemeinen erhebt der Sequenzer (Blockproduzent) Transaktionsgebühren auf L2/L3. Dies ist ein primärer Anreiz für den Betrieb eines Sequenzers. Zum Beispiel verdient Optimisms Sequenzer alle Gasgebühren, die Benutzer auf Optimism zahlen, muss dann aber für das Posten von Batches an Ethereum bezahlen. Normalerweise nimmt der Sequenzer die vom Benutzer gezahlten L2-Gebühren, zieht die L1-Kosten ab und behält den Rest als Gewinn. Auf einer gut geführten Chain sind die L1-Kosten ein Bruchteil der L2-Gebühren, was eine gewisse Gewinnspanne lässt. Für ZK-Rollups gibt es zusätzliche Kosten: die Generierung des ZK-Beweises. Dies kann erheblich sein (erfordert spezialisierte Hardware oder Cloud-Computing). Derzeit subventionieren einige ZK-Rollup-Betreiber die Proving-Kosten (Ausgabe von VC-Geldern), um die Benutzergebühren während der Wachstumsphase niedrig zu halten. Mit der Zeit werden die Proving-Kosten voraussichtlich mit besseren Algorithmen und Hardware sinken. Framework-seitig: zkSync und Polygon erlauben es dem Sequenzer, etwas mehr zu verlangen, um das Proving abzudecken – und wenn eine Chain einen externen Prover-Dienst verwendet, könnten sie eine Umsatzbeteiligung mit diesem haben. Bemerkenswert ist, dass kein Framework außer OP Superchain eine erzwungene Umsatzbeteiligung auf Protokollebene hat. Das Standard Rollup Revenue-Schema des Optimism Collective verlangt von OP Chains, entweder 2,5 % der Bruttogebühren oder 15 % des Nettogewinns (je nachdem, welcher Wert höher ist) an eine gemeinsame Kasse abzuführen. Dies ist eine freiwillige, aber erwartete Vereinbarung im Rahmen der Superchain-Charta, und keine Smart-Contract-Durchsetzung, aber alle großen OP Stack Chains (Base, opBNB, Worldcoin usw.) haben ihr zugestimmt. Diese Gebühren (bisher über 14.000 ETH) finanzieren öffentliche Güter über die Optimism-Governance. Im Gegensatz dazu erhebt Arbitrum keine Gebühren von Orbit Chains; Orbit ist permissionless zu verwenden. Die Arbitrum DAO könnte in Zukunft möglicherweise eine Umsatzbeteiligung fordern (um ihr eigenes Ökosystem zu finanzieren), aber im Jahr 2025 existiert keine. Polygon CDK erhebt ebenfalls keine Steuer; Polygons Ansatz ist es, Benutzer in sein Ökosystem zu locken (wodurch der MATIC-Wert und die Nutzung steigen), anstatt pro-Chain-Gebühren zu erheben. Polygon-Mitbegründer Sandeep Nailwal sagte explizit, dass AggLayer „keine Miete“ von Chains verlangt. zkSync hat ebenfalls keine Gebührenteilung angekündigt – Matter Labs konzentriert sich wahrscheinlich auf das Wachstum der Nutzung von zkSync Era und Hyperchains, was ihnen indirekt durch Netzwerkeffekte und möglicherweise zukünftigen Token-Wert zugutekommt.

• L1-Abwicklungskosten: Ein großer Teil des Gebührenmodells ist, wer für L1-Transaktionen zahlt (Daten oder Beweise bereitstellen). In allen Fällen zahlen letztendlich Benutzer, aber der Mechanismus unterscheidet sich. Bei Optimistic Rollups sendet der Sequenzer periodisch Batches von Transaktionen (mit Calldata) an L1. Die Gaskosten für diese L1-Transaktionen werden vom Sequenzer mit ETH bezahlt. Sequenzer berücksichtigen dies jedoch bei der L2-Gaspreisgestaltung. Optimism und Arbitrum haben Gaspreisformeln, die schätzen, wie viel die Calldata einer Transaktion auf L1 kosten wird, und dies in die L2-Gasgebühr einbeziehen (oft als „amortisierte L1-Kosten“ pro Transaktion bezeichnet). Zum Beispiel könnte eine einfache Optimism-Transaktion 21.000 L2-Gas für die Ausführung und vielleicht ein paar hundert zusätzlich für L1-Daten verursachen – die Gebühr des Benutzers deckt beides ab. Wenn die Preisgestaltung falsch eingeschätzt wird, könnte der Sequenzer bei diesem Batch Geld verlieren oder gewinnen, wenn die Nutzung hoch ist. Sequenzer passen die Gebühren typischerweise dynamisch an die L1-Bedingungen an (erhöhen die L2-Gebühren, wenn L1-Gas teuer ist). Bei Arbitrum ist der Mechanismus ähnlich, obwohl Arbitrum separate „L1-Preisgestaltung“- und „L2-Preisgestaltung“-Komponenten hat. Bei zkSync/Polygon (ZK) muss der Sequenzer einen Gültigkeitsnachweis an L1 senden (was eine feste Gasmenge zur Verifizierung kostet) plus entweder Calldata (wenn Rollup) oder State Root (wenn Validium). Die Beweisverifizierungskosten sind normalerweise pro Batch konstant (auf zkSync Era liegen sie in der Größenordnung von einigen hunderttausend Gas), sodass das Gebührenmodell von zkSync diese Kosten auf die Transaktionen verteilt. Sie könnten einen geringen Overhead auf jede Transaktion für das Proving erheben. Bemerkenswert ist, dass zkSync Funktionen wie State Diffs und Komprimierung eingeführt hat, um die veröffentlichten L1-Daten zu minimieren. Polygon zkEVM verwendet ebenfalls rekursive Beweise, um viele Transaktionen in einem Beweis zu bündeln und die Verifizierungskosten zu amortisieren. Wenn eine Chain eine alternative DA (Celestia/Avail) verwendet, zahlt sie anstelle von Ethereum für Calldata diesen DA-Anbieter. Celestia hat zum Beispiel seinen eigenen Gas-Token (TIA), um für Daten-Blobs zu bezahlen. Eine Chain müsste also einen Teil der Gebühren umwandeln, um Celestia-Miner zu bezahlen. Frameworks abstrahieren diese Kosten zunehmend: z. B. könnte eine OP Stack Chain einen Celestia DA-Node über einen Adapter bezahlen und diese Kosten in die Benutzergebühren einbeziehen.

• Kosten für Benutzer (Finalität und Abhebung): Für Optimistic Rollups (OP Stack, Arbitrum Orbit im Rollup-Modus) sehen sich Benutzer der berüchtigten Challenge-Periode für Abhebungen gegenüber – typischerweise 7 Tage auf Ethereum L1. Dies ist ein Usability-Nachteil, aber die meisten Ökosysteme haben Abhilfemaßnahmen. Schnelle Bridges (Liquiditätsnetzwerke) ermöglichen es Benutzern, ihre L2-Token sofort gegen L1-Token zu tauschen, gegen eine geringe Gebühr, während Arbitrageure die 7 Tage warten. Arbitrum ist für Orbit Chains noch weiter gegangen und arbeitet mit Teams zusammen, um schnelle Abhebungen in nur 15 Minuten über auf Protokollebene integrierte Liquiditätsanbieter zu ermöglichen. Dies bedeutet effektiv, dass Benutzer außer in Worst-Case-Szenarien nicht eine Woche warten müssen. ZK-Rollups haben diese Verzögerung nicht – sobald ein Gültigkeitsnachweis auf L1 akzeptiert wird, ist der Zustand final. So erhalten zkSync- und Polygon-Benutzer eine schnellere Finalität (oft Minuten bis eine Stunde), je nachdem, wie oft Beweise eingereicht werden. Der Kompromiss ist, dass das Proving eine kleine Verzögerung zwischen der Annahme einer Transaktion auf L2 und ihrer Aufnahme in einen L1-Beweis einführen kann (könnte ein paar Minuten dauern). Aber im Allgemeinen bieten ZK-Rollups im Jahr 2025 10–30-minütige Abhebungen an, was eine enorme Verbesserung gegenüber 7 Tagen darstellt. Benutzer zahlen möglicherweise eine etwas höhere Gebühr für sofortige Finalität (um die Prover-Kosten zu decken), aber viele halten es für lohnenswert. Die Gebührenanpassung ist ebenfalls erwähnenswert: Frameworks erlauben benutzerdefinierte Gebührenpläne (wie kostenlose Transaktionen oder Gas-Subventionen), wenn Projekte dies wünschen. Zum Beispiel könnte ein Unternehmen alle Benutzergebühren auf seiner Chain subventionieren, indem es den Sequenzer mit Verlust betreibt (vielleicht für ein Spiel oder eine soziale App). Oder sie könnten ein anderes Gasmodell einrichten (einige haben mit keinem Gas für bestimmte Aktionen oder alternativer Gasabrechnung gespielt). Da die meisten Frameworks auf Ethereum-Äquivalenz abzielen, sind solche tiefgreifenden Änderungen selten, aber mit Code-Modifikation möglich. Arbitrums Stylus könnte eine andere Gebührenmessung für WASM-Verträge ermöglichen (z. B. keine Gebühren für bestimmte Operationen, um die WASM-Nutzung zu fördern). Das Polygon CDK ist Open Source und modular, was bedeutet, dass ein Projekt, das einen neuartigen Gebührenmechanismus (wie Gebührenverbrennung oder dynamische Preisgestaltung) implementieren wollte, dies tun könnte.

Im Wesentlichen streben alle Rollup-Frameworks danach, wirtschaftliche Anreize auszurichten: den Betrieb eines Sequenzers profitabel zu machen (durch Gebühreneinnahmen), die Gebühren für Benutzer durch die Nutzung billigerer DA angemessen zu halten und (optional) einen Teil des Werts in ihr breiteres Ökosystem zu leiten. Optimisms Modell ist einzigartig, da es explizit Einnahmen für öffentliche Güter teilt, während andere auf Wachstum und Token-Ökonomie setzen (z. B. mehr Chains -> mehr MATIC/ETH-Nutzung, was den Wert dieser Token erhöht).

Architektur und Modularität​

Alle diese Frameworks rühmen sich einer modularen Architektur, was bedeutet, dass jede Schicht des Stacks (Ausführung, Abwicklung, Konsens, DA, Beweise) austauschbar oder aufrüstbar ist. Lassen Sie uns kurz auf jede eingehen:

• OP Stack: Als eine Reihe von Modulen aufgebaut, die den Ethereum-Schichten entsprechen – Ausführungs-Engine (OP EVM, abgeleitet von geth), Konsens-/Rollup-Node (op-node), Abwicklungs-Smart-Contracts und bald Betrugsprüfer. Das Designziel des OP Stacks war EVM-Äquivalenz (keine benutzerdefinierten Gaspläne oder Opcode-Änderungen) und einfache Integration mit Ethereum-Tools. Das Bedrock-Upgrade im Jahr 2023 modularisierte Optimisms Stack weiter, wodurch es einfacher wurde, Komponenten auszutauschen (z. B. um ZK-Beweise in Zukunft zu implementieren oder eine andere DA zu verwenden). Tatsächlich ist OP Stack nicht auf optimistische Betrugsbeweise beschränkt – das Team hat erklärt, dass es offen für die Integration von Gültigkeitsnachweisen ist, wenn diese ausgereift sind, wodurch OP Stack Chains im Wesentlichen zu ZK-Rollups werden, ohne die Entwicklererfahrung zu ändern. Das Superchain-Konzept erweitert die Architektur auf mehrere Chains: Standardisierung der Inter-Chain-Kommunikation, Bridging und möglicherweise Shared Sequencing. OP Stack wird mit einem reichhaltigen Satz von Smart Contracts auf L1 (für Einzahlungen, Abhebungen, Betrugsbeweisverifizierung usw.) geliefert, die Chains Out-of-the-Box erben. Es ist effektiv eine Plug-and-Play-L2-Chain-Vorlage – Projekte wie Base wurden durch das Forken der OP Stack-Repos und deren Konfiguration, um auf ihre eigenen Verträge zu verweisen, gestartet.

• ZK Stack: Der ZK Stack ist das Framework, das zkSync Era und zukünftigen „Hyperchains“ zugrunde liegt. Architektonisch umfasst er die zkEVM-Ausführungsumgebung (eine LLVM-basierte VM, die das Ausführen von Solidity-Code mit minimalen Änderungen ermöglicht), das Prover-System (die Schaltkreise und Beweisgenerierung für Transaktionen), den Sequenzer-Node und die L1-Verträge (die zkSync-Smart-Contracts, die Beweise verifizieren und State Roots verwalten). Modularität zeigt sich darin, wie es den ZK-Beweisschaltkreis von der Ausführung trennt – theoretisch könnte man ein anderes Beweisschema oder sogar eine andere VM einfügen (wenn auch nicht trivial). Der ZK Stack führt die Elastic Chain Architecture mit Komponenten wie ZK Router und ZK Gateway ein. Diese fungieren als Interoperabilitätsschicht, die mehrere ZK Chains verbindet. Es ist ein bisschen wie ein „Internet der ZK-Rollups“-Konzept, bei dem der Router (auf Ethereum) ein Register von Chains führt und Shared Bridging/Liquidität erleichtert, und das Gateway Nachrichten zwischen Chains Off-Chain verarbeitet. Dies ist modular, da eine neue Chain einfach durch die Bereitstellung mit den Standardverträgen in diese Architektur integriert werden kann. ZK Stack umfasst auch Account Abstraction auf Protokollebene (Verträge als Konten, native Meta-Transaktionen), was eine architektonische Wahl zur Verbesserung der UX ist. Ein weiterer modularer Aspekt: Wie in DA besprochen, kann es im Rollup- oder Validium-Modus betrieben werden – im Wesentlichen durch Umlegen eines Schalters in der Konfiguration. Auch hat der Stack eine Vorstellung von Pluggable Consensus für die Sequenzierung (wie zuvor erwähnt). Die Abwicklungsschicht kann Ethereum oder potenziell eine andere Chain sein: zkSyncs Roadmap sah sogar vor, Hyperchains auf L2 abzuwickeln (z. B. ein L3, das Beweise an zkSync Era L2 anstatt an L1 sendet) – tatsächlich starteten sie einen Prototyp namens „ZK Portal“ für L3-Abwicklung auf L2. Dies bietet eine hierarchische Modularität (L3->L2->L1). Insgesamt ist der ZK Stack im Jahr 2025 für Nicht-Matter-Labs-Teams etwas weniger schlüsselfertig (da der Betrieb einer ZK-Chain die Koordination von Provern usw. beinhaltet), aber er ist in fähigen Händen sehr flexibel.

• Arbitrum Orbit: Arbitrums Architektur basiert auf dem Arbitrum Nitro Stack, der die ArbOS-Ausführungsschicht (Arbitrums Interpretation von EVM mit einigen kleinen Unterschieden), den Sequenzer/Relay, die AnyTrust-Komponente für alternative DA und die Betrugsbeweis-Maschinerie (interaktive Betrugsbeweise) umfasst. Orbit ermöglicht es im Wesentlichen, denselben Stack zu verwenden, aber bestimmte Parameter zu konfigurieren (wie Chain-ID, L2-Genesis-Zustand, Wahl zwischen Rollup und AnyTrust). Modularität: Arbitrum führte Stylus ein, eine neue WASM-kompatible Smart-Contract-Engine, die neben der EVM läuft. Stylus ermöglicht das Schreiben von Verträgen in Rust, C, C++, die zu WASM kompilieren und mit nahezu nativer Geschwindigkeit auf Arbitrum Chains laufen. Dies ist ein optionales Modul – Orbit Chains können Stylus aktivieren oder nicht. Es ist ein Unterscheidungsmerkmal für Arbitrums Stack, das ihn für Hochleistungs-dApps attraktiv macht (z. B. könnten Gaming- oder Handels-Apps einige Logik in Rust für Geschwindigkeit schreiben). Das Datenverfügbarkeits-Modul ist ebenfalls steckbar, wie besprochen (Arbitrum Chains können On-Chain oder DAC wählen). Ein weiteres Modul ist die L1-Abwicklung: Orbit Chains können ihre Beweise entweder an Ethereum (L1) oder an Arbitrum One (L2) senden. Im letzteren Fall sind sie effektiv L3s, die in der Sicherheit von Arbitrum One verankert sind (mit leicht unterschiedlichen Vertrauensannahmen). Viele Orbit Chains werden als L3s gestartet (um Arbitrum Ones niedrigere Gebühren und letztendlich immer noch Ethereum-Sicherheit zu erben). Arbitrums Codebasis ist jetzt vollständig Open Source, und Projekte wie Caldera, Conduit bauen darauf auf, um benutzerfreundliche Bereitstellung zu ermöglichen – sie könnten ihre eigenen Module hinzufügen (wie Überwachung, Chain-Management-APIs). Es ist erwähnenswert, dass Arbitrums Betrugsbeweise historisch nicht permissionless waren (nur Whitelist-Validatoren konnten anfechten), aber mit BoLD ändert sich dieser Teil der Architektur, um jedem den Einstieg zu ermöglichen. Der Betrugsbeweis-Komponente wird also dezentraler (was in gewisser Weise ein modularer Upgrade ist). Man könnte sagen, Arbitrum ist weniger ein „Lego-Kit“ als OP Stack oder Polygon CDK, da Offchain Labs keinen Ein-Klick-Chain-Launcher veröffentlicht hat (obwohl sie eine Orbit-Bereitstellungs-GUI auf GitHub veröffentlichten). Aber funktional ist es modular genug, dass Dritte die Bereitstellung dafür automatisiert haben.

• Polygon CDK (AggLayer): Polygon CDK wird explizit als „modulares Framework“ für ZK-gestützte Chains beschrieben. Es nutzt Polygons ZK-Proving-Technologie (von Polygon zkEVM, das auf Plonky2 und rekursiven SNARKs basiert). Die Architektur trennt die Ausführungsschicht (die eine EVM ist – speziell ein Fork von Geth, angepasst für zkEVM) von der Prover-Schicht und den Bridge-/Abwicklungsverträgen. Da es modular ist, kann ein Entwickler verschiedene Optionen für jede wählen: z. B. Ausführung – vorerst vermutlich immer EVM (um bestehende Tools zu nutzen), DA – wie besprochen (Ethereum oder andere), Sequenzer-Konsens – Einzel- vs. Multi-Node, Prover – man kann den Prover Typ1 (Gültigkeitsnachweise an Ethereum gesendet) oder Typ2 (Validium-Nachweise) usw. betreiben, und AggLayer-Integration – ja oder nein (AggLayer für Interoperabilität). Polygon stellte sogar eine elegante Oberfläche (unten gezeigt) zur Visualisierung dieser Auswahlmöglichkeiten bereit:

Polygons CDK-Konfigurationsoberfläche, die modulare Auswahlmöglichkeiten veranschaulicht – z. B. Rollups vs. Validium (Skalierungslösung), dezentraler vs. zentralisierter Sequenzer, lokale/Ethereum/Drittanbieter-DA, verschiedene Prover-Typen und ob die AggLayer-Interoperabilität aktiviert werden soll.

Unter der Haube verwendet Polygon CDK zk-Beweise mit Rekursion, um einen hohen Durchsatz und ein dynamisches Validatoren-Set zu ermöglichen. Der AggLayer ist ein aufkommender Teil der Architektur, der Chains für vertrauensloses Messaging und Shared Liquidity verbinden wird. Das CDK ist so aufgebaut, dass zukünftige Verbesserungen in Polygons ZK-Technologie (wie schnellere Beweise oder neue VM-Funktionen) von allen CDK Chains über Upgrades übernommen werden können. Polygon hat ein Konzept von „Typ 1 vs. Typ 2“ zkEVM – Typ 1 ist vollständig Ethereum-äquivalent, Typ 2 ist fast äquivalent mit geringfügigen Änderungen für Effizienz. Eine CDK Chain könnte eine leicht modifizierte EVM für mehr Geschwindigkeit wählen (wobei ein Teil der Äquivalenz geopfert wird) – dies ist eine architektonische Option, die Projekte haben. Insgesamt ist CDK sehr Lego-ähnlich: Man kann eine Chain zusammenstellen, indem man Komponenten wählt, die für ihren Anwendungsfall geeignet sind (z. B. könnte ein Unternehmen Validium + permissioned Sequenzer + private Tx-Sichtbarkeit wählen; eine öffentliche DeFi-Chain könnte Rollup + dezentralisierten Sequenzer + AggLayer für Liquidität aktivieren). Diese Vielseitigkeit hat viele Projekte dazu bewogen, CDK für den Start ihrer eigenen Netzwerke in Betracht zu ziehen.

• Bilder und Diagramme: Die Frameworks stellen oft visuelle Diagramme ihrer modularen Architektur bereit. Zum Beispiel zeigt die Benutzeroberfläche von zkSync Schalter für Rollup/Validium, L2/L3, zentralisiert/dezentralisiert usw., was die Flexibilität des ZK Stacks hervorhebt:

Ein Beispiel für die Konfiguration einer zkSync „Hyperchain“. Die ZK Stack-Oberfläche ermöglicht die Auswahl des Chain-Modus (Rollup vs. Validium vs. Volition), der Schicht (L2 oder L3), der Transaktionssequenzierung (dezentralisiert, zentralisiert oder geteilt), der Datenverfügbarkeitsquelle (Ethereum, Drittanbieter-Netzwerk oder benutzerdefiniert), der Datensichtbarkeit (öffentliche oder private Chain) und des Gas-Tokens (ETH, benutzerdefiniert oder gaslos). Dieser modulare Ansatz wurde entwickelt, um eine Vielzahl von Anwendungsfällen zu unterstützen, von öffentlichen DeFi-Chains bis hin zu privaten Unternehmens-Chains.

Zusammenfassend lässt sich sagen, dass all diese Stacks hochmodular und aufrüstbar sind, was angesichts des Tempos der Blockchain-Innovation unerlässlich ist. Sie konvergieren in gewisser Weise: OP Stack fügt Gültigkeitsnachweise hinzu, Polygon fügt Shared Sequencing hinzu (OP Stack-Ideen), Arbitrum fügt interoperable L3s hinzu (wie andere), zkSync verfolgt L3s (wie Orbit und OP Stack). Diese gegenseitige Befruchtung bedeutet, dass modulare Frameworks im Jahr 2025 in ihrer Philosophie ähnlicher als unterschiedlich sind – jedes möchte das One-Stop-Toolkit sein, um skalierbare Chains zu starten, ohne das Rad neu zu erfinden.

Entwicklererfahrung und Tools​

Ein entscheidender Faktor für die Akzeptanz ist, wie einfach und entwicklerfreundlich diese Frameworks sind. Dazu gehören Dokumentation, SDKs/APIs, CLIs für die Bereitstellung, Überwachungstools und die Lernkurve für Entwickler:

• OP Stack – Entwicklererfahrung: Optimism’s OP Stack profitiert davon, EVM-äquivalent zu sein, sodass Ethereum-Entwickler vertraute Tools (Remix, Hardhat, Truffle, Solidity, Vyper) ohne Änderungen verwenden können. Smart Contracts, die auf einer OP-Chain bereitgestellt werden, verhalten sich genau wie auf L1. Dies senkt die Lernkurve drastisch. Optimism bietet eine umfassende Dokumentation: Die offiziellen Optimism-Dokumente enthalten Abschnitte zum OP Stack, zum Betrieb eines L2-Nodes und sogar ein „OP Stack from scratch“-Tutorial. Es gibt auch von der Community verfasste Anleitungen (zum Beispiel QuickNodes Schritt-für-Schritt-Anleitung zur Bereitstellung eines Optimism L2 Rollups). In Bezug auf Tools hat OP Labs den op-node-Client (für den Rollup-Node) und op-geth (Ausführungs-Engine) veröffentlicht. Um eine Chain zu starten, muss ein Entwickler diese typischerweise konfigurieren und die L1-Verträge (Standard Bridge usw.) bereitstellen. Dies war nicht trivial, wird aber mit Anbieterdiensten einfacher. Deployment-as-a-Service: Unternehmen wie Caldera, Conduit und Infura/Alchemy bieten verwaltete OP Stack Rollup-Bereitstellungen an, die einen Großteil der DevOps abstrahieren. Für die Überwachung können, da eine OP Stack Chain im Wesentlichen eine geth-Chain plus ein Rollup-Koordinator ist, Standard-Ethereum-Überwachungstools (ETH-Metrik-Dashboards, Block-Explorer wie Etherscan/Blockscout) verwendet werden. Tatsächlich unterstützt Etherscan OP Stack Chains wie Optimism und Base und bietet vertraute Block-Explorer-Oberflächen. Entwickler-Tools speziell für OP Chains umfassen das Optimism SDK für Bridging (Erleichterung von Einzahlungen/Abhebungen in Apps) und Bedrocks Integration mit Ethereum JSON-RPC (sodass Tools wie MetaMask einfach durch Netzwerkwechsel funktionieren). Der OP Stack-Code ist MIT-lizenziert und lädt Entwickler zum Forken und Experimentieren ein. Viele taten dies – z. B. nutzte das Team von BNB Chain den OP Stack, um opBNB mit eigenen Änderungen an Konsens und Gas-Token zu erstellen (sie verwenden BNB-Gas auf opBNB). Die Einhaltung der Ethereum-Standards durch den OP Stack macht die Entwicklererfahrung wohl zur reibungslosesten unter diesen: im Wesentlichen „Ethereum, aber billiger“ aus Sicht eines Vertragsentwicklers. Die wichtigsten neuen Fähigkeiten, die benötigt werden, betreffen den Betrieb der Infrastruktur (für diejenigen, die eine Chain starten) und das Verständnis der Nuancen des Cross-Chain-Bridgings. Optimisms Community und Support (Discord, Foren) sind aktiv, um neuen Chain-Teams zu helfen. Darüber hinaus hat Optimism Ökosystem-Tools wie Magi (einen alternativen Rust-Rollup-Client) finanziert, um den Stack zu diversifizieren und ihn für Entwickler robuster zu machen.

• zkSync ZK Stack – Entwicklererfahrung: Auf der Seite der Vertragsentwicklung bietet zkSync’s ZK Stack eine zkEVM, die eine hohe Kompatibilität aufweisen soll, aber derzeit nicht zu 100 % Bytecode-äquivalent ist. Sie unterstützt Solidity- und Vyper-Verträge, es gibt jedoch subtile Unterschiede (z. B. bestimmte Precompiles oder Gaskosten). Dennoch hat Matter Labs einen LLVM-Compiler entwickelt, der Solidity nimmt und zkEVM-Bytecode erzeugt, sodass die meisten Solidity-Codes mit geringfügigen oder keinen Änderungen funktionieren. Sie unterstützen auch nativ Account Abstraction, die Entwickler nutzen können, um gaslose Transaktionen, Multi-Sig-Wallets usw. einfacher zu erstellen als auf Ethereum (keine Notwendigkeit für ERC-4337). Die Entwicklerdokumentation für zkSync ist umfassend (docs.zksync.io) und behandelt die Bereitstellung von Verträgen, die Verwendung der Hyperchain CLI (falls vorhanden) und die Konfiguration einer Chain. Der Betrieb eines ZK-Rollups ist jedoch von Natur aus komplexer als der eines optimistischen Rollups – man benötigt ein Proving-Setup. Der ZK Stack stellt die Prover-Software bereit (z. B. die GPU-Prover für zkSyncs Schaltkreise), aber ein Chain-Operator muss Zugang zu ernsthafter Hardware oder Cloud-Diensten haben, um kontinuierlich Beweise zu generieren. Dies ist eine neue DevOps-Herausforderung; um sie zu mildern, entstehen einige Unternehmen, die Prover-Dienste oder sogar Proof-as-a-Service anbieten. Wenn ein Entwickler seine eigenen Prover nicht betreiben möchte, kann er dies möglicherweise auslagern (mit Vertrauens- oder kryptoökonomischen Zusicherungen). Tools: zkSync bietet standardmäßig ein Bridge- und Wallet-Portal (das zkSync Portal), das für eine neue Chain geforkt werden kann, um Benutzern eine Benutzeroberfläche zum Verschieben von Assets und Anzeigen von Konten zu bieten. Für die Block-Exploration wurde Blockscout an zkSync angepasst, und Matter Labs hat einen eigenen Block-Explorer für zkSync Era entwickelt, der wahrscheinlich für neue Chains verwendet werden könnte. Die Existenz des ZK Gateway und Routers bedeutet, dass ein Entwickler, wenn er sich daran anschließt, Out-of-the-Box-Interoperabilität mit anderen Chains erhält – aber er muss die Standards von Matter Labs befolgen. Insgesamt ist das Bauen auf zkSync für einen Smart-Contract-Entwickler nicht allzu schwierig (nur Solidity, mit vielleicht geringfügigen Unterschieden wie gasleft() könnte sich aufgrund des Fehlens tatsächlicher Ethereum-Gaskosten leicht anders verhalten). Aber für einen Chain-Operator hat der ZK Stack eine steilere Lernkurve als OP Stack oder Orbit. Im Jahr 2025 konzentriert sich Matter Labs auf die Verbesserung dessen – zum Beispiel die Vereinfachung des Startprozesses einer Hyperchain, möglicherweise die Bereitstellung von Skripten oder Cloud-Images, um den gesamten Stack hochzufahren. Es gibt auch eine aufstrebende Community von Entwicklern rund um den ZK Stack; z. B. ist die ZKSync Community Edition eine Initiative, bei der Community-Mitglieder Test-L3-Chains betreiben und Tipps austauschen. Wir sollten beachten, dass die Sprachunterstützung für zkSyncs Ökosystem erweitert werden könnte – sie haben über die Zulassung anderer Sprachen über die LLVM-Pipeline gesprochen (z. B. einen Rust-zu-zkEVM-Compiler in der Zukunft), aber Solidity ist derzeit die Hauptsprache. Zusammenfassend lässt sich sagen, dass die Entwicklererfahrung von zkSync: großartig für DApp-Entwickler (nahezu Ethereum-ähnlich), moderat für Chain-Launcher (müssen Prover und neue Konzepte wie Validiums handhaben).

• Arbitrum Orbit – Entwicklererfahrung: Für Solidity-Entwickler ist Arbitrum Orbit (und Arbitrum One) auf Bytecode-Ebene vollständig EVM-kompatibel (Arbitrum Nitro verwendet eine von geth abgeleitete Ausführung). Daher ist die Bereitstellung und Interaktion mit Verträgen auf einer Arbitrum-Chain genau wie auf Ethereum (mit einigen kleinen Unterschieden wie leicht unterschiedlichem L1-Blocknummerzugriff, ChainID usw., aber nichts Großes). Wo Arbitrum herausragt, ist Stylus – Entwickler können Smart Contracts in Sprachen wie Rust, C, C++ (kompiliert zu WebAssembly) schreiben und diese neben EVM-Verträgen bereitstellen. Dies öffnet die Blockchain-Entwicklung einem breiteren Pool von Programmierern und ermöglicht Hochleistungs-Anwendungsfälle. Zum Beispiel könnte eine algorithmisch intensive Logik für Geschwindigkeit in C geschrieben werden. Stylus befindet sich noch in der Beta-Phase auf Arbitrum Mainnet, aber Orbit Chains können damit experimentieren. Dies ist ein einzigartiger Vorteil für die Entwicklererfahrung, obwohl diejenigen, die Stylus verwenden, neue Tools lernen müssen (z. B. Rust-Toolchains und Arbitrums Bibliotheken für die Schnittstelle von WASM mit der Chain). Die Arbitrum-Dokumentation bietet Anleitungen zur Verwendung von Stylus und sogar zum Schreiben von Rust-Smart-Contracts. Für den Start einer Orbit Chain hat Offchain Labs Devnet-Skripte und eine Orbit-Bereitstellungs-UI bereitgestellt. Der Prozess ist etwas technisch: Man muss einen Arbitrum-Node mit --l3-Flags einrichten (wenn man einen L3 startet) und die Genesis, Chain-Parameter usw. konfigurieren. QuickNode und andere haben Anleitungen veröffentlicht („How to deploy your own Arbitrum Orbit chain“). Darüber hinaus bedeuten Orbit-Partnerschaften mit Caldera, AltLayer und Conduit, dass diese Drittanbieter einen Großteil der schweren Arbeit übernehmen. Ein Entwickler kann im Wesentlichen ein Formular ausfüllen oder einen Assistenten mit diesen Diensten ausführen, um eine angepasste Arbitrum-Chain zu erhalten, anstatt den Nitro-Code manuell zu ändern. In Bezug auf Debugging und Überwachung können Arbitrum Chains Arbiscan (für diejenigen, die es haben) oder Community-Explorer verwenden. Es gibt auch Grafana/Prometheus-Integrationen für Node-Metriken. Eine Komplexität ist das Betrugsbeweis-System – Entwickler, die eine Orbit Chain starten, sollten sicherstellen, dass es Validatoren gibt (vielleicht sie selbst oder vertrauenswürdige andere), die die Off-Chain-Validatoren-Software ausführen, um nach Betrug zu suchen. Offchain Labs stellt wahrscheinlich Standard-Skripte für den Betrieb solcher Validatoren bereit. Da Betrugsbeweise jedoch selten ausgelöst werden, geht es mehr darum, den Sicherheitsprozess zu etablieren. Arbitrums große Entwickler-Community (Projekte, die auf Arbitrum One aufbauen) ist ein Vorteil – Ressourcen wie Tutorials, StackExchange-Antworten usw. gelten oft auch für Orbit. Arbitrum ist auch bekannt für seine starken Entwickler-Bildungsbemühungen (Workshops, Hackathons), die sich vermutlich auf diejenigen erstrecken, die an Orbit interessiert sind.

• Polygon CDK – Entwicklererfahrung: Polygon CDK ist neuer (Mitte/Ende 2023 angekündigt), baut aber auf bekannten Komponenten auf. Für Entwickler, die Verträge schreiben, verwenden Polygon CDK Chains eine zkEVM, die der EVM von Ethereum entsprechen soll (Polygons Typ 2 zkEVM ist nahezu identisch mit einigen Randfällen). Daher sind Solidity und Vyper die bevorzugten Sprachen, mit voller Unterstützung für Standard-Ethereum-Entwicklungstools. Wenn Sie auf Polygon zkEVM oder Ethereum bereitgestellt haben, können Sie auf einer CDK Chain ähnlich bereitstellen. Die Herausforderung liegt eher auf der Seite der Chain-Operationen. Polygons CDK ist Open Source auf GitHub und wird mit Dokumentation zur Konfiguration einer Chain geliefert. Es bietet wahrscheinlich ein Befehlszeilentool zum Gerüstbau einer neuen Chain (ähnlich wie man Cosmos SDKs starport oder Substrates Node-Vorlage verwenden könnte). Polygon Labs hat investiert, um die Einrichtung so einfach wie möglich zu gestalten – ein Zitat: „Starten Sie einen hochdurchsatzfähigen ZK-gestützten Ethereum L2 so einfach wie die Bereitstellung eines Smart Contracts“. Obwohl vielleicht optimistisch, deutet dies darauf hin, dass Tools oder Skripte existieren, um die Bereitstellung zu vereinfachen. Tatsächlich gab es frühe Anwender wie Immutable (für Gaming) und OKX (Exchange Chain), die mit Polygon zusammengearbeitet haben, um CDK Chains zu starten, was auf einen ziemlich reibungslosen Prozess mit der Unterstützung des Polygon-Teams hindeutet. Das CDK enthält SDKs und Bibliotheken zur Interaktion mit der Bridge (für Einzahlungen/Abhebungen) und zur Aktivierung von AggLayer, falls gewünscht. Die Überwachung einer CDK Chain kann Polygons Block-Explorer (Polygonscan) nutzen, wenn sie ihn integrieren, oder Blockscout. Polygon ist auch bekannt für robuste SDKs für Gaming und Mobile (z. B. Unity SDKs) – diese können auf jeder Polygon-basierten Chain verwendet werden. Entwicklerunterstützung ist ein großer Schwerpunkt: Polygon veranstaltet regelmäßig Akademien, Stipendien, Hackathons, und ihr Developer Relations-Team hilft Projekten persönlich. Ein Beispiel für die Entwicklererfahrung im Unternehmen: Libre, eine mit CDK gestartete institutionelle Chain, hatte vermutlich benutzerdefinierte Anforderungen – Polygon konnte Dinge wie Identitätsmodule oder Compliance-Funktionen auf dieser Chain unterbringen. Dies zeigt, dass das CDK für spezifische Anwendungsfälle von Entwicklern mit Hilfe des Frameworks erweitert werden kann. Was Lernmaterialien angeht, so bieten Polygons Dokumentationsseite und Blog Anleitungen zur CDK-Nutzung, und da CDK im Wesentlichen die Evolution ihres zkEVM ist, können diejenigen, die mit dem Design von Polygons zkEVM vertraut sind, es schnell aufnehmen. Ein weiterer Tooling-Aspekt: Cross-Chain-Tools – da viele Polygon CDK Chains koexistieren werden, bietet Polygon den AggLayer für Messaging, fördert aber auch die Verwendung von Standard-Cross-Chain-Messaging wie LayerZero (tatsächlich integrierte Raribles Orbit Chain LayerZero für NFT-Transfers, und Polygon Chains können dies auch). So haben Entwickler Optionen, Interoperabilitäts-Plugins einfach zu integrieren. Alles in allem zielt die CDK-Entwicklererfahrung darauf ab, schlüsselfertig zu sein, um Ethereum-Level-Chains mit ZK-Sicherheit zu starten, und profitiert von Polygons jahrelanger L2-Erfahrung.

Zusammenfassend lässt sich sagen, dass sich die Entwicklererfahrung für den Start benutzerdefinierter Chains dramatisch verbessert hat: Was einst ein ganzes Team von Protokoll-Ingenieuren erforderte, kann jetzt mit geführten Frameworks und Unterstützung erledigt werden. Optimisms und Arbitrums Angebote nutzen die Vertrautheit (EVM-Äquivalenz), zkSync und Polygon bieten modernste Technologie mit zunehmender Benutzerfreundlichkeit, und alle haben wachsende Ökosysteme von Drittanbieter-Tools, um die Entwicklung zu vereinfachen (von Block-Explorern über Überwachungs-Dashboards bis hin zu DevOps-Skripten). Die Qualität der Dokumentation ist im Allgemeinen hoch – offizielle Dokumente sowie Community-Anleitungen (Medium-Artikel, QuickNode-/Alchemy-Anleitungen) decken viel ab. Es gibt immer noch eine nicht-triviale Lernkurve, um vom Smart-Contract-Entwickler zum „Rollup-Operator“ zu werden, aber es wird einfacher, da Best Practices entstehen und die Community der Rollup-Builder wächst.

Ökosystem-Unterstützung und Markteinführungsstrategien​

Eine Technologie zu entwickeln ist eine Sache; ein Ökosystem aufzubauen eine andere. Jedes dieser Frameworks wird von einer Organisation oder Community unterstützt, die durch Zuschüsse, Finanzierung, Marketing und Partnerschaftsunterstützung in Wachstum investiert. Hier vergleichen wir ihre Ökosystem-Unterstützungsstrategien – wie sie Entwickler und Projekte anziehen und wie sie diesen Projekten zum Erfolg verhelfen:

• OP Stack (Optimism) Ökosystem: Optimism hat eine robuste Ökosystemstrategie, die sich auf sein Optimism Collective und das Ethos der Finanzierung öffentlicher Güter konzentriert. Sie waren Pioniere der Retroaktiven Finanzierung öffentlicher Güter (RPGF) – die Verwendung des OP-Token-Schatzes, um Entwickler und Projekte zu belohnen, die dem Ökosystem zugutekommen. Durch mehrere RPGF-Runden hat Optimism Millionen an Finanzmitteln an Infrastrukturprojekte, Entwickler-Tools und Anwendungen auf Optimism verteilt. Jedes Projekt, das mit OP Stack baut (insbesondere wenn es mit der Superchain-Vision übereinstimmt), ist berechtigt, Zuschüsse vom Collective zu beantragen. Darüber hinaus kann die Optimism-Governance Anreizprogramme genehmigen (bereits 2022 gab es einen Airdrop und einen Governance-Fonds, den Projekte nutzen konnten, um OP-Belohnungen an Benutzer zu verteilen). Im Jahr 2024 etablierte Optimism das Superchain Revenue Sharing-Modell, bei dem jede OP Chain einen kleinen Teil der Gebühren an eine gemeinsame Kasse abführt. Dies erzeugt einen Kreislauf: Je mehr Chains (wie Base, opBNB, Worldcoins Chain usw.) genutzt werden, desto mehr öffentliche Güter finanzieren sie gemeinsam, die den OP Stack verbessern, was wiederum mehr Chains anzieht. Es ist ein Positive-Sum-Ansatz, der einzigartig für Optimism ist. Auf der Markteinführungsseite hat Optimism aktiv Partnerschaften mit großen Unternehmen geschlossen: Die Gewinnung von Coinbase zum Aufbau von Base war eine enorme Validierung des OP Stacks, und Optimism Labs bot Coinbase während dieses Prozesses technische Hilfe und Unterstützung. Ähnlich haben sie mit dem Team von Worldcoin zusammengearbeitet, und Celos Migration zu einem OP Stack L2 erfolgte in Absprache mit OP Labs. Optimism betreibt viel Entwickler-Outreach – von der Durchführung von Hackathons (oft in Kombination mit ETHGlobal-Events) bis zur Pflege eines Developer Hubs mit Tutorials. Sie investieren auch in Tools: z. B. die Finanzierung von Teams zum Aufbau alternativer Clients, Überwachungstools und die Bereitstellung eines offiziellen Faucets und einer Block-Explorer-Integration für neue Chains. Marketingtechnisch prägte Optimism den Begriff „Superchain“ und fördert aktiv die Vision vieler Chains, die sich unter einem interoperablen Dach vereinen, was Projekte angezogen hat, die Teil einer breiteren Erzählung sein wollen, anstatt einer isolierten Appchain. Es gibt auch den Reiz der Shared Liquidity: Mit dem bevorstehenden OPCraft (Superchain-Interoperabilität) können Apps auf einer OP Chain problemlos mit einer anderen interagieren, was es attraktiv macht, eine Chain zu starten, die keine Insel ist. Im Wesentlichen geht es bei OP Stacks Ökosystem-Spiel um Community und Zusammenarbeit – treten Sie der Superchain bei, erhalten Sie Zugang zu einem Pool von Benutzern (über einfaches Bridging), Finanzierung und kollektivem Branding. Sie haben sogar ein „Rollup Passport“-Konzept erstellt, bei dem Benutzer eine einheitliche Identität über OP Chains hinweg haben können. All diese Bemühungen senken die Hürde für neue Chains, Benutzer und Entwickler zu finden. Schließlich bedeutet Optimisms eigene Benutzerbasis und Reputation (als einer der Top-L2s), dass jede OP Stack Chain davon profitieren kann (Base tat dies, indem es sich beispielsweise als Teil des Optimism-Ökosystems bewarb).

• zkSync (ZK Stack/Hyperchains) Ökosystem: Matter Labs (das Team hinter zkSync) sicherte sich große Finanzierungsrunden (über 200 Millionen US-Dollar), um sein Ökosystem zu befeuern. Sie haben Fonds wie den zkSync Ecosystem Fund eingerichtet, oft in Zusammenarbeit mit VCs, um in Projekte zu investieren, die auf zkSync Era aufbauen. Speziell für den ZK Stack haben sie begonnen, das Konzept der Hyperchains in Communities zu fördern, die ihre eigene Chain benötigen. Eine Strategie ist die Ausrichtung auf bestimmte Vertikalen: zum Beispiel Gaming. zkSync hat hervorgehoben, wie ein Spielestudio seine eigene Hyperchain starten könnte, um Anpassbarkeit zu erhalten und dennoch mit Ethereum verbunden zu sein. Sie bieten wahrscheinlich den ersten Partnern enge Unterstützung (ähnlich wie Polygon bei einigen Unternehmen). Die Erwähnung in dem Zeeve-Artikel über eine „Schweizer Bank; die größte Bank der Welt“, die an ZK Stack interessiert ist, deutet darauf hin, dass Matter Labs Unternehmensanwendungsfälle umwirbt, die Privatsphäre benötigen (ZK-Beweise können Korrektheit gewährleisten, während einige Daten privat bleiben, ein großer Vorteil für Institutionen). Wenn zkSync eine große Unternehmens-Chain landet, würde dies ihre Glaubwürdigkeit stärken. Die Entwicklerunterstützung auf zkSync ist recht stark: Sie betreiben Acceleratoren (z. B. wurde ein Programm mit dem Blockchain Founders Fund angekündigt), Hackathons (oft ZK-thematische) und haben eine aktive Community auf ihrem Discord, die technische Hilfe leistet. Obwohl zkSync (Stand 2025) keinen Live-Token für Governance oder Anreize hat, gibt es Spekulationen über einen solchen, und Projekte könnten zukünftige Anreizprogramme erwarten. Matter Labs hat auch an der Bridge-Unterstützung gearbeitet: Sie haben sich mit großen Bridges wie Across, LayerZero, Wormhole zusammengetan, um sicherzustellen, dass Assets und Nachrichten problemlos zu und von zkSync und allen Hyperchains bewegt werden können. Tatsächlich integrierte Across Protocol den ZK Stack von zkSync und rühmte sich der Unterstützung über „alle wichtigen L2-Frameworks“ hinweg. Dieser Fokus auf Interoperabilität bedeutet, dass ein Projekt, das eine Hyperchain startet, problemlos mit dem Ethereum-Mainnet und anderen L2s verbunden werden kann, was entscheidend ist, um Benutzer anzuziehen (niemand möchte isoliert sein). Marketingtechnisch bewirbt zkSync den Slogan „Web3 ohne Kompromisse“ und betont, als Erster im ZK-Mainnet zu sein. Sie veröffentlichen Roadmaps (ihr Roadmap-Blog 2025), um die Begeisterung hochzuhalten. Wenn wir Ökosystemfonds betrachten: Neben direkten Matter Labs-Zuschüssen gibt es auch die Ethereum Foundation und andere ZK-fokussierte Fonds, die die zkSync-Entwicklung aufgrund der allgemeinen Bedeutung der ZK-Technologie bevorzugen. Eine weitere Strategie: zkSync ist Open Source und neutral (keine Lizenzgebühren), was Projekte anspricht, die möglicherweise davor zurückschrecken, sich an ein stärker zentralisiertes Ökosystem anzupassen. Der ZK Stack versucht, sich als die Wahl der Dezentralisierer zu positionieren – z. B. durch Hervorhebung vollständiger Dezentralisierung und ohne Stützräder, während OP Stack und andere in der Praxis immer noch eine gewisse Zentralisierung aufweisen. Die Zeit wird zeigen, ob das ankommt, aber sicherlich hat zkSync innerhalb der Ethereum-Community Unterstützer, die einen vollständig vertrauenslosen Stack wünschen. Schließlich haben Matter Labs und BitDAOs Windranger eine gemeinsame Initiative namens „ZK DAO“, die Kapital oder Anreize für die ZK Stack-Adoption bereitstellen könnte. Insgesamt sind zkSyncs Ökosystembemühungen eine Mischung aus technisch überlegener Botschaft (ZK ist die Zukunft) und dem Aufbau praktischer Brücken (sowohl im übertragenen als auch im wörtlichen Sinne) für Projekte, die an Bord kommen möchten.

• Arbitrum Orbit Ökosystem: Arbitrum Orbit erlebte nach seiner formellen Einführung Mitte 2023 einen Anstieg des Interesses. Ende 2023 wurden rund 18 Orbit Chains öffentlich bekannt gegeben, und Offchain Labs gab an, dass über 50 in Arbeit seien – was auf erhebliches Interesse hindeutet. Um dies zu fördern, verfolgte Offchain Labs einige Strategien. Erstens, Partnerschaften mit RaaS-Anbietern: Sie erkannten, dass nicht jedes Team die Rollup-Infrastruktur handhaben kann, und beauftragten daher Caldera, Conduit und AltLayer, um sie zu optimieren. Diese Partner haben oft ihre eigenen Förder- oder Anreizprogramme (manchmal von Arbitrum mitgesponsert), um Projekte anzulocken. Zum Beispiel könnte es einen Arbitrum x AltLayer-Zuschuss für Gaming-Chains geben. Zweitens bietet Offchain Labs direkte technische Unterstützung und Co-Entwicklung für Schlüsselprojekte. Der Fall der Xai Chain ist bezeichnend: Es handelt sich um einen Gaming-L3, bei dem Offchain Labs die Chain mitentwickelt und fortlaufende technische und sogar Marketingunterstützung bietet. Sie haben Xai im Grunde inkubiert, um das Potenzial von Orbit im Gaming zu demonstrieren. Ähnlich wurde Raribles RARI NFT Chain mit vielen Partnern (Gelato für Gasless, LayerZero für Cross-Chain-NFTs usw.) integriert, vermutlich unter Arbitrums Anleitung. Offchain Labs nutzt manchmal auch seine Kriegskasse (Arbitrum DAO verfügt über einen riesigen Schatz an ARB-Token), um Initiativen zu finanzieren. Obwohl die Arbitrum DAO getrennt ist, kann Offchain Labs mit ihr in Ökosystemfragen koordinieren. Wenn beispielsweise eine Orbit Chain den ARB-Token stark nutzt oder Arbitrum zugutekommt, könnte die DAO Zuschüsse beschließen. Ein direkterer Ansatz: Offchain Labs startete Arbitrum Orbit Challenge-Hackathons und Preise, um Entwickler zu ermutigen, L3s zu erstellen. Zum Marketing: Arbitrums Marke ist entwicklerorientiert, und sie bewerben Orbits Vorteile wie Stylus (schnelle, mehrsprachige Verträge) und keine 7-tägige Abhebung (mit schneller Bridging). Sie heben auch erfolgreiche Beispiele hervor: z. B. kündigte Treasure DAOs Bridgeworld eine Orbit Chain an usw. Ein weiterer Unterstützungsaspekt: Liquidität und DeFi-Integration. Arbitrum arbeitet mit Protokollen zusammen, damit Sie, wenn Sie eine Orbit Chain starten, problemlos Liquidität von Arbitrum One nutzen können (über native Bridging oder LayerZero). Je einfacher es ist, Assets und Benutzer auf Ihre neue Chain zu bringen, desto wahrscheinlicher ist Ihr Erfolg. Arbitrum hat eine sehr große, aktive Community (auf Reddit, Discord usw.), und durch die Erweiterung auf Orbit können neue Chains bestehende Arbitrum-Benutzer ansprechen (zum Beispiel könnte ein Arbitrum-Benutzer einen Airdrop auf einer neuen Orbit Chain erhalten, um sie auszuprobieren). Zusammenfassend lässt sich sagen, dass Arbitrums Ökosystemstrategie für Orbit darin besteht, ihre L2-Dominanz zu nutzen – wenn Sie einen L3 bauen, sind Sie effektiv eine Erweiterung des größten L2, sodass Sie an diesem Netzwerkeffekt teilhaben können. Offchain Labs beseitigt aktiv Hürden (technische und Liquiditätshürden) und hilft sogar direkt beim Aufbau einiger früher L3s, um Präzedenzfälle für andere zu schaffen.

• Polygon CDK (AggLayer) Ökosystem: Polygon war einer der aggressivsten in der Ökosystem- und Geschäftsentwicklung. Sie verfolgen einen mehrstufigen Ansatz:

  • Zuschüsse und Fonds: Polygon hat vor einiger Zeit einen 100-Millionen-Dollar-Ökosystemfonds eingerichtet und in Hunderte von Projekten investiert. Sie hatten auch spezifische vertikale Fonds (z. B. Polygon Gaming Fund, Polygon DeFi Fund). Für CDK Chains kündigte Polygon Anreize an, wie die Übernahme eines Teils der Kosten für den Betrieb einer Chain oder die Bereitstellung von Liquiditätsunterstützung. Die CoinLaw-Statistiken erwähnen „Mehr als 190 dApps nutzen Polygon CDK, um ihre eigenen Chains aufzubauen“ – was impliziert, dass Polygon eine riesige Pipeline von Projekten erhalten hat (wahrscheinlich viele noch in Entwicklung). Sie haben diesen Teams wahrscheinlich Zuschüsse oder Ressourcen-Sharing angeboten.
  • Onboarding von Unternehmen und Institutionen: Polygons BizDev-Team hat große Unternehmen (Starbucks, Reddit, Nike, Disney für NFTs auf Polygon POS) an Bord geholt. Jetzt mit CDK werben sie bei Unternehmen, dedizierte Chains zu starten. Z. B. Immutable (Gaming-Plattform), die sich mit CDK zusammenschließt, um Spielestudios die Möglichkeit zu geben, ihre eigenen ZK-Rollups zu starten, die mit Immutable und Polygon-Liquidität verbunden sind, Franklin Templeton startet einen Fonds auf Polygon und Walmarts Test einer Lieferkette auf einer privaten Polygon-Chain. Polygon bietet diesen Partnern erstklassigen Support: technische Beratung, Entwicklung kundenspezifischer Funktionen (Datenschutz, Compliance) und Co-Marketing. Die Einführung von Libre (von JP Morgan/Siemens), das auf Polygon CDK basiert, zeigt, wie sie Finanzinstitutionen mit speziellen Bedürfnissen bedienen.
  • Markteinführung und Interoperabilität: Polygon schafft den AggLayer als Interoperabilitäts- und Liquiditätshub, der alle Polygon Chains verbindet. Das bedeutet, wenn Sie eine CDK Chain starten, sind Sie nicht allein – Sie werden Teil von „Polygon 2.0“, einer Konstellation von Chains mit vereinheitlichter Liquidität. Sie versprechen Dinge wie Ein-Klick-Token-Transfer zwischen CDK Chains und Ethereum (über AggLayer). Sie erheben auch keine Protokollgebühren (keine Miete), was sie als Wettbewerbsvorteil gegenüber, sagen wir, Optimisms Gebührenteilung anpreisen. Polygons Marketing hebt hervor, dass der Start einer CDK Chain Ihnen „das Beste aus beiden Welten“ bieten kann: benutzerdefinierte Souveränität und Leistung plus Zugang zur großen Benutzerbasis und Entwicklerbasis von Polygon/Ethereum. Sie zitieren oft, dass Polygon (POS+zkEVM) zusammen über 30 % aller L2-Transaktionen verarbeitet hat, um potenziellen Chain-Buildern zu versichern, dass der Benutzerfluss auf Polygon riesig ist.
  • Entwicklerunterstützung: Polygon veranstaltet vielleicht die meisten Hackathons und DevRel-Events im Blockchain-Bereich. Sie haben eine dedizierte Polygon University, Online-Kurse und sponsern häufig ETHGlobal und andere Hackathons mit Herausforderungen rund um die Nutzung von CDK, zkEVM usw. So können Entwickler Preise gewinnen, indem sie Prototypen von CDK Chains oder Cross-Chain-dApps bauen. Sie pflegen auch eine starke Präsenz in Entwickler-Communities und bieten schnelle Unterstützung (der Polygon Discord hat Kanäle für technische Fragen, wo Kernentwickler antworten).
  • Community und Governance: Polygon geht mit einem neuen POL-Token und einer Community-Governance, die alle Chains umfasst, zu Polygon 2.0 über. Dies könnte bedeuten, dass Community-Treasuries oder Anreizprogramme für CDK Chains gelten. Zum Beispiel könnte es ein Polygon Ecosystem Mining-Programm geben, bei dem Liquiditäts-Mining-Belohnungen für Projekte angeboten werden, die auf neuen CDK Chains bereitgestellt werden, um die Nutzung anzukurbeln. Die Idee ist, sicherzustellen, dass neue Chains keine Geisterstädte sind.
  • Erfolgsgeschichten: Bereits mehrere CDK Chains sind live oder angekündigt: OKX’s OKB Chain (X Layer), Gnosis Pay’s Chain, Astar’s zkEVM, Palm Network migriert, GameSwift (Gaming Chain) usw. Polygon veröffentlicht diese aktiv und teilt Wissen daraus mit anderen.

Insgesamt lautet Polygons Strategie: „Wir werden alles tun, um Ihnen zum Erfolg zu verhelfen, wenn Sie auf unserem Stack aufbauen.“ Dazu gehören finanzielle Anreize, technisches Personal, Marketingpräsenz (Vorträge auf Konferenzen, Pressemitteilungen auf CoinTelegraph, wie wir gesehen haben) und die Integration in ein größeres Ökosystem. Es ist ein sehr geschäftsentwicklungsgetriebener Ansatz zusätzlich zur Basis-Entwickler-Community, der Polygons eher unternehmerischen Stil im Vergleich zu den anderen widerspiegelt.

Um die Ökosystem-Unterstützung zusammenzufassen: Alle diese Frameworks verstehen, dass das Anziehen von Entwicklern und Projekten mehr als nur Technologie erfordert – es braucht Finanzierung, Betreuung und Integration in eine größere Erzählung. Optimism fördert eine kollaborative, auf öffentliche Güter ausgerichtete Erzählung mit fairer Umsatzbeteiligung. zkSync treibt den technologischen Fortschritt voran und wird wahrscheinlich Anreize ankündigen, die mit einem zukünftigen Token verbunden sind. Arbitrum nutzt seine bestehende Dominanz und bietet Partnernetzwerke, um den Start zu erleichtern, plus möglicherweise die tiefste DeFi-Liquidität, die angezapft werden kann. Polygon geht wohl am weitesten, um den Weg für Krypto-native und Unternehmensakteure zu ebnen, indem es Chains effektiv subventioniert und gemeinsam vermarktet.

Eine vergleichende Momentaufnahme:

Wie die Tabelle zeigt, hat jedes Ökosystem seine Stärken – Optimism mit kollaborativem Ethos und Coinbases Gewicht, zkSync mit ZK-Führerschaft und Innovationsfokus, Arbitrum mit bewährter Akzeptanz und technischer Leistungsfähigkeit (Stylus), Polygon mit Unternehmensverbindungen und umfassender Unterstützung. Alle pumpen erhebliche Ressourcen in das Wachstum ihrer Communities, denn letztendlich wird der Erfolg eines Rollup-Frameworks an den Apps und Benutzern auf den damit aufgebauten Chains gemessen.

Bereitstellungen und Akzeptanz im Jahr 2025​

Werfen wir abschließend einen Blick darauf, wo diese Frameworks im Jahr 2025 in Bezug auf die reale Akzeptanz stehen – sowohl im krypto-nativen Kontext (öffentliche Netzwerke, DeFi/NFT/Gaming-Projekte) als auch im Unternehmens- oder institutionellen Bereich:

• OP Stack Akzeptanz: Der OP Stack hat das Optimism Mainnet angetrieben, das selbst einer der Top-Ethereum-L2s mit einem florierenden DeFi-Ökosystem (Uniswap, Aave usw.) und Zehntausenden täglichen Benutzern ist. In den Jahren 2023–2024 wurde der OP Stack von Coinbase für ihr Base-Netzwerk ausgewählt – Base wurde im August 2023 gestartet und integrierte schnell beliebte Apps (Coinbases eigene Wallet-Integration, die soziale App friend.tech) und erreichte eine hohe Aktivität (teilweise sogar Optimism bei Transaktionen übertreffend). Bases Erfolg bestätigte den OP Stack für viele; Base hatte 2024 800 Millionen Transaktionen und war damit die zweithöchste Chain nach Transaktionsanzahl in diesem Jahr. Eine weitere wichtige OP Stack-Bereitstellung ist opBNB – das BNB Chain-Team von Binance erstellte einen L2 mit dem OP Stack (der jedoch auf BNB Chain statt Ethereum abgewickelt wird). opBNB ging 2023 live und zeigte die Flexibilität des OP Stacks, eine Nicht-Ethereum-Abwicklung zu verwenden. Worldcoins World ID Chain ging 2023 auf dem OP Stack live (auf Ethereum abgewickelt), um seine einzigartigen biometrischen Identitätstransaktionen zu verarbeiten. Das Zora Network, eine NFT-zentrierte Chain von Zora, wurde ebenfalls auf dem OP Stack gestartet, zugeschnitten auf Anwendungsfälle der Creator Economy. Am ambitioniertesten ist vielleicht Celos Migration: Celo stimmte für den Übergang von einem unabhängigen L1 zu einem auf OP Stack basierenden Ethereum L2 – im Jahr 2025 ist diese Migration im Gange, wodurch ein ganzes bestehendes Ökosystem (Celos DeFi- und telefonorientierte Apps) in den OP Stack integriert wird. Wir haben auch kleinere Projekte wie Mode (Bybits Sidechain), Mantle (BitDAOs Chain) – tatsächlich entschied sich Mantle ebenfalls für einen modifizierten OP Stack. Und viele weitere sind gerüchteweise oder in Entwicklung, angesichts des Open-Source-Ansatzes von Optimism (jeder kann ohne Erlaubnis forken und starten). Auf Unternehmensseite haben wir nicht viel explizite OP Stack-Unternehmens-Chains gesehen (Unternehmen scheinen eher von Polygon oder kundenspezifischen Lösungen angezogen zu werden). Base wird jedoch von einem Unternehmen (Coinbase) unterstützt, und das ist bedeutsam. Die Superchain-Vision impliziert, dass sogar Unternehmens-Chains als OP Chains beitreten könnten, um von der gemeinsamen Governance zu profitieren – zum Beispiel, wenn ein Fintech eine konforme Chain starten wollte, könnte die Verwendung des OP Stacks und die Integration in die Superchain eine sofortige Konnektivität ermöglichen. Im Jahr 2025 verarbeiten OP Stack Chains (Optimism, Base, andere) kollektiv einen erheblichen Teil der L2-Aktivität, und der aggregierte Durchsatz der Superchain wird als Metrik dargestellt (Optimism veröffentlicht oft kombinierte Statistiken). Mit dem Bedrock-Upgrade und weiteren Verbesserungen erweisen sich OP Stack Chains als hochzuverlässig (Optimism hatte vernachlässigbare Ausfallzeiten). Das wichtigste Maß für die Akzeptanz: Der OP Stack ist wohl das bisher am häufigsten geforkte Rollup-Framework, angesichts von Base, BNB, Celo usw., die hochkarätig sind. Insgesamt sind ~5-10 OP Stack Chains Live-Mainnets, und viele weitere Testnets. Wenn wir Devnets und bevorstehende Starts einschließen, wächst die Zahl.

• zkSync Hyperchains Akzeptanz: Das zkSync Era Mainnet (L2) selbst wurde im März 2023 gestartet und gehört bis 2025 zu den Top-ZK-Rollups, mit ~100 Mio. $ TVL und Dutzenden von Projekten. Bemerkenswerte Apps wie Curve, Uniswap, Chainlink wurden auf zkSync bereitgestellt oder kündigten die Bereitstellung an. Was nun Hyperchains (L3 oder souveräne Chains) betrifft, so ist dies sehr innovativ. Ende 2024 startete Matter Labs ein Programm für Teams, um mit L3s auf zkSync zu experimentieren. Ein Beispiel: Der Rollup-as-a-Service-Anbieter Decentriq testete Berichten zufolge eine private Hyperchain für den Datenaustausch. Auch Blockchain Capital (VC) deutete an, mit einem L3 zu experimentieren. Es wird erwähnt, dass ein Ökosystem von über 18 Protokollen den ZK Stack für Dinge wie KI-Agenten und spezialisierte Anwendungsfälle nutzt – möglicherweise auf Testnets. Bisher (Mitte 2025) bedient noch keine große Hyperchain öffentlich Benutzer (soweit bekannt). Das Interesse ist jedoch in bestimmten Bereichen hoch: Gaming-Projekte haben Interesse an ZK-Hyperchains für schnelle Finalität und Anpassbarkeit gezeigt, und datenschutzorientierte Chains (eine Hyperchain könnte Verschlüsselung enthalten und zkProofs verwenden, um Daten zu verbergen – etwas, das ein optimistischer Rollup nicht so einfach bieten kann). Der Kommentar über eine „Schweizer Bank“ deutet darauf hin, dass vielleicht UBS oder ein Konsortium eine private Chain mit dem ZK Stack testet, wahrscheinlich angezogen von Durchsatz (~10k TPS) und Datenschutz. Wenn dies in Produktion geht, wäre es ein Flaggschiff-Unternehmensfall. Zusammenfassend lässt sich sagen, dass die Akzeptanz von zkSyncs Hyperchain im Jahr 2025 in einer frühen Pilotphase ist: Die Entwicklerinfrastruktur ist bereit (wie durch Dokumentation und einige Testbereitstellungen belegt), aber wir warten auf die ersten, die live gehen. Es ist vergleichbar mit dem Stand von Optimism Anfang 2021 – bewährte Technologie, aber gerade erst beginnende Akzeptanz. Bis Ende 2025 könnten wir ein paar Live-Hyperchains erwarten, möglicherweise eine von der Community betriebene (vielleicht eine Gaming-Hyperchain, die aus einem beliebten zkSync-Spiel hervorgegangen ist) und eine von Unternehmen betriebene. Ein weiterer Faktor: Es wird auch über Layer3s auf zkSync Era gesprochen – im Wesentlichen permissionless L3s, auf denen jeder eine App-Chain auf zkSyncs L2 bereitstellen kann. Matter Labs hat die Verträge dafür erstellt, sodass wir benutzergesteuerte L3s sehen könnten (wie jemand, der einen Mini-Rollup für seine spezifische App startet), was als Akzeptanz des ZK Stacks zählt.

• Arbitrum Orbit Akzeptanz: Arbitrum Orbit erlebte nach seiner formellen Einführung Mitte 2023 einen Anstieg des Interesses. Ende 2023 wurden rund 18 Orbit Chains öffentlich bekannt gegeben, und Offchain Labs gab an, dass über 50 in Arbeit seien. Im Jahr 2025 sind einige der prominentesten:

  • Xai Chain: Ein Gaming-fokussierter L3, jetzt live (Mainnet Ende 2023 gestartet). Es wird von Spieleentwicklern (wie dem Ex Populus Studio) verwendet und hatte einen Token-Launch über Binance Launchpad. Dies deutet auf eine gute Akzeptanz hin (die Beteiligung von Binance Launchpad deutet auf großes Benutzerinteresse hin). Xai verwendet den AnyTrust-Modus (für hohe TPS).
  • Rari Chain: Ein NFT-zentrierter L3 von Rarible. Mainnet im Januar 2024 gestartet. Es konzentriert sich auf NFT-Marktplätze mit Funktionen wie Kreditkartenzahlungen für Gas (über Stripe) und gaslose Listings. Diese Chain ist ein gutes Beispiel für die Anpassung der Benutzererfahrung (wie erwähnt, bietet Gelato gaslose Transaktionen usw. auf Rari Chain).
  • Frame: Ein Creator-fokussierter L2 (obwohl als L2 bezeichnet, ist es wahrscheinlich eine Orbit Chain, die auf Ethereum oder Arbitrum abgewickelt wird). Es wurde Anfang 2024 nach einer Finanzierungsrunde gestartet.
  • EduChain (von Camelot/GMX-Communities): Der Zeeve-Artikel erwähnt eine EDU-Chain mit einer großen Anzahl von Projekten – möglicherweise ein Ökosystem für On-Chain-Bildung und KI, das auf Orbit basiert.
  • Ape Chain: Nicht explizit oben erwähnt, aber der Kontext von Zeeve deutet darauf hin, dass eine „Ape Chain“ (vielleicht Yuga Labs oder ApeCoin DAO Chain) existiert, mit 9,86 Mio. $ TVL und APE für Gas verwendet. Das könnte eine Orbit Chain im ApeCoin-Ökosystem sein (dies wäre angesichts des Einflusses von Yuga bei NFTs bedeutsam).
  • Andere Gaming-Chains: z. B. wurde Comeths „Muster“ L3 angekündigt (eine Gaming-Plattform, die mit AltLayer zusammenarbeitet). Syndr Chain für ein Optionshandelsprotokoll ist auf Testnet als Orbit L3. Meliora (DeFi-Kreditprotokoll) baut einen Orbit L3.
  • Viele davon befinden sich in frühen Stadien (Testnet oder kürzlich gestartetes Mainnet), aber insgesamt zeigen sie, dass Orbit bei spezialisierten dApps, die eine gemeinsame L2-Umgebung entwachsen sind oder ihre eigene Governance wollten, an Akzeptanz gewinnt.
  • Im Unternehmensbereich: hier weniger Aufsehen. Arbitrum ist eher für DeFi-/Gaming-Akzeptanz bekannt. Die Technologie könnte jedoch für Unternehmen attraktiv sein, wenn sie eine Ethereum-gesicherte Chain mit flexiblem Vertrauen (über AnyTrust) wünschen. Es ist möglich, dass einige Unternehmen Arbitrum-Technologie stillschweigend für eine private Chain verwendet haben, dies aber nicht veröffentlicht wurde.
  • Nach Zahlen könnte Arbitrum Orbits größter Nutzer bisher Ape Chain (falls bestätigt) sein, mit ~10 Mio. $TVL und 17 Protokollen darauf (laut Zeeve). Eine weitere ist **EDU Chain** mit 1,35 Mio.$ TVL und über 30 Projekten.
  • Arbitrum One und Nova selbst sind Teil dieser Erzählung – die Tatsache, dass Orbit Chains auf Nova (ultra-billige Social-/Gaming-Chain) oder One abgewickelt werden können, bedeutet, dass die Akzeptanz von Orbit auch die Aktivität in diesen Netzwerken fördert. Nova wurde für Reddit-Punkte usw. genutzt. Wenn Orbit Chains in Novas AnyTrust-Komitee integriert werden, wächst Novas Rolle.
  • Zusammenfassend lässt sich sagen, dass Arbitrum Orbit über die Theorie hinausgegangen ist: Dutzende realer Projekte bauen darauf auf und konzentrieren sich auf Gaming, Social und benutzerdefiniertes DeFi. Arbitrums Ansatz, reale Anwendungsfälle (wie Xai, Rari) zu zeigen, hat sich ausgezahlt, und wir können davon ausgehen, dass bis Ende 2025 möglicherweise über 50 Orbit Chains live sein werden, einige davon mit erheblichen Benutzerbasen (insbesondere wenn eine der Gaming-Chains eine beliebte Spielveröffentlichung erreicht).

• Polygon CDK Akzeptanz: Polygon kündigte CDK erst in der zweiten Hälfte des Jahres 2023 an, baut aber auf dem Erfolg der bestehenden Netzwerke von Polygon auf. Bereits Polygon zkEVM (Mainnet Beta) selbst ist im Wesentlichen eine CDK Chain, die von Polygon Labs betrieben wird. Es hat eine anständige Akzeptanz erfahren (über 50 Mio. $ TVL, große Protokolle bereitgestellt). Darüber hinaus sind zahlreiche unabhängige Chains in Bewegung:

  • Immutable X (eine große Web3-Gaming-Plattform) erklärte ihre Unterstützung für Polygon CDK, um Spielestudios die Möglichkeit zu geben, ihre eigenen ZK-Rollups zu starten, die mit Immutable und Polygon-Liquidität verbunden sind. Diese Allianz bedeutet möglicherweise Dutzende von Spielen, die CDK über Immutable im Jahr 2025 nutzen.
  • OKX (Börse) startete OKB Chain (auch bekannt als X Layer) mit Polygon CDK Ende 2024. Eine Börsen-Chain kann viele Transaktionen antreiben (CEX-zu-DEX-Flüsse usw.). OKX wählte Polygon vermutlich wegen der Skalierbarkeit und weil viele ihrer Benutzer bereits Polygon nutzen.
  • Canto (DeFi-Chain) und Astar (Polkadot-Sidechain) werden als Migration zu oder Integration mit Polygon CDK erwähnt. Cantos Umzug von Cosmos zur Polygon-Schicht zeigt die Attraktivität, Sicherheit mit Ethereum über Polygons ZK zu teilen.
  • Gnosis Pay: startete die Gnosis Card Chain mit CDK – es ist eine Chain, die schnelle Stablecoin-Zahlungen in Verbindung mit einer Visa-Karte ermöglicht. Dies ist live und eine innovative Fintech-Anwendung.
  • Palm Network: eine auf NFTs spezialisierte Chain, ursprünglich auf Ethereum, wechselt zu Polygon CDK (Palm wurde von ConsenSys für NFTs mit DC Comics usw. mitbegründet).
  • dYdX: Dies ist interessant – dYdX baute seine eigene Cosmos-Chain, aber Zevees Informationen listen dYdX unter AggLayer CDK Chains auf. Wenn dYdX stattdessen Polygon in Betracht ziehen würde, wäre das riesig (obwohl dYdX V4 nach bekannten Informationen Cosmos-basiert ist; vielleicht planen sie Cross-Chain oder eine zukünftige Umstellung).
  • Nubank: eine der größten digitalen Banken Brasiliens, erscheint in Zevees Liste. Nubank hatte zuvor einen Token auf Polygon gestartet; eine CDK Chain für ihre Belohnungen oder ein CBDC-ähnliches Programm könnte getestet werden.
  • Wirex, IDEX, GameSwift, Aavegotchi, Powerloom, Manta… diese Namen in Zevees Liste zeigen, wie Ökosystem-übergreifend die CDK-Reichweite ist: z. B. könnte Manta (ein Polkadot-Datenschutzprojekt) CDK für eine Ethereum-orientierte ZK-Lösung verwenden; Aavegotchi (ein NFT-Spiel, ursprünglich auf Polygon POS) könnte seine eigene Chain für die Spiel-Logik erhalten.
  • Die Celestia-Integration Anfang 2024 wird wahrscheinlich Projekte anziehen, die die Polygon-Technologie, aber mit Celestia DA wünschen – möglicherweise werden einige Cosmos-Projekte (da Celestia Cosmos-basiert ist) Polygon CDK für die Ausführung und Celestia für DA wählen.
  • Unternehmen: Polygon hat ein dediziertes Unternehmens-Team. Abgesehen von den erwähnten (Stripe für Stablecoins, Franklin Templeton-Fonds auf Polygon, Länderregierungen, die Briefmarken prägen usw.), können sie mit CDK Unternehmen ihre eigene Chain mit benutzerdefinierten Regeln versprechen. Wir könnten Piloten wie „Polygon Siemens Chain“ oder Regierungs-Chains entstehen sehen, obwohl diese oft privat beginnen.
  • Polygons Ansatz, Chain-agnostisch zu sein (sie unterstützen jetzt sogar einen „OP Stack-Modus“ im CDK laut Zeeve!) und keine Miete zu verlangen, hat zu einer schnellen Integration geführt – sie behaupten, dass über 190 Projekte CDK bis Q1 2025 nutzen oder in Betracht ziehen. Wenn auch nur ein Viertel davon live geht, wird Polygon ein expansives Netzwerk von Chains haben. Sie sehen sich nicht nur als eine Chain, sondern als ein Ökosystem vieler Chains (Polygon 2.0), möglicherweise das größte solche Netzwerk, wenn erfolgreich.
  • Nach Zahlen: Anfang 2025 sind laut der AggLayer-Website über 21 Chains entweder im Mainnet oder Testnet mit CDK in Betrieb. Dies sollte sich im Laufe des Jahres 2025 beschleunigen, da weitere migrieren oder starten.
  • Wir können einige hochkarätige Starts erwarten, z. B. eine Reddit-Chain (Reddits Avatare auf Polygon POS waren riesig; ein dedizierter Polygon L2 für Reddit könnte entstehen). Auch wenn Zentralbank-Digitalwährungen (CBDCs) oder Regierungsprojekte eine Skalierungslösung wählen, ist Polygon oft in diesen Gesprächen – eine CDK Chain könnte ihre Wahl für einen permissioned L2 mit ZK-Beweisen sein.

Zusammenfassend lässt sich sagen, dass der Akzeptanzstatus 2025: OP Stack und Arbitrum Orbit verfügen über mehrere Live-Chains mit echten Benutzern und TVL, zkSyncs Hyperchains stehen kurz vor dem Durchbruch mit starken Testpiloten, und Polygon CDK hat viele in der Pipeline und einige Live-Erfolge sowohl im Krypto- als auch im Unternehmensbereich. Der Bereich entwickelt sich rasant, und Projekte prüfen diese Frameworks oft sorgfältig, bevor sie sich entscheiden. Es ist auch kein Nullsummenspiel – z. B. könnte eine App eine OP Stack Chain und eine Polygon CDK Chain für verschiedene Regionen oder Zwecke verwenden. Die modulare Blockchain-Zukunft beinhaltet wahrscheinlich Interoperabilität zwischen all diesen Frameworks. Es ist bemerkenswert, dass Bemühungen wie LayerZero und Bridge-Aggregatoren jetzt sicherstellen, dass Assets relativ frei zwischen Optimism, Arbitrum, Polygon, zkSync usw. bewegt werden können, sodass Benutzer möglicherweise nicht einmal merken, auf welchem Stack eine Chain unter der Haube aufgebaut ist.

Fazit​

Rollups-as-a-Service im Jahr 2025 bietet eine reichhaltige Auswahl an Optionen. OP Stack bietet ein kampferprobtes Optimistic Rollup-Framework mit Ethereum-Ausrichtung und der Unterstützung einer kollaborativen Superchain-Community. ZK Stack (Hyperchains) liefert modernste Zero-Knowledge-Technologie mit modularen Gültigkeits- und Datenoptionen, die auf massive Skalierbarkeit und neue Anwendungsfälle wie private oder Layer-3-Chains abzielen. Arbitrum Orbit erweitert eine hochoptimierte Optimistic Rollup-Architektur für Entwickler, mit Flexibilität bei der Datenverfügbarkeit und der spannenden Ergänzung von Stylus für mehrsprachige Smart Contracts. Polygon CDK ermöglicht Projekten den Start von zkEVM-Chains mit Out-of-the-Box-Interoperabilität (AggLayer) und der vollen Unterstützung von Polygons Ökosystem und Unternehmensbeziehungen. zkSync Hyperchains (über ZK Stack) versprechen, Web3 in großem Maßstab zu ermöglichen – mehrere Hyperchains, die alle durch Ethereum gesichert sind, jeweils für ihren Bereich optimiert (sei es Gaming, DeFi oder Social), mit nahtloser Konnektivität durch zkSyncs Elastic Framework.

Beim Vergleich der Datenverfügbarkeit haben wir gesehen, dass alle Frameworks modulare DA nutzen – Ethereum für Sicherheit und neuere Lösungen wie Celestia, EigenDA oder Komitees für den Durchsatz. Sequenzer-Designs sind anfänglich zentralisiert, bewegen sich aber in Richtung Dezentralisierung: Optimism und Arbitrum bieten L1-Fallback-Warteschlangen und ermöglichen Multi-Sequenzer- oder permissionless Validatoren-Modelle, während Polygon und zkSync die Bereitstellung benutzerdefinierter Konsens für Chains ermöglichen, die dies wünschen. Gebührenmodelle unterscheiden sich hauptsächlich in der Ökosystemphilosophie – Optimisms Umsatzbeteiligung vs. die eigenständigen Ökonomien der anderen – aber alle erlauben benutzerdefinierte Token und zielen darauf ab, die Benutzerkosten durch die Nutzung billigerer DA und schneller Finalität (insbesondere ZK-Chains) zu minimieren.

In Bezug auf die Ökosystem-Unterstützung fördert Optimism ein Kollektiv, in dem jede Chain zu gemeinsamen Zielen (Finanzierung öffentlicher Güter) beiträgt und von gemeinsamen Upgrades profitiert. Arbitrum nutzt seine florierende Community und Liquidität, hilft Projekten aktiv beim Start von Orbit Chains und integriert sie in seinen DeFi-Hub. Polygon setzt alle Ressourcen ein, um sowohl Krypto-Projekte als auch Unternehmen zu umwerben, bietet vielleicht die praktischste Unterstützung und verfügt über ein umfangreiches Netzwerk von Partnerschaften und Fonds. Matter Labs (zkSync) treibt Innovationen voran und spricht diejenigen an, die die neueste ZK-Technologie wünschen, und obwohl seine Anreizprogramme weniger öffentlich strukturiert sind (bis zur Einführung eines Tokens), verfügt es über erhebliche Finanzmittel und eine starke Anziehungskraft für ZK-orientierte Entwickler.

Aus Entwicklersicht ist der Start eines Rollups im Jahr 2025 zugänglicher denn je. Ob die Priorität EVM-Äquivalenz und Einfachheit (OP Stack, Arbitrum) oder maximale Leistung und zukunftssichere Technologie (ZK Stack, Polygon CDK) ist, die Tools und Dokumentation sind vorhanden. Sogar Überwachungs- und Entwickler-Tools wurden erweitert, um diese benutzerdefinierten Chains zu unterstützen – zum Beispiel unterstützen Alchemie und QuickNodes RaaS-Plattformen Optimism-, Arbitrum- und zkSync-Stacks Out-of-the-Box. Dies bedeutet, dass Teams sich auf ihre Anwendung konzentrieren und einen Großteil der schweren Arbeit diesen Frameworks überlassen können.

Betrachtet man die öffentliche und unternehmerische Akzeptanz, so ist klar, dass modulare Rollups von experimentell zu Mainstream übergehen. Wir haben globale Marken wie Coinbase, Binance und OKX, die ihre eigenen Chains betreiben, große DeFi-Protokolle wie Uniswap, die auf mehrere L2s und möglicherweise ihre eigenen Rollups expandieren, und sogar Regierungen und Banken, die diese Technologien erforschen. Der Wettbewerb (und die Zusammenarbeit) zwischen OP Stack, ZK Stack, Orbit, CDK usw. treibt schnelle Innovationen voran – was letztendlich Ethereum zugutekommt, indem es durch maßgeschneiderte Rollups auf Millionen neuer Benutzer skaliert wird.

Jedes Framework hat sein einzigartiges Wertversprechen:

• OP Stack: Einfacher Einstieg in L2, Shared Superchain-Netzwerkeffekte und eine Philosophie von „Impact = Profit“ durch öffentliche Güter.
• ZK Stack: Endgültige Skalierbarkeit mit ZK-Integrität, Flexibilität im Design (L2 oder L3, Rollup oder Validium) und Verhinderung von Liquiditätsfragmentierung durch das Elastic Chain-Modell.
• Arbitrum Orbit: Bewährte Technologie (Arbitrum One hatte nie einen größeren Ausfall), hohe Leistung (Nitro + Stylus) und die Möglichkeit, Vertrauensannahmen (volle Rollup-Sicherheit oder schnelleres AnyTrust) für verschiedene Bedürfnisse anzupassen.
• Polygon CDK: Schlüsselfertige ZK-Rollups, unterstützt von einem der größten Ökosysteme, mit sofortiger Konnektivität zu Polygon/Ethereum-Assets und dem Versprechen zukünftiger „vereinheitlichter Liquidität“ über AggLayer – effektiv ein Launchpad nicht nur für eine Chain, sondern für eine ganze Ökonomie auf dieser Chain.
• zkSync Hyperchains: Eine Vision von Layer-3-Skalierbarkeit, bei der selbst kleine Apps ihre eigene, durch Ethereum gesicherte Chain mit minimalem Overhead haben können, was Web2-Niveau-Leistung in einer Web3-Umgebung ermöglicht.

Mitte 2025 sehen wir, wie sich das Multi-Chain-Modulare-Ökosystem materialisiert: Dutzende von App-spezifischen oder Sektor-spezifischen Chains koexistieren, viele davon mit diesen Stacks aufgebaut. L2Beat und ähnliche Websites verfolgen jetzt nicht nur L2s, sondern auch L3s und benutzerdefinierte Chains, von denen viele OP Stack, Orbit, CDK oder ZK Stack verwenden. Interoperabilitätsstandards werden entwickelt, damit Chains, egal ob sie Optimism- oder Polygon-Technologie verwenden, miteinander kommunizieren können (Projekte wie Hyperlane, LayerZero und sogar die Zusammenarbeit von OP und Polygon bei Shared Sequencing).

Zusammenfassend lässt sich sagen, dass Rollups-as-a-Service im Jahr 2025 ausgereift ist und eine wettbewerbsintensive Landschaft mit OP Stack, ZK Stack, Arbitrum Orbit, Polygon CDK und zkSync Hyperchains bietet, die jeweils robuste, modulare Blockchain-Frameworks anbieten. Sie unterscheiden sich im technischen Ansatz (Optimistic vs. ZK), zielen aber alle darauf ab, Entwicklern die Möglichkeit zu geben, skalierbare, sichere Chains zu starten, die auf ihre Bedürfnisse zugeschnitten sind. Die Wahl des Stacks kann von den spezifischen Prioritäten eines Projekts abhängen – EVM-Kompatibilität, Finalitätsgeschwindigkeit, Anpassung, Community-Ausrichtung usw. – wie oben beschrieben. Die gute Nachricht ist, dass es keinen Mangel an Optionen oder Unterstützung gibt. Ethereums Rollup-zentrierte Roadmap wird durch diese Frameworks realisiert und läutet eine Ära ein, in der der Start einer neuen Chain keine monumentale Leistung mehr ist, sondern eine strategische Entscheidung, ähnlich der Wahl eines Cloud-Anbieters oder Technologie-Stacks in Web2. Die Frameworks werden sich weiterentwickeln (z. B. erwarten wir mehr Konvergenz, wie OP Stack, das ZK-Beweise übernimmt, Polygons AggLayer, das sich mit Nicht-Polygon-Chains verbindet usw.), aber schon jetzt stellen sie gemeinsam sicher, dass Ethereums Skalierbarkeit und Ökosystemwachstum nur durch die Vorstellungskraft und nicht durch die Infrastruktur begrenzt sind.

Quellen:

• Optimism OP Stack – Dokumentation und Mirror-Beiträge
• zkSync ZK Stack – zkSync-Dokumente und Matter Labs-Beiträge
• Arbitrum Orbit – Arbitrum-Dokumente, Offchain Labs-Ankündigungen
• Polygon CDK – Polygon Tech-Dokumente, CoinTelegraph-Bericht
• Allgemeiner Vergleich – QuickNode Guides (März 2025), Zeeve und andere für Ökosystem-Statistiken, plus verschiedene Projektblogs wie oben zitiert.

1. Überblick über die TEE-Technologie​

Definition und Architektur: Eine Trusted Execution Environment (TEE) ist ein sicherer Bereich eines Prozessors, der den darin geladenen Code und die Daten im Hinblick auf Vertraulichkeit und Integrität schützt. In der Praxis fungiert eine TEE als isolierte „Enklave“ innerhalb der CPU – eine Art Black Box, in der sensible Berechnungen geschützt vom Rest des Systems ausgeführt werden können. Code, der innerhalb einer TEE-Enklave ausgeführt wird, ist so geschützt, dass selbst ein kompromittiertes Betriebssystem oder ein Hypervisor die Daten oder den Code der Enklave nicht lesen oder manipulieren kann. Die wichtigsten von TEEs bereitgestellten Sicherheitseigenschaften umfassen:

• Isolierung: Der Speicher der Enklave ist von anderen Prozessen und sogar vom Betriebssystemkern isoliert. Selbst wenn ein Angreifer volle Administratorrechte auf der Maschine erhält, kann er den Speicher der Enklave nicht direkt inspizieren oder modifizieren.
• Integrität: Die Hardware stellt sicher, dass Code, der in der TEE ausgeführt wird, nicht durch externe Angriffe verändert werden kann. Jede Manipulation des Enklaven-Codes oder des Laufzeitstatus wird erkannt, was kompromittierte Ergebnisse verhindert.
• Vertraulichkeit: Daten innerhalb der Enklave bleiben im Speicher verschlüsselt und werden nur für die Verwendung innerhalb der CPU entschlüsselt, sodass geheime Daten der Außenwelt nicht im Klartext zugänglich sind.
• Remote Attestation: Die TEE kann kryptografische Beweise (Attestierungen) erstellen, um eine entfernte Partei davon zu überzeugen, dass sie echt ist und dass spezifischer vertrauenswürdiger Code darin ausgeführt wird. Dies bedeutet, dass Benutzer überprüfen können, ob sich eine Enklave in einem vertrauenswürdigen Zustand befindet (z. B. Ausführung des erwarteten Codes auf echter Hardware), bevor sie sie mit geheimen Daten versorgen.

Konzeptionelles Diagramm einer Trusted Execution Environment als sichere Enklave „Black Box“ für die Ausführung von Smart Contracts. Verschlüsselte Eingaben (Daten und Vertragscode) werden innerhalb der sicheren Enklave entschlüsselt und verarbeitet, und nur verschlüsselte Ergebnisse verlassen die Enklave. Dies stellt sicher, dass sensible Vertragsdaten für jeden außerhalb der TEE vertraulich bleiben.

Unter der Haube werden TEEs durch hardwarebasierte Speicherverschlüsselung und Zugriffskontrolle in der CPU ermöglicht. Wenn beispielsweise eine TEE-Enklave erstellt wird, weist die CPU ihr einen geschützten Speicherbereich zu und verwendet dedizierte Schlüssel (die in die Hardware eingebrannt sind oder von einem sicheren Koprozessor verwaltet werden), um Daten on-the-fly zu verschlüsseln/entschlüsseln. Jeder Versuch von externer Software, den Enklavenspeicher zu lesen, liefert nur verschlüsselte Bytes. Dieser einzigartige Schutz auf CPU-Ebene ermöglicht es sogar Code auf Benutzerebene, private Speicherbereiche (Enklaven) zu definieren, die privilegierte Malware oder sogar ein böswilliger Systemadministrator nicht ausspähen oder modifizieren kann. Im Wesentlichen bietet eine TEE ein höheres Sicherheitsniveau für Anwendungen als die normale Betriebsumgebung, während sie gleichzeitig flexibler ist als dedizierte Sicherheitselemente oder Hardware-Sicherheitsmodule.

Wichtige Hardware-Implementierungen: Es existieren mehrere Hardware-TEE-Technologien, jede mit unterschiedlichen Architekturen, aber dem ähnlichen Ziel, eine sichere Enklave innerhalb des Systems zu schaffen:

• Intel SGX (Software Guard Extensions): Intel SGX ist eine der am weitesten verbreiteten TEE-Implementierungen. Sie ermöglicht es Anwendungen, Enklaven auf Prozessebene zu erstellen, wobei Speicherverschlüsselung und Zugriffskontrollen von der CPU erzwungen werden. Entwickler müssen ihren Code in „vertrauenswürdigen“ Code (innerhalb der Enklave) und „nicht vertrauenswürdigen“ Code (normale Welt) aufteilen und spezielle Anweisungen (ECALL/OCALL) verwenden, um Daten in die Enklave hinein und aus ihr heraus zu transferieren. SGX bietet eine starke Isolierung für Enklaven und unterstützt Remote Attestation über Intels Attestation Service (IAS). Viele Blockchain-Projekte – insbesondere Secret Network und Oasis Network – haben datenschutzfreundliche Smart-Contract-Funktionalitäten auf SGX-Enklaven aufgebaut. Das Design von SGX auf komplexen x86-Architekturen hat jedoch zu einigen Schwachstellen geführt (siehe §4), und die Attestierung von Intel führt eine zentralisierte Vertrauensabhängigkeit ein.

• ARM TrustZone: TrustZone verfolgt einen anderen Ansatz, indem es die gesamte Ausführungsumgebung des Prozessors in zwei Welten unterteilt: eine Secure World und eine Normal World. Sensibler Code läuft in der Secure World, die Zugriff auf bestimmte geschützte Speicherbereiche und Peripheriegeräte hat, während die Normal World das reguläre Betriebssystem und die Anwendungen ausführt. Wechsel zwischen den Welten werden von der CPU gesteuert. TrustZone wird häufig in Mobil- und IoT-Geräten für Dinge wie sichere Benutzeroberflächen, Zahlungsabwicklung oder digitales Rechtemanagement verwendet. In einem Blockchain-Kontext könnte TrustZone mobile-first Web3-Anwendungen ermöglichen, indem private Schlüssel oder sensible Logik in der sicheren Enklave des Telefons ausgeführt werden. TrustZone-Enklaven sind jedoch typischerweise grobkörniger (auf Betriebssystem- oder VM-Ebene) und werden in aktuellen Web3-Projekten nicht so häufig eingesetzt wie SGX.

• AMD SEV (Secure Encrypted Virtualization): Die SEV-Technologie von AMD zielt auf virtualisierte Umgebungen ab. Anstatt Enklaven auf Anwendungsebene zu erfordern, kann SEV den Speicher ganzer virtueller Maschinen verschlüsseln. Es verwendet einen eingebetteten Sicherheitsprozessor zur Verwaltung kryptografischer Schlüssel und zur Durchführung der Speicherverschlüsselung, sodass der Speicher einer VM selbst für den hostenden Hypervisor vertraulich bleibt. Dies macht SEV gut geeignet für Cloud- oder Server-Anwendungsfälle: Beispielsweise könnte ein Blockchain-Knoten oder ein Off-Chain-Worker innerhalb einer vollständig verschlüsselten VM laufen und seine Daten vor einem böswilligen Cloud-Anbieter schützen. Das Design von SEV bedeutet weniger Aufwand für Entwickler bei der Partitionierung von Code (man kann eine bestehende Anwendung oder sogar ein ganzes Betriebssystem in einer geschützten VM ausführen). Neuere Iterationen wie SEV-SNP fügen Funktionen wie Manipulationserkennung hinzu und ermöglichen es VM-Besitzern, ihre VMs zu attestieren, ohne auf einen zentralisierten Dienst angewiesen zu sein. SEV ist für den TEE-Einsatz in Cloud-basierter Blockchain-Infrastruktur hochrelevant.

Andere aufkommende oder Nischen-TEE-Implementierungen umfassen Intel TDX (Trust Domain Extensions für enklavenähnlichen Schutz in VMs auf neueren Intel-Chips), Open-Source-TEEs wie Keystone (RISC-V) und Secure-Enclave-Chips in Mobilgeräten (wie die Secure Enclave von Apple, obwohl sie normalerweise nicht für beliebigen Code offen ist). Jede TEE bringt ihr eigenes Entwicklungsmodell und ihre eigenen Vertrauensannahmen mit, aber alle teilen die Kernidee der hardware-isolierten sicheren Ausführung.

Privatsphäre-wahrende Smart Contracts​

Eine der bekanntesten Anwendungen von TEEs in Web3 ist die Ermöglichung von vertraulichen Smart Contracts – Programmen, die auf einer Blockchain laufen, aber private Daten sicher verarbeiten können. Blockchains wie Ethereum sind standardmäßig transparent: Alle Transaktionsdaten und der Vertragsstatus sind öffentlich. Diese Transparenz ist problematisch für Anwendungsfälle, die Vertraulichkeit erfordern (z. B. private Finanzgeschäfte, geheime Abstimmungen, Verarbeitung personenbezogener Daten). TEEs bieten eine Lösung, indem sie als privatsphärenschonende Rechenenklave fungieren, die mit der Blockchain verbunden ist.

In einem TEE-gestützten Smart-Contract-System können Transaktionseingaben an eine sichere Enklave auf einem Validator- oder Worker-Node gesendet werden. Dort werden sie innerhalb der Enklave verarbeitet, wo sie für die Außenwelt verschlüsselt bleiben. Anschließend kann die Enklave ein verschlüsseltes oder gehashtes Ergebnis zurück an die Chain ausgeben. Nur autorisierte Parteien mit dem Entschlüsselungsschlüssel (oder die Vertragslogik selbst) können auf das Klartextergebnis zugreifen. Zum Beispiel verwendet das Secret Network Intel SGX in seinen Konsens-Nodes, um CosmWasm-Smart-Contracts mit verschlüsselten Eingaben auszuführen. So können Dinge wie Kontostände, Transaktionsbeträge oder der Vertragsstatus vor der Öffentlichkeit verborgen bleiben, während sie dennoch für Berechnungen nutzbar sind. Dies hat Secret DeFi-Anwendungen ermöglicht – z. B. private Token-Swaps, bei denen die Beträge vertraulich sind, oder geheime Auktionen, bei denen Gebote verschlüsselt und erst nach Auktionsende offengelegt werden. Ein weiteres Beispiel ist das Parcel von Oasis Network und das vertrauliche ParaTime, die es ermöglichen, Daten zu tokenisieren und in Smart Contracts unter Vertraulichkeitsbeschränkungen zu nutzen, was Anwendungsfälle wie Kredit-Scoring oder medizinische Daten auf der Blockchain unter Einhaltung des Datenschutzes ermöglicht.

Privatsphäre-wahrende Smart Contracts via TEEs sind attraktiv für die Einführung von Blockchain in Unternehmen und Institutionen. Organisationen können Smart Contracts nutzen und gleichzeitig sensible Geschäftslogik und Daten vertraulich behandeln. Beispielsweise könnte eine Bank einen TEE-fähigen Vertrag verwenden, um Kreditanträge oder Handelsabwicklungen zu bearbeiten, ohne Kundendaten on-chain preiszugeben, und dennoch von der Transparenz und Integrität der Blockchain-Verifizierung profitieren. Diese Fähigkeit adressiert direkt regulatorische Datenschutzanforderungen (wie die DSGVO oder HIPAA) und ermöglicht die konforme Nutzung von Blockchain im Gesundheitswesen, im Finanzwesen und in anderen sensiblen Branchen. Tatsächlich erleichtern TEEs die Einhaltung von Datenschutzgesetzen, indem sie sicherstellen, dass personenbezogene Daten innerhalb einer Enklave verarbeitet werden können und nur verschlüsselte Ausgaben nach außen gelangen, was die Regulierungsbehörden davon überzeugt, dass die Daten geschützt sind.

Über die Vertraulichkeit hinaus helfen TEEs auch dabei, die Fairness in Smart Contracts zu erzwingen. Beispielsweise könnte eine dezentrale Börse ihre Matching-Engine innerhalb einer TEE ausführen, um zu verhindern, dass Miner oder Validatoren ausstehende Aufträge sehen und Transaktionen unzulässig durch Front-Running manipulieren. Zusammenfassend lässt sich sagen, dass TEEs eine dringend benötigte Privatsphäre-Schicht in Web3 bringen und Anwendungen wie vertrauliches DeFi, private Abstimmungen/Governance und Unternehmensverträge freischalten, die zuvor auf öffentlichen Ledgern nicht machbar waren.

Skalierbarkeit und Off-Chain-Berechnung​

Eine weitere kritische Rolle für TEEs ist die Verbesserung der Blockchain-Skalierbarkeit durch das Auslagern schwerer Berechnungen off-chain in eine sichere Umgebung. Blockchains haben aufgrund von Leistungsgrenzen und Kosten für die On-Chain-Ausführung Schwierigkeiten mit komplexen oder rechenintensiven Aufgaben. TEE-fähige Off-Chain-Berechnungen ermöglichen es, diese Aufgaben außerhalb der Haupt-Chain zu erledigen (wodurch kein Block-Gas verbraucht oder der On-Chain-Durchsatz verlangsamt wird), während gleichzeitig Vertrauensgarantien über die Korrektheit der Ergebnisse erhalten bleiben. Effektiv kann eine TEE als verifizierbarer Off-Chain-Rechenbeschleuniger für Web3 dienen.

Beispielsweise nutzt die Plattform iExec TEEs, um einen dezentralen Cloud-Computing-Marktplatz zu schaffen, auf dem Entwickler Berechnungen off-chain ausführen können und Ergebnisse erhalten, denen die Blockchain vertraut. Eine dApp kann eine Berechnung anfordern (z. B. eine komplexe KI-Modell-Inferenz oder eine Big-Data-Analyse), die von iExec-Worker-Nodes durchgeführt werden soll. Diese Worker-Nodes führen die Aufgabe innerhalb einer SGX-Enklave aus und produzieren ein Ergebnis zusammen mit einem Attest (Nachweis), dass der korrekte Code in einer echten Enklave lief. Das Ergebnis wird dann on-chain zurückgegeben, und der Smart Contract kann das Attest der Enklave verifizieren, bevor er die Ausgabe akzeptiert. Diese Architektur ermöglicht es, schwere Arbeitslasten off-chain zu bewältigen, ohne auf Vertrauen zu verzichten, was den Durchsatz effektiv steigert. Die Integration des iExec Orchestrators mit Chainlink demonstriert dies: Ein Chainlink-Oracle ruft externe Daten ab, übergibt dann eine komplexe Berechnung an die TEE-Worker von iExec (z. B. Aggregieren oder Bewerten der Daten), und schließlich wird das sichere Ergebnis on-chain geliefert. Anwendungsfälle umfassen Dinge wie dezentrale Versicherungsberechnungen (wie iExec gezeigt hat), bei denen eine große Menge an Datenverarbeitung kostengünstig off-chain durchgeführt werden kann, wobei nur das Endergebnis auf die Blockchain gelangt.

TEE-basierte Off-Chain-Berechnungen bilden auch die Grundlage für einige Layer-2-Skalierungslösungen. Der frühe Prototyp von Oasis Labs, Ekiden (der Vorläufer des Oasis Network), nutzte SGX-Enklaven, um die Transaktionsausführung off-chain parallel auszuführen und dann nur State Roots an die Haupt-Chain zu übermitteln – im Prinzip ähnlich wie Rollup-Ideen, aber unter Verwendung von Hardware-Vertrauen. Durch die Vertragsausführung in TEEs erreichten sie einen hohen Durchsatz, während sie sich auf Enklaven verließen, um die Sicherheit zu gewährleisten. Ein weiteres Beispiel ist das kommende Op-Succinct L2 von Sanders Network, das TEEs und zkSNARKs kombiniert: TEEs führen Transaktionen privat und schnell aus, und anschließend werden ZK-Proofs generiert, um Ethereum die Korrektheit dieser Ausführungen zu beweisen. Dieser hybride Ansatz nutzt die Geschwindigkeit von TEEs und die Verifizierbarkeit von ZK für eine skalierbare, private L2-Lösung.

Im Allgemeinen können TEEs Berechnungen mit nahezu nativer Leistung ausführen (da sie tatsächliche CPU-Instruktionen verwenden, nur mit Isolierung). Daher sind sie für komplexe Logik um Größenordnungen schneller als rein kryptografische Alternativen wie homomorphe Verschlüsselung oder Zero-Knowledge-Proofs. Durch das Auslagern von Arbeit in Enklaven können Blockchains komplexere Anwendungen verarbeiten (wie maschinelles Lernen, Bild-/Audioverarbeitung, große Analysen), die on-chain unpraktisch wären. Die Ergebnisse kommen mit einem Attest zurück, das der On-Chain-Vertrag oder die Benutzer als von einer vertrauenswürdigen Enklave stammend verifizieren können, wodurch Datenintegrität und Korrektheit gewahrt bleiben. Dieses Modell wird oft als „verifizierbare Off-Chain-Berechnung“ bezeichnet, und TEEs sind ein Eckpfeiler für viele solcher Entwürfe (z. B. nutzt das Trusted Compute Framework von Hyperledger Avalon, entwickelt von Intel, iExec und anderen, TEEs zur Off-Chain-Ausführung von EVM-Bytecode mit on-chain veröffentlichtem Korrektheitsnachweis).

Sichere Oracles und Datenintegrität​

Oracles schlagen die Brücke zwischen Blockchains und realen Daten, bringen jedoch Herausforderungen in Bezug auf das Vertrauen mit sich: Wie kann ein Smart Contract darauf vertrauen, dass ein Off-Chain-Datenfeed korrekt und unmanipuliert ist? TEEs bieten eine Lösung, indem sie als sichere Sandbox für Oracle-Nodes fungieren. Ein TEE-basierter Oracle-Node kann Daten von externen Quellen (APIs, Webdiensten) abrufen und sie innerhalb einer Enklave verarbeiten, die garantiert, dass die Daten nicht vom Node-Betreiber oder einer Malware auf dem Node manipuliert wurden. Die Enklave kann dann die Wahrheit der bereitgestellten Daten signieren oder attestieren. Dies verbessert die Datenintegrität und Vertrauenswürdigkeit von Oracles erheblich. Selbst wenn ein Oracle-Betreiber bösartig ist, kann er die Daten nicht ändern, ohne das Attest der Enklave zu brechen (was die Blockchain erkennen würde).

Ein bemerkenswertes Beispiel ist Town Crier, ein bei Cornell entwickeltes Oracle-System, das als eines der ersten Intel SGX-Enklaven nutzte, um authentifizierte Daten für Ethereum-Verträge bereitzustellen. Town Crier rief Daten (z. B. von HTTPS-Websites) innerhalb einer SGX-Enklave ab und lieferte sie zusammen mit einem Beweis (einer Enklaven-Signatur) an einen Vertrag, dass die Daten direkt von der Quelle stammten und nicht gefälscht wurden. Chainlink erkannte den Wert davon und erwarb Town Crier im Jahr 2018, um TEE-basierte Oracles in sein dezentrales Netzwerk zu integrieren. Heute haben Chainlink und andere Oracle-Anbieter TEE-Initiativen: Beispielsweise beinhalten die DECO- und Fair Sequencing Services von Chainlink TEEs, um Datenvertraulichkeit und eine faire Reihenfolge zu gewährleisten. Wie in einer Analyse angemerkt wurde: „TEEs haben die Oracle-Sicherheit revolutioniert, indem sie eine manipulationssichere Umgebung für die Datenverarbeitung bieten... selbst die Node-Betreiber selbst können die Daten während der Verarbeitung nicht manipulieren“. Dies ist besonders wichtig für hochwertige Finanzdatenfeeds (wie Preis-Oracles für DeFi): Eine TEE kann selbst subtile Manipulationen verhindern, die zu großen Exploits führen könnten.

TEEs ermöglichen es Oracles auch, mit sensiblen oder proprietären Daten umzugehen, die nicht im Klartext auf einer Blockchain veröffentlicht werden könnten. Beispielsweise könnte ein Oracle-Netzwerk Enklaven nutzen, um private Daten (wie vertrauliche Aktien-Orderbücher oder persönliche Gesundheitsdaten) zu aggregieren und nur abgeleitete Ergebnisse oder validierte Beweise an die Blockchain zu liefern, ohne die rohen sensiblen Eingaben preiszugeben. Auf diese Weise erweitern TEEs den Umfang der Daten, die sicher in Smart Contracts integriert werden können, was entscheidend für die Tokenisierung realer Vermögenswerte (RWA), Kredit-Scoring, Versicherungen und andere datenintensive On-Chain-Dienste ist.

Beim Thema Cross-Chain-Bridges verbessern TEEs die Integrität in ähnlicher Weise. Bridges verlassen sich oft auf eine Gruppe von Validatoren oder eine Multi-Sig, um Vermögenswerte zu verwahren und Übertragungen zwischen Chains zu validieren, was sie zu Hauptzielen für Angriffe macht. Durch die Ausführung der Bridge-Validator-Logik innerhalb von TEEs kann man die privaten Schlüssel und Verifizierungsprozesse der Bridge gegen Manipulationen absichern. Selbst wenn das Betriebssystem eines Validators kompromittiert ist, sollte der Angreifer nicht in der Lage sein, private Schlüssel zu extrahieren oder Nachrichten aus dem Inneren der Enklave zu fälschen. TEEs können erzwingen, dass Bridge-Transaktionen genau nach den Protokollregeln verarbeitet werden, was das Risiko verringert, dass menschliche Betreiber oder Malware betrügerische Übertragungen einschleusen. Darüber hinaus können TEEs Atomic Swaps und Cross-Chain-Transaktionen ermöglichen, die in einer sicheren Enklave abgewickelt werden, die entweder beide Seiten abschließt oder sauber abbricht, um Szenarien zu verhindern, in denen Gelder aufgrund von Störungen stecken bleiben. Mehrere Bridge-Projekte und Konsortien haben TEE-basierte Sicherheit untersucht, um die Plage von Bridge-Hacks abzumildern, die in den letzten Jahren aufgetreten sind.

Datenintegrität und Verifizierbarkeit Off-Chain​

In all den oben genannten Szenarien ist ein wiederkehrendes Thema, dass TEEs dazu beitragen, die Datenintegrität auch außerhalb der Blockchain aufrechtzuerhalten. Da eine TEE beweisen kann, welchen Code sie ausführt (über ein Attest) und sicherstellen kann, dass der Code ohne Einmischung läuft, bietet sie eine Form des verifizierbaren Computings. Benutzer und Smart Contracts können den Ergebnissen einer TEE vertrauen, als wären sie on-chain berechnet worden, sofern das Attest gültig ist. Diese Integritätsgarantie ist der Grund, warum TEEs manchmal so bezeichnet werden, dass sie einen „Vertrauensanker“ für Off-Chain-Daten und -Berechnungen bilden.

Es ist jedoch erwähnenswert, dass dieses Vertrauensmodell einige Annahmen auf die Hardware verlagert (siehe §4). Die Datenintegrität ist nur so stark wie die Sicherheit der TEE. Wenn die Enklave kompromittiert oder das Attest gefälscht wird, könnte die Integrität versagen. Dennoch machen TEEs in der Praxis (wenn sie auf dem neuesten Stand gehalten werden) bestimmte Angriffe erheblich schwieriger. Beispielsweise könnte eine DeFi-Lending-Plattform eine TEE verwenden, um Kredit-Scores aus den privaten Daten eines Benutzers off-chain zu berechnen, und der Smart Contract würde den Score nur akzeptieren, wenn er von einem gültigen Enklaven-Attest begleitet wird. Auf diese Weise weiß der Vertrag, dass der Score durch den genehmigten Algorithmus auf echten Daten berechnet wurde, anstatt dem Benutzer oder einem Oracle blind zu vertrauen.

TEEs spielen auch eine Rolle in aufstrebenden Systemen für dezentrale Identität (DID) und Authentifizierung. Sie können private Schlüssel, persönliche Daten und Authentifizierungsprozesse sicher verwalten, sodass die sensiblen Informationen des Benutzers niemals der Blockchain oder dApp-Anbietern ausgesetzt werden. Beispielsweise könnte eine TEE auf einem mobilen Gerät die biometrische Authentifizierung verarbeiten und eine Blockchain-Transaktion signieren, wenn die biometrische Prüfung erfolgreich ist – und das alles, ohne die Biometrie des Benutzers preiszugeben. Dies bietet sowohl Sicherheit als auch Privatsphäre im Identitätsmanagement – eine wesentliche Komponente, wenn Web3 Dinge wie Reisepässe, Zertifikate oder KYC-Daten auf nutzersouveräne Weise handhaben soll.

Zusammenfassend lässt sich sagen, dass TEEs als vielseitiges Werkzeug in Web3 dienen: Sie ermöglichen Vertraulichkeit für die On-Chain-Logik, erlauben Skalierung über sichere Off-Chain-Berechnungen, schützen die Integrität von Oracles und Bridges und eröffnen neue Einsatzmöglichkeiten (von privater Identität bis hin zum konformen Datenaustausch). Als Nächstes werden wir uns spezifische Projekte ansehen, die diese Funktionen nutzen.

3. Namhafte Web3-Projekte, die TEEs nutzen​

Eine Reihe führender Blockchain-Projekte hat ihr Kernangebot um Trusted Execution Environments (TEEs) herum aufgebaut. Im Folgenden gehen wir auf einige bemerkenswerte Projekte ein und untersuchen, wie sie die TEE-Technologie nutzen und welchen einzigartigen Mehrwert sie dadurch schaffen:

Secret Network​

Secret Network ist eine Layer-1-Blockchain (basierend auf dem Cosmos SDK), die Pionierarbeit bei datenschutzfreundlichen Smart Contracts unter Verwendung von TEEs geleistet hat. Alle Validator-Knoten im Secret Network führen Intel SGX-Enklaven aus, die den Smart-Contract-Code so verarbeiten, dass der Vertragsstatus sowie die Ein- und Ausgaben selbst für die Knotenbetreiber verschlüsselt bleiben. Dies macht Secret zu einer der ersten Privacy-first Smart-Contract-Plattformen – Datenschutz ist kein optionales Add-on, sondern ein Standardmerkmal des Netzwerks auf Protokollebene.

Im Modell des Secret Networks übermitteln Benutzer verschlüsselte Transaktionen, die von den Validatoren zur Ausführung in ihre SGX-Enklave geladen werden. Die Enklave entschlüsselt die Eingaben, führt den Vertrag aus (geschrieben in einer modifizierten CosmWasm-Laufzeitumgebung) und erzeugt verschlüsselte Ausgaben, die in die Blockchain geschrieben werden. Nur Benutzer mit dem richtigen „Viewing Key“ (oder der Vertrag selbst mit seinem internen Schlüssel) können die tatsächlichen Daten entschlüsseln und einsehen. Dies ermöglicht es Anwendungen, private Daten On-Chain zu verwenden, ohne sie öffentlich preiszugeben.

Das Netzwerk hat mehrere neuartige Anwendungsfälle demonstriert:

• Secret DeFi: z. B. SecretSwap (ein AMM), bei dem die Kontostände und Transaktionsbeträge der Benutzer privat sind, was Front-Running abmildert und Handelsstrategien schützt. Liquiditätsanbieter und Händler können agieren, ohne jeden ihrer Schritte an die Konkurrenz zu senden.
• Secret Auctions: Auktionsverträge, bei denen Gebote bis zum Ende der Auktion geheim gehalten werden, um strategisches Verhalten basierend auf den Geboten anderer zu verhindern.
• Private Abstimmungen und Governance: Token-Inhaber können über Vorschläge abstimmen, ohne ihre Wahlentscheidung preiszugeben, während das Gesamtergebnis dennoch verifiziert werden kann – was eine faire, einschüchterungsfreie Governance gewährleistet.
• Datenmarktplätze: Sensible Datensätze können gehandelt und für Berechnungen verwendet werden, ohne die Rohdaten gegenüber Käufern oder Knoten offenzulegen.

Secret Network integriert TEEs im Wesentlichen auf Protokollebene, um ein einzigartiges Wertversprechen zu schaffen: Es bietet programmierbare Privatsphäre. Zu den Herausforderungen, die sie bewältigen, gehören die Koordinierung der Enklaven-Attestierung über ein dezentrales Validator-Set hinweg und die Verwaltung der Schlüsselverteilung, damit Verträge Eingaben entschlüsseln können, während sie vor Validatoren geheim gehalten werden. Nach allgemeiner Einschätzung hat Secret die Durchführbarkeit von TEE-gestützter Vertraulichkeit auf einer öffentlichen Blockchain bewiesen und sich als Marktführer in diesem Bereich etabliert.

Oasis Network​

Oasis Network ist eine weitere Layer-1-Blockchain, die auf Skalierbarkeit und Datenschutz abzielt und in ihrer Architektur intensiv TEEs (Intel SGX) nutzt. Oasis führte ein innovatives Design ein, das Konsens von Berechnung trennt und in verschiedene Schichten unterteilt, die als Consensus Layer und ParaTime Layer bezeichnet werden. Der Consensus Layer übernimmt die Blockchain-Sortierung und Finalität, während jede ParaTime eine Laufzeitumgebung für Smart Contracts sein kann. Bemerkenswerterweise ist die Emerald ParaTime von Oasis eine EVM-kompatible Umgebung, und Sapphire ist eine vertrauliche EVM, die TEEs verwendet, um den Status von Smart Contracts privat zu halten.

Der Einsatz von TEEs bei Oasis konzentriert sich auf vertrauliche Berechnungen in großem Maßstab. Durch die Isolierung der rechenintensiven Aufgaben in parallelisierbaren ParaTimes (die auf vielen Knoten laufen können) erreichen sie einen hohen Durchsatz. Durch den Einsatz von TEEs innerhalb dieser ParaTime-Knoten stellen sie sicher, dass die Berechnungen sensible Daten enthalten können, ohne diese preiszugeben. Beispielsweise könnte eine Institution einen Kredit-Scoring-Algorithmus auf Oasis ausführen, indem sie private Daten in eine vertrauliche ParaTime einspeist – die Daten bleiben für den Knoten verschlüsselt (da sie in der Enklave verarbeitet werden), und nur das Ergebnis wird ausgegeben. Währenddessen zeichnet der Oasis-Konsens lediglich den Beweis auf, dass die Berechnung korrekt stattgefunden hat.

Technisch gesehen hat Oasis zusätzliche Sicherheitsebenen über das Standard-SGX hinaus hinzugefügt. Sie implementierten eine „geschichtete Vertrauensbasis“ (layered root of trust): Sie nutzen die Quoting-Enklave von Intel SGX und einen speziellen leichtgewichtigen Kernel, um die Vertrauenswürdigkeit der Hardware zu verifizieren und die Systemaufrufe der Enklave in einer Sandbox zu isolieren. Dies reduziert die Angriffsfläche (indem gefiltert wird, welche Betriebssystemaufrufe Enklaven tätigen können) und schützt vor bestimmten bekannten SGX-Angriffen. Oasis führte auch Funktionen wie persistente Enklaven (damit Enklaven den Status über Neustarts hinweg beibehalten können) und sicheres Logging ein, um Rollback-Angriffe abzumildern (bei denen ein Knoten versuchen könnte, einen alten Enklavenstatus erneut abzuspielen). Diese Innovationen wurden in ihren technischen Whitepapern beschrieben und sind mit ein Grund, warum Oasis als forschungsorientiertes Projekt im Bereich des TEE-basierten Blockchain-Computings gilt.

Aus Sicht des Ökosystems hat sich Oasis für Bereiche wie privates DeFi (das es Banken ermöglicht teilzunehmen, ohne Kundendaten preiszugeben) und Datentokenisierung (bei der Einzelpersonen oder Unternehmen Daten auf vertrauliche Weise mit KI-Modellen teilen und dafür vergütet werden können, alles über die Blockchain) positioniert. Sie haben auch mit Unternehmen an Pilotprojekten zusammengearbeitet (beispielsweise mit BMW zum Thema Datenschutz und mit anderen im Bereich des Austauschs medizinischer Forschungsdaten). Insgesamt zeigt das Oasis Network, wie die Kombination von TEEs mit einer skalierbaren Architektur sowohl Datenschutz als auch Leistung adressieren kann, was es zu einem bedeutenden Akteur bei TEE-basierten Web3-Lösungen macht.

Sanders Network​

Sanders Network ist ein dezentrales Cloud-Computing-Netzwerk im Polkadot-Ökosystem, das TEEs nutzt, um vertrauliche und hochperformante Rechendienste bereitzustellen. Es ist eine Parachain auf Polkadot, was bedeutet, dass es von der Sicherheit und Interoperabilität von Polkadot profitiert, aber eine eigene neuartige Laufzeitumgebung für Off-Chain-Berechnungen in sicheren Enklaven einführt.

Die Kernidee von Sanders besteht darin, ein großes Netzwerk von Worker-Knoten (sogenannte Sanders-Miner) zu unterhalten, die Aufgaben innerhalb von TEEs (speziell Intel SGX) ausführen und verifizierbare Ergebnisse produzieren. Diese Aufgaben können von der Ausführung von Smart-Contract-Segmenten bis hin zu universellen Berechnungen reichen, die von Benutzern angefordert werden. Da die Worker in SGX laufen, gewährleistet Sanders, dass die Berechnungen mit Vertraulichkeit (Eingabedaten sind vor dem Worker-Betreiber verborgen) und Integrität (die Ergebnisse werden mit einer Attestierung geliefert) durchgeführt werden. Dies schafft effektiv eine vertrauenslose Cloud, in der Benutzer Workloads bereitstellen können, in dem Wissen, dass der Host diese nicht einsehen oder manipulieren kann.

Man kann sich Sanders analog zu Amazon EC2 oder AWS Lambda vorstellen, jedoch dezentralisiert: Entwickler können Code im Sanders-Netzwerk bereitstellen und ihn auf vielen SGX-fähigen Rechnern weltweit ausführen lassen, wobei sie den Dienst mit dem Sanders-Token bezahlen. Einige hervorgehobene Anwendungsfälle:

• Web3-Analytik und KI: Ein Projekt könnte Benutzerdaten analysieren oder KI-Algorithmen in Sanders-Enklaven ausführen, sodass rohe Benutzerdaten verschlüsselt bleiben (Schutz der Privatsphäre), während nur aggregierte Erkenntnisse die Enklave verlassen.
• Game-Backends und Metaverse: Sanders kann intensive Spiellogik oder Simulationen virtueller Welten Off-Chain verarbeiten und nur Verpflichtungen (Commitments) oder Hashes an die Blockchain senden, was ein reichhaltigeres Gameplay ermöglicht, ohne auf einen einzelnen Server vertrauen zu müssen.
• On-Chain-Dienste: Sanders hat eine Off-Chain-Rechenplattform namens Sanders Cloud aufgebaut. Diese kann beispielsweise als Backend für Bots, dezentrale Webdienste oder sogar ein Off-Chain-Orderbuch dienen, das Trades mit TEE-Attestierung an einen DEX-Smart-Contract übermittelt.

Sanders betont, dass es vertrauliche Berechnungen horizontal skalieren kann: Wird mehr Kapazität benötigt? Dann werden einfach mehr TEE-Worker-Knoten hinzugefügt. Dies unterscheidet sich von einer einzelnen Blockchain, bei der die Rechenkapazität durch den Konsens begrenzt ist. Somit eröffnet Sanders Möglichkeiten für rechenintensive dApps, die dennoch vertrauenslose Sicherheit wünschen. Wichtig ist, dass Sanders sich nicht rein auf Hardware-Vertrauen verlässt; es wird in den Konsens von Polkadot integriert (z. B. Staking und Slashing bei fehlerhaften Ergebnissen) und erforscht sogar eine Kombination aus TEE mit Zero-Knowledge Proofs (wie erwähnt nutzt ihr kommendes L2 TEEs zur Beschleunigung der Ausführung und ZKPs zur prägnanten Verifizierung auf Ethereum). Dieser hybride Ansatz hilft, das Risiko einer Kompromittierung eines einzelnen TEEs zu mindern, indem eine zusätzliche kryptografische Verifizierung hinzugefügt wird.

Zusammenfassend lässt sich sagen, dass das Sanders Network TEEs nutzt, um eine dezentrale, vertrauliche Cloud für Web3 bereitzustellen, die Off-Chain-Berechnungen mit Sicherheitsgarantien ermöglicht. Dies setzt eine Klasse von Blockchain-Anwendungen frei, die sowohl hohe Rechenleistung als auch Datenschutz benötigen, und schließt die Lücke zwischen On-Chain- und Off-Chain-Welten.

iExec​

iExec ist ein dezentraler Marktplatz für Cloud-Computing-Ressourcen, der auf Ethereum aufbaut. Im Gegensatz zu den drei vorgenannten Projekten (die eigene Chains oder Parachains sind), operiert iExec als Layer-2- oder Off-Chain-Netzwerk, das mit Ethereum-Smart-Contracts koordiniert. TEEs (speziell Intel SGX) sind ein Eckpfeiler des Ansatzes von iExec, um Vertrauen in Off-Chain-Berechnungen zu schaffen.

Das iExec-Netzwerk besteht aus Worker-Knoten, die von verschiedenen Anbietern beigesteuert werden. Diese Worker können Aufgaben ausführen, die von Benutzern (dApp-Entwicklern, Datenanbietern usw.) angefordert werden. Um sicherzustellen, dass diese Off-Chain-Berechnungen vertrauenswürdig sind, hat iExec ein Framework für „Trusted Off-chain Computing“ eingeführt: Aufgaben können innerhalb von SGX-Enklaven ausgeführt werden, und die Ergebnisse werden mit einer Enklaven-Signatur geliefert, die beweist, dass die Aufgabe korrekt auf einem sicheren Knoten ausgeführt wurde. iExec ist eine Partnerschaft mit Intel eingegangen, um diese Trusted-Computing-Funktion einzuführen, und ist sogar dem Confidential Computing Consortium beigetreten, um Standards voranzutreiben. Ihr Konsensprotokoll namens Proof-of-Contribution (PoCo) aggregiert bei Bedarf Stimmen/Attestierungen von mehreren Workern, um einen Konsens über das korrekte Ergebnis zu erzielen. In vielen Fällen reicht die Attestierung einer einzelnen Enklave aus, wenn der Code deterministisch ist und das Vertrauen in SGX hoch ist; für eine höhere Absicherung kann iExec Aufgaben über mehrere TEEs hinweg replizieren und einen Konsens oder Mehrheitsentscheid verwenden.

Die Plattform von iExec ermöglicht mehrere interessante Anwendungsfälle:

• Dezentrales Oracle-Computing: Wie bereits erwähnt, kann iExec mit Chainlink zusammenarbeiten. Ein Chainlink-Knoten könnte Rohdaten abrufen, diese dann an einen iExec SGX-Worker übergeben, um eine Berechnung (z. B. einen proprietären Algorithmus oder eine KI-Inferenz) auf diesen Daten durchzuführen, und schließlich ein Ergebnis On-Chain zurückgeben. Dies erweitert die Möglichkeiten von Oracles über das bloße Weiterleiten von Daten hinaus – sie können nun berechnete Dienste anbieten (wie den Aufruf eines KI-Modells oder die Aggregation vieler Quellen), wobei TEE die Ehrlichkeit gewährleistet.
• KI und DePIN (Decentralized Physical Infrastructure Network): iExec positioniert sich als Vertrauensebene für dezentrale KI-Apps. Beispielsweise kann eine dApp, die ein maschinelles Lernmodell verwendet, das Modell in einer Enklave ausführen, um sowohl das Modell (falls es proprietär ist) als auch die eingespeisten Benutzerdaten zu schützen. Im Kontext von DePIN (wie verteilten IoT-Netzwerken) können TEEs auf Edge-Geräten eingesetzt werden, um Sensormesswerten und Berechnungen auf diesen Werten zu vertrauen.
• Sichere Datenmonetarisierung: Datenanbieter können ihre Datensätze in verschlüsselter Form auf dem Marktplatz von iExec zur Verfügung stellen. Käufer können ihre Algorithmen senden, um sie auf den Daten innerhalb eines TEEs auszuführen (sodass die Rohdaten des Datenanbieters niemals offengelegt werden, was dessen geistiges Eigentum schützt, und auch die Details des Algorithmus verborgen bleiben können). Das Ergebnis der Berechnung wird an den Käufer zurückgegeben, und die entsprechende Zahlung an den Datenanbieter wird über Smart Contracts abgewickelt. Dieses Schema, das oft als sicherer Datenaustausch bezeichnet wird, wird durch die Vertraulichkeit von TEEs ermöglicht.

Insgesamt bietet iExec das Bindeglied zwischen Ethereum-Smart-Contracts und einer sicheren Off-Chain-Ausführung. Es zeigt, wie TEE-„Worker“ vernetzt werden können, um eine dezentrale Cloud zu bilden, komplett mit einem Marktplatz (unter Verwendung des RLC-Tokens von iExec für Zahlungen) und Konsensmechanismen. Durch die Leitung der Trusted Compute Working Group der Enterprise Ethereum Alliance und die Mitwirkung an Standards (wie Hyperledger Avalon) treibt iExec zudem die breitere Akzeptanz von TEEs in Enterprise-Blockchain-Szenarien voran.

Andere Projekte und Ökosysteme​

Über die vier oben genannten hinaus gibt es einige weitere erwähnenswerte Projekte:

• Integritee – eine weitere Polkadot-Parachain ähnlich wie Sanders (tatsächlich ging sie aus der TEE-Arbeit der Energy Web Foundation hervor). Integritee nutzt TEEs, um „Parachain-as-a-Service“ für Unternehmen anzubieten, wobei On-Chain- und Off-Chain-Enklavenverarbeitung kombiniert werden.
• Automata Network – ein Middleware-Protokoll für Web3-Privatsphäre, das TEEs für private Transaktionen, anonyme Abstimmungen und MEV-resistente Transaktionsverarbeitung nutzt. Automata fungiert als Off-Chain-Netzwerk, das Dienste wie ein privates RPC-Relay anbietet, und wurde im Zusammenhang mit der Nutzung von TEEs für Dinge wie geschützte Identitäten und gaslose private Transaktionen erwähnt.
• Hyperledger Sawtooth (PoET) – im Unternehmensbereich führte Sawtooth einen Konsensalgorithmus namens Proof of Elapsed Time ein, der auf SGX beruhte. Jeder Validator führt eine Enklave aus, die eine zufällige Zeit lang wartet und einen Beweis erstellt; derjenige mit der kürzesten Wartezeit „gewinnt“ den Block, eine faire Lotterie, die durch SGX erzwungen wird. Obwohl Sawtooth per se kein Web3-Projekt ist (eher Enterprise-Blockchain), ist es eine kreative Nutzung von TEEs für den Konsens.
• Unternehmens-/Konsortial-Chains – Viele Enterprise-Blockchain-Lösungen (z. B. ConsenSys Quorum, IBM Blockchain) integrieren TEEs, um vertrauliche Konsortialtransaktionen zu ermöglichen, bei denen nur autorisierte Knoten bestimmte Daten sehen. Beispielsweise nutzt das Blueprint des Trusted Compute Framework (TCF) der Enterprise Ethereum Alliance TEEs, um private Verträge Off-Chain auszuführen und Merkle-Proofs On-Chain zu liefern.

Diese Projekte zeigen zusammen die Vielseitigkeit von TEEs: Sie treiben ganze datenschutzorientierte L1s an, dienen als Off-Chain-Netzwerke, sichern Infrastrukturkomponenten wie Oracles und Bridges und bilden sogar die Grundlage für Konsensalgorithmen. Als Nächstes betrachten wir die breiteren Vorteile und Herausforderungen des Einsatzes von TEEs in dezentralen Umgebungen.

4. Vorteile und Herausforderungen von TEEs in dezentralen Umgebungen​

Die Einführung von Trusted Execution Environments ( TEEs ) in Blockchain-Systemen bringt sowohl signifikante technische Vorteile als auch bemerkenswerte Herausforderungen und Kompromisse mit sich. Wir werden beide Seiten untersuchen: was TEEs für dezentrale Anwendungen bieten und welche Probleme oder Risiken aus ihrer Verwendung resultieren.

Vorteile und technische Stärken​

• Starke Sicherheit & Privatsphäre: Der wichtigste Vorteil sind die Garantien für Vertraulichkeit und Integrität. TEEs ermöglichen es, sensiblen Code mit der Gewissheit auszuführen, dass er nicht von externer Malware ausspioniert oder verändert werden kann. Dies bietet ein Maß an Vertrauen in Off-Chain-Berechnungen, das zuvor nicht verfügbar war. Für die Blockchain bedeutet dies, dass private Daten genutzt werden können ( was die Funktionalität von dApps erweitert ), ohne die Sicherheit zu opfern. Selbst in nicht vertrauenswürdigen Umgebungen ( Cloud-Server, von Dritten betriebene Validator-Nodes ) halten TEEs Geheimnisse sicher. Dies ist besonders vorteilhaft für die Verwaltung von privaten Schlüsseln, Benutzerdaten und proprietären Algorithmen innerhalb von Krypto-Systemen. Zum Beispiel könnte eine Hardware-Wallet oder ein Cloud-Signierungsdienst ein TEE verwenden, um Blockchain-Transaktionen intern zu signieren, sodass der private Schlüssel niemals im Klartext offengelegt wird, was Komfort mit Sicherheit kombiniert.

• Nahezu native Performance: Im Gegensatz zu rein kryptografischen Ansätzen für sicheres Rechnen ( wie ZK-Proofs oder homomorphe Verschlüsselung ) ist der Overhead von TEEs relativ gering. Der Code wird direkt auf der CPU ausgeführt, sodass eine Berechnung innerhalb einer Enklave in etwa so schnell ist wie außerhalb ( mit gewissen Einbußen für Enklaven-Übergänge und Speicherverschlüsselung, typischerweise im einstelligen Prozentbereich bei SGX ). Das bedeutet, dass TEEs rechenintensive Aufgaben effizient bewältigen können, was Anwendungsfälle ermöglicht ( wie Echtzeit-Datenfeeds, komplexe Smart Contracts, maschinelles Lernen ), die um Größenordnungen langsamer wären, wenn sie mit kryptografischen Protokollen durchgeführt würden. Die geringe Latenz von Enklaven macht sie für Bereiche geeignet, in denen schnelle Reaktionen erforderlich sind ( z. B. durch TEEs gesicherte Hochfrequenz-Trading-Bots oder interaktive Anwendungen und Spiele, bei denen die Benutzererfahrung unter hohen Verzögerungen leiden würde ).

• Verbesserte Skalierbarkeit ( durch Auslagerung ): Durch die Ermöglichung sicherer Off-Chain-Berechnungen tragen TEEs dazu bei, Überlastungen und Gaskosten auf den Hauptketten zu reduzieren. Sie ermöglichen Layer-2-Designs und Side-Protokolle, bei denen die Blockchain nur zur Verifizierung oder endgültigen Abrechnung verwendet wird, während der Großteil der Berechnungen in parallelen Enklaven stattfindet. Diese Modularisierung ( rechenintensive Logik in TEEs, Konsens auf der Chain ) kann den Durchsatz und die Skalierbarkeit dezentraler Anwendungen drastisch verbessern. Beispielsweise könnte eine DEX das Matchmaking in einem TEE off-chain durchführen und nur die gematchten Trades on-chain posten, was den Durchsatz erhöht und das On-Chain-Gas reduziert.

• Bessere Benutzererfahrung & Funktionalität: Mit TEEs können dApps Funktionen wie Vertraulichkeit oder komplexe Analysen anbieten, die mehr Nutzer ( einschließlich Institutionen ) anziehen. TEEs ermöglichen auch gaslose oder Meta-Transaktionen, indem sie diese sicher off-chain ausführen und dann die Ergebnisse übermitteln, wie in Automatas Nutzung von TEEs zur Reduzierung von Gas für private Transaktionen angemerkt. Darüber hinaus kann das Speichern von sensitivem Status off-chain in einer Enklave die Menge der on-chain veröffentlichten Daten reduzieren, was gut für die Privatsphäre der Nutzer und die Netzwerkeffizienz ist ( weniger On-Chain-Daten zum Speichern / Verifizieren ).

• Komponierbarkeit mit anderen Technologien: Interessanterweise können TEEs andere Technologien ergänzen ( was nicht unbedingt ein inhärenter Vorteil von TEEs allein ist, sondern in Kombination ). Sie können als Bindeglied für hybride Lösungen dienen: z. B. das Ausführen eines Programms in einer Enklave und das gleichzeitige Erzeugen eines ZK-Proofs seiner Ausführung, wobei die Enklave Teile des Beweisprozesses unterstützt, um diesen zu beschleunigen. Oder die Verwendung von TEEs in MPC-Netzwerken, um bestimmte Aufgaben mit weniger Kommunikationsrunden zu bewältigen. Wir werden Vergleiche in §5 diskutieren, aber viele Projekte betonen, dass TEEs die Kryptografie nicht ersetzen müssen – sie können zusammenarbeiten, um die Sicherheit zu stärken ( Sanders’ Mantra: „Die Stärke von TEEs liegt darin, andere zu unterstützen, nicht sie zu ersetzen“ ).

Vertrauensannahmen und Sicherheitsanfälligkeiten​

Trotz ihrer Stärken führen TEEs spezifische Vertrauensannahmen ein und sind nicht unantastbar. Es ist entscheidend, diese Herausforderungen zu verstehen:

• Hardware-Vertrauen und Zentralisierung: Durch die Verwendung von TEEs setzt man inhärent Vertrauen in den Chiphersteller ( Silicon Vendor ) sowie in die Sicherheit seines Hardware-Designs und seiner Lieferkette. Die Verwendung von Intel SGX bedeutet beispielsweise das Vertrauen darauf, dass Intel keine Backdoors eingebaut hat, dass die Fertigung sicher ist und dass der Mikrocode der CPU die Enklaven-Isolierung korrekt implementiert. Dies ist ein zentralisierteres Vertrauensmodell im Vergleich zu reiner Kryptografie ( die auf mathematischen Annahmen beruht, die unter allen Nutzern verteilt sind ). Darüber hinaus beruht die Attestierung für SGX historisch auf der Kontaktaufnahme mit Intels Attestation Service. Das bedeutet: Wenn Intel offline ginge oder beschließen würde, Schlüssel zu widerrufen, könnten Enklaven weltweit betroffen sein. Diese Abhängigkeit von der Infrastruktur eines einzelnen Unternehmens wirft Bedenken auf: Es könnte ein Single Point of Failure oder sogar ein Ziel für staatliche Regulierungen sein ( z. B. könnten US-Exportkontrollen theoretisch einschränken, wer starke TEEs nutzen darf ). AMD SEV mildert dies ab, indem es eine dezentralere Attestierung ermöglicht ( VM-Besitzer können ihre VMs attestieren ), vertraut aber weiterhin dem Chip und der Firmware von AMD. Das Zentralisierungsrisiko wird oft als etwas angeführt, das dem Dezentralisierungsgedanken der Blockchain widerspricht. Projekte wie Keystone ( Open-Source-TEE ) und andere erforschen Wege, um die Abhängigkeit von proprietären Black Boxes zu verringern, aber diese sind noch nicht im Mainstream angekommen.

• Seitenkanal- und andere Schwachstellen: Ein TEE ist kein Allheilmittel; es kann durch indirekte Mittel angegriffen werden. Seitenkanalangriffe ( Side-Channel Attacks ) nutzen die Tatsache aus, dass, selbst wenn der direkte Speicherzugriff blockiert ist, der Betrieb einer Enklave das System subtil beeinflussen kann ( durch Timing, Cache-Nutzung, Stromverbrauch, elektromagnetische Emissionen usw. ). In den letzten Jahren wurden zahlreiche akademische Angriffe auf Intel SGX demonstriert: von Foreshadow ( Extrahieren von Enklaven-Geheimnissen über L1-Cache-Timing-Leckagen ) über Plundervolt ( Voltage Fault Injection über privilegierte Befehle ) bis hin zu SGAxe ( Extrahieren von Attestierungsschlüsseln ) und anderen. Diese hochentwickelten Angriffe zeigen, dass TEEs kompromittiert werden können, ohne kryptografische Schutzmechanismen brechen zu müssen – stattdessen durch das Ausnutzen von mikroarchitektonischen Verhaltensweisen oder Fehlern in der Implementierung. Infolgedessen wird anerkannt, dass „Forscher verschiedene potenzielle Angriffsvektoren identifiziert haben, die Hardware-Schwachstellen oder Zeitunterschiede bei TEE-Operationen ausnutzen könnten“. Obwohl diese Angriffe nicht trivial sind und oft entweder lokalen Zugriff oder bösartige Hardware erfordern, stellen sie eine reale Bedrohung dar. TEEs schützen im Allgemeinen auch nicht vor physischen Angriffen, wenn ein Angreifer den Chip in der Hand hat ( z. B. das Öffnen des Chips / Decapping, das Sondieren von Bussen usw. kann die meisten kommerziellen TEEs überwinden ).

  Die Reaktionen der Hersteller auf Entdeckungen von Seitenkanälen bestanden in Mikrocode-Patches und Updates des Enklaven-SDKs, um bekannte Lecks zu mildern ( manchmal auf Kosten der Performance ). Aber es bleibt ein Katz-und-Maus-Spiel. Für Web3 bedeutet dies: Wenn jemand einen neuen Seitenkanal auf SGX findet, könnte ein „sicherer“ DeFi-Vertrag, der in SGX läuft, potenziell ausgenutzt werden ( z. B. um geheime Daten zu lecken oder die Ausführung zu manipulieren ). Sich auf TEEs zu verlassen, bedeutet also, eine potenzielle Angriffsfläche auf Hardware-Ebene zu akzeptieren, die außerhalb des typischen Blockchain-Bedrohungsmodells liegt. Es ist ein aktives Forschungsgebiet, TEEs gegen diese Angriffe zu stärken ( zum Beispiel durch das Entwerfen von Enklaven-Code mit Constant-Time-Operationen, das Vermeiden von geheimnisabhängigen Speicherzugriffsmustern und die Verwendung von Techniken wie Oblivious RAM ). Einige Projekte ergänzen TEEs auch durch sekundäre Prüfungen – z. B. die Kombination mit ZK-Proofs oder das Ausführen mehrerer Enklaven auf Hardware verschiedener Hersteller, um das Risiko eines einzelnen Chips zu verringern.

• Performance- und Ressourcenbeschränkungen: Obwohl TEEs bei CPU-gebundenen Aufgaben mit nahezu nativer Geschwindigkeit laufen, bringen sie einige Overheads und Einschränkungen mit sich. Der Wechsel in eine Enklave ( ein ECALL ) und heraus ( OCALL ) verursacht Kosten, ebenso wie die Verschlüsselung / Entschlüsselung von Speicherseiten. Dies kann die Performance bei sehr häufigen Enklaven-Grenzübergängen beeinträchtigen. Enklaven haben zudem oft Einschränkungen bei der Speichergröße. Beispielsweise hatte das frühe SGX einen begrenzten Enclave Page Cache ( EPC ), und wenn Enklaven mehr Speicher verwendeten, mussten Seiten ausgelagert werden ( mit Verschlüsselung ), was die Performance massiv verlangsamte. Selbst neuere TEEs erlauben es oft nicht, den gesamten System-RAM problemlos zu nutzen – es gibt einen sicheren Speicherbereich, der begrenzt sein kann. Dies bedeutet, dass sehr umfangreiche Berechnungen oder Datensätze eine Herausforderung darstellen können, wenn sie vollständig innerhalb eines TEEs abgewickelt werden sollen. Im Web3-Kontext könnte dies die Komplexität von Smart Contracts oder ML-Modellen einschränken, die in einer Enklave laufen können. Entwickler müssen für den Speicher optimieren und möglicherweise Arbeitslasten aufteilen.

• Komplexität der Attestierung und Schlüsselverwaltung: Die Verwendung von TEEs in einer dezentralen Umgebung erfordert robuste Attestierungs-Workflows: Jeder Knoten muss anderen beweisen, dass er eine authentische Enklave mit dem erwarteten Code ausführt. Die Einrichtung dieser On-Chain-Attestierungsverifizierung kann komplex sein. In der Regel müssen der öffentliche Attestierungsschlüssel oder das Zertifikat des Herstellers fest im Protokoll kodiert und die Verifizierungslogik in Smart Contracts oder Off-Chain-Clients geschrieben werden. Dies führt zu Overhead im Protokolldesign, und alle Änderungen ( wie der Wechsel des Attestierungs-Signaturschlüsselformats von EPID zu DCAP durch Intel ) können Wartungsaufwand verursachen. Darüber hinaus fügt die Verwaltung von Schlüsseln innerhalb von TEEs ( zum Entschlüsseln von Daten oder Signieren von Ergebnissen ) eine weitere Komplexitätsebene hinzu. Fehler bei der Enklaven-Schlüsselverwaltung könnten die Sicherheit untergraben ( z. B. wenn eine Enklave versehentlich einen Entschlüsselungsschlüssel durch einen Bug preisgibt, brechen alle ihre Vertraulichkeitsversprechen zusammen ). Best Practices beinhalten die Nutzung der Sealing-APIs des TEEs, um Schlüssel sicher zu speichern und Schlüssel bei Bedarf zu rotieren, aber auch dies erfordert ein sorgfältiges Design durch die Entwickler.

• Denial-of-Service und Verfügbarkeit: Ein vielleicht weniger diskutiertes Problem: TEEs helfen nicht bei der Verfügbarkeit und können sogar neue DoS-Wege eröffnen. Zum Beispiel könnte ein Angreifer einen TEE-basierten Dienst mit Eingaben überfluten, deren Verarbeitung kostspielig ist, wohlwissend, dass die Enklave vom Betreiber nicht einfach inspiziert oder unterbrochen werden kann ( da sie isoliert ist ). Wenn zudem eine Schwachstelle gefunden wird und ein Patch Firmware-Updates erfordert, müssen während dieses Zyklus viele Enklaven-Dienste möglicherweise aus Sicherheitsgründen pausieren, bis die Knoten gepatcht sind, was zu Ausfallzeiten führt. Stellen Sie sich im Blockchain-Konsens vor, ein kritischer SGX-Bug würde gefunden – Netzwerke wie Secret müssten möglicherweise anhalten, bis ein Fix vorliegt, da das Vertrauen in die Enklaven gebrochen wäre. Die Koordinierung solcher Reaktionen in einem dezentralen Netzwerk ist eine Herausforderung.

Komponierbarkeit und Ökosystem-Einschränkungen​

• Eingeschränkte Komponierbarkeit mit anderen Verträgen: In einer öffentlichen Smart-Contract-Plattform wie Ethereum können Verträge problemlos andere Verträge aufrufen, und der gesamte Status ist offen, was DeFi-Money-Legos und eine reichhaltige Komposition ermöglicht. In einem TEE-basierten Vertragsmodell kann der private Status nicht frei geteilt oder kombiniert werden, ohne die Vertraulichkeit zu verletzen. Wenn beispielsweise Vertrag A in einer Enklave mit Vertrag B interagieren muss und beide geheime Daten enthalten, wie arbeiten sie zusammen? Entweder müssen sie ein komplexes sicheres Multi-Party-Protokoll durchführen ( was einen Teil der Einfachheit von TEEs zunichtemacht ) oder sie werden in einer Enklave kombiniert ( was die Modularität verringert ). Dies ist eine Herausforderung, vor der das Secret Network und andere stehen: Vertragsübergreifende Aufrufe mit Privatsphäre sind nicht trivial. Einige Lösungen sehen vor, dass eine einzige Enklave die Ausführung mehrerer Verträge übernimmt, sodass sie intern geteilte Geheimnisse verwalten kann, aber das kann das System monolithischer machen. Daher ist die Komponierbarkeit privater Verträge eingeschränkter als die öffentlicher oder erfordert neue Designmuster. Ebenso erfordert die Integration von TEE-basierten Modulen in bestehende Blockchain-dApps ein sorgfältiges Schnittstellendesign – oft wird nur das Ergebnis einer Enklave on-chain gepostet, was ein SNARK oder ein Hash sein kann, und andere Verträge können nur diese begrenzten Informationen nutzen. Dies ist definitiv ein Kompromiss; Projekte wie Secret bieten Viewing-Keys an und erlauben das Teilen von Geheimnissen nach dem „Need-to-know“-Prinzip, aber es ist nicht so nahtlos wie die normale On-Chain-Komponierbarkeit.

• Standardisierung und Interoperabilität: Dem TEE-Ökosystem fehlen derzeit einheitliche Standards über verschiedene Hersteller hinweg. Intel SGX, AMD SEV und ARM TrustZone haben alle unterschiedliche Programmiermodelle und Attestierungsmethoden. Diese Fragmentierung bedeutet, dass eine für SGX-Enklaven geschriebene dApp nicht ohne Weiteres auf TrustZone usw. portierbar ist. In der Blockchain kann dies ein Projekt an eine bestimmte Hardware binden ( z. B. sind Secret und Oasis derzeit an x86-Server mit SGX gebunden ). Wenn diese später ARM-Knoten unterstützen wollten ( z. B. Validatoren auf Mobilgeräten ), würde dies zusätzliche Entwicklung und vielleicht eine andere Attestierungs-Verifizierungslogik erfordern. Es gibt Bemühungen ( wie das CCC – Confidential Computing Consortium ), Attestierungs- und Enklaven-APIs zu standardisieren, aber wir sind noch nicht ganz am Ziel. Der Mangel an Standards wirkt sich auch auf die Entwickler-Tools aus – man findet vielleicht das SGX-SDK ausgereift, muss sich dann aber an ein anderes TEE mit einem anderen SDK anpassen. Diese Interoperabilitäts-Herausforderung kann die Akzeptanz verlangsamen und die Kosten erhöhen.

• Lernkurve für Entwickler: Das Erstellen von Anwendungen, die innerhalb von TEEs laufen, erfordert spezialisiertes Wissen, das viele Blockchain-Entwickler möglicherweise nicht haben. Oft ist Low-Level-Programmierung in C / C++ ( für SGX / TrustZone ) oder ein Verständnis von Speichersicherheit und seitenkanalresistentem Coding erforderlich. Das Debuggen von Enklaven-Code ist bekanntermaßen schwierig ( man kann aus Sicherheitsgründen während des Betriebs nicht einfach in eine Enklave hineinschauen! ). Obwohl Frameworks und höhere Sprachen existieren ( wie die Verwendung von Rust durch Oasis für ihre vertrauliche Runtime oder sogar Tools zum Ausführen von WebAssembly in Enklaven ), ist die Entwicklererfahrung immer noch mühsamer als die typische Smart-Contract-Entwicklung oder die Off-Chain-Web2-Entwicklung. Diese steile Lernkurve und unausgereifte Tools können Entwickler abschrecken oder zu Fehlern führen, wenn nicht sorgfältig vorgegangen wird. Hinzu kommt der Aspekt, dass Hardware zum Testen benötigt wird – zum Ausführen von SGX-Code ist eine SGX-fähige CPU oder ein Emulator erforderlich ( der langsamer ist ), sodass die Einstiegshürde höher ist. Infolgedessen sind heute relativ wenige Entwickler tief mit der Enklaven-Entwicklung vertraut, was Audits und Community-Support seltener macht als beispielsweise in der weit verbreiteten Solidity-Community.

• Betriebskosten: Der Betrieb einer TEE-basierten Infrastruktur kann kostspieliger sein. Die Hardware selbst kann teurer oder knapper sein ( z. B. verlangen bestimmte Cloud-Anbieter einen Aufpreis für SGX-fähige VMs ). Hinzu kommt der operative Aufwand: Firmware auf dem neuesten Stand halten ( für Sicherheitspatches ), Verwaltung des Attestierungs-Networkings usw., was kleine Projekte als belastend empfinden könnten. Wenn jeder Knoten eine bestimmte CPU haben muss, könnte dies den potenziellen Validator-Pool verkleinern ( nicht jeder hat die erforderliche Hardware ), was die Dezentralisierung beeinträchtigt und möglicherweise zu einer höheren Nutzung von Cloud-Hosting führt.

Zusammenfassend lässt sich sagen: Während TEEs leistungsstarke Funktionen freischalten, bringen sie auch Vertrauenskompromisse ( Hardware-Vertrauen vs. mathematisches Vertrauen ), potenzielle Sicherheitsforschwächen ( insbesondere Seitenkanäle ) und Integrationshürden in einem dezentralen Kontext mit sich. Projekte, die TEEs einsetzen, müssen diese Probleme sorgfältig umgehen – indem sie Defense-in-Depth anwenden ( nicht davon ausgehen, dass das TEE unzerbrechlich ist ), die Trusted Computing Base minimal halten und gegenüber den Nutzern transparent über die Vertrauensannahmen kommunizieren ( damit klar ist, dass man beispielsweise neben dem Blockchain-Konsens auch der Hardware von Intel vertraut ).

5. TEEs vs. andere datenschutzfreundliche Technologien (ZKP, FHE, MPC)​

Trusted Execution Environments (TEEs) sind ein Ansatz, um Datenschutz und Sicherheit im Web3 zu erreichen. Es gibt jedoch weitere wichtige Techniken, darunter Zero-Knowledge-Proofs (ZKPs), vollhomomorphe Verschlüsselung (FHE) und sichere Mehrparteienberechnung (MPC). Jede dieser Technologien verfügt über ein anderes Vertrauensmodell und Leistungsprofil. In vielen Fällen schließen sie sich nicht gegenseitig aus – sie können sich ergänzen –, aber es ist nützlich, ihre Abwägungen in Bezug auf Performance, Vertrauen und Benutzerfreundlichkeit für Entwickler zu vergleichen:

Kurzdefinitionen der Alternativen:

• ZKPs: Kryptographische Beweise (wie zk-SNARKs, zk-STARKs), die es einer Partei ermöglichen, anderen gegenüber zu beweisen, dass eine Aussage wahr ist (z. B. „Ich kenne ein Geheimnis, das diese Berechnung erfüllt“), ohne zu verraten, warum sie wahr ist (das Verbergen der geheimen Eingabe). In der Blockchain werden ZKPs für private Transaktionen (z. B. Zcash, Aztec) und für die Skalierbarkeit verwendet (Rollups, die Beweise für eine korrekte Ausführung übermitteln). Sie gewährleisten starken Datenschutz (keine geheimen Daten werden geleakt, nur Beweise) und durch Mathematik garantierte Integrität, aber die Erzeugung dieser Beweise kann rechentechnisch schwerfällig sein, und die Schaltkreise müssen sorgfältig entworfen werden.
• FHE: Ein Verschlüsselungsverfahren, das beliebige Berechnungen auf verschlüsselten Daten ermöglicht, sodass das Ergebnis nach der Entschlüsselung dem Ergebnis der Berechnung auf Klartexten entspricht. Theoretisch bietet FHE ultimativen Datenschutz – die Daten bleiben jederzeit verschlüsselt –, und man muss niemandem die Rohdaten anvertrauen. FHE ist jedoch für allgemeine Berechnungen extrem langsam (obwohl es sich durch Forschung verbessert); aufgrund der Performance befindet es sich noch größtenteils in der experimentellen oder spezialisierten Anwendung.
• MPC: Protokolle, bei denen mehrere Parteien gemeinsam eine Funktion über ihre privaten Eingaben berechnen, ohne diese Eingaben einander offenzulegen. Dabei werden Daten oft mittels Secret-Sharing auf Parteien verteilt und kryptographische Operationen durchgeführt, sodass die Ausgabe korrekt ist, die einzelnen Eingaben jedoch verborgen bleiben. MPC kann Vertrauen verteilen (keine einzelne Instanz sieht alle Daten) und für bestimmte Operationen effizient sein, verursacht aber typischerweise einen Kommunikations- und Koordinationsaufwand und kann für große Netzwerke komplex in der Implementierung sein.

Unten finden Sie eine Vergleichstabelle, die die wichtigsten Unterschiede zusammenfasst:

Quellen: Der obige Vergleich stützt sich auf Analysen wie die von Sanders Network, die hervorheben, dass TEEs bei Geschwindigkeit und Benutzerfreundlichkeit glänzen, während ZK und FHE auf maximale Vertrauenslosigkeit auf Kosten hoher Rechenleistung setzen und MPC Vertrauen verteilt, aber Netzwerk-Overhead einführt.

Aus der Tabelle ergeben sich einige wichtige Abwägungen:

• Performance: TEEs haben einen großen Vorteil bei der reinen Geschwindigkeit und der geringen Latenz. MPC kann oft moderate Komplexität mit gewissen Verzögerungen bewältigen, ZK ist langsam in der Erzeugung, aber schnell in der Verifizierung (asynchrone Nutzung), und FHE ist derzeit bei weitem am langsamsten für beliebige Aufgaben (wenn auch in Ordnung für begrenzte Operationen wie einfache Additionen/Multiplikationen). Wenn Ihre Anwendung komplexe Echtzeitverarbeitung benötigt (wie interaktive Anwendungen, Hochfrequenzentscheidungen), sind TEEs oder vielleicht MPC (mit wenigen Parteien und guten Verbindungen) heute die einzigen praktikablen Optionen. ZK und FHE wären in solchen Szenarien zu langsam.

• Vertrauensmodell: ZKP und FHE sind rein vertrauenslos (man vertraut nur der Mathematik). MPC verlagert das Vertrauen auf Annahmen über die Ehrlichkeit der Teilnehmer (was durch viele Parteien oder wirtschaftliche Anreize gestärkt werden kann). TEEs setzen Vertrauen in die Hardware und den Hersteller voraus. Dies ist ein grundlegender Unterschied: TEEs führen eine vertrauenswürdige dritte Partei (den Chip) in die normalerweise vertrauenslose Welt der Blockchain ein. Im Gegensatz dazu werden ZK und FHE oft dafür gelobt, dass sie besser mit dem dezentralen Ethos übereinstimmen – keine speziellen Instanzen, denen man vertrauen muss, nur rechnerische Härte. MPC liegt dazwischen: Vertrauen ist dezentralisiert, aber nicht eliminiert (wenn N von M Knoten kolludieren, bricht der Datenschutz). Für maximale Vertrauenslosigkeit (z. B. ein wirklich zensurresistentes, dezentrales System) tendiert man eher zu kryptographischen Lösungen. Andererseits akzeptieren viele praktische Systeme die Annahme, dass Intel ehrlich ist oder dass eine Gruppe großer Validatoren nicht kolludieren wird, und tauschen ein Stück Vertrauen gegen enorme Effizienzgewinne ein.

• Sicherheit/Schwachstellen: TEEs können, wie besprochen, durch Hardware-Bugs oder Seitenkanäle untergraben werden. Die Sicherheit von ZK und FHE kann untergraben werden, wenn die zugrunde liegende Mathematik (z. B. elliptische Kurven oder Gitterprobleme) gebrochen wird, aber dies sind gut untersuchte Probleme, und Angriffe würden wahrscheinlich bemerkt werden (zudem können Parameterwahlen bekannte Risiken mindern). Die Sicherheit von MPC kann durch aktive Angreifer gebrochen werden, wenn das Protokoll nicht dafür ausgelegt ist (einige MPC-Protokolle setzen „ehrliche, aber neugierige“ Teilnehmer voraus und könnten scheitern, wenn jemand offen betrügt). Im Blockchain-Kontext könnte ein TEE-Bruch katastrophaler sein (alle Enklaven-basierten Verträge könnten bis zum Patch gefährdet sein), während ein kryptographischer ZK-Bruch (wie die Entdeckung einer Schwachstelle in einer Hash-Funktion eines ZK-Rollups) ebenfalls katastrophal wäre, aber angesichts der einfacheren Annahme im Allgemeinen als weniger wahrscheinlich gilt. Die Angriffsfläche ist sehr unterschiedlich: TEEs müssen sich um Dinge wie Leistungsanalyse sorgen, während ZK sich um mathematische Durchbrüche sorgen muss.

• Datenschutz: FHE und ZK bieten die stärksten Datenschutzgarantien – Daten bleiben kryptographisch geschützt. MPC stellt sicher, dass Daten verteilt (secret-shared) werden, sodass keine einzelne Partei sie sieht (obwohl Informationen leaken könnten, wenn Ausgaben öffentlich sind). TEEs halten Daten vor der Außenwelt geheim, aber innerhalb der Enklave werden die Daten entschlüsselt; wenn jemand irgendwie die Kontrolle über die Enklave erlangt, geht die Vertraulichkeit verloren. Zudem erlauben TEEs dem Code typischerweise, alles mit den Daten zu tun (einschließlich des unbeabsichtigten Leakens durch Seitenkanäle oder das Netzwerk, wenn der Code bösartig ist). TEEs erfordern also, dass man auch dem Enklaven-Code vertraut, nicht nur der Hardware. Im Gegensatz dazu beweisen ZKPs Eigenschaften des Codes, ohne jemals Geheimnisse preiszugeben, sodass man nicht einmal dem Code vertrauen muss (über die Tatsache hinaus, dass er tatsächlich die bewiesene Eigenschaft besitzt). Wenn eine Enklaven-Anwendung einen Bug hätte, der Daten in eine Logdatei schreibt, würde die TEE-Hardware das nicht verhindern – während ein ZK-Beweissystem einfach nichts außer dem beabsichtigten Beweis offenbaren würde. Dies ist eine Nuance: TEEs schützen vor externen Angreifern, aber nicht unbedingt vor Logikfehlern im Enklaven-Programm selbst, während das Design von ZK einen deklarativeren Ansatz erzwingt (man beweist genau das, was beabsichtigt ist, und nichts mehr).

• Komponierbarkeit & Integration: TEEs lassen sich relativ einfach in bestehende Systeme integrieren – man kann ein bestehendes Programm nehmen, es in eine Enklave verschieben und erhält Sicherheitsvorteile, ohne das Programmiermodell zu stark zu verändern. ZK und FHE erfordern oft das Umschreiben des Programms in einen Schaltkreis oder eine restriktive Form, was einen massiven Aufwand bedeuten kann. Beispielsweise beinhaltet das Schreiben einer einfachen KI-Modellverifizierung in ZK die Transformation in eine Reihe von arithmetischen Operationen und Constraints, was weit davon entfernt ist, einfach TensorFlow in einer TEE auszuführen und das Ergebnis zu attestieren. MPC erfordert ähnlich oft benutzerdefinierte Protokolle pro Anwendungsfall. Aus Sicht der Entwicklerproduktivität und Kosten sind TEEs daher attraktiv. Wir haben in einigen Bereichen eine schnellere Einführung von TEEs gesehen, gerade weil man bestehende Software-Ökosysteme nutzen kann. ZK/MPC erfordern spezialisierte Ingenieurstalente, die knapp sind. Die Kehrseite ist jedoch, dass TEEs oft zu isolierteren Lösungen führen (man muss dieser Enklave oder dieser Gruppe von Knoten vertrauen), während ZK einen Beweis liefert, den jeder On-Chain prüfen kann, was es hochgradig komponierbar macht. ZK-Ergebnisse sind portabel – sie erzeugen einen kleinen Beweis, den beliebig viele andere Verträge oder Nutzer verwenden können. TEE-Ergebnisse liegen meist in Form einer Attestierung vor, die an eine bestimmte Hardware gebunden und möglicherweise nicht prägnant ist; sie sind vielleicht nicht so leicht teilbar oder Chain-agnostisch.

In der Praxis sehen wir hybride Ansätze: Zum Beispiel argumentiert Sanders Network, dass TEE, MPC und ZK jeweils in unterschiedlichen Bereichen glänzen und sich ergänzen können. Ein konkreter Fall ist die dezentrale Identität: Man könnte ZK-Beweise verwenden, um ein Identitätsmerkmal zu beweisen, ohne es offenzulegen, aber dieses Merkmal könnte durch einen TEE-basierten Prozess verifiziert und ausgestellt worden sein, der Dokumente privat geprüft hat. Oder betrachten Sie die Skalierung: ZK-Rollups liefern prägnante Beweise für viele Transaktionen, aber die Erzeugung dieser Beweise könnte beschleunigt werden, indem TEEs verwendet werden, um einige Berechnungen schneller durchzuführen (und dann nur eine kleinere Aussage zu beweisen). Die Kombination kann manchmal die Vertrauensanforderung an TEEs verringern (z. B. TEEs für Performance nutzen, aber die endgültige Korrektheit dennoch über einen ZK-Beweis oder ein On-Chain-Challenge-Game verifizieren, sodass eine kompromittierte TEE nicht betrügen kann, ohne erwischt zu werden). Gleichzeitig kann MPC mit TEEs kombiniert werden, indem der Rechenknoten jeder Partei eine TEE ist, was eine zusätzliche Schutzschicht bietet, sodass selbst bei Kollusion einiger Parteien diese die Daten der anderen nicht sehen können, es sei denn, sie brechen auch die Hardware-Sicherheit.

Zusammenfassend bieten TEEs einen sehr praktischen und unmittelbaren Weg zu sicherer Berechnung mit moderaten Annahmen (Hardware-Vertrauen), während ZK und FHE einen eher theoretischen und vertrauenslosen Weg bei hohen Rechenkosten bieten und MPC einen Pfad des verteilten Vertrauens mit Netzwerkkosten darstellt. Die richtige Wahl im Web3 hängt von den Anforderungen der Anwendung ab:

• Wenn Sie schnelle, komplexe Berechnungen auf privaten Daten benötigen (wie KI, große Datensätze) – sind TEEs (oder MPC mit wenigen Parteien) derzeit der einzige gangbare Weg.
• Wenn Sie maximale Dezentralisierung und Verifizierbarkeit benötigen – glänzen ZK-Beweise (beispielsweise bevorzugen private Kryptowährungstransaktionen ZKP wie in Zcash, da Nutzer nichts außer der Mathematik vertrauen wollen).
• Wenn Sie kollaboratives Rechnen zwischen mehreren Stakeholdern benötigen – ist MPC von Natur aus geeignet (wie Multi-Party Key Management oder Auktionen).
• Wenn Sie extrem sensible Daten haben und langfristiger Datenschutz ein Muss ist – könnte FHE attraktiv sein, falls sich die Performance verbessert, denn selbst wenn jemand Ihre Chiffretexte Jahre später erhielte, würde er ohne den Schlüssel nichts erfahren; während ein Enklaven-Bruch Geheimnisse rückwirkend offenlegen könnte, falls Logs aufbewahrt wurden.

Es ist bemerkenswert, dass der Blockchain-Raum all diese Technologien aktiv parallel erforscht. Wir werden wahrscheinlich Kombinationen sehen: z. B. Layer-2-Lösungen, die TEEs integrieren, um Transaktionen zu sequenzieren, und dann einen ZKP verwenden, um zu beweisen, dass die TEE die Regeln befolgt hat, oder MPC-Netzwerke, die TEEs in jedem Knoten verwenden, um die Komplexität der MPC-Protokolle zu verringern.

Letztendlich ist die Wahl zwischen TEEs, ZK, MPC und FHE keine Nullsummenentscheidung – sie zielen jeweils auf unterschiedliche Punkte im Dreieck aus Sicherheit, Performance und Vertrauenslosigkeit ab. Wie es in einem Artikel hieß: Alle vier stehen vor einem „unmöglichen Dreieck“ aus Performance, Kosten und Sicherheit – keine einzelne Lösung ist in allen Aspekten überlegen. Das optimale Design nutzt oft das richtige Werkzeug für den richtigen Teil des Problems.

6. Einführung in bedeutenden Blockchain-Ökosystemen​

Trusted Execution Environments (TEEs) wurden in verschiedenen Blockchain-Ökosystemen in unterschiedlichem Maße eingeführt, oft beeinflusst durch die Prioritäten dieser Communities und die Einfachheit der Integration. Hier bewerten wir, wie TEEs in einigen der wichtigsten Ökosysteme verwendet (oder erforscht) werden: Ethereum, Cosmos und Polkadot, sowie in weiteren Bereichen:

Ethereum (und allgemeine Layer-1-Lösungen)​

Auf dem Ethereum-Mainnet selbst sind TEEs kein Teil des Kernprotokolls, aber sie finden Anwendung in Anwendungen und Layer-2-Lösungen. Die Philosophie von Ethereum stützt sich primär auf kryptografische Sicherheit (z. B. die aufkommenden ZK-Rollups), doch TEEs haben Rollen in Orakeln und der Off-chain-Ausführung für Ethereum übernommen:

• Orakel-Dienste: Wie bereits erörtert, hat Chainlink TEE-basierte Lösungen wie Town Crier integriert. Obwohl nicht alle Chainlink-Nodes standardmäßig TEEs verwenden, ist die Technologie für Datenfeeds vorhanden, die ein besonderes Maß an Vertrauen erfordern. Auch API3 (ein weiteres Orakel-Projekt) hat die Verwendung von Intel SGX erwähnt, um APIs zu betreiben und Daten zu signieren, um die Authentizität zu gewährleisten. Diese Dienste liefern Daten an Ethereum-Smart-Contracts mit stärkeren Zusicherungen.

• Layer-2 und Rollups: In der Ethereum-Community gibt es laufende Forschungen und Debatten über den Einsatz von TEEs in Rollup-Sequencern oder Validatoren. Beispielsweise haben das „ZK-Portal“-Konzept von ConsenSys und andere die Nutzung von TEEs vorgeschlagen, um die korrekte Reihenfolge in optimistischen Rollups zu erzwingen oder den Sequencer vor Zensur zu schützen. Ein Medium-Artikel deutet sogar an, dass TEE bis 2025 ein Standardmerkmal in einigen L2-Lösungen für Bereiche wie den Schutz des Hochfrequenzhandels werden könnte. Projekte wie Catalyst (eine DEX für Hochfrequenzhandel) und Flashbots (für MEV-Relays) haben TEEs untersucht, um eine faire Reihenfolge von Transaktionen zu erzwingen, bevor sie die Blockchain erreichen.

• Enterprise Ethereum: In Konsortial- oder zugangsbeschränkten Ethereum-Netzwerken sind TEEs weiter verbreitet. Das Trusted Compute Framework (TCF) der Enterprise Ethereum Alliance war im Grunde ein Entwurf für die Integration von TEEs in Ethereum-Clients. Hyperledger Avalon (ehemals EEA TCF) ermöglicht es, Teile von Ethereum-Smart-Contracts off-chain in einem TEE auszuführen und anschließend on-chain zu verifizieren. Mehrere Unternehmen wie IBM, Microsoft und iExec haben dazu beigetragen. Während dies im öffentlichen Ethereum-Netzwerk nicht üblich geworden ist, können TEEs in privaten Implementierungen (z. B. eine Gruppe von Banken, die Quorum oder Besu nutzen) verwendet werden, damit selbst Konsortialmitglieder die Daten der anderen nicht sehen, sondern nur die autorisierten Ergebnisse. Dies kann die Datenschutzanforderungen im Unternehmensumfeld erfüllen.

• Bemerkenswerte Projekte: Neben iExec, das auf Ethereum operiert, gab es Projekte wie Enigma (das ursprünglich als MPC-Projekt am MIT begann, dann auf SGX umschwenkte und später zum Secret Network auf Cosmos wurde). Ein weiteres war Decentralized Cloud Services (DCS) in frühen Ethereum-Diskussionen. In jüngerer Zeit ermöglicht Oasis Ethereum ParaTime (Oasis Sapphire), dass Solidity-Contracts mit Vertraulichkeit ausgeführt werden, indem das TEE-Backend von Oasis genutzt wird, während die Abrechnung auf Ethereum erfolgt. Auch einige Ethereum-basierte DApps für den Austausch medizinischer Daten oder für Spiele haben mit TEEs experimentiert, indem sie eine Off-chain-Enklaven-Komponente nutzen, die mit ihren Smart Contracts interagiert.

Die Einführung bei Ethereum ist also eher indirekt – das Protokoll wurde nicht dahingehend geändert, TEEs vorauszusetzen, aber es gibt eine Vielzahl optionaler Dienste und Erweiterungen, die TEEs für spezifische Anforderungen nutzen. Wichtig ist, dass Ethereum-Forscher vorsichtig bleiben: Vorschläge für einen „nur TEE-basierten Shard“ oder eine tiefe Integration von TEEs stießen aufgrund von Vertrauensbedenken auf Skepsis in der Community. Stattdessen werden TEEs eher als „Co-Prozessoren“ für Ethereum und nicht als Kernkomponenten gesehen.

Cosmos-Ökosystem​

Das Cosmos-Ökosystem ist dank seines modularen SDKs und souveräner Chains offen für Experimente, und das Secret Network (oben behandelt) ist ein Paradebeispiel für die TEE-Einführung in Cosmos. Secret Network ist faktisch eine Cosmos SDK-Chain mit Tendermint-Konsens, die so modifiziert wurde, dass SGX für ihre Validatoren obligatorisch ist. Es ist eine der bekanntesten Cosmos-Zonen nach dem Cosmos Hub, was auf eine erhebliche Akzeptanz der TEE-Technologie in dieser Community hindeutet. Der Erfolg von Secret bei der Bereitstellung von Interchain-Datenschutz (durch seine IBC-Verbindungen kann Secret als Datenschutz-Hub für andere Cosmos-Chains fungieren) ist ein bemerkenswerter Fall von TEE-Integration auf Layer-1-Ebene.

Ein weiteres Projekt mit Cosmos-Bezug ist das Oasis Network (obwohl es nicht auf dem Cosmos SDK aufbaut, wurde es von einigen der gleichen Personen entworfen, die zu Tendermint beigetragen haben, und teilt ein ähnliches Ethos einer modularen Architektur). Oasis ist eigenständig, kann aber über Bridges usw. mit Cosmos verbunden werden. Sowohl Secret als auch Oasis zeigen, dass im Cosmos-Umfeld die Idee von „Datenschutz als Feature“ via TEEs genug Anklang fand, um dedizierte Netzwerke zu rechtfertigen.

Cosmos verfügt sogar über ein Konzept von „Datenschutz-Providern“ für Interchain-Anwendungen – z. B. kann eine App auf einer Chain einen Contract auf dem Secret Network via IBC aufrufen, um eine vertrauliche Berechnung durchzuführen, und das Ergebnis zurückerhalten. Diese Komponierbarkeit entwickelt sich gerade.

Zusätzlich hat das Projekt Anoma (nicht strikt Cosmos, aber im Sinne der Interoperabilität verwandt) über die Nutzung von TEEs für Intent-zentrierte Architekturen gesprochen, wenngleich dies eher theoretischer Natur ist.

Kurz gesagt: Cosmos hat mindestens eine große Chain, die TEEs vollständig nutzt (Secret), und andere, die damit interagieren, was eine gesunde Akzeptanz in diesem Bereich illustriert. Die Modularität von Cosmos könnte weitere solcher Chains ermöglichen (man könnte sich beispielsweise eine Cosmos-Zone vorstellen, die auf TEE-basierte Orakel oder Identität spezialisiert ist).

Polkadot und Substrate​

Das Design von Polkadot erlaubt es Parachains, sich zu spezialisieren, und tatsächlich beherbergt Polkadot mehrere Parachains, die TEEs nutzen:

• Sanders Network: Bereits beschrieben; eine Parachain, die eine TEE-basierte Compute-Cloud anbietet. Sanders ist als Parachain live und stellt Dienste für andere Chains über XCMP (Cross-Chain Message Passing) bereit. Beispielsweise kann ein anderes Polkadot-Projekt eine vertrauliche Aufgabe an die Worker von Sanders auslagern und einen Beweis oder ein Ergebnis zurückerhalten. Die Token-Ökonomik von Sanders schafft Anreize für den Betrieb von TEE-Nodes, und das Projekt hat eine beachtliche Community, was auf eine starke Akzeptanz hindeutet.
• Integritee: Eine weitere Parachain, die sich auf Unternehmens- und Datenschutzlösungen mittels TEEs konzentriert. Integritee ermöglicht es Teams, eigene private Sidechains (genannt Teewasms) bereitzustellen, in denen die Ausführung in Enklaven erfolgt. Es zielt auf Anwendungsfälle wie die vertrauliche Datenverarbeitung für Unternehmen ab, die dennoch die Sicherheit von Polkadot als Anker nutzen möchten.
• /Root oder Crust?: Es gab Ideen zur Nutzung von TEEs für dezentrale Speicherung oder Random Beacons in einigen Polkadot-bezogenen Projekten. Zum Beispiel plante das Crust Network (dezentraler Speicher) ursprünglich einen TEE-basierten Proof-of-Storage (obwohl man später zu einem anderen Design überging). Und Polkadots Random-Parachain (Entropy) zog TEEs gegenüber VRFs in Erwägung.

Polkadots Vertrauen auf On-chain-Governance und Upgrades bedeutet, dass Parachains neue Technologien schnell integrieren können. Sowohl Sanders und Integritee haben Upgrades durchlaufen, um ihre TEE-Integration zu verbessern (z. B. die Unterstützung neuer SGX-Funktionen oder die Verfeinerung von Attestierungsmethoden). Die Web3 Foundation finanzierte zudem frühere Bemühungen an Substrate-basierten TEE-Projekten wie SubstraTEE (ein früher Prototyp, der die Off-chain-Ausführung von Contracts in TEEs mit On-chain-Verifizierung demonstrierte).

Das Polkadot-Ökosystem zeigt somit mehrere unabhängige Teams, die auf TEE-Technologie setzen, was auf einen positiven Trend hindeutet. Es wird zu einem Verkaufsargument für Polkadot, dass man sagen kann: „Wenn Sie vertrauliche Smart Contracts oder Off-chain-Berechnungen benötigen, haben wir Parachains dafür.“

Andere Ökosysteme und allgemeine Einführung​

• Unternehmen und Konsortien: Außerhalb des öffentlichen Krypto-Sektors haben Hyperledger und Unternehmens-Chains TEEs stetig für zugangsbeschränkte Umgebungen übernommen. Beispielsweise testete der Basler Ausschuss eine TEE-basierte Blockchain für Handelsfinanzierung. Das allgemeine Muster ist: Wo Datenschutz oder Vertraulichkeit ein Muss sind und die Teilnehmer bekannt sind (sodass sie vielleicht sogar kollektiv in Hardware-Sicherheitsmodule investieren), finden TEEs ein ideales Zuhause. Diese machen vielleicht keine Schlagzeilen in den Krypto-Nachrichten, aber in Sektoren wie Lieferketten, Bankenkonsortien oder Netzwerken zum Austausch von Gesundheitsdaten sind TEEs oft die erste Wahl (als Alternative dazu, einfach einem Dritten zu vertrauen oder komplexe Kryptografie einzusetzen).

• Layer-1-Lösungen außerhalb von Ethereum: Einige neuere L1-Lösungen haben mit TEEs experimentiert. Das NEAR Protocol hatte ein frühes Konzept eines TEE-basierten Shards für private Contracts (noch nicht implementiert). Celo zog TEEs für Light-Client-Beweise in Betracht (ihre Plumo-Proofs basieren jetzt auf SNARKs, aber man untersuchte SGX, um Chain-Daten für Mobilgeräte zu komprimieren). Concordium, eine regulierte Datenschutz-L1, verwendet ZK für Anonymität, erforscht aber auch TEEs für die Identitätsprüfung. Dfinity/Internet Computer verwendet sichere Enklaven in seinen Node-Maschinen, allerdings für das Bootstrapping von Vertrauen (nicht für die Contract-Ausführung, da deren „Chain Key“-Kryptografie dies übernimmt).

• Bitcoin: Während Bitcoin selbst keine TEEs verwendet, gab es Nebenprojekte. Zum Beispiel TEE-basierte Custody-Lösungen (wie Vault-Systeme) für Bitcoin-Keys oder bestimmte Vorschläge in DLC (Discrete Log Contracts), Orakel zu verwenden, die durch TEEs gesichert sein könnten. Generell ist die Bitcoin-Community konservativer und würde Intel nicht ohne Weiteres als Teil des Konsenses vertrauen, aber als ergänzende Technologie (Hardware-Wallets mit Secure Elements) ist sie bereits akzeptiert.

• Regulierungsbehörden und Regierungen: Ein interessanter Aspekt der Einführung: Einige Forschungen zu CBDCs (zentralbankgestützte digitale Währungen) haben TEEs untersucht, um Datenschutz durchzusetzen und gleichzeitig Prüfbarkeit zu ermöglichen. Beispielsweise führte die Banque de France Experimente durch, bei denen ein TEE verwendet wurde, um bestimmte Compliance-Prüfungen für ansonsten private Transaktionen durchzuführen. Dies zeigt, dass selbst Regulierungsbehörden TEEs als einen Weg sehen, Datenschutz mit Aufsicht in Einklang zu bringen – man könnte eine CBDC haben, bei der Transaktionen für die Öffentlichkeit verschlüsselt sind, aber eine Regulierungs-Enklave sie unter bestimmten Bedingungen überprüfen kann (dies ist hypothetisch, wird aber in politischen Kreisen diskutiert).

• Metriken zur Einführung: Die Einführung lässt sich schwer quantifizieren, aber wir können auf Indikatoren wie die Anzahl der Projekte, investierte Mittel und die Verfügbarkeit von Infrastruktur blicken. In dieser Hinsicht haben wir heute (2025): mindestens 3-4 öffentliche Chains (Secret, Oasis, Sanders, Integritee, Automata als Off-chain), die explizit TEEs nutzen; große Orakel-Netzwerke, die sie integrieren; große Technologieunternehmen, die Confidential Computing unterstützen (Microsoft Azure und Google Cloud bieten TEE-VMs an – und diese Dienste werden von Blockchain-Nodes als Optionen genutzt). Das Confidential Computing Consortium umfasst mittlerweile Mitglieder mit Blockchain-Fokus (Ethereum Foundation, Chainlink, Fortanix etc.), was eine branchenübergreifende Zusammenarbeit zeigt. All dies deutet auf eine wachsende, aber nischige Einführung hin – TEEs sind im Web3 noch nicht allgegenwärtig, aber sie haben sich wichtige Nischen dort erschlossen, wo Datenschutz und sichere Off-chain-Berechnungen erforderlich sind.

Dies hat einen positiven regulatorischen Aspekt: Einige Aufsichtsbehörden haben angedeutet, dass Lösungen wie TEEs (und verwandte Konzepte des Confidential Computing) vorteilhaft sind, da sie die technische Durchsetzung des Datenschutzes gewährleisten. Wir haben gesehen, dass das Weltwirtschaftsforum und andere Organisationen TEEs als Mittel hervorheben, um „Privacy by Design“ in Blockchain-Systeme zu integrieren (im Grunde wird die Compliance direkt auf Protokollebene eingebettet). Aus geschäftlicher Sicht können TEEs somit die institutionelle Akzeptanz beschleunigen, indem sie eines der Haupthindernisse (Datenvertraulichkeit) beseitigen. Unternehmen sind eher bereit, Blockchain zu nutzen oder darauf aufzubauen, wenn sie wissen, dass es eine Hardware-Sicherung für ihre Daten gibt.

Ein weiterer Compliance-Aspekt ist die Auditierbarkeit und Aufsicht. Unternehmen benötigen oft Audit-Protokolle und die Möglichkeit, Prüfern gegenüber nachzuweisen, dass sie die Kontrolle über die Daten haben. TEEs können hier tatsächlich helfen, indem sie Attestierungsberichte und sichere Protokolle darüber erstellen, worauf zugegriffen wurde. Beispielsweise bietet das „durable logging“ von Oasis in einer Enklave ein manipulationssicheres Protokoll sensibler Operationen. Ein Unternehmen kann dieses Protokoll den Regulierungsbehörden vorlegen, um zu beweisen, dass beispielsweise nur autorisierter Code ausgeführt wurde und nur bestimmte Abfragen zu Kundendaten erfolgt sind. Diese Art von attestiertem Auditing könnte Regulierungsbehörden mehr überzeugen als ein traditionelles System, bei dem man den Protokollen von Systemadministratoren vertrauen muss.

Vertrauen und Haftung​

Auf der anderen Seite verändert die Einführung von TEEs die Vertrauensstruktur und damit das Haftungsmodell in Blockchain-Lösungen. Wenn eine DeFi-Plattform ein TEE verwendet und aufgrund eines Hardwarefehlers etwas schiefgeht, wer ist dann verantwortlich? Stellen Sie sich ein Szenario vor, in dem ein Intel-SGX-Fehler zum Durchsickern von Details geheimer Swap-Transaktionen führt, wodurch Benutzer Geld verlieren (z. B. durch Front-Running etc.). Die Benutzer haben den Sicherheitsversprechen der Plattform vertraut. Liegt der Fehler bei der Plattform oder bei Intel? Rechtlich gesehen könnten Benutzer gegen die Plattform vorgehen (die wiederum gegen Intel vorgehen müsste). Dies verkompliziert die Angelegenheit, da ein Technologieanbieter eines Drittanbieters (der CPU-Hersteller) tief in das Sicherheitsmodell integriert ist. Unternehmen, die TEEs einsetzen, müssen dies in Verträgen und Risikobewertungen berücksichtigen. Einige könnten Garantien oder Support von Hardwareherstellern verlangen, wenn sie deren TEEs in kritischen Infrastrukturen einsetzen.

Es gibt auch Zentralisierungsbedenken: Wenn die Sicherheit einer Blockchain von der Hardware eines einzelnen Unternehmens (Intel oder AMD) abhängt, könnten Regulierungsbehörden dies skeptisch betrachten. Könnte beispielsweise eine Regierung dieses Unternehmen vorladen oder zwingen, bestimmte Enklaven zu kompromittieren? Dies ist keine rein theoretische Sorge – man denke an Exportkontrollgesetze: Hochwertige Verschlüsselungshardware kann reguliert werden. Wenn ein großer Teil der Krypto-Infrastruktur auf TEEs angewiesen ist, ist es denkbar, dass Regierungen versuchen könnten, Backdoors einzuführen (obwohl es dafür keine Beweise gibt, zählt die Wahrnehmung). Einige Datenschutzbefürworter weisen Regulierungsbehörden darauf hin, dass TEEs das Vertrauen konzentrieren und die Behörden sie daher eher sorgfältig prüfen sollten. Umgekehrt könnten Regulierungsbehörden, die mehr Kontrolle wünschen, TEEs gegenüber mathematikbasiertem Datenschutz wie ZK bevorzugen, da bei TEEs zumindest die Vorstellung besteht, dass Strafverfolgungsbehörden bei absolutem Bedarf mit einer gerichtlichen Anordnung an den Hardwarehersteller herantreten könnten (z. B. um einen Master-Attestierungsschlüssel oder Ähnliches zu erhalten – nicht, dass dies einfach oder wahrscheinlich wäre, aber es ist ein Weg, der bei ZK nicht existiert). Daher kann die regulatorische Aufnahme geteilt sein: Datenschutzbehörden sind pro-TEE für die Compliance, während die Strafverfolgung vorsichtig optimistisch sein könnte, da TEEs nicht in dem Maße „im Dunkeln bleiben“ wie starke Verschlüsselung – es gibt einen theoretischen Hebel (die Hardware), an dem sie versuchen könnten zu ziehen.

Unternehmen müssen dies navigieren, indem sie sich möglicherweise um Zertifizierungen bemühen. Es gibt Sicherheitszertifizierungen wie FIPS 140 oder Common Criteria für Hardwaremodule. Derzeit verfügen SGX und andere über einige Zertifizierungen (zum Beispiel hatte SGX Common Criteria EAL-Zertifizierungen für bestimmte Anwendungen). Wenn eine Blockchain-Plattform darauf verweisen kann, dass die Enklaven-Technologie nach einem hohen Standard zertifiziert ist, fühlen sich Regulierungsbehörden und Partner möglicherweise wohler. Ein CBDC-Projekt könnte beispielsweise verlangen, dass jedes verwendete TEE FIPS-zertifiziert ist, damit sie der Zufallszahlengenerierung usw. vertrauen können. Dies führt zusätzliche Prozesse ein und beschränkt die Auswahl möglicherweise auf bestimmte Hardwareversionen.

Ökosystem- und Kostenüberlegungen​

Aus geschäftlicher Sicht könnte der Einsatz von TEEs die Kostenstruktur eines Blockchain-Betriebs beeinflussen. Knoten müssen über spezifische CPUs verfügen (die teurer oder weniger energieeffizient sein können). Dies könnte höhere Cloud-Hosting-Rechnungen oder Investitionsausgaben bedeuten. Wenn ein Projekt beispielsweise Intel Xeon mit SGX für alle Validatoren vorschreibt, ist das eine Einschränkung – Validatoren können nicht einfach jeder mit einem Raspberry Pi oder einem alten Laptop sein; sie benötigen diese spezielle Hardware. Dies kann zentralisieren, wer teilnehmen kann (was möglicherweise diejenigen bevorzugt, die sich High-End-Server leisten können oder Cloud-Anbieter nutzen, die SGX-VMs anbieten). In extremen Fällen könnte dies das Netzwerk dazu drängen, eher zugangsbeschränkt zu sein oder sich auf Cloud-Anbieter zu verlassen, was einen Abwägungsprozess bei der Dezentralisierung und ein geschäftliches Manko darstellt (das Netzwerk müsste möglicherweise Knotenanbieter subventionieren).

Andererseits könnten einige Unternehmen dies akzeptabel finden, weil sie bekannte Validatoren wollen oder eine Zulassungsliste haben (insbesondere in Unternehmenskonsortien). In öffentlichen Kryptonetzwerken hat dies jedoch zu Debatten geführt – z. B. als SGX erforderlich wurde, fragten die Leute: „Bedeutet das, dass nur noch große Rechenzentren Knoten betreiben werden?“ Das ist etwas, das die Stimmung in der Community und damit die Marktakzeptanz beeinflusst. Krypto-Puristen könnten beispielsweise eine Chain meiden, die TEEs erfordert, und sie als „weniger vertrauenswürdig“ oder zu zentralisiert bezeichnen. Daher müssen Projekte PR und Community-Aufklärung betreiben und klarmachen, wie die Vertrauensannahmen aussehen und warum es dennoch sicher ist. Wir haben gesehen, wie das Secret Network FUD adressiert hat, indem es die strenge Überwachung von Intel-Updates erklärte und darauf hinwies, dass Validatoren geslasht werden, wenn sie ihre Enklaven nicht aktualisieren usw. – im Grunde wurde eine soziale Vertrauensebene über das Hardware-Vertrauen gelegt.

Ein weiterer Aspekt sind Partnerschaften und Support. Das geschäftliche Ökosystem rund um TEEs umfasst große Tech-Unternehmen (Intel, AMD, ARM, Microsoft, Google usw.). Blockchain-Projekte, die TEEs nutzen, gehen oft Partnerschaften mit diesen ein (z. B. iExec mit Intel, das Secret Network mit Intel an Verbesserungen der Attestierung, Oasis mit Microsoft an vertraulicher KI usw.). Diese Partnerschaften können Finanzierung, technische Unterstützung und Glaubwürdigkeit bieten. Es ist ein strategischer Punkt: Die Ausrichtung auf die Confidential-Computing-Branche kann Türen öffnen (für Finanzierungen oder Unternehmenspiloten), bedeutet aber auch, dass sich ein Krypto-Projekt mit großen Konzernen abstimmt, was ideologische Auswirkungen in der Community hat.

Regulatorische Unsicherheiten​

Mit dem Wachstum von Blockchain-Anwendungen, die TEEs nutzen, könnten neue regulatorische Fragen auftauchen. Zum Beispiel:

• Datenjurisdiktion: Wenn Daten innerhalb eines TEE in einem bestimmten Land verarbeitet werden, gelten sie dann als „in diesem Land verarbeitet“ oder als nirgendwo (da sie verschlüsselt sind)? Einige Datenschutzgesetze verlangen, dass die Daten von Bürgern bestimmte Regionen nicht verlassen. TEEs könnten die Grenzen verwischen – man könnte eine Enklave in einer Cloud-Region haben, aber nur verschlüsselte Daten gehen hinein/hinaus. Regulierungsbehörden müssen möglicherweise klären, wie sie eine solche Verarbeitung betrachten.
• Exportkontrollen: Fortgeschrittene Verschlüsselungstechnologie kann Exportbeschränkungen unterliegen. TEEs beinhalten die Verschlüsselung von Arbeitsspeicher – historisch gesehen war dies kein Problem (da CPUs mit diesen Funktionen weltweit verkauft werden), aber falls sich das jemals ändern sollte, könnte dies die Lieferkette beeinträchtigen. Zudem könnten einige Länder die Nutzung ausländischer TEEs aus Gründen der nationalen Sicherheit verbieten oder davon abraten (z. B. hat China ein eigenes Äquivalent zu SGX, da sie Intel nicht vertrauen, und könnten SGX für sensible Anwendungen nicht zulassen).
• Rechtlicher Zwang: Ein Szenario: Könnte eine Regierung einen Knotenbetreiber per Vorladung zwingen, Daten aus einer Enklave zu extrahieren? Normalerweise können sie das nicht, da selbst der Betreiber nicht hineinsehen kann. Aber was, wenn sie Intel für einen bestimmten Attestierungsschlüssel vorladen? Das Design von Intel ist so ausgelegt, dass selbst sie den Speicher der Enklave nicht entschlüsseln können (sie geben Schlüssel an die CPU aus, die die Arbeit erledigt). Aber wenn eine Hintertür existierte oder eine spezielle Firmware von Intel signiert werden könnte, um den Speicher auszulesen, wäre das ein hypothetisches Szenario, das die Menschen beunruhigt. Rechtlich gesehen könnte ein Unternehmen wie Intel sich weigern, wenn es aufgefordert würde, seine Sicherheit zu untergraben (sie würden es wahrscheinlich tun, um das Vertrauen in ihr Produkt nicht zu zerstören). Allein die Möglichkeit könnte jedoch in regulatorischen Diskussionen über den rechtmäßigen Zugriff auftauchen. Unternehmen, die TEEs einsetzen, sollten über solche Entwicklungen auf dem Laufenden bleiben, obwohl derzeit kein öffentlicher Mechanismus für Intel/AMD existiert, um Enklavendaten zu extrahieren – genau das ist ja der Punkt von TEEs.

Marktdifferenzierung und neue Dienste​

Positiv für das Geschäft ist, dass TEEs neue Produkte und Dienstleistungen ermöglichen, die monetarisiert werden können. Zum Beispiel:

• Marktplätze für vertrauliche Daten: Wie iExec, das Ocean Protocol und andere festgestellt haben, besitzen Unternehmen wertvolle Daten, die sie monetarisieren könnten, wenn sie Garantien hätten, dass diese nicht durchsickern. TEEs ermöglichen das „Mieten von Daten“, wobei die Daten die Enklave nie verlassen, sondern nur die daraus gewonnenen Erkenntnisse. Dies könnte neue Einnahmequellen und Geschäftsmodelle erschließen. Wir sehen Start-ups im Web3-Bereich, die Unternehmen Dienstleistungen für vertrauliches Rechnen anbieten und im Grunde die Idee verkaufen: „Erhalten Sie Erkenntnisse aus der Blockchain oder unternehmensübergreifenden Daten, ohne etwas preiszugeben.“
• Enterprise DeFi: Finanzinstitute nennen oft den Mangel an Privatsphäre als Grund, sich nicht an DeFi oder öffentlichen Blockchains zu beteiligen. Wenn TEEs die Vertraulichkeit für ihre Positionen oder Trades garantieren können, könnten sie teilnehmen und so mehr Liquidität und Geschäft in das Ökosystem bringen. Projekte, die darauf abzielen (wie die geheimen Kredite von Secret oder das private AMM von Oasis mit Compliance-Kontrollen), positionieren sich, um institutionelle Nutzer anzuziehen. Wenn dies gelingt, kann dies ein bedeutender Markt sein (man stelle sich institutionelle AMM-Pools vor, in denen Identitäten und Beträge abgeschirmt sind, aber eine Enklave sicherstellt, dass Compliance-Prüfungen wie AML intern durchgeführt werden – das ist ein Produkt, das unter regulatorischer Sicherheit viel Geld in DeFi bringen könnte).
• Versicherung und Risikomanagement: Da TEEs bestimmte Risiken verringern (wie die Manipulation von Orakeln), könnten wir niedrigere Versicherungsprämien oder neue Versicherungsprodukte für Smart-Contract-Plattformen sehen. Umgekehrt führen TEEs neue Risiken ein (wie das technische Versagen von Enklaven), die selbst versicherbare Ereignisse sein könnten. Es gibt einen entstehenden Bereich der Krypto-Versicherung; es wird interessant sein zu sehen, wie sie mit TEE-abhängigen Systemen umgehen. Eine Plattform könnte damit werben, dass sie TEEs einsetzt, um das Risiko von Datenschutzverletzungen zu senken, was sie einfacher oder billiger versicherbar macht und ihr einen Wettbewerbsvorteil verschafft.

Zusammenfassend lässt sich sagen, dass es in der geschäftlichen und regulatorischen Landschaft von TEE-gestütztem Web3 darum geht, Vertrauen und Innovation in Einklang zu bringen. TEEs bieten einen Weg, Gesetze einzuhalten und Anwendungsfälle für Unternehmen zu erschließen (ein großes Plus für die Akzeptanz im Mainstream), bringen aber auch eine Abhängigkeit von Hardwareanbietern und Komplexitäten mit sich, die transparent verwaltet werden müssen. Stakeholder müssen sowohl mit Tech-Giganten (für den Support) als auch mit Regulierungsbehörden (für Klarheit und Sicherheit) zusammenarbeiten, um das Potenzial von TEEs in der Blockchain-Technologie voll auszuschöpfen. Wenn dies gut umgesetzt wird, könnten TEEs ein Eckpfeiler sein, der es der Blockchain ermöglicht, sich tief in Branchen zu integrieren, die mit sensiblen Daten arbeiten, und so die Reichweite von Web3 in Bereiche auszudehnen, die zuvor aufgrund von Datenschutzbedenken tabu waren.

Fazit​

Trusted Execution Environments haben sich als eine leistungsstarke Komponente im Web3-Instrumentarium herauskristallisiert und ermöglichen eine neue Klasse von dezentralen Anwendungen, die Vertraulichkeit und sichere Off-Chain-Berechnungen erfordern. Wir haben gesehen, dass TEEs wie Intel SGX, ARM TrustZone und AMD SEV eine hardware-isolierte „Safe Box“ für Berechnungen bieten, und diese Eigenschaft wurde für datenschutzfreundliche Smart Contracts, verifizierbare Oracles, skalierbare Off-Chain-Verarbeitung und mehr genutzt. Projekte über verschiedene Ökosysteme hinweg – von den privaten Kontrakten von Secret Network auf Cosmos über die vertraulichen ParaTimes von Oasis bis hin zur TEE-Cloud von Sanders auf Polkadot und dem Off-Chain-Marktplatz von iExec auf Ethereum – demonstrieren die vielfältigen Möglichkeiten, wie TEEs in Blockchain-Plattformen integriert werden.

Technisch gesehen bieten TEEs überzeugende Vorteile in Bezug auf Geschwindigkeit und starke Datenvertraulichkeit, bringen jedoch auch eigene Herausforderungen mit sich: die Notwendigkeit, Hardware-Anbietern zu vertrauen, potenzielle Seitenkanal-Schwachstellen sowie Hürden bei der Integration und Komponierbarkeit. Wir haben TEEs mit kryptografischen Alternativen (ZKPs, FHE, MPC) verglichen und festgestellt, dass jede ihre Nische hat: TEEs glänzen durch Leistung und Benutzerfreundlichkeit, während ZK und FHE maximale Vertrauenslosigkeit bei hohen Kosten bieten und MPC das Vertrauen unter den Teilnehmern verteilt. Tatsächlich sind viele wegweisende Lösungen hybrid und nutzen TEEs zusammen mit kryptografischen Methoden, um das Beste aus beiden Welten zu erhalten.

Die Akzeptanz von TEE-basierten Lösungen wächst stetig. Ethereum dApps nutzen TEEs für die Oracle-Sicherheit und private Berechnungen, Cosmos und Polkadot bieten native Unterstützung über spezialisierte Chains, und Bemühungen im Bereich der Enterprise-Blockchains setzen auf TEEs zur Einhaltung von Compliance-Vorgaben. Geschäftlich gesehen können TEEs eine Brücke zwischen dezentraler Technologie und Regulierung schlagen – sie ermöglichen den Umgang mit sensiblen Daten On-Chain unter den Schutzmaßnahmen von Hardware-Sicherheit, was die Tür für institutionelle Nutzung und neue Dienste öffnet. Gleichzeitig bedeutet die Nutzung von TEEs, sich auf neue Vertrauensparadigmen einzulassen und sicherzustellen, dass das Dezentralisierungs-Ethos der Blockchain nicht durch undurchsichtiges Silizium untergraben wird.

Zusammenfassend lässt sich sagen, dass Trusted Execution Environments eine entscheidende Rolle in der Evolution von Web3 spielen: Sie adressieren einige der dringlichsten Bedenken hinsichtlich Datenschutz und Skalierbarkeit, und obwohl sie kein Allheilmittel sind (und nicht ohne Kontroversen bleiben), erweitern sie die Möglichkeiten dezentraler Anwendungen erheblich. Da die Technologie reift – mit Verbesserungen in der Hardware-Sicherheit und Standards für die Attestierung – und da immer mehr Projekte ihren Wert unter Beweis stellen, können wir erwarten, dass TEEs (zusammen mit ergänzenden kryptografischen Technologien) zu einer Standardkomponente von Blockchain-Architekturen werden, die darauf abzielen, das volle Potenzial von Web3 auf sichere und vertrauenswürdige Weise zu erschließen. Die Zukunft hält wahrscheinlich schichtbasierte Lösungen bereit, bei denen Hardware und Kryptografie Hand in Hand arbeiten, um Systeme zu liefern, die sowohl performant als auch nachweislich sicher sind und gleichermaßen den Anforderungen von Nutzern, Entwicklern und Regulierungsbehörden gerecht werden.

Quellen: Die Informationen in diesem Bericht wurden aus einer Vielzahl aktueller Quellen zusammengetragen, darunter offizielle Projektdokumentationen und Blogs, Branchenanalysen und akademische Forschung, wie im gesamten Text zitiert. Zu den bemerkenswerten Referenzen gehören der Metaschool 2025 Leitfaden zu TEEs in Web3, Vergleiche von Sanders Network, technische Einblicke von ChainCatcher und anderen zu FHE / TEE / ZKP / MPC sowie Erklärungen zur regulatorischen Compliance von Binance Research und viele andere. Diese Quellen bieten weitere Details und werden Lesern empfohlen, die bestimmte Aspekte vertiefen möchten.

Am 7. Mai 2025 wurde Ethereums Pectra-Upgrade (Prague + Electra) im Mainnet aktiviert. Zu den für Entwickler sichtbarsten Änderungen gehört EIP-7702, das einem extern besessenen Konto (EOA) ermöglicht, Smart-Contract-Logik zu „implementieren“ – ohne Gelder zu migrieren oder Adressen zu ändern. Wenn Sie Wallets, DApps oder Relayer entwickeln, eröffnet dies einen einfacheren Weg zur Smart-Account-UX.

Im Folgenden finden Sie einen prägnanten, implementierungszentrierten Leitfaden: Was tatsächlich ausgeliefert wurde, wie 7702 funktioniert, wann Sie es gegenüber reinem ERC-4337 wählen sollten und ein sofort anpassbares Code-Gerüst.

Was tatsächlich ausgeliefert wurde​

• EIP-7702 ist im finalen Umfang von Pectra enthalten. Das Meta-EIP für den Pectra-Hardfork listet 7702 offiziell unter den enthaltenen Änderungen auf.
• Aktivierungsdetails: Pectra wurde am 7. Mai 2025 im Mainnet bei Epoch 364032 aktiviert, nach erfolgreichen Aktivierungen auf allen wichtigen Testnets.
• Hinweis zur Toolchain: Solidity v0.8.30 hat sein Standard-EVM-Ziel für die Pectra-Kompatibilität auf prague aktualisiert. Sie müssen Ihre Compiler und CI-Pipelines aktualisieren, insbesondere wenn Sie bestimmte Versionen festlegen.

EIP-7702 – Funktionsweise (Grundlagen)​

EIP-7702 führt einen neuen Transaktionstyp und einen Mechanismus ein, mit dem ein EOA seine Ausführungslogik an einen Smart Contract delegieren kann.

• Neuer Transaktionstyp (0x04): Eine Typ-4-Transaktion enthält ein neues Feld namens authorization_list. Diese Liste enthält ein oder mehrere Autorisierungs-Tupel – (chain_id, address, nonce, y_parity, r, s) – jeweils signiert mit dem privaten Schlüssel des EOA. Wenn diese Transaktion verarbeitet wird, schreibt das Protokoll einen Delegationsindikator in das Code-Feld des EOA: 0xef0100 || address. Von diesem Zeitpunkt an werden alle Aufrufe an das EOA an die angegebene address (die Implementierung) weitergeleitet, aber sie werden im Speicher- und Kontostandkontext des EOA ausgeführt. Diese Delegation bleibt aktiv, bis sie explizit geändert wird.
• Kettenumfang: Eine Autorisierung kann kettenspezifisch sein, indem eine chain_id angegeben wird, oder sie kann für alle Ketten gelten, wenn chain_id auf 0 gesetzt ist. Dies ermöglicht es Ihnen, denselben Implementierungsvertrag über mehrere Netzwerke hinweg bereitzustellen, ohne dass Benutzer für jedes Netzwerk eine neue Autorisierung unterzeichnen müssen.
• Widerruf: Um ein EOA auf sein ursprüngliches, nicht-programmierbares Verhalten zurückzusetzen, senden Sie einfach eine weitere 7702-Transaktion, bei der die Implementierungs-address auf die Null-Adresse gesetzt ist. Dies löscht den Delegationsindikator.
• Selbstfinanziert vs. weitergeleitet: Ein EOA kann die Typ-4-Transaktion selbst senden, oder ein Drittanbieter-Relayer kann sie im Namen des EOA senden. Letzteres ist üblich, um eine gaslose Benutzererfahrung zu schaffen. Die Nonce-Handhabung unterscheidet sich geringfügig je nach Methode, daher ist es wichtig, Bibliotheken zu verwenden, die diese Unterscheidung korrekt verwalten.

Verschiebung des Sicherheitsmodells: Da der ursprüngliche private Schlüssel des EOA weiterhin existiert, kann er Smart-Contract-Regeln (wie Social Recovery oder Ausgabenlimits) jederzeit außer Kraft setzen, indem er eine neue 7702-Transaktion zur Änderung der Delegation übermittelt. Dies ist eine grundlegende Verschiebung. Verträge, die sich auf tx.origin verlassen, um zu überprüfen, ob ein Aufruf von einem EOA stammt, müssen neu geprüft werden, da 7702 diese Annahmen brechen kann. Überprüfen Sie Ihre Abläufe entsprechend.

7702 oder ERC-4337? (Und wann man sie kombiniert)​

Sowohl EIP-7702 als auch ERC-4337 ermöglichen Account Abstraction, dienen aber unterschiedlichen Zwecken.

• Wählen Sie EIP-7702, wenn…
  • Sie eine sofortige Smart-Account-UX für bestehende EOAs bereitstellen möchten, ohne Benutzer zum Migrieren von Geldern oder zum Ändern von Adressen zu zwingen.
  • Sie konsistente Adressen über Ketten hinweg benötigen, die schrittweise mit neuen Funktionen erweitert werden können.
  • Sie Ihren Übergang zur Account Abstraction schrittweise gestalten möchten, beginnend mit einfachen Funktionen und im Laufe der Zeit Komplexität hinzufügen.
• Wählen Sie reines ERC-4337, wenn…
  • Ihr Produkt von Anfang an volle Programmierbarkeit und komplexe Policy-Engines (z. B. Multi-Sig, erweiterte Wiederherstellung) erfordert.
  • Sie für neue Benutzer entwickeln, die keine bestehenden EOAs haben, wodurch neue Smart-Account-Adressen und die damit verbundene Einrichtung akzeptabel sind.
• Kombinieren Sie sie: Das leistungsstärkste Muster ist die Verwendung beider. Ein EOA kann eine 7702-Transaktion verwenden, um eine ERC-4337 Wallet-Implementierung als seine Logik zu bestimmen. Dies lässt das EOA wie ein 4337-Konto agieren, wodurch es gebündelt, von Paymastern gesponsert und von der bestehenden 4337-Infrastruktur verarbeitet werden kann – alles, ohne dass der Benutzer eine neue Adresse benötigt. Dies ist ein zukunftskompatibler Weg, der von den Autoren des EIP explizit gefördert wird.

Minimales 7702-Gerüst, das Sie anpassen können​

Hier ist ein praktisches Beispiel für einen Implementierungsvertrag und den clientseitigen Code zu dessen Aktivierung.

1. Ein kleiner, auditierbarer Implementierungsvertrag​

Dieser Vertragscode wird, sobald er bestimmt wurde, im Kontext des EOA ausgeführt. Halten Sie ihn klein, auditierbar und erwägen Sie, einen Upgrade-Mechanismus hinzuzufügen.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @notice Executes calls from the EOA context when designated via EIP-7702.
contract DelegatedAccount {
    // Unique storage slot to avoid collisions with other contracts.
    bytes32 private constant INIT_SLOT =
        0x3fb93b3d3dcd1d1f4b4a1a8db6f4c5d55a1b7f9ac01dfe8e53b1b0f35f0c1a01;

    event Initialized(address indexed account);
    event Executed(address indexed to, uint256 value, bytes data, bytes result);

    modifier onlyEOA() {
        // Optional: add checks to restrict who can call certain functions.
        _;
    }

    function initialize() external payable onlyEOA {
        // Set a simple one-time init flag in the EOA's storage.
        bytes32 slot = INIT_SLOT;
        assembly {
            if iszero(iszero(sload(slot))) { revert(0, 0) } // Revert if already initialized
            sstore(slot, 1)
        }
        emit Initialized(address(this));
    }

    function execute(address to, uint256 value, bytes calldata data)
        external
        payable
        onlyEOA
        returns (bytes memory result)
    {
        (bool ok, bytes memory ret) = to.call{value: value}(data);
        require(ok, "CALL_FAILED");
        emit Executed(to, value, data, ret);
        return ret;
    }

    function executeBatch(address[] calldata to, uint256[] calldata value, bytes[] calldata data)
        external
        payable
        onlyEOA
    {
        uint256 n = to.length;
        require(n == value.length && n == data.length, "LENGTH_MISMATCH");
        for (uint256 i = 0; i < n; i++) {
            (bool ok, ) = to[i].call{value: value[i]}(data[i]);
            require(ok, "CALL_FAILED");
        }
    }
}

2. Den Vertrag auf einem EOA (Typ-4-Transaktion) mit viem bestimmen​

Moderne Clients wie viem verfügen über integrierte Hilfsfunktionen zum Signieren von Autorisierungen und Senden von Typ-4-Transaktionen. In diesem Beispiel zahlt ein Relayer-Konto das Gas, um ein eoa zu aktualisieren.

import { createWalletClient, http, encodeFunctionData } from "viem";
import { sepolia } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";
import { abi, implementationAddress } from "./DelegatedAccountABI";

// 1. Define the relayer (sponsors gas) and the EOA to be upgraded
const relayer = privateKeyToAccount(process.env.RELAYER_PK as `0x${string}`);
const eoa = privateKeyToAccount(process.env.EOA_PK as `0x${string}`);

const client = createWalletClient({
  account: relayer,
  chain: sepolia,
  transport: http(),
});

// 2. The EOA signs the authorization pointing to the implementation contract
const authorization = await client.signAuthorization({
  account: eoa,
  contractAddress: implementationAddress,
  // If the EOA itself were sending this, you would add: executor: 'self'
});

// 3. The relayer sends a Type-4 transaction to set the EOA's code and call initialize()
const hash = await client.sendTransaction({
  to: eoa.address, // The destination is the EOA itself
  authorizationList: [authorization], // The new EIP-7702 field
  data: encodeFunctionData({ abi, functionName: "initialize" }),
});

// 4. Now, the EOA can be controlled via its new logic without further authorizations
// For example, to execute a transaction:
// await client.sendTransaction({
//   to: eoa.address,
//   data: encodeFunctionData({ abi, functionName: 'execute', args: [...] })
// });

3. Delegation widerrufen (Zurück zum einfachen EOA)​

Um das Upgrade rückgängig zu machen, lassen Sie das EOA eine Autorisierung unterzeichnen, die die Null-Adresse als Implementierung bestimmt, und senden Sie eine weitere Typ-4-Transaktion. Danach sollte ein Aufruf von eth_getCode(eoa.address) leere Bytes zurückgeben.

Integrationsmuster, die in der Produktion funktionieren​

• Direktes Upgrade für bestehende Benutzer: Erkennen Sie in Ihrer DApp, ob der Benutzer sich in einem Pectra-kompatiblen Netzwerk befindet. Falls ja, zeigen Sie eine optionale Schaltfläche „Konto aktualisieren“ an, die die einmalige Autorisierungssignatur auslöst. Behalten Sie Fallback-Pfade (z. B. klassisches approve + swap) für Benutzer mit älteren Wallets bei.
• Gasloses Onboarding: Verwenden Sie einen Relayer (entweder Ihr Backend oder einen Dienst), um die anfängliche Typ-4-Transaktion zu sponsern. Für fortlaufende gaslose Transaktionen leiten Sie Benutzeroperationen über einen ERC-4337-Bundler, um bestehende Paymaster und öffentliche Mempools zu nutzen.
• Kettenübergreifende Rollouts: Verwenden Sie eine chain_id = 0-Autorisierung, um denselben Implementierungsvertrag über alle Ketten hinweg zu bestimmen. Sie können dann Funktionen auf einer Pro-Kette-Basis innerhalb Ihrer Anwendungslogik aktivieren oder deaktivieren.
• Beobachtbarkeit: Ihr Backend sollte Typ-4-Transaktionen indizieren und die authorization_list parsen, um zu verfolgen, welche EOAs aktualisiert wurden. Überprüfen Sie nach einer Transaktion die Änderung, indem Sie eth_getCode aufrufen und bestätigen, dass der Code des EOA nun dem Delegationsindikator (0xef0100 || implementationAddress) entspricht.

Bedrohungsmodell & Fallstricke (Nicht überspringen)​

• Delegation ist persistent: Behandeln Sie Änderungen am Implementierungsvertrag eines EOA mit der gleichen Ernsthaftigkeit wie ein Standard-Smart-Contract-Upgrade. Dies erfordert Audits, klare Benutzerkommunikation und idealerweise einen Opt-in-Flow. Pushen Sie niemals stillschweigend neue Logik an Benutzer.
• tx.origin-Fallstricke: Jede Logik, die msg.sender == tx.origin verwendete, um sicherzustellen, dass ein Aufruf direkt von einem EOA stammte, ist nun potenziell anfällig. Dieses Muster muss durch robustere Prüfungen ersetzt werden, wie EIP-712-Signaturen oder explizite Whitelists.
• Nonce-Berechnung: Wenn ein EOA seine eigene 7702-Transaktion (executor: 'self') sponsert, interagieren seine Autorisierungs-Nonce und Transaktions-Nonce auf eine spezifische Weise. Verwenden Sie immer eine Bibliothek, die dies korrekt handhabt, um Replay-Probleme zu vermeiden.
• Verantwortung der Wallet-UX: Die EIP-7702-Spezifikation warnt davor, dass DApps Benutzer nicht auffordern sollten, beliebige Bestimmungen zu unterzeichnen. Es liegt in der Verantwortung der Wallet, vorgeschlagene Implementierungen zu prüfen und deren Sicherheit zu gewährleisten. Gestalten Sie Ihre UX so, dass sie diesem Prinzip der Wallet-vermittelten Sicherheit entspricht.

Wann 7702 ein klarer Gewinn ist​

Diese Anwendungsfälle repräsentieren die gleichen Kernvorteile, die ERC-4337 verspricht, sind aber jetzt für jedes bestehende EOA mit nur einer einzigen Autorisierung verfügbar.

• DEX-Abläufe: Ein mehrstufiger approve- und swap-Vorgang kann mit der executeBatch-Funktion zu einem einzigen Klick zusammengefasst werden.
• Spiele & Sessions: Gewähren Sie Session-Key-ähnliche Berechtigungen für eine begrenzte Zeit oder einen begrenzten Umfang, ohne dass der Benutzer eine neue Wallet erstellen und finanzieren muss.
• Unternehmen & Fintech: Ermöglichen Sie gesponserte Transaktionen und wenden Sie benutzerdefinierte Ausgabenrichtlinien an, während Sie für Buchhaltung und Identität auf jeder Kette dieselbe Unternehmensadresse beibehalten.
• L2-Bridges & Intents: Erstellen Sie reibungslosere Meta-Transaktions-Abläufe mit einer konsistenten EOA-Identität über verschiedene Netzwerke hinweg.

Bereitstellungs-Checkliste​

Protokoll​

• Stellen Sie sicher, dass Nodes, SDKs und Infrastrukturanbieter Typ-4-Transaktionen und Pectras „prague“-EVM unterstützen.
• Aktualisieren Sie Indexer und Analysetools, um das Feld authorization_list in neuen Transaktionen zu parsen.

Verträge​

• Entwickeln Sie einen minimalen, geprüften Implementierungsvertrag mit wesentlichen Funktionen (z. B. Batching, Widerruf).
• Testen Sie die Abläufe zum Widerrufen und Neubestimmen gründlich auf Testnets, bevor Sie im Mainnet bereitstellen.

Clients​

• Aktualisieren Sie clientseitige Bibliotheken (viem, ethers usw.) und testen Sie die Funktionen signAuthorization und sendTransaction.
• Überprüfen Sie, dass sowohl selbstfinanzierte als auch weitergeleitete Transaktionspfade Nonces und Replays korrekt handhaben.

Sicherheit​

• Entfernen Sie alle Annahmen, die auf tx.origin basieren, aus Ihren Verträgen und ersetzen Sie diese durch sicherere Alternativen.
• Implementieren Sie eine Überwachung nach der Bereitstellung, um unerwartete Codeänderungen bei Benutzeradressen zu erkennen und bei verdächtigen Aktivitäten zu alarmieren.

Fazit: EIP-7702 bietet einen reibungslosen Einstieg in die Smart-Account-UX für die Millionen bereits genutzter EOAs. Beginnen Sie mit einer kleinen, geprüften Implementierung, nutzen Sie einen weitergeleiteten Pfad für die gaslose Einrichtung, gestalten Sie den Widerruf klar und einfach, und Sie können 90 % der Vorteile der vollständigen Account Abstraction liefern – ohne den Aufwand von Adresswechseln und Asset-Migrationen.

Metas Stablecoin-Initiative 2025 – Ankündigungen und Projekte​

Im Mai 2025 tauchten Berichte auf, wonach Meta (ehemals Facebook) mit neuen Initiativen, die sich auf digitale Währungen konzentrieren, wieder in den Stablecoin-Markt einsteigt. Obwohl Meta keine neue eigene Währung offiziell angekündigt hat, enthüllte ein Fortune-Bericht, dass das Unternehmen Gespräche mit Krypto-Firmen über die Nutzung von Stablecoins für Zahlungen führt. Diese Gespräche sind noch vorläufig (Meta befindet sich im „Lernmodus“), markieren aber Metas ersten bedeutenden Krypto-Schritt seit dem Libra/Diem-Projekt von 2019–2022. Insbesondere beabsichtigt Meta, Stablecoins zu nutzen, um Auszahlungen für Content-Ersteller und grenzüberschreitende Überweisungen auf seinen Plattformen abzuwickeln.

Offizielle Haltung: Meta hat bis Mai 2025 keine eigene neue Kryptowährung eingeführt. Andy Stone, Metas Kommunikationsdirektor, reagierte auf die Gerüchte mit der Klarstellung, dass „Diem ‚tot‘ ist. Es gibt keinen Meta-Stablecoin.“. Dies deutet darauf hin, dass Meta, anstatt eine interne Währung wie Diem wiederzubeleben, wahrscheinlich darauf abzielt, bestehende Stablecoins (möglicherweise von Partnerfirmen ausgegeben) in sein Ökosystem zu integrieren. Tatsächlich deuten Quellen darauf hin, dass Meta mehrere Stablecoins anstelle einer einzigen proprietären Währung verwenden könnte. Kurz gesagt, das Projekt im Jahr 2025 ist kein Relaunch von Libra/Diem, sondern ein neuer Versuch, Stablecoins innerhalb von Metas Produkten zu unterstützen.

Strategische Ziele und Motivationen für Meta​

Metas erneuter Vorstoß in den Kryptobereich wird von klaren strategischen Zielen angetrieben. Das wichtigste davon ist die Reduzierung von Zahlungsreibung und -kosten bei globalen Benutzer-Transaktionen. Durch die Verwendung von Stablecoins (digitale Token, die 1:1 an Fiat-Währungen gekoppelt sind) kann Meta grenzüberschreitende Zahlungen und die Monetarisierung von Kreativen für seine über 3 Milliarden Nutzer vereinfachen. Spezifische Motivationen umfassen:

• Senkung der Zahlungskosten: Meta tätigt unzählige kleine Auszahlungen an Mitwirkende und Kreative weltweit. Stablecoin-Auszahlungen würden es Meta ermöglichen, alle in einer einzigen an den USD gekoppelten Währung zu bezahlen, wodurch hohe Gebühren für Banküberweisungen oder Währungsumrechnungen vermieden würden. Ein Kreativer in Indien oder Nigeria könnte beispielsweise einen USD-Stablecoin erhalten, anstatt sich mit kostspieligen internationalen Banküberweisungen auseinandersetzen zu müssen. Dies könnte Meta Geld sparen (weniger Bearbeitungsgebühren) und Zahlungen beschleunigen.

• Mikrozahlungen und neue Einnahmequellen: Stablecoins ermöglichen schnelle, kostengünstige Mikrotransaktionen. Meta könnte Trinkgelder, In-App-Käufe oder Umsatzbeteiligungen in winzigen Schritten (Cents oder Dollars) ohne exorbitante Gebühren ermöglichen. Das Senden weniger Dollar in Stablecoins kostet beispielsweise auf bestimmten Netzwerken nur Bruchteile eines Cents. Diese Fähigkeit ist entscheidend für Geschäftsmodelle wie das Trinkgeldgeben an Content-Ersteller, grenzüberschreitenden E-Commerce auf dem Facebook Marketplace oder den Kauf digitaler Güter im Metaverse.

• Globale Benutzerbindung: Ein in Facebook, Instagram, WhatsApp usw. integrierter Stablecoin würde als universelle digitale Währung innerhalb von Metas Ökosystem fungieren. Dies kann Nutzer und ihr Geld innerhalb von Metas Apps zirkulieren lassen (ähnlich wie WeChat WeChat Pay nutzt). Meta könnte zu einer wichtigen Fintech-Plattform werden, indem es Überweisungen, Einkäufe und Zahlungen an Kreative intern abwickelt. Ein solcher Schritt steht im Einklang mit CEO Mark Zuckerbergs langjährigem Interesse, Metas Rolle bei Finanzdienstleistungen und der Metaverse-Wirtschaft (wo digitale Währungen für Transaktionen benötigt werden) auszubauen.

• Wettbewerbsfähig bleiben: Die breitere Technologie- und Finanzbranche sieht Stablecoins zunehmend als wesentliche Infrastruktur. Konkurrenten und Finanzpartner setzen auf Stablecoins, von PayPals PYUSD-Einführung im Jahr 2023 bis hin zu den Stablecoin-Projekten von Mastercard, Visa und Stripe. Meta möchte nicht ins Hintertreffen geraten, wenn es um die Zukunft der Zahlungen geht. Der Wiedereinstieg in den Kryptobereich ermöglicht es Meta nun, von einem sich entwickelnden Markt zu profitieren (Stablecoins könnten laut Standard Chartered bis 2028 um 2 Billionen US-Dollar wachsen) und sein Geschäft über die Werbung hinaus zu diversifizieren.

Zusammenfassend lässt sich sagen, dass Metas Stablecoin-Vorstoß darauf abzielt, Kosten zu senken, neue Funktionen (schnelle globale Zahlungen) freizuschalten und Meta als wichtigen Akteur in der digitalen Wirtschaft zu positionieren. Diese Motivationen spiegeln die ursprüngliche Libra-Vision der finanziellen Inklusion wider, jedoch mit einem fokussierteren und pragmatischeren Ansatz im Jahr 2025.

Technologie- und Blockchain-Infrastrukturpläne​

Im Gegensatz zum Libra-Projekt – das die Schaffung einer brandneuen Blockchain beinhaltete – tendiert Metas Strategie für 2025 zur Nutzung bestehender Blockchain-Infrastruktur und Stablecoins. Berichten zufolge erwägt Meta die Ethereum-Blockchain als eine der Grundlagen für diese Stablecoin-Transaktionen. Ethereum ist aufgrund seiner Reife und weiten Verbreitung im Krypto-Ökosystem attraktiv. Tatsächlich plant Meta, „Stablecoins auf der Ethereum-Blockchain zu verwenden“, um seine riesige Nutzerbasis zu erreichen. Dies deutet darauf hin, dass Meta beliebte Ethereum-basierte Stablecoins (wie USDC oder USDT) in seine Apps integrieren könnte.

Meta scheint jedoch offen für einen Multi-Chain- oder Multi-Coin-Ansatz zu sein. Das Unternehmen wird „wahrscheinlich mehr als eine Art von Stablecoin“ für verschiedene Zwecke verwenden. Dies könnte Folgendes umfassen:

• Partnerschaften mit großen Stablecoin-Emittenten: Meta soll Berichten zufolge Gespräche mit Firmen wie Circle (Emittent von USDC) und anderen geführt haben. Es könnte USD Coin (USDC) und Tether (USDT), die beiden größten USD-Stablecoins, unterstützen, um Liquidität und Vertrautheit für die Nutzer zu gewährleisten. Die Integration bestehender regulierter Stablecoins würde Meta die Mühe ersparen, einen eigenen Token auszugeben, und gleichzeitig sofortige Skalierbarkeit bieten.

• Nutzung effizienter Netzwerke: Meta scheint auch an schnellen, kostengünstigen Blockchain-Netzwerken interessiert zu sein. Die Einstellung von Ginger Baker (mehr dazu weiter unten) deutet auf diese Strategie hin. Baker ist Mitglied des Vorstands der Stellar Development Foundation, und Analysten stellen fest, dass Stellars Netzwerk auf Compliance und günstige Transaktionen ausgelegt ist. Stellar unterstützt nativ regulierte Stablecoins und Funktionen wie KYC und On-Chain-Reporting. Es wird spekuliert, dass Metas Pay-Wallet Stellar für nahezu sofortige Mikrozahlungen nutzen könnte (das Senden von USDC über Stellar kostet einen Bruchteil eines Cents). Im Wesentlichen könnte Meta Transaktionen über die Blockchain leiten, die die beste Mischung aus Compliance, Geschwindigkeit und niedrigen Gebühren bietet (Ethereum für breite Kompatibilität, Stellar oder andere für Effizienz).

• Meta Pay Wallet-Transformation: Auf der Frontend-Seite wird Meta wahrscheinlich seine bestehende Meta Pay-Infrastruktur zu einem „dezentralisierungsfähigen“ digitalen Wallet aufrüsten. Meta Pay (ehemals Facebook Pay) wickelt derzeit traditionelle Zahlungen auf Metas Plattformen ab. Unter Bakers Führung soll es Kryptowährungen und Stablecoins nahtlos unterstützen. Dies bedeutet, dass Benutzer Stablecoin-Guthaben halten, an andere senden oder In-App-Auszahlungen erhalten könnten, wobei die Komplexität der Blockchain im Hintergrund verwaltet wird.

Wichtig ist, dass Meta dieses Mal keine neue Währung oder Blockchain von Grund auf neu aufbaut. Durch die Verwendung bewährter öffentlicher Blockchains und von Partnern ausgegebener Währungen kann Meta die Stablecoin-Funktionalität schneller und (hoffentlich) mit weniger regulatorischem Widerstand einführen. Der Technologieplan konzentriert sich auf Integration statt auf Erfindung – Stablecoins werden so in Metas Produkte integriert, dass es sich für die Nutzer natürlich anfühlt (z. B. könnte ein WhatsApp-Nutzer eine USDC-Zahlung so einfach senden wie ein Foto).

Diem/Novi wiederbeleben oder neu anfangen?​

Metas aktuelle Initiative unterscheidet sich deutlich von seinen früheren Libra/Diem-Bemühungen. Libra (2019 angekündigt) war ein ehrgeiziger Plan für eine von Facebook geführte globale Währung, die durch einen Korb von Vermögenswerten gedeckt und von einem Unternehmensverband verwaltet wurde. Sie wurde später in Diem (einen an den USD gekoppelten Stablecoin) umbenannt, aber letztendlich Anfang 2022 inmitten regulatorischer Gegenreaktionen eingestellt. Novi, das begleitende Krypto-Wallet, wurde kurzzeitig getestet, aber ebenfalls eingestellt.

Im Jahr 2025 belebt Meta Diem/Novi nicht einfach wieder. Zu den wesentlichen Unterschieden des neuen Ansatzes gehören:

• Kein hauseigener „Meta Coin“ (vorerst): Während der Libra-Zeit schuf Facebook im Wesentlichen seine eigene Währung. Jetzt betonen Metas Sprecher, dass „kein Meta-Stablecoin“ in Entwicklung ist. Diem ist tot und wird nicht wiederbelebt. Stattdessen liegt der Fokus auf der Verwendung bestehender Stablecoins (ausgegeben von Dritten) als Zahlungsmittel. Dieser Wandel vom Emittenten zum Integrator ist eine direkte Lehre aus dem Scheitern von Libra – Meta vermeidet den Anschein, eigenes Geld zu prägen.

• Compliance-First-Strategie: Libras weitreichende Vision verunsicherte Regulierungsbehörden, die befürchteten, dass eine private Währung für Milliarden von Menschen nationale Währungen untergraben könnte. Heute agiert Meta leiser und kooperativer. Das Unternehmen stellt Compliance- und Fintech-Experten ein (zum Beispiel Ginger Baker) und wählt Technologien, die für regulatorische Konformität (z. B. Stellar) bekannt sind. Alle neuen Stablecoin-Funktionen werden wahrscheinlich eine Identitätsprüfung erfordern und den Finanzvorschriften in jeder Gerichtsbarkeit entsprechen, im Gegensatz zu Libras ursprünglich dezentralisiertem Ansatz.

• Reduzierung der Ambitionen (zumindest anfänglich): Libra zielte darauf ab, eine universelle Währung und ein Finanzsystem zu sein. Metas Bemühungen im Jahr 2025 haben einen engeren anfänglichen Umfang: Auszahlungen und Peer-to-Peer-Zahlungen innerhalb von Metas Plattformen. Indem Meta auf Zahlungen an Kreative abzielt (wie „bis zu 100 US-Dollar“ Mikrozahlungen auf Instagram), findet es einen Anwendungsfall, der Regulierungsbehörden weniger beunruhigen dürfte als eine globale Währung im vollen Umfang. Im Laufe der Zeit könnte dies erweitert werden, aber die Einführung wird voraussichtlich schrittweise und anwendungsfallorientiert erfolgen, anstatt eines Big-Bang-Starts einer neuen Währung.

• Keine öffentliche Vereinigung oder neue Blockchain: Libra wurde von einer unabhängigen Vereinigung verwaltet und erforderte Partner, die Nodes auf einer brandneuen Blockchain betrieben. Der neue Ansatz beinhaltet nicht die Schaffung eines Konsortiums oder eines benutzerdefinierten Netzwerks. Meta arbeitet direkt mit etablierten Krypto-Unternehmen zusammen und nutzt deren Infrastruktur. Diese Zusammenarbeit hinter den Kulissen bedeutet weniger Öffentlichkeit und potenziell weniger regulatorische Angriffsflächen als Libras sehr öffentliche Koalition.

Zusammenfassend lässt sich sagen, dass Meta neu anfängt und die Lehren aus Libra/Diem nutzt, um einen pragmatischeren Kurs einzuschlagen. Das Unternehmen hat sich im Wesentlichen von der Rolle des „Krypto-Emittenten“ zu der einer „krypto-freundlichen Plattform“ gewandelt. Wie ein Krypto-Analyst bemerkte, ist noch nicht entschieden, ob Meta „einen eigenen [Stablecoin] entwickelt und ausgibt oder mit jemandem wie Circle zusammenarbeitet“ – aber alle Anzeichen deuten auf Partnerschaften statt auf ein Solo-Unternehmen wie Diem hin.

Schlüsselpersonal, Partnerschaften und Kooperationen​

Meta hat strategische Neueinstellungen vorgenommen und wahrscheinlich Partnerschaften geschlossen, um diese Stablecoin-Initiative voranzutreiben. Der herausragende Personalwechsel ist die Ernennung von Ginger Baker zur Vice President of Product für Zahlungen und Krypto bei Meta. Baker kam im Januar 2025 zu Meta, um speziell „Metas Stablecoin-Erkundungen zu begleiten“. Ihr Hintergrund ist ein starker Indikator für Metas Strategie:

• Ginger Baker – Fintech-Veteranin: Baker ist eine erfahrene Führungskraft im Zahlungsverkehr. Sie arbeitete zuvor bei Plaid (als Chief Network Officer) und verfügt über Erfahrung bei Ripple, Square und Visa – allesamt wichtige Akteure im Zahlungs-/Kryptobereich. Einzigartig ist, dass sie auch im Vorstand der Stellar Development Foundation tätig war und dort eine Führungsposition innehatte. Durch die Einstellung von Baker gewinnt Meta Expertise sowohl im traditionellen Fintech-Bereich als auch in Blockchain-Netzwerken (Ripple und Stellar konzentrieren sich auf grenzüberschreitende Transaktionen und Compliance). Baker „führt nun Metas erneuerte Stablecoin-Initiativen an“, einschließlich der Transformation von Meta Pay in ein krypto-fähiges Wallet. Ihre Führung deutet darauf hin, dass Meta ein Produkt entwickeln wird, das konventionelle Zahlungen mit Krypto verbindet (wobei wahrscheinlich Dinge wie Bankintegrationen, reibungslose UX, KYC usw. neben den Blockchain-Elementen gewährleistet werden).

• Weitere Teammitglieder: Neben Baker stellt Meta „Krypto-erfahrene Personen“ für seine Teams ein, um die Stablecoin-Pläne zu unterstützen. Einige ehemalige Mitglieder des Libra/Diem-Teams könnten hinter den Kulissen beteiligt sein, obwohl viele gegangen sind (zum Beispiel verließ der ehemalige Novi-Chef David Marcus das Unternehmen, um seine eigene Krypto-Firma zu gründen, und andere wechselten zu Projekten wie Aptos). Die aktuellen Bemühungen scheinen größtenteils unter Metas bestehender Einheit Meta Financial Technologies (die Meta Pay betreibt) zu laufen. Bisher wurden im Jahr 2025 keine größeren Übernahmen von Krypto-Unternehmen angekündigt – Meta scheint sich auf interne Einstellungen und Partnerschaften zu verlassen, anstatt ein Stablecoin-Unternehmen direkt zu kaufen.

• Potenzielle Partnerschaften: Obwohl noch keine offiziellen Partner genannt wurden, haben mehrere Krypto-Firmen Gespräche mit Meta geführt. Mindestens zwei Führungskräfte von Krypto-Unternehmen bestätigten, dass sie frühe Gespräche mit Meta über Stablecoin-Auszahlungen hatten. Es ist vernünftig zu spekulieren, dass Circle (Emittent von USDC) darunter ist – der Fortune-Bericht erwähnte Circles Aktivitäten im selben Kontext. Meta könnte mit einem regulierten Stablecoin-Emittenten (wie Circle oder Paxos) zusammenarbeiten, um die Währungsausgabe und -verwahrung zu übernehmen. Zum Beispiel könnte Meta USDC durch die Zusammenarbeit mit Circle integrieren, ähnlich wie PayPal mit Paxos zusammenarbeitete, um seinen eigenen Stablecoin einzuführen. Andere Partnerschaften könnten Krypto-Infrastrukturanbieter (für Sicherheit, Verwahrung oder Blockchain-Integration) oder Fintech-Unternehmen in verschiedenen Regionen für Compliance umfassen.

• Externe Berater/Influencer: Es ist erwähnenswert, dass Metas Schritt erfolgt, während andere in der Technologie- und Finanzbranche ihre Stablecoin-Bemühungen verstärken. Unternehmen wie Stripe und Visa haben kürzlich Schritte unternommen (Stripe kaufte ein Krypto-Startup, Visa ging eine Partnerschaft mit einer Stablecoin-Plattform ein). Meta wird möglicherweise nicht formell mit diesen Unternehmen zusammenarbeiten, aber diese Branchenverbindungen (z. B. Bakers Vergangenheit bei Visa oder bestehende Geschäftsbeziehungen, die Meta mit Stripe für Zahlungen unterhält) könnten den Weg für die Stablecoin-Akzeptanz ebnen. Darüber hinaus könnten First Digital (Emittent von FDUSD) und Tether eine indirekte Zusammenarbeit sehen, wenn Meta beschließt, ihre Coins für bestimmte Märkte zu unterstützen.

Im Wesentlichen wird Metas Stablecoin-Initiative von erfahrenen Fintech-Insidern geleitet und beinhaltet wahrscheinlich eine enge Zusammenarbeit mit etablierten Krypto-Akteuren. Wir sehen eine bewusste Anstrengung, Menschen einzubeziehen, die sowohl Silicon Valley als auch Krypto verstehen. Dies ist ein gutes Zeichen dafür, dass Meta die technischen und regulatorischen Herausforderungen mit sachkundiger Führung meistern wird.

Regulierungsstrategie und Positionierung​

Regulierung ist der Elefant im Raum für Metas Krypto-Ambitionen. Nach der schmerzhaften Erfahrung mit Libra (wo globale Regulierungsbehörden und Gesetzgeber Facebooks Währung fast einstimmig ablehnten) nimmt Meta im Jahr 2025 eine sehr vorsichtige, Compliance-orientierte Haltung ein. Schlüsselelemente von Metas regulatorischer Positionierung umfassen:

• Arbeit innerhalb regulatorischer Rahmenbedingungen: Meta scheint darauf bedacht zu sein, mit den Behörden zusammenzuarbeiten, anstatt zu versuchen, sie zu umgehen. Durch die Verwendung bestehender regulierter Stablecoins (wie USDC, das den US-Bundesstaatsvorschriften und Audits entspricht) und durch die Integration von KYC/AML-Funktionen richtet sich Meta an den aktuellen Finanzregeln aus. Zum Beispiel werden Stellars Compliance-Funktionen (KYC, Sanktionsprüfung) explizit als mit Metas Bedürfnis übereinstimmend genannt, bei den Regulierungsbehörden in gutem Ansehen zu bleiben. Dies deutet darauf hin, dass Meta sicherstellen wird, dass Benutzer, die Stablecoins über seine Apps abwickeln, verifiziert werden und dass Transaktionen auf illegale Aktivitäten überwacht werden können, ähnlich wie bei jeder Fintech-App.

• Politisches Timing: Das regulatorische Klima in den USA hat sich seit den Libra-Tagen verschoben. Ab 2025 wird die Regierung von Präsident Donald Trump als krypto-freundlicher angesehen als die vorherige Biden-Regierung. Diese Änderung könnte Meta eine Öffnung bieten. Tatsächlich kommt Metas erneuter Vorstoß genau zu dem Zeitpunkt, an dem Washington aktiv über Stablecoin-Gesetze debattiert. Ein Paar Stablecoin-Gesetzesentwürfe durchlaufen den Kongress, und der GENIUS Act des Senats zielt darauf ab, Leitplanken für Stablecoins zu setzen. Meta könnte hoffen, dass ein klarerer rechtlicher Rahmen die Beteiligung von Unternehmen an digitalen Währungen legitimiert. Dies ist jedoch nicht ohne Widerstand – Senatorin Elizabeth Warren und andere Gesetzgeber haben Meta ins Visier genommen und fordern, dass große Technologieunternehmen in jedem neuen Gesetz vom Ausgeben von Stablecoins ausgeschlossen werden. Meta wird solche politischen Hürden überwinden müssen, möglicherweise indem es betont, dass es keine neue Währung ausgibt, sondern lediglich bestehende verwendet (somit technisch keine „Facebook Coin“, die den Kongress beunruhigte).

• Globale und lokale Compliance: Über die USA hinaus wird Meta die Vorschriften in jedem Markt berücksichtigen. Wenn es beispielsweise Stablecoin-Zahlungen in WhatsApp für Überweisungen einführt, könnte es dies in Ländern mit aufgeschlossenen Regulierungsbehörden testen (ähnlich wie WhatsApp Pay in Märkten wie Brasilien oder Indien mit lokaler Genehmigung eingeführt wurde). Meta könnte Zentralbanken und Finanzaufsichtsbehörden in Zielregionen einbeziehen, um sicherzustellen, dass seine Stablecoin-Integration die Anforderungen erfüllt (z. B. vollständig durch Fiat-Währung gedeckt, einlösbar und die Stabilität der lokalen Währung nicht beeinträchtigt). Der First Digital USD (FDUSD), einer der Stablecoins, die Meta unterstützen könnte, hat seinen Sitz in Hongkong und unterliegt den dortigen Treuhandgesetzen, was darauf hindeutet, dass Meta Regionen mit krypto-freundlichen Regeln (z. B. Hongkong, Singapur) für erste Phasen nutzen könnte.

• Den „Libra-Fehler“ vermeiden: Bei Libra befürchteten die Regulierungsbehörden, dass Meta eine globale Währung außerhalb staatlicher Kontrolle kontrollieren würde. Metas Strategie besteht nun darin, sich als Teilnehmer und nicht als Kontrolleur zu positionieren. Indem das Unternehmen sagt „es gibt keinen Meta-Stablecoin“, distanziert es sich von der Idee, Geld zu drucken. Stattdessen kann Meta argumentieren, dass es die Zahlungsinfrastruktur für Benutzer verbessert, analog zur Unterstützung von PayPal oder Kreditkarten. Diese Erzählung – „wir verwenden lediglich sichere, vollständig gedeckte Währungen wie USDC, um Benutzern bei Transaktionen zu helfen“ – ist wahrscheinlich die Art und Weise, wie Meta das Projekt den Regulierungsbehörden präsentieren wird, um Ängste vor einer Destabilisierung des Währungssystems zu zerstreuen.

• Compliance und Lizenzierung: Sollte Meta sich entscheiden, einen gebrandeten Stablecoin anzubieten oder die Krypto-Assets der Nutzer zu verwahren, könnte es die entsprechenden Lizenzen beantragen (z. B. als lizenzierter Geldübermittler werden, eine staatliche oder föderale Charta für die Stablecoin-Ausgabe über eine Tochtergesellschaft oder Partnerbank erhalten). Es gibt Präzedenzfälle: PayPal erhielt eine New Yorker Treuhandcharta (über Paxos) für seinen Stablecoin. Meta könnte in ähnlicher Weise eine Partnerschaft eingehen oder eine regulierte Einheit für alle Verwahrungsaspekte schaffen. Vorerst kann Meta durch die Zusammenarbeit mit etablierten Stablecoin-Emittenten und Banken auf deren behördliche Genehmigungen vertrauen.

Insgesamt kann Metas Ansatz als „regulatorische Anpassung“ verstanden werden – es versucht, das Projekt so zu gestalten, dass es in die rechtlichen Rahmenbedingungen passt, die Regulierungsbehörden geschaffen haben oder schaffen. Dies beinhaltet proaktive Kontaktaufnahme, langsames Skalieren und den Einsatz von Experten, die die Regeln kennen. Dennoch bleibt die regulatorische Unsicherheit ein Risiko. Das Unternehmen wird die Ergebnisse der Stablecoin-Gesetzesentwürfe genau beobachten und sich wahrscheinlich an politischen Diskussionen beteiligen, um sicherzustellen, dass es ohne rechtliche Hindernisse vorankommen kann.

Marktauswirkungen und Stablecoin-Landschaftsanalyse​

Metas Eintritt in den Stablecoin-Markt könnte ein Game-Changer für den Stablecoin-Markt sein, der Anfang 2025 bereits boomt. Die gesamte Marktkapitalisierung von Stablecoins erreichte im April 2025 ein Allzeithoch von rund 238–245 Milliarden US-Dollar, was etwa dem Doppelten des Vorjahres entspricht. Dieser Markt wird derzeit von einigen Schlüsselakteuren dominiert:

• Tether (USDT): Der größte Stablecoin mit fast 70 % Marktanteil und rund 148 Milliarden US-Dollar im Umlauf (Stand April). USDT wird von Tether Ltd. ausgegeben und ist im Krypto-Handel und bei der Liquidität über Börsen hinweg weit verbreitet. Er ist für weniger Transparenz bei den Reserven bekannt, hat aber seine Bindung beibehalten.

• USD Coin (USDC): Der zweitgrößte, ausgegeben von Circle (in Partnerschaft mit Coinbase) mit einem Umlauf von rund 62 Milliarden US-Dollar (≈26 % Marktanteil). USDC ist in den USA reguliert, vollständig in Bargeld und Staatsanleihen gedeckt und wird von Institutionen wegen seiner Transparenz bevorzugt. Es wird sowohl im Handel als auch in einer zunehmenden Anzahl von Mainstream-Fintech-Apps verwendet.

• First Digital USD (FDUSD): Ein neuerer Akteur (Mitte 2023 eingeführt), ausgegeben von First Digital Trust aus Hongkong. FDUSD wuchs als Alternative auf Plattformen wie Binance, nachdem regulatorische Probleme Binances eigenen BUSD trafen. Bis April 2025 betrug die Marktkapitalisierung von FDUSD etwa 1,25 Milliarden US-Dollar. Es gab einige Volatilität (verlor im April kurzzeitig seine 1-Dollar-Bindung), wird aber dafür gelobt, in einem freundlicheren regulatorischen Umfeld in Asien ansässig zu sein.

Die folgende Tabelle vergleicht Metas geplante Stablecoin-Integration mit USDT, USDC und FDUSD:

Prognostizierte Auswirkungen: Wenn Meta Stablecoin-Zahlungen erfolgreich einführt, könnte dies die Reichweite und Nutzung von Stablecoins erheblich erweitern. Metas Apps könnten Hunderte Millionen neuer Stablecoin-Nutzer an Bord holen, die noch nie zuvor Krypto verwendet haben. Diese Mainstream-Adoption könnte die gesamte Stablecoin-Marktkapitalisierung über die derzeitigen Marktführer hinaus erhöhen. Sollte Meta beispielsweise mit Circle zusammenarbeiten, um USDC in großem Umfang zu nutzen, könnte die Nachfrage nach USDC stark ansteigen – was möglicherweise die Dominanz von USDT im Laufe der Zeit herausfordern würde. Es ist plausibel, dass Meta USDC (oder welche Währung es auch immer annimmt) helfen könnte, Tethers Größe näherzukommen, indem es Anwendungsfälle außerhalb des Handels (Social Commerce, Überweisungen usw.) bereitstellt.

Andererseits könnte Metas Beteiligung Wettbewerb und Innovation unter Stablecoins anregen. Tether und andere etablierte Anbieter könnten sich anpassen, indem sie die Transparenz verbessern oder eigene Big-Tech-Allianzen bilden. Neue Stablecoins könnten entstehen, die auf soziale Netzwerke zugeschnitten sind. Auch die Unterstützung mehrerer Stablecoins durch Meta deutet darauf hin, dass keine einzelne Währung Metas Ökosystem „monopolisieren“ wird – Nutzer könnten nahtlos mit verschiedenen Dollar-Token je nach Region oder Präferenz Transaktionen durchführen. Dies könnte zu einem stärker diversifizierten Stablecoin-Markt führen, in dem die Dominanz verteilt ist.

Es ist auch wichtig, den Infrastruktur-Boost zu beachten, den Meta bieten könnte. Ein in Meta integrierter Stablecoin wird wahrscheinlich eine robuste Kapazität für Millionen täglicher Transaktionen benötigen. Dies könnte Verbesserungen an den zugrunde liegenden Blockchains vorantreiben (z. B. Ethereum Layer-2-Skalierung oder erhöhte Nutzung des Stellar-Netzwerks). Beobachter deuten bereits an, dass Metas Schritt „die Aktivität auf [Ethereum] und die Nachfrage nach ETH erhöhen“ könnte, wenn viele Transaktionen dorthin fließen. Ähnlich könnte, wenn Stellar verwendet wird, sein nativer Token XLM eine höhere Nachfrage als Gas für Transaktionen erfahren.

Schließlich ist Metas Eintritt für die Krypto-Industrie zweischneidig: Er legitimiert Stablecoins als Zahlungsmechanismus (potenziell positiv für Akzeptanz und Marktwachstum), erhöht aber auch die regulatorischen Risiken. Regierungen könnten Stablecoins stärker als Angelegenheit von nationaler Bedeutung behandeln, wenn Milliarden von Social-Media-Nutzern beginnen, damit zu handeln. Dies könnte die regulatorische Klarheit – oder die Durchgreifen – beschleunigen, je nachdem, wie Metas Einführung verläuft. In jedem Fall wird die Stablecoin-Landschaft bis Ende der 2020er Jahre wahrscheinlich durch Metas Beteiligung, zusammen mit anderen großen Akteuren wie PayPal, Visa und traditionellen Banken, die in diesen Bereich vordringen, neu gestaltet werden.

Integration in Metas Plattformen (Facebook, Instagram, WhatsApp usw.)​

Ein entscheidender Aspekt von Metas Strategie ist die nahtlose Integration von Stablecoin-Zahlungen in seine App-Familie. Ziel ist es, digitale Währungsfunktionen benutzerfreundlich in Facebook, Instagram, WhatsApp, Messenger und sogar neue Plattformen wie Threads einzubetten. So wird die Integration voraussichtlich auf jedem Dienst ablaufen:

• Instagram: Instagram ist prädestiniert, ein Testfeld für Stablecoin-Auszahlungen zu sein. Kreative auf Instagram könnten wählen, ihre Einnahmen (für Reels-Boni, Affiliate-Verkäufe usw.) in einem Stablecoin statt in lokaler Währung zu erhalten. Berichte erwähnen ausdrücklich, dass Meta möglicherweise damit beginnen wird, bis zu ~$100 an Kreative über Stablecoins auf Instagram auszuzahlen. Dies deutet auf einen Fokus auf kleine grenzüberschreitende Zahlungen hin – ideal für Influencer in Ländern, in denen der direkte Empfang von US-Dollar bevorzugt wird. Zusätzlich könnte Instagram das Trinkgeldgeben an Kreative in der App mithilfe von Stablecoins ermöglichen oder Benutzern erlauben, digitale Sammlerstücke und Dienstleistungen mit einem Stablecoin-Guthaben zu kaufen. Da Instagram bereits mit NFT-Anzeigefunktionen (im Jahr 2022) experimentiert und einen Creator-Marktplatz hat, könnte das Hinzufügen eines Stablecoin-Wallets sein Creator-Ökosystem verbessern.

• Facebook (Meta): Auf Facebook selbst könnte sich die Stablecoin-Integration in Facebook Pay/Meta Pay-Funktionen manifestieren. Nutzer auf Facebook könnten sich gegenseitig in Chats Geld mit Stablecoins senden oder Spenden an Spendenaktionen mit Krypto tätigen. Der Facebook Marketplace (wo Menschen Waren kaufen/verkaufen) könnte Stablecoin-Transaktionen unterstützen und so den grenzüberschreitenden Handel durch die Eliminierung von Währungsumtauschproblemen erleichtern. Ein weiterer Bereich sind Spiele und Apps auf Facebook – Entwickler könnten in Stablecoins ausgezahlt werden, oder In-Game-Käufe könnten einen Stablecoin für ein universelles Erlebnis nutzen. Angesichts der breiten Nutzerbasis von Facebook könnte die Integration eines Stablecoin-Wallets im Profil oder Messenger das Konzept des Sendens von „digitalen Dollars“ an Freunde und Familie schnell populär machen. Metas eigene Beiträge deuten auf die Monetarisierung von Inhalten hin: zum Beispiel die Auszahlung von Boni an Facebook-Content-Erstellern oder Stars (Facebooks Trinkgeld-Token), die in Zukunft potenziell durch Stablecoins gedeckt sein könnten.

• WhatsApp: Dies ist vielleicht die transformativste Integration. WhatsApp hat über 2 Milliarden Nutzer und wird intensiv für Messaging in Regionen genutzt, in denen Überweisungen entscheidend sind (Indien, Lateinamerika usw.). Metas Stablecoin könnte WhatsApp in eine globale Überweisungsplattform verwandeln. Nutzer könnten einen Stablecoin so einfach an einen Kontakt senden wie eine Textnachricht, wobei WhatsApp bei Bedarf den Währungstausch an beiden Enden abwickelt. Tatsächlich hat WhatsApp 2021 kurzzeitig das Novi-Wallet für das Senden eines Stablecoins (USDP) in den USA und Guatemala getestet – das Konzept ist also im kleinen Maßstab bewiesen. Jetzt könnte Meta Stablecoin-Überweisungen nativ in die WhatsApp-Benutzeroberfläche integrieren. Zum Beispiel könnte ein indischer Arbeiter in den USA USDC über WhatsApp an seine Familie in Indien senden, die es dann auszahlen oder ausgeben könnte, wenn Integrationen mit lokalen Zahlungsanbietern vorhanden sind. Dies umgeht teure Überweisungsgebühren. Abgesehen von P2P könnten kleine Unternehmen auf WhatsApp (häufig in Schwellenländern) Stablecoin-Zahlungen für Waren akzeptieren und es wie ein kostengünstiges Händlerzahlungssystem nutzen. Die Altcoin Buzz-Analyse spekuliert sogar, dass WhatsApp nach den Auszahlungen an Kreative einer der nächsten Integrationspunkte sein wird.

• Messenger: Ähnlich wie WhatsApp könnte der Facebook Messenger das Senden von Geld in Chats mit Stablecoins ermöglichen. Messenger verfügt bereits über Peer-to-Peer-Fiat-Zahlungen in den USA. Wenn dies auf Stablecoins ausgeweitet wird, könnte es Nutzer international verbinden. Man könnte sich vorstellen, dass Messenger-Chatbots oder der Kundenservice Stablecoin-Transaktionen nutzen (z. B. eine Rechnung bezahlen oder Produkte über eine Messenger-Interaktion bestellen und in Stablecoin abrechnen).

• Threads und andere: Threads (Metas Twitter-ähnliche Plattform, die 2023 eingeführt wurde) und das breitere Meta VR/Metaverse (Reality Labs) könnten ebenfalls Stablecoins nutzen. In Horizon Worlds oder anderen Metaverse-Erlebnissen könnte ein Stablecoin als In-World-Währung für den Kauf virtueller Güter, Tickets für Veranstaltungen usw. dienen und ein Echtgeldäquivalent bereitstellen, das über verschiedene Erlebnisse hinweg funktioniert. Während Metas Metaverse-Einheit derzeit Verluste macht, könnte die Integration einer währungsübergreifenden Akzeptanz in Spielen und Welten eine einheitliche Wirtschaft schaffen, die die Nutzung ankurbeln könnte (ähnlich wie Roblox Robux hat, aber im Fall von Meta wäre es ein USD-Stablecoin im Hintergrund). Dies würde Zuckerbergs Vision der Metaverse-Wirtschaft entsprechen, ohne einen neuen Token nur für VR zu schaffen.

Integrationsstrategie: Meta wird dies wahrscheinlich sorgfältig einführen. Eine plausible Reihenfolge ist:

1. Pilot-Auszahlungen an Kreative auf Instagram (begrenzte Menge, ausgewählte Regionen) – dies testet das System mit echtem Wert, aber auf kontrollierte Weise.
2. Erweiterung auf P2P-Überweisungen in Messaging-Diensten (WhatsApp/Messenger), sobald Vertrauen gewonnen wurde – beginnend mit Überweisungskorridoren oder innerhalb bestimmter Länder.
3. Händlerzahlungen und -dienste – Unternehmen auf seinen Plattformen ermöglichen, in Stablecoin zu handeln (dies könnte Partnerschaften mit Zahlungsabwicklern beinhalten, um eine einfache Umwandlung in lokale Fiat-Währung zu ermöglichen).
4. Vollständige Ökosystem-Integration – schließlich könnte das Meta Pay-Wallet eines Benutzers ein Stablecoin-Guthaben anzeigen, das überall für Facebook-Anzeigen, Instagram-Shopping, WhatsApp Pay usw. verwendet werden kann.

Es ist erwähnenswert, dass die Benutzererfahrung entscheidend sein wird. Meta wird Begriffe wie „USDC“ oder „Ethereum“ wahrscheinlich für den Durchschnittsnutzer abstrahieren. Das Wallet könnte einfach ein Guthaben in „USD“ anzeigen (im Backend von Stablecoins unterstützt), um es einfach zu halten. Nur fortgeschrittenere Benutzer könnten mit On-Chain-Funktionen (wie dem Abheben auf ein externes Krypto-Wallet) interagieren, falls dies erlaubt ist. Metas Vorteil ist seine riesige Nutzerbasis; wenn auch nur ein Bruchteil die Stablecoin-Funktion annimmt, könnte dies die aktuelle Krypto-Nutzerpopulation übertreffen.

Zusammenfassend lässt sich sagen, dass Metas Plan, Stablecoins in seine Plattformen zu integrieren, die Grenze zwischen traditionellen digitalen Zahlungen und Kryptowährungen verwischen könnte. Ein Facebook- oder WhatsApp-Nutzer könnte bald einen Stablecoin verwenden, ohne überhaupt zu merken, dass es sich um ein Krypto-Asset handelt – er wird einfach einen schnelleren, günstigeren Weg sehen, Geld zu senden und global Transaktionen durchzuführen. Diese tiefe Integration könnte Metas Apps in Märkten hervorheben, in denen die Finanzinfrastruktur kostspielig oder langsam ist, und es positioniert Meta als ernstzunehmenden Konkurrenten sowohl für Fintech-Unternehmen als auch für Krypto-Börsen im Bereich der digitalen Zahlungen.

Quellen:

• Metas Sondierungsgespräche zu Stablecoins und Einstellung eines Krypto-VP
• Metas Absicht, Stablecoins für grenzüberschreitende Auszahlungen an Kreative zu nutzen (Fortune-Bericht)
• Kommentar von Metas Kommunikationsdirektor („Diem ist tot, kein Meta-Stablecoin“)
• Analyse von Metas strategischen Motivationen (Kostenreduzierung, einheitliche Währung für Auszahlungen)
• Technologische Infrastrukturwahl – Ethereum-Integration und Stellars Compliance-Funktionen
• Ginger Bakers Rolle und Hintergrund (ehemals Plaid, Ripple, Stellar-Vorstand)
• Fortune/LinkedIn-Einblicke in Metas Krypto-Team und diskutierte Partnerschaften
• Regulatorischer Kontext: Libras Zusammenbruch im Jahr 2022 und das freundlichere Umfeld 2025 unter Trump vs. legislativer Widerstand (Senatorin Warren zum Verbot von Big Tech Stablecoins)
• Stablecoin-Marktdaten (Q2 2025): ~$238 Mrd. Marktkapitalisierung, USDT ~$148 Mrd. vs. USDC ~$62 Mrd., Wachstumstrends
• Vergleichsinformationen für USDT, USDC, FDUSD (Marktanteil, regulatorische Haltung, Emittenten)
• Integrationsdetails über Metas Produkte hinweg (Auszahlungen an Content-Ersteller, WhatsApp-Zahlungen).

Einleitung​

Ika ist ein paralleles Multi-Party Computation (MPC)-Netzwerk, das strategisch von der Sui Foundation unterstützt wird. Früher bekannt als dWallet Network, wurde Ika entwickelt, um vertrauenslose, Cross-Chain-Interoperabilität mit hoher Geschwindigkeit und Skalierbarkeit zu ermöglichen. Es erlaubt Smart Contracts (insbesondere auf der Sui-Blockchain), Vermögenswerte auf anderen Blockchains sicher zu kontrollieren und zu koordinieren, ohne traditionelle Bridges. Dieser Bericht bietet einen tiefen Einblick in Ikas technische Architektur und kryptographisches Design aus der Perspektive eines Gründers sowie eine Geschäfts- und Investitionsanalyse, die Team, Finanzierung, Tokenomics, Adoption und Wettbewerb abdeckt. Eine zusammenfassende Vergleichstabelle von Ika mit anderen MPC-basierten Netzwerken (Lit Protocol, Threshold Network und Zama) ist ebenfalls zur Kontextualisierung enthalten.

Technische Architektur und Funktionen (Gründerperspektive)​

Architektur und kryptographische Primitive​

Ikas Kerninnovation ist ein neuartiges „2PC-MPC“-Kryptographieschema – eine Zwei-Parteien-Berechnung innerhalb eines Multi-Party Computation-Frameworks. Vereinfacht ausgedrückt, umfasst der Signaturprozess immer zwei Parteien: (1) den Benutzer und (2) das Ika-Netzwerk. Der Benutzer behält einen privaten Schlüsselanteil, und das Netzwerk – bestehend aus vielen unabhängigen Nodes – hält den anderen Anteil. Eine Signatur kann nur mit Beteiligung beider Parteien erstellt werden, wodurch sichergestellt wird, dass das Netzwerk allein niemals eine Signatur ohne den Benutzer fälschen kann. Die Netzwerkseite ist keine einzelne Entität, sondern eine verteilte MPC unter N Validatoren, die gemeinsam als zweite Partei agieren. Eine Schwelle von mindestens zwei Dritteln dieser Nodes muss zustimmen (ähnlich dem Byzantine Fault Tolerance-Konsens), um den Netzwerkanteil der Signatur zu generieren. Diese verschachtelte MPC-Struktur (Benutzer + Netzwerk) macht Ika nicht-kollusiv: selbst wenn alle Ika-Nodes kolludieren, können sie keine Benutzervermögenswerte stehlen, da die Beteiligung des Benutzers (sein Schlüsselanteil) kryptographisch immer erforderlich ist. Mit anderen Worten, Ika ermöglicht „Zero-Trust“-Sicherheit und wahrt die Dezentralisierungs- und Benutzerbesitzprinzipien von Web3 – keine einzelne Entität oder kleine Gruppe kann Vermögenswerte einseitig kompromittieren.

Abbildung: Schematische Darstellung von Ikas 2PC-MPC-Architektur – der Benutzer agiert als eine Partei (hält einen privaten Schlüsselanteil) und das Ika-Netzwerk von N Validatoren bildet die andere Partei über ein MPC-Schwellenwertprotokoll (t-von-N). Dies garantiert, dass sowohl der Benutzer als auch eine Supermajorität dezentraler Nodes kooperieren müssen, um eine gültige Signatur zu erzeugen.

Technisch gesehen ist Ika als eigenständiges Blockchain-Netzwerk implementiert, das vom Sui-Codebase geforkt wurde. Es betreibt seine eigene Instanz von Suis Hochleistungs-Konsens-Engine (Mysticeti, ein DAG-basiertes BFT-Protokoll), um die MPC-Nodes zu koordinieren. Bemerkenswert ist, dass Ikas Sui-Version Smart Contracts deaktiviert hat (Ikas Chain existiert ausschließlich, um das MPC-Protokoll auszuführen) und benutzerdefinierte Module für den 2PC-MPC-Signaturalgorithmus enthält. Mysticeti bietet einen zuverlässigen Broadcast-Kanal zwischen den Nodes, der das komplexe Geflecht von Peer-to-Peer-Nachrichten ersetzt, die traditionelle MPC-Protokolle verwenden. Durch die Nutzung eines DAG-basierten Konsenses für die Kommunikation vermeidet Ika den exponentiellen Kommunikations-Overhead früherer Schwellenwert-Signaturschemata, die erforderten, dass jede von n Parteien Nachrichten an alle anderen sendet. Stattdessen senden Ikas Nodes Nachrichten über den Konsens, wodurch eine lineare Kommunikationskomplexität O(n) erreicht wird, und verwenden Batching- und Aggregationstechniken, um die Kosten pro Node nahezu konstant zu halten, selbst wenn N groß wird. Dies stellt einen bedeutenden Durchbruch in der Schwellenwert-Kryptographie dar: Das Ika-Team ersetzte die Punkt-zu-Punkt-„Unicast“-Kommunikation durch effizientes Broadcast und Aggregation, wodurch das Protokoll Hunderte oder Tausende von Teilnehmern unterstützen kann, ohne langsamer zu werden.

Zero-Knowledge-Integrationen: Derzeit wird Ikas Sicherheit durch Schwellenwert-Kryptographie und BFT-Konsens und nicht durch explizite Zero-Knowledge-Proofs erreicht. Das System stützt sich in seinem Kernsignaturprozess nicht auf zk-SNARKs oder zk-STARKs. Ika verwendet jedoch On-Chain-State Proofs (Light-Client-Proofs), um Ereignisse von anderen Chains zu verifizieren, was eine Form der kryptographischen Verifizierung ist (z. B. Verifizierung von Merkle-Proofs von Block-Headern oder States). Das Design lässt Raum für die Integration von Zero-Knowledge-Techniken in der Zukunft – zum Beispiel, um Cross-Chain-States oder -Bedingungen zu validieren, ohne sensible Daten preiszugeben – aber ab 2025 ist kein spezifisches zk-SNARK-Modul Teil von Ikas veröffentlichter Architektur. Der Schwerpunkt liegt stattdessen auf dem „Zero-Trust“-Prinzip (was keine Vertrauensannahmen bedeutet) über das 2PC-MPC-Schema, anstatt auf Zero-Knowledge-Proof-Systemen.

Leistung und Skalierbarkeit​

Ein primäres Ziel von Ika ist es, die Leistungsengpässe früherer MPC-Netzwerke zu überwinden. Ältere Schwellenwert-Signaturprotokolle (wie Lindells 2PC ECDSA oder GG20) hatten Schwierigkeiten, mehr als eine Handvoll Teilnehmer zu unterstützen, und benötigten oft viele Sekunden oder Minuten, um eine einzige Signatur zu erzeugen. Im Gegensatz dazu erreicht Ikas optimiertes Protokoll eine Latenz im Sub-Sekunden-Bereich für die Signaturerstellung und kann einen sehr hohen Durchsatz von Signaturanfragen parallel verarbeiten. Benchmark-Angaben deuten darauf hin, dass Ika auf etwa 10.000 Signaturen pro Sekunde skalieren kann, während die Sicherheit in einem großen Node-Cluster aufrechterhalten wird. Dies ist dank der oben genannten linearen Kommunikation und der intensiven Nutzung von Batching möglich: Viele Signaturen können vom Netzwerk in einer Protokollrunde gleichzeitig generiert werden, wodurch die Kosten dramatisch amortisiert werden. Laut dem Team kann Ika unter Last „10.000-mal schneller“ sein als bestehende MPC-Netzwerke. Praktisch bedeutet dies, dass Echtzeit-Transaktionen mit hoher Frequenz (wie Handel oder Cross-Chain-DeFi-Operationen) ohne die üblichen Verzögerungen der Schwellenwert-Signatur unterstützt werden können. Die Latenz liegt in der Größenordnung von Sub-Sekunden-Finalität, was bedeutet, dass eine Signatur (und die entsprechende Cross-Chain-Operation) fast sofort nach einer Benutzeranfrage abgeschlossen werden kann.

Ebenso wichtig ist, dass Ika dies erreicht, während die Anzahl der Signierer skaliert wird, um die Dezentralisierung zu verbessern. Traditionelle MPC-Setups verwendeten oft ein festes Komitee von vielleicht 10–20 Nodes, um einen Leistungskollaps zu vermeiden. Ikas Architektur kann auf Hunderte oder sogar Tausende von Validatoren erweitert werden, die am Signaturprozess teilnehmen, ohne signifikante Verlangsamung. Diese massive Dezentralisierung verbessert die Sicherheit (es ist schwieriger für einen Angreifer, eine Mehrheit zu korrumpieren) und die Netzwerkrobustheit. Der zugrunde liegende Konsens ist Byzantiner fehlertolerant, sodass das Netzwerk bis zu einem Drittel der Nodes tolerieren kann, die kompromittiert oder offline sind, und trotzdem korrekt funktioniert. Bei jeder Signaturoperation muss nur eine Schwelle von t-von-N Nodes (z. B. 67 % von N) aktiv teilnehmen; wenn zu viele Nodes ausfallen, kann die Signatur verzögert werden, aber das System ist so konzipiert, dass es typische Fehlerszenarien elegant handhabt (ähnlich den Liveness- und Safety-Eigenschaften einer Blockchain). Zusammenfassend erreicht Ika sowohl hohen Durchsatz als auch eine hohe Validatorenanzahl, eine Kombination, die es von früheren MPC-Lösungen unterscheidet, die Dezentralisierung gegen Geschwindigkeit eintauschen mussten.

Entwickler-Tools und Integration​

Das Ika-Netzwerk ist so konzipiert, dass es entwicklerfreundlich ist, insbesondere für diejenigen, die bereits auf Sui aufbauen. Entwickler schreiben keine Smart Contracts auf Ika selbst (da Ikas Chain keine benutzerdefinierten Contracts ausführt), sondern interagieren stattdessen von anderen Chains aus mit Ika. Zum Beispiel kann ein Sui Move-Smart Contract Ikas Funktionalität aufrufen, um Transaktionen auf externen Chains zu signieren. Um dies zu erleichtern, bietet Ika robuste Tools und SDKs:

• TypeScript SDK: Ika bietet ein TypeScript SDK (Node.js-Bibliothek), das dem Stil des Sui SDK ähnelt. Dieses SDK ermöglicht es Entwicklern, dWallets (dezentrale Wallets) zu erstellen und zu verwalten und Signaturanfragen an Ika von ihren Anwendungen aus zu senden. Mit dem TS SDK können Entwickler Schlüsselpaare generieren, Benutzeranteile registrieren und Ikas RPC aufrufen, um Schwellenwert-Signaturen zu koordinieren – alles mit vertrauten Mustern aus Suis API. Das SDK abstrahiert die Komplexität des MPC-Protokolls und macht es so einfach wie das Aufrufen einer Funktion, um (zum Beispiel) eine Bitcoin-Transaktionssignatur anzufordern, vorausgesetzt, der entsprechende Kontext und die Benutzergenehmigung liegen vor.

• CLI und lokales Netzwerk: Für eine direktere Interaktion steht eine Befehlszeilenschnittstelle (CLI) namens dWallet CLI zur Verfügung. Entwickler können einen lokalen Ika-Node oder sogar ein lokales Testnetzwerk betreiben, indem sie das Open-Source-Repository forken. Dies ist wertvoll für Tests und Integration in einer Entwicklungsumgebung. Die Dokumentation führt durch die Einrichtung eines lokalen Devnets, den Erhalt von Testnet-Tokens (DWLT – der Testnet-Token) und die Erstellung einer ersten dWallet-Adresse.

• Dokumentation und Beispiele: Ikas Dokumentation enthält Schritt-für-Schritt-Anleitungen für gängige Szenarien, wie zum Beispiel „Ihr erstes dWallet“. Diese zeigen, wie man ein dWallet einrichtet, das einer Adresse auf einer anderen Chain entspricht (z. B. einer Bitcoin-Adresse, die von Ikas Schlüsseln kontrolliert wird), wie man den Schlüsselanteil des Benutzers zur sicheren Aufbewahrung verschlüsselt und wie man Cross-Chain-Transaktionen initiiert. Beispielcode deckt Anwendungsfälle wie die Übertragung von BTC über einen Sui-Smart Contract-Aufruf oder die Planung zukünftiger Transaktionen ab (eine Funktion, die Ika unterstützt, bei der eine Transaktion unter bestimmten Bedingungen vorab signiert werden kann).

• Sui-Integration (Light Clients): Out-of-the-box ist Ika eng mit der Sui-Blockchain integriert. Das Ika-Netzwerk betreibt intern einen Sui Light Client, um Sui On-Chain-Daten vertrauenslos zu lesen. Dies bedeutet, dass ein Sui-Smart Contract ein Ereignis auslösen oder einen Aufruf tätigen kann, den Ika (über einen State Proof) als Auslöser für eine Aktion erkennt. Zum Beispiel könnte ein Sui-Smart Contract Ika anweisen: „Wenn Ereignis X eintritt, signiere und sende eine Transaktion auf Ethereum“. Ika-Nodes verifizieren das Sui-Ereignis mithilfe des Light-Client-Proofs und erzeugen dann gemeinsam die Signatur für die Ethereum-Transaktion. Die signierte Payload kann dann an die Ziel-Chain (möglicherweise von einem Off-Chain-Relayer oder vom Benutzer) geliefert werden, um die gewünschte Aktion auszuführen. Derzeit ist Sui die erste vollständig unterstützte Controller-Chain (angesichts Ikas Ursprüngen auf Sui), aber die Architektur ist von Natur aus Multi-Chain. Die Unterstützung für State Proofs und Integrationen anderer Chains ist auf der Roadmap – zum Beispiel hat das Team erwähnt, Ika so zu erweitern, dass es mit Rollups im Polygon Avail-Ökosystem (Bereitstellung von dWallet-Funktionen auf Rollups mit Avail als Datenschicht) und anderen Layer-1s in der Zukunft funktioniert.

• Unterstützte Krypto-Algorithmen: Ikas Netzwerk kann Schlüssel/Signaturen für praktisch jedes Signaturschema einer Blockchain generieren. Zunächst unterstützt es ECDSA (den elliptischen Kurvenalgorithmus, der von Bitcoin, Ethereums ECDSA-Konten, BNB Chain usw. verwendet wird). Kurzfristig ist geplant, EdDSA (Ed25519, verwendet von Chains wie Solana und einigen Cosmos-Chains) und Schnorr-Signaturen (z. B. Bitcoin Taproots Schnorr-Schlüssel) zu unterstützen. Diese breite Unterstützung bedeutet, dass ein Ika-dWallet eine Adresse auf Bitcoin, eine Adresse auf Ethereum, auf Solana usw. haben kann – alle kontrolliert durch denselben zugrunde liegenden verteilten Schlüssel. Entwickler auf Sui oder anderen Plattformen können somit jede dieser Chains über ein einziges, vereinheitlichtes Framework (Ika) in ihre dApps integrieren, anstatt sich mit Chain-spezifischen Bridges oder Custodians auseinandersetzen zu müssen.

Zusammenfassend bietet Ika eine Entwicklererfahrung, die der Interaktion mit einem Blockchain-Node oder einer Wallet ähnelt, wobei die komplexe Kryptographie abstrahiert wird. Ob über das TypeScript SDK oder direkt über Move-Smart Contracts und Light Clients, es ist bestrebt, Cross-Chain-Logik für Entwickler „Plug-and-Play“ zu gestalten.

Sicherheit, Dezentralisierung und Fehlertoleranz​

Sicherheit ist in Ikas Design von größter Bedeutung. Das Zero-Trust-Modell bedeutet, dass kein Benutzer dem Ika-Netzwerk zu irgendeinem Zeitpunkt die einseitige Kontrolle über Vermögenswerte anvertrauen muss. Wenn ein Benutzer ein dWallet erstellt (sagen wir eine BTC-Adresse, die von Ika verwaltet wird), wird der private Schlüssel dieser Adresse niemals von einer einzelnen Partei gehalten – nicht einmal vom Benutzer allein. Stattdessen hält der Benutzer einen geheimen Anteil und das Netzwerk hält kollektiv den anderen Anteil. Beide sind erforderlich, um eine Transaktion zu signieren. Selbst wenn das Worst-Case-Szenario eintreten würde (z. B. viele Ika-Nodes von einem Angreifer kompromittiert würden), könnten sie immer noch keine Gelder bewegen ohne den geheimen Schlüsselanteil des Benutzers. Diese Eigenschaft adressiert ein großes Risiko bei konventionellen Bridges, bei denen ein Quorum von Validatoren kolludieren könnte, um gesperrte Vermögenswerte zu stehlen. Ika eliminiert dieses Risiko, indem es die Zugriffsstruktur grundlegend ändert (die Schwelle ist so festgelegt, dass das Netzwerk allein niemals ausreicht – die Schwelle schließt den Benutzer effektiv mit ein). In der Literatur ist dies ein neues Paradigma: ein nicht-kollusives MPC-Netzwerk, bei dem der Vermögensinhaber per Design Teil des Signatur-Quorums bleibt.

Auf der Netzwerkseite verwendet Ika ein delegiertes Proof-of-Stake-Modell (von Suis Design geerbt) zur Auswahl und Anreizsetzung von Validatoren. IKA-Token-Inhaber können Stake an Validatoren-Nodes delegieren; die Top-Validatoren (gewichtet nach Stake) werden für eine Epoche zu den Autoritäten und sind in jeder Epoche Byzantiner fehlertolerant (2/3 ehrlich). Dies bedeutet, dass das System davon ausgeht, dass <33 % des Stakes bösartig sind, um die Sicherheit zu gewährleisten. Wenn ein Validator sich falsch verhält (z. B. versucht, einen falschen Signaturanteil zu erzeugen oder Transaktionen zu zensieren), wird der Konsens und das MPC-Protokoll dies erkennen – falsche Signaturanteile können identifiziert werden (sie werden sich nicht zu einer gültigen Signatur kombinieren), und ein bösartiger Node kann protokolliert und möglicherweise in zukünftigen Epochen geslasht oder entfernt werden. Gleichzeitig wird die Liveness aufrechterhalten, solange genügend Nodes (>67 %) teilnehmen; der Konsens kann Operationen weiterhin finalisieren, selbst wenn viele Nodes unerwartet abstürzen oder offline gehen. Diese Fehlertoleranz gewährleistet die Robustheit des Dienstes – es gibt keinen Single Point of Failure, da Hunderte unabhängiger Betreiber in verschiedenen Jurisdiktionen teilnehmen. Die Dezentralisierung wird durch die schiere Anzahl der Teilnehmer weiter verstärkt: Ika beschränkt sich nicht auf ein festes kleines Komitee, sodass es mehr Validatoren aufnehmen kann, um die Sicherheit zu erhöhen, ohne viel Leistung einzubüßen. Tatsächlich wurde Ikas Protokoll explizit entwickelt, um „die Node-Grenze von MPC-Netzwerken zu überwinden“ und eine massive Dezentralisierung zu ermöglichen.

Schließlich hat das Ika-Team seine Kryptographie einer externen Überprüfung unterzogen. Sie veröffentlichten 2024 ein umfassendes Whitepaper, das das 2PC-MPC-Protokoll detailliert beschreibt, und sie haben bisher mindestens ein Sicherheitsaudit durch Dritte durchlaufen. Zum Beispiel untersuchte im Juni 2024 ein Audit von Symbolic Software Ikas Rust-Implementierung des 2PC-MPC-Protokolls und verwandter Krypto-Bibliotheken. Das Audit konzentrierte sich auf die Validierung der Korrektheit der kryptographischen Protokolle (Sicherstellung, dass kein Fehler im Schwellenwert-ECDSA-Schema, der Schlüsselgenerierung oder der Anteilaggregation vorliegt) und die Überprüfung auf potenzielle Schwachstellen. Der Codebase ist Open Source (unter dWallet Labs GitHub), was der Community ermöglicht, seine Sicherheit zu überprüfen und dazu beizutragen. Im Alpha-Testnet-Stadium warnte das Team auch, dass die Software noch experimentell und noch nicht produktionsgeprüft sei, aber laufende Audits und Sicherheitsverbesserungen vor dem Mainnet-Start oberste Priorität hätten. Zusammenfassend ist Ikas Sicherheitsmodell eine Kombination aus nachweisbaren kryptographischen Garantien (aus Schwellenwertschemata) und Blockchain-gerechter Dezentralisierung (aus dem PoS-Konsens und einem großen Validatoren-Set), von Experten überprüft, um starke Zusicherungen gegen externe Angreifer und interne Kollusion zu bieten.

Kompatibilität und Ökosystem-Interoperabilität​

Ika ist speziell als Interoperabilitätsschicht konzipiert, zunächst für Sui, aber erweiterbar auf viele Ökosysteme. Am ersten Tag ist seine engste Integration mit der Sui-Blockchain: Es fungiert effektiv als Add-on-Modul für Sui, das Sui-dApps mit Multi-Chain-Fähigkeiten ausstattet. Diese enge Abstimmung ist beabsichtigt – Suis Move-Smart Contracts und das objektzentrierte Modell machen es zu einem guten „Controller“ für Ikas dWallets. Zum Beispiel kann eine Sui-DeFi-Anwendung Ika verwenden, um Liquidität von Ethereum oder Bitcoin im Handumdrehen abzuziehen, wodurch Sui zu einem Hub für Multi-Chain-Liquidität wird. Die Unterstützung der Sui Foundation für Ika deutet auf eine Strategie hin, Sui als „die Basiskette für jede Kette“ zu positionieren, indem Ika genutzt wird, um sich mit externen Vermögenswerten zu verbinden. In der Praxis könnte ein Sui-Entwickler, wenn Ika Mainnet live ist, einen Move-Smart Contract erstellen, der beispielsweise BTC-Einzahlungen akzeptiert: Hinter den Kulissen würde dieser Smart Contract über Ika ein Bitcoin-dWallet (eine Adresse) erstellen und Anweisungen zum Verschieben von BTC bei Bedarf ausgeben. Der Endbenutzer erlebt dies, als ob Bitcoin nur ein weiteres Asset wäre, das innerhalb der Sui-App verwaltet wird, obwohl der BTC nativ auf Bitcoin bleibt, bis eine gültige, schwellenwert-signierte Transaktion ihn bewegt.

Über Sui hinaus unterstützt Ikas Architektur andere Layer-1-Blockchains, Layer-2s und sogar Off-Chain-Systeme. Das Netzwerk kann mehrere Light Clients gleichzeitig hosten, sodass es den State von Ethereum, Solana, Avalanche oder anderen validieren kann – wodurch Smart Contracts auf diesen Chains (oder deren Benutzer) auch Ikas MPC-Netzwerk nutzen können. Obwohl solche Funktionen schrittweise eingeführt werden könnten, ist das Designziel Chain-agnostisch. In der Zwischenzeit, auch ohne tiefe On-Chain-Integration, kann Ika auf manuellere Weise verwendet werden: zum Beispiel könnte eine Anwendung auf Ethereum eine Ika-API (über ein Oracle oder einen Off-Chain-Dienst) aufrufen, um eine Signatur für eine Ethereum-Transaktion oder eine Nachricht anzufordern. Da Ika ECDSA unterstützt, könnte es sogar verwendet werden, um den Schlüssel eines Ethereum-Kontos dezentral zu verwalten, ähnlich wie Lit Protocols PKPs funktionieren (wir besprechen Lit später). Ika hat auch Anwendungsfälle wie die Kontrolle von Bitcoin auf Rollups gezeigt – ein Beispiel ist die Integration mit dem Polygon Avail-Framework, um Rollup-Benutzern die Verwaltung von BTC zu ermöglichen, ohne einem zentralisierten Custodian vertrauen zu müssen. Dies deutet darauf hin, dass Ika mit verschiedenen Ökosystemen (Polygon/Avail, Celestia-Rollups usw.) als Anbieter dezentraler Schlüsselinfrastruktur zusammenarbeiten könnte.

Zusammenfassend ist Ika aus technischer Sicht kompatibel mit jedem System, das auf digitalen Signaturen basiert – was im Wesentlichen alle Blockchains sind. Seine anfängliche Bereitstellung auf Sui ist nur der Anfang; die langfristige Vision ist eine universelle MPC-Schicht, an die jede Chain oder dApp für sichere Cross-Chain-Operationen angeschlossen werden kann. Durch die Unterstützung gängiger kryptographischer Standards (ECDSA, Ed25519, Schnorr) und die Bereitstellung der erforderlichen Light-Client-Verifizierungen könnte Ika zu einer Art „MPC-as-a-Service“-Netzwerk für das gesamte Web3 werden, das Vermögenswerte und Aktionen auf vertrauensminimierte Weise verbindet.

Geschäfts- und Investitionsperspektive​

Gründerteam und Hintergrund​

Ika wurde von einem Team erfahrener Kryptographie- und Blockchain-Spezialisten gegründet, die hauptsächlich in Israel ansässig sind. Der Projektgründer und CEO ist Omer Sadika, ein Unternehmer mit einer starken Erfolgsbilanz im Bereich der Krypto-Sicherheit. Omer war zuvor Mitbegründer des Odsy Network, einem weiteren Projekt, das sich auf dezentrale Wallet-Infrastruktur konzentrierte, und er ist der Gründer/CEO von dWallet Labs, dem Unternehmen hinter Ika. Sein Hintergrund umfasst eine Ausbildung bei Y Combinator (YC-Alumnus) und einen Fokus auf Cybersicherheit und verteilte Systeme. Omers Erfahrung mit Odsy und dWallet Labs prägte Ikas Vision direkt – im Wesentlichen kann Ika als eine Weiterentwicklung des „dynamischen dezentralen Wallet“-Konzepts angesehen werden, an dem Odsy gearbeitet hat, nun als MPC-Netzwerk auf Sui implementiert.

Ikas CTO und Mitbegründer ist Yehonatan Cohen Scaly, ein Kryptographie-Experte, der das 2PC-MPC-Protokoll mitverfasst hat. Yehonatan leitet die Forschung und Entwicklung für Ikas neuartige kryptographische Algorithmen und hatte zuvor im Bereich Cybersicherheit gearbeitet (möglicherweise mit akademischer Forschung in Kryptographie). Er wurde zitiert, wie er die Einschränkungen bestehender Schwellenwertschemata und wie Ikas Ansatz diese überwindet, diskutierte, was seine tiefe Expertise in MPC und verteilten kryptographischen Protokollen widerspiegelt. Ein weiterer Mitbegründer ist David Lachmish, der die Produktentwicklung leitet. Davids Rolle ist es, die Kerntechnologie in entwicklerfreundliche Produkte und reale Anwendungsfälle zu übersetzen. Das Trio Omer, Yehonatan und David – zusammen mit anderen Forschern wie Dr. Dolev Mutzari (VP of Research bei dWallet Labs) – bildet Ikas Führung. Insgesamt umfassen die Referenzen des Teams frühere Startups, akademische Forschungsbeiträge und Erfahrungen an der Schnittstelle von Krypto, Sicherheit und Blockchain. Diese Tiefe ist der Grund, warum Ika als von „einigen der weltweit führenden Kryptographie-Experten“ geschaffen beschrieben wird.

Zusätzlich zu den Gründern gehören zum erweiterten Team und den Beratern von Ika wahrscheinlich Personen mit starkem kryptographischem Hintergrund. Zum Beispiel ist Dolev Mutzari (oben erwähnt) Mitautor des technischen Papiers und maßgeblich am Protokolldesign beteiligt. Die Präsenz solcher Talente gibt Investoren Vertrauen, dass Ikas komplexe Technologie in fähigen Händen ist. Darüber hinaus profitiert Ika davon, dass ein Gründer (Omer) bereits erfolgreich Gelder beschafft und eine Community um Odsy/dWallet-Konzepte aufgebaut hat, von den Lehren aus früheren Iterationen der Idee. Die Basis des Teams in Israel – einem Land, das für seinen Kryptographie- und Cybersicherheitssektor bekannt ist – positioniert sie auch in einem reichen Talentpool für die Einstellung von Entwicklern und Forschern.

Finanzierungsrunden und wichtige Unterstützer​

Ika (und seine Muttergesellschaft, dWallet Labs) hat seit seiner Gründung erhebliche Risikofinanzierungen und strategische Investitionen angezogen. Bisher wurden über 21 Millionen US-Dollar in mehreren Runden gesammelt. Die anfängliche Seed-Runde im August 2022 betrug 5 Millionen US-Dollar, was angesichts der damaligen Bärenmarktbedingungen bemerkenswert war. Diese Seed-Runde umfasste eine Vielzahl bekannter Krypto-Investoren und Angel-Investoren. Zu den bemerkenswerten Teilnehmern gehörten Node Capital (Lead), Lemniscap, Collider Ventures, Dispersion Capital, Lightshift Capital, Tykhe Block Ventures, Liquid2 Ventures, Zero Knowledge Ventures und andere. Prominente Einzelinvestoren schlossen sich ebenfalls an, wie Naval Ravikant (Mitbegründer von AngelList und prominenter Tech-Investor), Marc Bhargava (Mitbegründer von Tagomi), Rene Reinsberg (Mitbegründer von Celo) und mehrere andere Branchengrößen. Eine solche Liste von Unterstützern unterstrich das starke Vertrauen in Ikas Ansatz zur dezentralen Verwahrung bereits in der Ideenphase.

Im Mai 2023 sammelte Ika weitere ~7,5 Millionen US-Dollar in einer scheinbar Series A oder strategischen Runde, Berichten zufolge bei einer Bewertung von rund 250 Millionen US-Dollar. Diese Runde wurde von Blockchange Ventures und Node Capital (erneut) angeführt, mit Beteiligung von Insignius Capital, Rubik Ventures und anderen. Zu diesem Zeitpunkt hatte die These skalierbarer MPC-Netzwerke an Zugkraft gewonnen, und Ikas Fortschritte zogen diese Investoren wahrscheinlich an, um ihre Investitionen zu verdoppeln. Die Bewertung von 250 Millionen US-Dollar für ein relativ frühes Netzwerk spiegelte die Erwartung des Marktes wider, dass Ika zu einer grundlegenden Infrastruktur im Web3 werden könnte (vergleichbar mit L1-Blockchains oder großen DeFi-Protokollen in Bezug auf den Wert).

Die prominenteste Investition erfolgte im April 2025, als die Sui Foundation eine strategische Investition in Ika bekannt gab. Diese Partnerschaft mit Suis Ökosystemfonds erhöhte Ikas Gesamtfinanzierung auf über 21 Millionen US-Dollar und festigte eine enge Ausrichtung auf die Sui-Blockchain. Obwohl der genaue Betrag, den die Sui Foundation investierte, nicht öffentlich bekannt gegeben wurde, ist klar, dass dies eine bedeutende Bestätigung war – wahrscheinlich in der Größenordnung von mehreren Millionen US-Dollar. Die Unterstützung der Sui Foundation ist nicht nur finanzieller Natur; sie bedeutet auch, dass Ika innerhalb des Sui-Ökosystems starke Go-to-Market-Unterstützung erhält (Entwickler-Outreach, Integrationsunterstützung, Marketing usw.). Laut Pressemitteilungen „kündigte Ika… eine strategische Investition von der Sui Foundation an, wodurch die Gesamtfinanzierung auf über 21 Millionen US-Dollar stieg.“ Diese strategische Runde, anstatt einer traditionellen VC-Eigenkapitalrunde, unterstreicht, dass Sui Ika als kritische Infrastruktur für die Zukunft seiner Blockchain ansieht (ähnlich wie die Ethereum Foundation direkt ein Layer-2- oder Interoperabilitätsprojekt unterstützen könnte, das Ethereum zugutekommt).

Neben Sui sind weitere erwähnenswerte Unterstützer Node Capital (ein in China ansässiger Krypto-Fonds, bekannt für frühe Investitionen in Infrastruktur), Lemniscap (ein Krypto-VC, der sich auf frühe Protokollinnovationen konzentriert) und Collider Ventures (ein in Israel ansässiger VC, der wahrscheinlich lokale Unterstützung bietet). Die Führung der Runde 2023 durch Blockchange Ventures ist bemerkenswert; Blockchange ist ein VC, der mehrere Krypto-Infrastrukturprojekte unterstützt hat, und ihre Führung deutet darauf hin, dass sie Ikas Technologie als potenziell kategoriedefinierend ansahen. Darüber hinaus führten Digital Currency Group (DCG) und Node Capital eine 5-Millionen-Dollar-Finanzierungsrunde für dWallet Labs vor Ikas Rebranding an (laut einem LinkedIn-Beitrag von Omer) – die Beteiligung von DCG (über eine frühere Runde für das Unternehmen) deutet auf noch mehr Unterstützung im Hintergrund hin.

Zusammenfassend zeigt Ikas Finanzierungsreise eine Mischung aus traditionellen VCs und strategischen Partnern. Die Beteiligung der Sui Foundation sticht besonders hervor, da sie nicht nur Kapital, sondern auch ein integriertes Ökosystem zur Bereitstellung von Ikas Technologie bereitstellt. Investoren wetten im Wesentlichen darauf, dass Ika die Go-to-Lösung für dezentrales Schlüsselmanagement und Bridging über viele Netzwerke hinweg werden wird, und sie haben das Projekt entsprechend bewertet.

Tokenomics und Wirtschaftsmodell​

Ika wird einen nativen Utility-Token namens $IKA haben, der für die Ökonomie und das Sicherheitsmodell des Netzwerks zentral ist. Einzigartig ist, dass der IKA-Token auf der Sui-Blockchain (als natives SUI-Asset) gestartet wird, obwohl das Ika-Netzwerk selbst eine separate Chain ist. Dies bedeutet, dass IKA als Coin existieren wird, der auf Sui wie jedes andere Sui-Asset gehalten und übertragen werden kann, und er wird auf zweifache Weise verwendet: innerhalb des Ika-Netzwerks für Staking und Gebühren sowie auf Sui für Governance oder Zugang in dApps. Die Tokenomics können wie folgt skizziert werden:

• Gasgebühren: So wie ETH Gas in Ethereum oder SUI Gas in Sui ist, dient IKA als Gas/Zahlung für MPC-Operationen im Ika-Netzwerk. Wenn ein Benutzer oder eine dApp eine Signatur oder dWallet-Operation anfordert, wird eine Gebühr in IKA an das Netzwerk gezahlt. Diese Gebühren entschädigen Validatoren für die Rechen- und Kommunikationsarbeit beim Betrieb des Schwellenwert-Signaturprotokolls. Das Whitepaper vergleicht IKAs Rolle mit Suis Gas und bestätigt, dass alle von Ika ermöglichten Cross-Chain-Transaktionen eine kleine IKA-Gebühr verursachen werden. Die Gebührenstruktur ist wahrscheinlich proportional zur Komplexität der Operation (z. B. könnte eine einzelne Signatur eine Basisgebühr kosten, während komplexere mehrstufige Workflows mehr kosten könnten).

• Staking und Sicherheit: IKA ist auch ein Staking-Token. Validatoren-Nodes im Ika-Netzwerk müssen einen Stake von IKA delegiert bekommen, um am Konsens und der Signaturerstellung teilzunehmen. Der Konsens folgt einem delegierten Proof-of-Stake, ähnlich dem von Sui: Token-Inhaber delegieren IKA an Validatoren, und das Gewicht jedes Validators im Konsens (und damit in den Schwellenwert-Signaturprozessen) wird durch den Stake bestimmt. In jeder Epoche werden Validatoren ausgewählt und ihre Stimmkraft ist eine Funktion des Stakes, wobei das gesamte Set Byzantiner fehlertolerant ist (was bedeutet, dass, wenn ein Validatoren-Set einen Gesamtstake von $X$ hat, bis zu ~$X/3$ Stake bösartig sein könnte, ohne die Garantien des Netzwerks zu verletzen). Staker (Delegatoren) werden durch Staking-Belohnungen incentiviert: Ikas Modell beinhaltet wahrscheinlich die Verteilung der gesammelten Gebühren (und möglicherweise inflationäre Belohnungen) an Validatoren und ihre Delegatoren am Ende der Epochen. Tatsächlich wird in der Dokumentation erwähnt, dass alle gesammelten Transaktionsgebühren an die Autoritäten verteilt werden, die einen Teil davon als Belohnung an ihre Delegatoren weitergeben können. Dies spiegelt das Sui-Modell wider, Dienstleister für den Durchsatz zu belohnen.

• Angebot und Verteilung: Zum jetzigen Zeitpunkt (Q2 2025) sind Details zu IKAs Gesamtangebot, anfänglicher Verteilung und Inflation nicht vollständig öffentlich. Angesichts der Finanzierungsrunden können wir jedoch eine gewisse Struktur ableiten. Wahrscheinlich ist ein Teil von IKA frühen Investoren (Seed- und Series-Runden) und dem Team zugewiesen, wobei ein großer Teil für die Community und zukünftige Anreize reserviert ist. Es könnte ein Community-Verkauf oder Airdrop geplant sein, insbesondere da Ika eine bemerkenswerte NFT-Kampagne durchgeführt hat, die 1,4 Millionen SUI einbrachte, wie in den Nachrichten erwähnt (dies war eine NFT-Kunstkampagne auf Sui, die einen Rekord aufstellte; es ist möglich, dass Teilnehmer dieser Kampagne IKA-Belohnungen oder frühen Zugang erhalten). Die NFT-Kampagne deutet auf eine Strategie hin, die Community einzubeziehen und die Token-Verteilung an Benutzer, nicht nur an VCs, zu starten.

• Zeitpunkt des Token-Starts: Die Ankündigung der Sui Foundation im Oktober 2024 besagte: „Der IKA-Token wird nativ auf Sui starten und neue Funktionen und Nutzen in der dezentralen Sicherheit freischalten.“ Der Mainnet-Start war für Dezember 2024 geplant, sodass das Token Generation Event (TGE) vermutlich gleichzeitig oder kurz danach stattfinden würde. Wenn der Mainnet-Start planmäßig erfolgte, könnten IKA-Tokens Ende 2024 oder Anfang 2025 mit der Verteilung begonnen haben. Der Token würde dann für Gas im Ika-Netzwerk und für Staking verwendet werden. Zuvor wurde im Testnet ein temporärer Token (DWLT im Testnet) für Gas verwendet, der keinen realen Wert hatte.

• Anwendungsfälle und Wertakkumulation: Der Wert von IKA als Investition hängt von der Nutzung des Ika-Netzwerks ab. Je mehr Cross-Chain-Transaktionen über Ika fließen, desto mehr Gebühren werden in IKA gezahlt, was Nachfrage schafft. Wenn viele Validatoren betreiben oder das Netzwerk sichern wollen, müssen sie IKA erwerben und staken, was das Angebot bindet (reduziert den Umlauf). Somit hat IKA eine Utility- plus Governance-Natur – Utility bei der Bezahlung von Diensten und beim Staking, und wahrscheinlich Governance bei der Steuerung der Zukunft des Protokolls (obwohl Governance noch nicht explizit erwähnt wird, ist es für solche Netzwerke üblich, die Kontrolle schließlich über Token-Abstimmungen zu dezentralisieren). Man kann sich vorstellen, dass IKA-Token-Inhaber über die Unterstützung neuer Chains, die Anpassung von Gebührenparametern oder andere Protokoll-Upgrades in der Zukunft abstimmen.

Insgesamt zielt IKAs Tokenomics darauf ab, die Netzwerksicherheit mit der Benutzerfreundlichkeit in Einklang zu bringen. Durch den Start auf Sui wird es für Benutzer des Sui-Ökosystems einfach, IKA zu erhalten und zu verwenden (kein separates Chain-Onboarding für den Token selbst erforderlich), was die Adoption ankurbeln kann. Investoren werden Kennzahlen wie den Anteil des gestakten Angebots (was auf Sicherheit hindeutet), die Gebühreneinnahmen (was auf Nutzung hindeutet) und Partnerschaften, die Transaktionen vorantreiben (was auf Nachfrage nach dem Token hindeutet), beobachten.

Geschäftsmodell und Go-to-Market-Strategie​

Ikas Geschäftsmodell ist das eines Infrastrukturanbieters im Blockchain-Ökosystem. Es bietet kein Endverbraucherprodukt an; stattdessen bietet es einen Protokolldienst (dezentrales Schlüsselmanagement und Transaktionsausführung), den andere Projekte integrieren. Als solches ist der primäre Umsatz- (oder Wertschöpfungs-) Mechanismus die Gebühr für den Dienst – d. h. die Gasgebühren in IKA für die Nutzung des Netzwerks. Man kann Ika mit einem dezentralen AWS für die Schlüssel-Signatur vergleichen: Jeder Entwickler kann sich einklinken und es nutzen, wobei er pro Nutzung bezahlt. Langfristig, wenn das Netzwerk dezentralisiert wird, könnte dWallet Labs (das Gründungsunternehmen) Wert durch das Halten eines Anteils am Netzwerk und durch die Wertsteigerung des Tokens erfassen, anstatt Off-Chain-Gebühren im SaaS-Stil zu erheben.

Go-to-Market (GTM)-Strategie: Frühzeitig zielt Ika auf Blockchain-Entwickler und Projekte ab, die Cross-Chain-Funktionalität oder Custody-Lösungen benötigen. Die Ausrichtung auf Sui bietet einen fertigen Pool solcher Entwickler. Sui selbst, als neuere L1, benötigt einzigartige Funktionen, um Benutzer anzuziehen – und Ika bietet Cross-Chain-DeFi, Bitcoin-Zugang und mehr auf Sui, was überzeugende Funktionen sind. Somit stützt sich Ikas GTM auf Suis wachsendes Ökosystem. Bemerkenswerterweise haben bereits vor dem Mainnet mehrere Sui-Projekte angekündigt, Ika zu integrieren:

• Projekte wie Full Sail, Rhei, Aeon, Human Tech, Covault, Lucky Kat, Native, Nativerse, Atoma und Ekko (alles Builder auf Sui) haben „ihre bevorstehenden Starts unter Nutzung von Ika angekündigt“, die Anwendungsfälle von DeFi bis Gaming abdecken. Zum Beispiel könnte Full Sail eine Börse aufbauen, die BTC über Ika handeln kann; Lucky Kat (ein Gaming-Studio) könnte Ika nutzen, um In-Game-Assets zu ermöglichen, die auf mehreren Chains liegen; Covault beinhaltet wahrscheinlich Custody-Lösungen usw. Durch die Sicherung dieser Partnerschaften frühzeitig stellt Ika sicher, dass es beim Start sofortiges Transaktionsvolumen und reale Anwendungen geben wird, die seine Fähigkeiten demonstrieren.

• Ika betont auch institutionelle Anwendungsfälle, wie z. B. dezentrale Verwahrung für Institutionen. In Pressemitteilungen heben sie „unübertroffene Sicherheit für institutionelle und individuelle Benutzer“ bei der Verwahrung über Ika hervor. Dies deutet darauf hin, dass Ika an Krypto-Custodians, Börsen oder sogar TradFi-Akteure vermarktet werden könnte, die eine sicherere Möglichkeit zur Verwaltung privater Schlüssel wünschen (vielleicht als Alternative oder Ergänzung zu Fireblocks oder Copper, die MPC, aber in einem zentralisierten Unternehmensumfeld verwenden). Tatsächlich könnte Ika als dezentrales Netzwerk es Wettbewerbern in der Verwahrung ermöglichen, sich alle auf dasselbe robuste Signatur-Netzwerk zu verlassen, anstatt jeder sein eigenes aufzubauen. Dieses kooperative Modell könnte Institutionen anziehen, die einen neutralen, dezentralen Custodian für bestimmte Vermögenswerte bevorzugen.

• Ein weiterer Aspekt sind KI-Integrationen: Ika erwähnt „Leitplanken für KI-Agenten“ als Anwendungsfall. Dies ist zukunftsweisend und spielt auf den Trend der KI-Autonomie an (z. B. KI-Agenten, die auf der Blockchain ausgeführt werden). Ika kann sicherstellen, dass ein KI-Agent (sagen wir ein autonomer Wirtschaftsagent, dem die Kontrolle über einige Gelder gegeben wurde) nicht mit den Geldern davonlaufen kann, da der Agent selbst nicht der alleinige Inhaber des Schlüssels ist – er würde immer noch den Anteil des Benutzers benötigen oder sich an die Bedingungen in Ika halten. Die Vermarktung von Ika als Bereitsteller von Sicherheitsleitplanken für KI im Web3 ist ein neuartiger Ansatz, um das Interesse dieses Sektors zu wecken.

Geographisch deutet die Präsenz von Node Capital und anderen neben dem westlichen Markt auch auf einen Fokus auf Asien hin. Sui hat eine starke asiatische Community (insbesondere in China). Ikas NFT-Kampagne auf Sui (die Kunstkampagne, die 1,4 Millionen SUI einbrachte) deutet auf eine Community-Building-Anstrengung hin – möglicherweise die Einbindung chinesischer Benutzer, die im Sui-NFT-Bereich aktiv sind. Durch NFT-Verkäufe oder Community-Airdrops kann Ika eine Basis von Benutzern aufbauen, die IKA-Tokens halten und Anreize haben, deren Adoption zu fördern.

Im Laufe der Zeit könnte das Geschäftsmodell auf das Anbieten von Premium-Funktionen oder Unternehmensintegrationen ausgeweitet werden. Zum Beispiel könnte dWallet Labs, während das öffentliche Ika-Netzwerk permissionless ist, private Instanzen oder Konsortiumsversionen für bestimmte Kunden einrichten oder Beratungsdienste für Projekte anbieten, die Ika integrieren. Sie könnten auch durch den Betrieb einiger Validatoren in der Anfangsphase (Bootstrap-Phase) Einnahmen erzielen und so einen Teil der Gebühren einziehen.

Zusammenfassend ist Ikas GTM stark an Ökosystem-Partnerschaften gebunden. Durch die tiefe Einbettung in Suis Roadmap (wo Suis Ziele für 2025 Cross-Chain-Liquidität und einzigartige Anwendungsfälle umfassen) stellt Ika sicher, dass es das Wachstum dieser L1 mitreiten wird. Gleichzeitig positioniert es sich als eine allgemeine Lösung für die Multi-Chain-Koordination, die dann Projekten auf anderen Chains angeboten werden kann, sobald ein Erfolg auf Sui demonstriert wurde. Die Unterstützung durch die Sui Foundation und die frühen Integrationsankündigungen verschaffen Ika einen erheblichen Vorsprung in Bezug auf Glaubwürdigkeit und Adoption im Vergleich zu einem isolierten Start.

Ökosystem-Adoption, Partnerschaften und Roadmap​

Schon in seinem frühen Stadium hat Ika eine beeindruckende Liste von Ökosystem-Engagements aufgebaut:

• Sui-Ökosystem-Adoption: Wie erwähnt, integrieren mehrere Sui-basierte Projekte Ika. Dies bedeutet, dass wir nach dem Mainnet-Start von Ika erwarten, dass Sui-dApps Funktionen wie „Powered by Ika“ ermöglichen – zum Beispiel ein Sui-Lending-Protokoll, das Benutzern die Einzahlung von BTC ermöglicht, oder eine DAO auf Sui, die Ika verwendet, um ihre Treasury auf mehreren Chains zu halten. Die Tatsache, dass Namen wie Rhei, Atoma, Nativerse (wahrscheinlich DeFi-Projekte) und Lucky Kat (Gaming/NFT) an Bord sind, zeigt, dass Ikas Anwendbarkeit verschiedene Vertikalen umfasst.

• Strategische Partnerschaften: Ikas wichtigste Partnerschaft besteht mit der Sui Foundation selbst, die sowohl Investor als auch Förderer ist. Suis offizielle Kanäle (Blog usw.) haben Ika prominent vorgestellt und es effektiv als Interoperabilitätslösung für Sui befürwortet. Darüber hinaus hat Ika wahrscheinlich mit anderen Infrastrukturanbietern zusammengearbeitet. Zum Beispiel könnte es angesichts der Erwähnung von zkLogin (Suis Web2-Login-Funktion) neben Ika einen kombinierten Anwendungsfall geben, bei dem zkLogin die Benutzerauthentifizierung und Ika Cross-Chain-Transaktionen abwickelt, um gemeinsam eine nahtlose UX zu bieten. Auch Ikas Erwähnung von Avail (Polygon) in seinen Blogs deutet auf eine Partnerschaft oder ein Pilotprojekt in diesem Ökosystem hin: vielleicht mit Polygon Labs oder Teams, die Rollups auf Avail aufbauen, um Ika für die Überbrückung von Bitcoin zu diesen Rollups zu nutzen. Ein weiterer potenzieller Partnerschaftsbereich ist mit Custodians – zum Beispiel die Integration von Ika mit Wallet-Anbietern wie Zengo (bemerkenswert, da Zengos Mitbegründer Omers früheres Projekt war) oder mit institutioneller Custody-Technologie wie Fireblocks. Obwohl nicht bestätigt, wären dies logische Ziele (tatsächlich hat Fireblocks anderswo mit Sui zusammengearbeitet; man könnte sich vorstellen, dass Fireblocks Ika für MPC auf Sui nutzt).

• Community- und Entwicklerengagement: Ika betreibt einen Discord und wahrscheinlich Hackathons, um Entwickler zum Bauen mit dWallets zu bewegen. Die Technologie ist neuartig, daher ist die Evangelisierung durch Bildung entscheidend. Die Präsenz von „Anwendungsfällen“ und „Buildern“-Abschnitten auf ihrer Website sowie Blogbeiträge, die Kernkonzepte erklären, deuten auf einen Vorstoß hin, Entwickler mit dem Konzept der dWallets vertraut zu machen. Je mehr Entwickler verstehen, dass sie Cross-Chain-Logik ohne Bridges (und ohne Kompromittierung der Sicherheit) aufbauen können, desto stärker wird die organische Adoption wachsen.

• Roadmap: Ab 2025 umfasste Ikas Roadmap:

  • Alpha und Testnet (2023–2024): Das Alpha-Testnet wurde 2024 auf Sui gestartet, um Entwicklern das Experimentieren mit dWallets und das Geben von Feedback zu ermöglichen. Diese Phase wurde genutzt, um das Protokoll zu verfeinern, Fehler zu beheben und interne Audits durchzuführen.
  • Mainnet-Start (Dezember 2024): Ika plante, bis Ende 2024 auf Mainnet live zu gehen. Wenn dies erreicht wurde, sollte Ikas Mainnet jetzt (Mitte 2025) betriebsbereit sein. Der Start umfasste wahrscheinlich die anfängliche Unterstützung für eine Reihe von Chains: mindestens Bitcoin und Ethereum (ECDSA-Chains) von Anfang an, da diese in der Vermarktung stark erwähnt wurden.
  • Ziele nach dem Start 2025: Im Jahr 2025 erwarten wir, dass der Fokus auf der Skalierung der Nutzung (durch Sui-Apps und möglicherweise die Erweiterung auf andere Chains) liegen wird. Das Team wird kurz nach dem Start an der Hinzufügung von Ed25519- und Schnorr-Unterstützung arbeiten, um die Integration mit Solana, Polkadot und anderen Ökosystemen zu ermöglichen. Sie werden auch mehr Light Clients implementieren (vielleicht Ethereum Light Client für Ika, Solana Light Client usw.), um die vertrauenslose Kontrolle zu erweitern. Ein weiterer Roadmap-Punkt ist wahrscheinlich die permissionless Validator-Erweiterung – mehr unabhängige Validatoren zum Beitritt zu ermutigen und das Netzwerk weiter zu dezentralisieren. Da der Code ein Sui-Fork ist, ist der Betrieb eines Ika-Validators ähnlich dem Betrieb eines Sui-Nodes, was viele Betreiber tun können.
  • Funktionserweiterungen: Zwei interessante Funktionen, die in Blogs angedeutet wurden, sind verschlüsselte Benutzeranteile und zukünftige Transaktionssignierung. Verschlüsselte Benutzeranteile bedeuten, dass Benutzer ihren privaten Anteil optional verschlüsseln und On-Chain (vielleicht auf Ika oder anderswo) so speichern können, dass nur sie ihn entschlüsseln können, was die Wiederherstellung vereinfacht. Zukünftige Transaktionssignierung impliziert die Fähigkeit, Ika eine Transaktion vorab signieren zu lassen, die später ausgeführt wird, wenn Bedingungen erfüllt sind. Diese Funktionen erhöhen die Benutzerfreundlichkeit (Benutzer müssen nicht für jede Aktion online sein, wenn sie bestimmte Logik vorab genehmigen, während die nicht-verwahrte Sicherheit erhalten bleibt). Die Bereitstellung dieser Funktionen im Jahr 2025 würde Ikas Angebot weiter differenzieren.
  • Ökosystemwachstum: Bis Ende 2025 strebt Ika wahrscheinlich an, dass mehrere Chain-Ökosysteme es aktiv nutzen. Wir könnten zum Beispiel sehen, wie ein Ethereum-Projekt Ika über ein Oracle nutzt (wenn eine direkte On-Chain-Integration noch nicht vorhanden ist) oder Kooperationen mit Interchain-Projekten wie Wormhole oder LayerZero, wo Ika als Signaturmechanismus für sichere Nachrichten dienen könnte.

Die Wettbewerbslandschaft wird auch Ikas Strategie prägen. Es ist nicht allein beim Anbieten von dezentralem Schlüsselmanagement, daher wird ein Teil seiner Roadmap darin bestehen, seinen Leistungsvorteil und seine einzigartige Zwei-Parteien-Sicherheit im Gegensatz zu anderen hervorzuheben. Im nächsten Abschnitt vergleichen wir Ika mit seinen bemerkenswerten Konkurrenten Lit Protocol, Threshold Network und Zama.

Wettbewerbsanalyse: Ika vs. andere MPC-/Schwellenwert-Netzwerke​

Ika agiert in einem hochmodernen Bereich kryptographischer Netzwerke, in dem einige Projekte ähnliche Ziele mit unterschiedlichen Ansätzen verfolgen. Unten finden Sie einen zusammenfassenden Vergleich von Ika mit Lit Protocol, Threshold Network und Zama (jeder ein repräsentativer Konkurrent in der dezentralen Schlüsselinfrastruktur oder im Privacy Computing):

Ikas Wettbewerbsvorteil: Ikas Alleinstellungsmerkmale liegen in seiner Leistung bei Skalierung und seinem einzigartigen Sicherheitsmodell. Im Vergleich zu Lit Protocol kann Ika weitaus mehr Signierer und einen viel höheren Durchsatz unterstützen, wodurch es für Anwendungsfälle (wie Hochvolumenhandel oder Gaming) geeignet ist, mit denen Lits Netzwerk Schwierigkeiten hätte. Ika verlässt sich auch nicht auf Trusted Execution Environments, denen einige Entwickler misstrauen (aufgrund potenzieller Exploits in SGX); stattdessen erreicht Ika Vertrauenslosigkeit rein durch Kryptographie und Konsens. Gegenüber dem Threshold Network bietet Ika eine allgemeiner einsetzbare Plattform. Threshold konzentriert sich weitgehend auf das Bitcoin↔Ethereum-Bridging (tBTC) und einige kryptographische Dienste wie Proxy-Re-Encryption, während Ika eine flexible Interoperabilitätsschicht ist, die sofort mit jeder Chain und jedem Asset arbeiten kann. Außerdem bedeutet Ikas Benutzer-im-Kreislauf-Modell, dass es keine Überbesicherung oder Versicherung für Einlagen erfordert (tBTC v2 verwendet ein robustes, aber komplexes Wirtschaftsmodell zur Sicherung von BTC-Einlagen, während der Benutzer bei Ika die Kontrolle niemals aufgibt). Im Vergleich zu Zama adressiert Ika ein anderes Problem – Zama zielt auf Datenschutz ab, während Ika auf Interoperabilität abzielt. Es ist jedoch denkbar, dass sich die beiden in Zukunft ergänzen könnten (z. B. die Verwendung von FHE auf Ika-gespeicherten Assets). Vorerst hat Ika den Vorteil, in einer Nische mit sofortiger Nachfrage früher operativ zu sein (Bridges und MPC-Netzwerke werden heute benötigt, während FHE noch reift).

Eine potenzielle Herausforderung für Ika ist die Marktbildung und das Vertrauen. Es führt eine neuartige Art der Cross-Chain-Interaktion ein (dWallets anstelle traditioneller Lock-and-Mint-Bridges). Es muss seine Sicherheit im Laufe der Zeit in der Praxis demonstrieren, um das gleiche Maß an Vertrauen zu gewinnen, das beispielsweise das Threshold Network schrittweise erworben hat (Threshold musste tBTC nach einer früheren Version, die aufgrund von Risiken pausiert wurde, beweisen). Wenn Ikas Technologie wie beworben funktioniert, übertrifft es die Konkurrenz effektiv, indem es das Trilemma von Dezentralisierung, Sicherheit und Geschwindigkeit im MPC-Bereich löst. Die starke Unterstützung durch Sui und die umfangreichen Audits/Papiere verleihen Glaubwürdigkeit.

Zusammenfassend sticht Ika unter den MPC-Netzwerken durch seine ehrgeizige Skalierbarkeit und sein benutzerzentriertes Sicherheitsmodell hervor. Investoren sehen es als Wette auf die Zukunft der Cross-Chain-Koordination – eine, bei der Benutzer Werte und Logik nahtlos über viele Blockchains hinweg bewegen können, ohne jemals die Kontrolle über ihre Schlüssel aufzugeben. Wenn Ika eine breite Akzeptanz erreicht, könnte es so integral für die Web3-Infrastruktur werden wie Cross-Chain-Messaging-Protokolle oder große Layer-1-Blockchains selbst. Das kommende Jahr (2025) wird entscheidend sein, wenn Ikas Mainnet und erste Anwendungsfälle live gehen und beweisen, ob diese hochmoderne Kryptographie ihre Versprechen unter realen Marktbedingungen einlösen kann. Die frühen Anzeichen – starke technische Grundlagen, eine aktive Integrationspipeline und erhebliche Investorenunterstützung – deuten darauf hin, dass Ika eine echte Chance hat, die Blockchain-Interoperabilität mit MPC neu zu definieren.

Quellen: Primäre Informationen wurden aus Ikas offizieller Dokumentation und Whitepaper, Sui Foundation-Ankündigungen, Pressemitteilungen und Finanzierungsnachrichten sowie technischen Dokumenten und Analysen von Wettbewerbern zur Kontextualisierung (Lit Protocols Messari-Bericht, Threshold Network-Dokumentation und Zamas FHE-Beschreibungen) gesammelt. Alle Informationen sind auf dem Stand von 2025.

Öffentliche Blockchains bieten Transparenz und Integrität auf Kosten der Privatsphäre – jeder Transaktions- und Kontraktstatus ist für alle Teilnehmer einsehbar. Diese Offenheit schafft Probleme wie MEV-Angriffe (Miner Extractable Value), Copy-Trading und das Abfließen sensibler Geschäftslogik. Programmierbare Privatsphäre zielt darauf ab, diese Probleme zu lösen, indem Berechnungen auf privaten Daten ermöglicht werden, ohne die Daten selbst preiszugeben. Zwei aufstrebende kryptografische Paradigmen machen dies möglich: Virtual Machines für vollständig homomorphe Verschlüsselung (FHE-VM) und Zero-Knowledge (ZK)-Coprozessoren. Diese Ansätze ermöglichen Off-Chain- oder verschlüsselte Berechnungen mit On-Chain-Verifizierung, wodurch die Vertraulichkeit gewahrt bleibt, während die vertrauenslose Korrektheit erhalten bleibt. In diesem Bericht tauchen wir tief in FHE-VM- und ZK-Coprozessor-Architekturen ein, vergleichen ihre Kompromisse und untersuchen Anwendungsfälle in den Bereichen Finanzen, Identität, Gesundheitswesen, Datenmärkte und dezentrales maschinelles Lernen.

Virtual Machine für vollständig homomorphe Verschlüsselung (FHE-VM)​

Vollständig homomorphe Verschlüsselung (FHE) ermöglicht beliebige Berechnungen auf verschlüsselten Daten, ohne diese jemals entschlüsseln zu müssen. Eine FHE Virtual Machine integriert diese Fähigkeit in Blockchain Smart Contracts und ermöglicht so verschlüsselte Kontraktzustände und -logik. In einer FHE-fähigen Blockchain (oft als fhEVM für EVM-kompatible Designs bezeichnet) bleiben alle Eingaben, der Kontraktspeicher und die Ausgaben während der gesamten Ausführung verschlüsselt. Dies bedeutet, dass Validatoren Transaktionen verarbeiten und Zustände aktualisieren können, ohne sensible Werte zu erfahren, wodurch eine On-Chain-Ausführung mit Datenvertraulichkeit erreicht wird.

Architektur und Design der FHE-VM​

Eine typische FHE-VM erweitert eine Standard-Smart-Contract-Laufzeitumgebung (wie die Ethereum Virtual Machine) um native Unterstützung für verschlüsselte Datentypen und Operationen. Beispielsweise führt die FHEVM von Zama verschlüsselte Ganzzahlen (euint8, euint32 usw.), verschlüsselte Booleans (ebool) und sogar verschlüsselte Arrays als First-Class-Typen ein. Smart-Contract-Sprachen wie Solidity werden durch Bibliotheken oder neue Opcodes ergänzt, sodass Entwickler arithmetische Operationen (add, mul usw.), logische Operationen und Vergleiche direkt auf Ciphertexten durchführen können. Im Hintergrund rufen diese Operationen FHE-Primitive auf (z. B. unter Verwendung der TFHE-Bibliothek), um verschlüsselte Bits zu manipulieren und verschlüsselte Ergebnisse zu erzeugen.

Die verschlüsselte Zustandspeicherung wird unterstützt, sodass Kontraktvariablen im Blockchain-Status verschlüsselt bleiben. Der Ausführungsfluss ist typischerweise:

1. Client-seitige Verschlüsselung: Benutzer verschlüsseln ihre Eingaben lokal mit dem öffentlichen FHE-Schlüssel, bevor sie Transaktionen senden. Der Verschlüsselungsschlüssel ist öffentlich (für Verschlüsselung und Auswertung), während der Entschlüsselungsschlüssel geheim bleibt. In einigen Designs verwaltet jeder Benutzer seinen eigenen Schlüssel; in anderen wird ein einzelner globaler FHE-Schlüssel verwendet (unten besprochen).
2. On-Chain homomorphe Berechnung: Miner/Validatoren führen den Kontrakt mit verschlüsselten Opcodes aus. Sie führen dieselben deterministischen homomorphen Operationen auf den Ciphertexten durch, sodass ein Konsens über den verschlüsselten neuen Zustand erzielt werden kann. Entscheidend ist, dass Validatoren niemals Klartextdaten sehen – sie sehen nur „unverständlichen“ Ciphertext, können diesen aber dennoch konsistent verarbeiten.
3. Entschlüsselung (optional): Wenn ein Ergebnis offengelegt oder Off-Chain verwendet werden muss, kann eine autorisierte Partei mit dem privaten Schlüssel den Ausgabe-Ciphertext entschlüsseln. Andernfalls bleiben die Ergebnisse verschlüsselt und können als Eingaben für weitere Transaktionen verwendet werden (was fortlaufende Berechnungen auf persistentem verschlüsseltem Zustand ermöglicht).

Eine wichtige Designüberlegung ist das Key Management. Ein Ansatz sind benutzerspezifische Schlüssel, bei denen jeder Benutzer seinen geheimen Schlüssel hält und nur er die für ihn relevanten Ausgaben entschlüsseln kann. Dies maximiert die Privatsphäre (niemand sonst kann jemals Ihre Daten entschlüsseln), aber homomorphe Operationen können Daten, die unter verschiedenen Schlüsseln verschlüsselt sind, nicht ohne komplexe Multi-Key-Protokolle mischen. Ein anderer Ansatz, der von Zamas FHEVM verwendet wird, ist ein globaler FHE-Schlüssel: Ein einziger öffentlicher Schlüssel verschlüsselt alle Kontraktdaten, und eine verteilte Gruppe von Validatoren hält Anteile am Threshold-Entschlüsselungsschlüssel. Die öffentlichen Verschlüsselungs- und Auswertungsschlüssel werden On-Chain veröffentlicht, sodass jeder Daten für das Netzwerk verschlüsseln kann; der private Schlüssel wird unter den Validatoren aufgeteilt, die bei Bedarf gemeinsam unter einem Threshold-Schema entschlüsseln können. Um zu verhindern, dass Absprachen zwischen Validatoren die Privatsphäre gefährden, setzt Zama ein Threshold-FHE-Protokoll (basierend auf ihrer Noah’s Ark-Forschung) mit „Noise Flooding“ ein, um Teilentschlüsselungen sicher zu machen. Nur wenn ein ausreichendes Quorum von Validatoren kooperiert, kann ein Klartext wiederhergestellt werden, beispielsweise um eine Leseanfrage zu bedienen. Im Normalbetrieb sieht jedoch kein einzelner Knoten jemals Klartext – die Daten bleiben jederzeit auf der Chain verschlüsselt.

Die Zugriffskontrolle ist eine weitere entscheidende Komponente. FHE-VM-Implementierungen enthalten feinkörnige Kontrollen, um zu verwalten, wer (falls überhaupt jemand) Entschlüsselungen auslösen oder auf bestimmte verschlüsselte Felder zugreifen kann. Beispielsweise unterstützt die fhEVM von Cypher Access Control Lists (ACLs) auf Ciphertexten, was es Entwicklern ermöglicht, festzulegen, welche Adressen oder Kontrakte mit bestimmten Daten interagieren oder diese neu verschlüsseln dürfen. Einige Frameworks unterstützen die Neuverschlüsselung (Re-encryption): die Fähigkeit, einen verschlüsselten Wert von dem Schlüssel eines Benutzers auf den eines anderen zu übertragen, ohne den Klartext offenzulegen. Dies ist nützlich für Dinge wie Datenmarktplätze, auf denen ein Dateneigentümer einen Datensatz mit seinem Schlüssel verschlüsseln und ihn beim Kauf auf den Schlüssel des Käufers neu verschlüsseln kann – alles On-Chain, ohne jemals öffentlich zu entschlüsseln.

Sicherstellung von Korrektheit und Privatsphäre​

Man könnte fragen: Wenn alle Daten verschlüsselt sind, wie setzen wir die Korrektheit der Kontraktlogik durch? Wie kann die Chain ungültige Operationen verhindern, wenn sie die Werte nicht „sehen“ kann? FHE allein liefert keinen Beweis für die Korrektheit – Validatoren können die homomorphen Schritte ausführen, aber sie können nicht von Natur aus feststellen, ob die verschlüsselte Eingabe eines Benutzers gültig war oder ob ein bedingter Zweig genommen werden sollte usw., ohne zu entschlüsseln. Zero-Knowledge-Proofs (ZKPs) können FHE ergänzen, um diese Lücke zu schließen. In einer FHE-VM müssen Benutzer in der Regel einen ZK-Beweis vorlegen, der bestimmte Klartextbedingungen bestätigt, wann immer dies erforderlich ist. Zamas Design verwendet beispielsweise einen ZK Proof of Plaintext Knowledge (ZKPoK), der jede verschlüsselte Eingabe begleitet. Dies beweist, dass der Benutzer den Klartext kennt, der seinem Ciphertext entspricht, und dass dieser die erwarteten Kriterien erfüllt, ohne den Klartext selbst offenzulegen. Solche „zertifizierten Ciphertexte“ verhindern, dass ein böswilliger Benutzer eine fehlerhafte Verschlüsselung oder einen Wert außerhalb des zulässigen Bereichs einreicht. Ähnlich kann der Benutzer bei Operationen, die eine Entscheidung erfordern (z. B. sicherstellen, dass Kontostand ≥ Auszahlungsbetrag), einen ZK-Beweis liefern, dass diese Bedingung auf den Klartexten zutrifft, bevor die verschlüsselte Operation ausgeführt wird. Auf diese Weise entschlüsselt oder sieht die Chain die Werte nicht, gewinnt aber die Gewissheit, dass die verschlüsselten Transaktionen den Regeln folgen.

Ein anderer Ansatz in FHE-Rollups besteht darin, eine Off-Chain-Validierung mit ZKPs durchzuführen. Fhenix (ein L2-Rollup, das FHE verwendet) entscheidet sich für ein optimistisches Modell, bei dem eine separate Netzwerkkomponente namens Threshold Service Network verschlüsselte Ergebnisse entschlüsseln oder verifizieren kann, und jede fehlerhafte Berechnung mit einem Fraud-Proof angefochten werden kann. Im Allgemeinen stellt die Kombination von FHE + ZK oder Fraud-Proofs sicher, dass die verschlüsselte Ausführung vertrauenslos (trustless) bleibt. Validatoren entschlüsseln entweder kollektiv nur bei Autorisierung oder sie verifizieren Beweise, dass jeder verschlüsselte Zustandsübergang gültig war, ohne Klartext sehen zu müssen.

Performance-Überlegungen: FHE-Operationen sind rechenintensiv – viele Größenordnungen langsamer als normale Arithmetik. Beispielsweise kostet eine einfache 64-Bit-Addition auf Ethereum etwa 3 Gas, während eine Addition auf einer verschlüsselten 64-Bit-Ganzzahl (euint64) unter Zamas FHEVM etwa 188.000 Gas kostet. Selbst eine 8-Bit-Addition kann rund 94k Gas kosten. Dieser enorme Overhead bedeutet, dass eine einfache Implementierung auf bestehenden Knoten unpraktisch langsam und kostspielig wäre. FHE-VM-Projekte gehen dies mit optimierten kryptografischen Bibliotheken (wie Zamas TFHE-rs-Bibliothek für binäres Gate-Bootstrapping) und kundenspezifischen EVM-Modifikationen für die Performance an. Beispielsweise fügt der modifizierte Geth-Client von Cypher neue Opcodes hinzu und optimiert die Ausführung homomorpher Instruktionen in C++/Assembly, um den Overhead zu minimieren. Dennoch erfordert das Erreichen eines nutzbaren Durchsatzes eine Beschleunigung. Laufende Arbeiten umfassen den Einsatz von GPUs, FPGAs und sogar spezialisierten photonischen Chips, um FHE-Berechnungen zu beschleunigen. Zama berichtet, dass sich ihre FHE-Performance seit 2024 verhundertfacht hat und strebt mit GPU/FPGA-Beschleunigung Tausende von TPS an. Dedizierte FHE-Coprozessor-Server (wie der LightLocker Node von Optalysys) können an Validator-Knoten angeschlossen werden, um verschlüsselte Operationen auf Hardware auszulagern und so über 100 verschlüsselte ERC-20-Transfers pro Sekunde und Knoten zu unterstützen. Da sich Hardware und Algorithmen verbessern, wird sich die Lücke zwischen FHE und herkömmlicher Berechnung verringern, sodass private Kontrakte praxistaugliche Geschwindigkeiten erreichen.

Kompatibilität: Ein Hauptziel von FHE-VM-Designs ist es, mit bestehenden Entwicklungs-Workflows kompatibel zu bleiben. Die fhEVM-Implementierungen von Cypher und Zama ermöglichen es Entwicklern, Kontrakte in Solidity mit minimalen Änderungen zu schreiben – unter Verwendung einer Bibliothek zur Deklaration verschlüsselter Typen und Operationen. Der Rest der Ethereum-Toolchain (Remix, Hardhat usw.) kann weiterhin verwendet werden, da die zugrunde liegenden Modifikationen hauptsächlich auf Client-/Knotenebene stattfinden. Dies senkt die Eintrittsbarriere: Entwickler müssen keine Kryptografie-Experten sein, um einen vertraulichen Smart Contract zu schreiben. Beispielsweise kann eine einfache Addition zweier Zahlen als euint32 c = a + b; geschrieben werden, und die FHEVM übernimmt die verschlüsselungsspezifischen Details im Hintergrund. Die Kontrakte können sogar mit normalen Kontrakten interagieren – z. B. könnte ein verschlüsselter Kontrakt ein entschlüsseltes Ergebnis an einen Standardkontrakt ausgeben, was eine Mischung aus privaten und öffentlichen Teilen in einem Ökosystem ermöglicht.

Aktuelle FHE-VM-Projekte: Mehrere Projekte leisten Pionierarbeit in diesem Bereich. Zama (ein in Paris ansässiges FHE-Startup) entwickelte das grundlegende FHEVM-Konzept und die Bibliotheken (TFHE-rs und eine fhevm-solidity-Bibliothek). Sie beabsichtigen nicht, eine eigene Chain zu starten, sondern stellen anderen die Infrastruktur zur Verfügung. Inco ist eine L1-Blockchain (aufgebaut auf dem Cosmos SDK mit Evmos), die Zamas FHEVM integriert hat, um eine modulare vertrauliche Chain zu schaffen. Ihre Testnets (genannt Gentry und Paillier) demonstrieren verschlüsselte ERC-20-Transfers und andere private DeFi-Primitive. Fhenix ist ein Ethereum Layer-2 Optimistic Rollup, das FHE für die Privatsphäre nutzt. Man entschied sich für einen optimistischen (Fraud-Proof) Ansatz anstelle eines ZK-Rollups aufgrund der hohen Kosten, die FHE und ZK zusammen für jeden Block verursachen würden. Fhenix verwendet dieselbe TFHE-rs-Bibliothek (mit einigen Modifikationen) und führt ein Threshold Service Network ein, um Entschlüsselungen dezentral zu handhaben. Es gibt auch unabhängige Teams wie Fhenix (jetzt umbenannt) und Startups, die MPC + FHE-Hybride erforschen. Darüber hinaus baut Cypher (von Z1 Labs) ein Layer-3-Netzwerk mit Fokus auf KI und Privatsphäre auf, das eine fhEVM mit Funktionen wie Secret Stores und Unterstützung für Federated Learning nutzt. Das Ökosystem ist noch jung, wächst aber rasant, angetrieben durch signifikante Finanzierungen – so wurde Zama bis 2025 mit über 130 Millionen US-Dollar eingeworbenem Kapital zu einem „Unicorn“, um die FHE-Technologie voranzutreiben.

Zusammenfassend lässt sich sagen, dass eine FHE-VM privatsphärenschützende Smart Contracts ermöglicht, indem sie die gesamte Logik auf verschlüsselten Daten On-Chain ausführt. Dieses Paradigma gewährleistet maximale Vertraulichkeit – nichts Sensibles wird jemals in Transaktionen oder Zuständen offengelegt –, während der bestehende Blockchain-Konsens für die Integrität genutzt wird. Die Kosten dafür sind eine erhöhte Rechenlast für Validatoren und Komplexität bei der Schlüsselverwaltung und der Integration von Beweisen. Als Nächstes untersuchen wir ein alternatives Paradigma, das die Berechnung vollständig Off-Chain auslagert und die Chain nur zur Verifizierung nutzt: den Zero-Knowledge-Coprozessor.

Zero-Knowledge-Coprozessoren (ZK-Coprocessors)​

Ein ZK-Coprozessor ist ein neues Blockchain-Architekturmuster, bei dem aufwendige Berechnungen Off-Chain durchgeführt werden und ein prägnanter (succinct) Zero-Knowledge-Proof ihrer Korrektheit On-Chain verifiziert wird. Dies ermöglicht es Smart Contracts, eine weitaus größere Rechenleistung und Datenmenge zu nutzen, als eine On-Chain-Ausführung zulassen würde, ohne dabei die Vertrauenslosigkeit (Trustlessness) zu opfern. Der Begriff Coprozessor wird in Analogie zu Hardware-Coprozessoren verwendet (wie ein Mathematik-Coprozessor oder eine GPU), die spezialisierte Aufgaben für eine CPU übernehmen. Hier delegiert die „CPU“ der Blockchain (die native VM wie die EVM) bestimmte Aufgaben an ein Zero-Knowledge-Proof-System, das als kryptografischer Coprozessor fungiert. Der ZK-Coprozessor liefert ein Ergebnis und einen Beweis dafür zurück, dass das Ergebnis korrekt berechnet wurde, den der On-Chain-Contract verifizieren und anschließend verwenden kann.

Architektur und Workflow​

In einem typischen Setup identifiziert ein dApp-Entwickler Teile seiner Anwendungslogik, die für eine On-Chain-Ausführung zu teuer oder zu komplex sind (z. B. umfangreiche Berechnungen über historische Daten, schwere Algorithmen, ML-Modell-Inferenz usw.). Er implementiert diese Teile als ein Off-Chain-Programm (in einer Hochsprache oder einer Schaltungs-DSL), das einen Zero-Knowledge-Proof seiner Ausführung erstellen kann. Die On-Chain-Komponente ist ein Verifier-Smart-Contract, der Beweise prüft und die Ergebnisse für den Rest des Systems verfügbar macht. Der Ablauf lässt sich wie folgt zusammenfassen:

1. Anfrage (Request) – Der On-Chain-Contract löst eine Anfrage für eine bestimmte Berechnung aus, die Off-Chain durchgeführt werden soll. Dies kann durch eine Benutzertransaktion oder durch den Aufruf der Schnittstelle des ZK-Coprozessors durch einen Contract initiiert werden. Beispielsweise könnte ein DeFi-Contract „proveInterestRate(currentState)“ aufrufen oder ein Benutzer fragt „queryHistoricalData(query)“ ab.
2. Off-Chain-Ausführung & Beweiserstellung (Off-Chain Execution & Proving) – Ein Off-Chain-Dienst (der je nach Design ein dezentrales Netzwerk von Provern oder ein vertrauenswürdiger Dienst sein kann) nimmt die Anfrage auf. Er sammelt alle erforderlichen Daten (On-Chain-Status, Off-Chain-Inputs usw.) und führt die Berechnung in einer speziellen Zero-Knowledge Virtual Machine (ZKVM) oder Schaltung (Circuit) aus. Während der Ausführung wird ein Proof-Trace generiert. Am Ende erstellt der Dienst einen prägnanten Beweis (z. B. einen SNARK oder STARK), der bescheinigt, dass „die Berechnung der Funktion F mit der Eingabe X das Ergebnis Y liefert“, und optional die Datenintegrität bestätigt (mehr dazu unten).
3. On-Chain-Verifizierung (On-Chain Verification) – Der Beweis und das Ergebnis werden an die Blockchain zurückgegeben (oft über eine Callback-Funktion). Der Verifier-Contract prüft die Gültigkeit des Beweises mithilfe effizienter kryptografischer Verifizierung (Pairing-Checks usw.). Wenn er gültig ist, kann der Contract dem Output Y als korrekt vertrauen. Das Ergebnis kann im Status gespeichert, als Event ausgegeben oder in die weitere Contract-Logik eingespeist werden. Wenn der Beweis ungültig ist oder nicht innerhalb einer bestimmten Zeit erbracht wird, kann die Anfrage als fehlgeschlagen betrachtet werden (und es greift potenziell eine Fallback- oder Timeout-Logik).

Abbildung 1: Architektur eines ZK-Coprozessors (Beispiel RISC Zero Bonsai). Off-Chain läuft ein Programm auf einer ZKVM mit Eingaben aus dem Smart-Contract-Aufruf. Ein Ausführungsbeweis wird über einen Relay-Contract On-Chain zurückgegeben, der einen Callback mit den verifizierten Ergebnissen aufruft.

Entscheidend ist, dass die On-Chain-Gas-Kosten für die Verifizierung konstant sind (oder nur sehr langsam wachsen), unabhängig davon, wie komplex die Off-Chain-Berechnung war. Die Verifizierung eines prägnanten Beweises kann in der Größenordnung von einigen hunderttausend Gas kosten (ein Bruchteil eines Ethereum-Blocks), aber dieser Beweis könnte Millionen von Off-Chain durchgeführten Rechenschritten repräsentieren. Wie ein Entwickler einmal scherzte: „Möchten Sie eine digitale Signatur beweisen? ~$15. Möchten Sie eine Million Signaturen beweisen? Ebenfalls ~$15.“. Diese Skalierbarkeit ist ein riesiger Gewinn: dApps können komplexe Funktionalitäten (Big-Data-Analysen, aufwendige Finanzmodelle usw.) anbieten, ohne die Blockchain zu verstopfen.

Die Hauptkomponenten eines ZK-Coprozessor-Systems sind:

• Umgebung zur Beweiserstellung (Proof Generation Environment): Dies kann eine Allzweck-ZKVM (die beliebige Programme ausführen kann) oder maßgeschneiderte Schaltungen sein, die auf spezifische Berechnungen zugeschnitten sind. Die Ansätze variieren:

  • Einige Projekte verwenden handgefertigte Schaltungen (handcrafted circuits) für jede unterstützte Abfrage oder Funktion (um die Effizienz für diese Funktion zu maximieren).
  • Andere bieten eine domänenspezifische Sprache (DSL) oder eine eingebettete DSL an, die Entwickler verwenden, um ihre Off-Chain-Logik zu schreiben, welche dann in Schaltungen kompiliert wird (ein Kompromiss zwischen Benutzerfreundlichkeit und Leistung).
  • Der flexibelste Ansatz ist eine ZKVM: eine virtuelle Maschine (oft basierend auf RISC-Architekturen), auf der Programme in Standardsprachen (Rust, C usw.) geschrieben und automatisch bewiesen werden können. Dies opfert Leistung (die Simulation einer CPU in einer Schaltung verursacht Overhead) für eine maximale Entwicklererfahrung.

• Datenzugriff und Integrität (Data Access and Integrity): Eine besondere Herausforderung besteht darin, die Off-Chain-Berechnung mit den richtigen Daten zu versorgen, insbesondere wenn diese Daten auf der Blockchain liegen (vergangene Blöcke, Contract-Zustände usw.). Eine naive Lösung wäre, dass der Prover von einem Archivknoten liest und ihm vertraut – aber das führt Vertrauensannahmen ein. ZK-Coprozessoren beweisen stattdessen in der Regel, dass alle verwendeten On-Chain-Daten tatsächlich authentisch waren, indem sie eine Verknüpfung zu Merkle-Beweisen oder State-Commitments herstellen. Zum Beispiel könnte das Abfrageprogramm eine Blocknummer und einen Merkle-Beweis eines Speicherplatzes oder einer Transaktion entgegennehmen, und die Schaltung verifiziert diesen Beweis gegen einen bekannten Block-Header-Hash. Es existieren drei Muster:

  1. Inline-Daten: Die benötigten Daten werden On-Chain bereitgestellt (als Eingabe für den Verifier), damit sie direkt geprüft werden können. Dies ist bei großen Datenmengen sehr kostspielig und untergräbt den eigentlichen Zweck.
  2. Vertrauen in ein Oracle: Ein Oracle-Dienst liefert die Daten an den Beweis und bürgt dafür. Dies ist einfacher, führt aber wieder Vertrauen in einen Dritten ein.
  3. Datenaufnahme via ZK beweisen: Beweise für die Aufnahme von Daten in die Historie der Chain werden direkt in die Zero-Knowledge-Schaltung integriert. Dies nutzt die Tatsache aus, dass jeder Ethereum-Block-Header den gesamten vorherigen Zustand (über die State Root) und die Transaktionshistorie festschreibt. Durch die Verifizierung von Merkle-Patricia-Beweisen der Daten innerhalb der Schaltung garantiert der resultierende Beweis dem Contract, dass „diese Berechnung echte Blockchain-Daten aus Block N verwendet hat“, ohne dass zusätzliches Vertrauen erforderlich ist.

  Der dritte Ansatz ist der vertrauensloseste und wird von fortschrittlichen ZK-Coprozessoren wie Axiom und Xpansion verwendet (er erhöht zwar die Beweiskosten, ist aber aus Sicherheitsgründen vorzuziehen). Das System von Axiom beispielsweise modelliert die Blockstruktur, den State Trie und den Transaction Trie von Ethereum innerhalb seiner Schaltungen, sodass es Aussagen beweisen kann wie „das Konto X hatte in Block N den Kontostand Y“ oder „eine Transaktion mit bestimmten Eigenschaften fand in Block N statt“. Es nutzt die Tatsache aus, dass man ausgehend von einem aktuellen vertrauenswürdigen Block-Hash rekursiv die Aufnahme historischer Daten beweisen kann, ohne einer externen Partei vertrauen zu müssen.

• Verifier-Contract: Dieser On-Chain-Contract enthält den Verifizierungsschlüssel und die Logik zum Akzeptieren oder Ablehnen von Beweisen. Bei SNARKs wie Groth16 oder PLONK führt der Verifier einige elliptische Kurven-Pairings aus; bei STARKs führt er Hash-Berechnungen durch. Leistungsoptimierungen wie Aggregation und Rekursion können die On-Chain-Last minimieren. Beispielsweise verwendet Bonsai von RISC Zero einen STARK-zu-SNARK-Wrapper: Es führt Off-Chain eine STARK-basierte VM für hohe Geschwindigkeit aus, generiert dann aber einen kleinen SNARK-Beweis, der die Gültigkeit des STARK bestätigt. Dies schrumpft die Beweisgröße von hunderten Kilobytes auf einige hundert Bytes, was die On-Chain-Verifizierung machbar und günstig macht. Der Solidity-Verifier prüft dann nur noch den SNARK (was eine Operation mit konstanter Zeit ist).

In Bezug auf das Deployment können ZK-Coprozessoren als Layer-2-ähnliche Netzwerke oder als reine Off-Chain-Dienste fungieren. Einige, wie Axiom, begannen als spezialisierter Dienst für Ethereum (mit Unterstützung von Paradigm), bei dem Entwickler Abfragen an das Prover-Netzwerk von Axiom senden und Beweise On-Chain erhalten. Der Slogan von Axiom lautete, Ethereum-Contracts „vertrauenslosen Zugriff auf alle On-Chain-Daten und beliebig ausdrucksstarke Berechnungen darüber“ zu ermöglichen. Es fungiert effektiv als Abfrage-Oracle, bei dem die Antworten durch ZKPs anstatt durch Vertrauen verifiziert werden. Andere, wie Bonsai von RISC Zero, bieten eine offenere Plattform an: Jeder Entwickler kann ein Programm hochladen (kompiliert für eine RISC-V-kompatible ZKVM) und den Beweisdienst von Bonsai über einen Relay-Contract nutzen. Das Relay-Muster, wie in Abbildung 1 dargestellt, umfasst einen Contract, der Anfragen und Antworten vermittelt: Der dApp-Contract ruft das Relay auf, um einen Beweis anzufordern, der Off-Chain-Dienst hört dies ab (z. B. über ein Event oder einen direkten Aufruf), berechnet den Beweis und das Relay ruft anschließend eine Callback-Funktion auf dem dApp-Contract mit dem Ergebnis und dem Beweis auf. Dieses asynchrone Modell ist notwendig, da die Beweiserstellung je nach Komplexität Sekunden bis Minuten dauern kann. Dies führt eine Latenz ein (und die Annahme der Lebendigkeit, dass der Prover antwortet), während FHE-VM-Berechnungen synchron innerhalb eines Blocks stattfinden. Die Gestaltung der Anwendung für diesen asynchronen Workflow (ähnlich wie bei Oracle-Antworten) ist Teil der Nutzung eines ZK-Coprozessors.

Bekannte ZK-Coprozessor-Projekte​

• Axiom: Axiom ist ein auf Ethereum zugeschnittener ZK-Coprozessor, der sich ursprünglich auf den Beweis von Abfragen historischer On-Chain-Daten konzentrierte. Er verwendet das Halo2-Proof-Framework (ein Plonk-ähnlicher SNARK), um Beweise zu erstellen, die die kryptografischen Strukturen von Ethereum einbeziehen. Im System von Axiom kann ein Entwickler Dinge abfragen wie „wie war der Zustand von Contract X in Block N?“ oder eine Berechnung über alle Transaktionen in einem Bereich durchführen. Unter der Haube mussten die Schaltungen von Axiom die State/Trie-Logik von Ethereum implementieren und sogar Operationen auf elliptischen Kurven sowie SNARK-Verifizierungen innerhalb der Schaltung durchführen, um Rekursion zu unterstützen. Trail of Bits stellte in einem Audit die Komplexität der Halo2-Schaltungen von Axiom fest, die ganze Blöcke und Zustände modellieren. Nach dem Audit generalisierte Axiom seine Technologie zu einer OpenVM, die es ermöglicht, beliebigen Rust-Code mit derselben Halo2-basierten Infrastruktur zu beweisen. (Dies spiegelt den Trend wider, von domänenspezifischen Schaltungen zu einem allgemeineren ZKVM-Ansatz überzugehen.) Das Axiom-Team demonstrierte ZK-Abfragen, die Ethereum nativ nicht durchführen kann, und ermöglichte so einen zustandslosen Zugriff auf alle historischen Daten mit kryptografischer Integrität. Sie betonten auch die Sicherheit, indem sie Bugs in unzureichend eingeschränkten Schaltungen (under-constrained circuits) fanden und behoben und die Korrektheit (Soundness) sicherstellten. Während das ursprüngliche Produkt von Axiom während ihrer Neuausrichtung eingestellt wurde, bleibt ihr Ansatz ein Meilenstein für ZK-Coprozessoren.

• RISC Zero Bonsai: RISC Zero ist eine ZKVM, die auf der RISC-V-Architektur basiert. Ihre zkVM kann beliebige Programme ausführen (geschrieben in Rust, C++ und anderen Sprachen, die für RISC-V kompiliert wurden) und einen STARK-Beweis der Ausführung erstellen. Bonsai ist der Cloud-Dienst von RISC Zero, der diese Beweiserstellung auf Abfrage bereitstellt und als Coprozessor für Smart Contracts fungiert. Um ihn zu nutzen, schreibt ein Entwickler ein Programm (z. B. eine Funktion, die komplexe Mathematik ausführt oder eine Off-Chain-API-Antwort verifiziert), lädt es in den Bonsai-Dienst hoch und stellt einen entsprechenden Verifier-Contract bereit. Wenn der Contract diese Berechnung benötigt, ruft er das Bonsai-Relay auf, welches die Beweiserstellung auslöst und das Ergebnis per Callback zurückgibt. Ein demonstriertes Anwendungsbeispiel war die Off-Chain-Governance-Berechnung: RISC Zero zeigte eine DAO, die Bonsai nutzte, um Stimmen auszuzählen und komplexe Abstimmungsmetriken Off-Chain zu berechnen und dann einen Beweis zu posten, sodass der On-Chain-Governor-Contract dem Ergebnis mit minimalen Gas-Kosten vertrauen konnte. Die Technologie von RISC Zero betont, dass Entwickler vertraute Programmierparadigmen nutzen können – zum Beispiel das Schreiben einer Rust-Funktion zur Berechnung von Werten –, während die schwere Arbeit der Schaltungserstellung von der zkVM erledigt wird. Da Beweise jedoch groß sein können, implementierten sie, wie bereits erwähnt, eine SNARK-Kompression für die On-Chain-Verifizierung. Im August 2023 verifizierten sie erfolgreich RISC-Zero-Beweise im Sepolia-Testnet von Ethereum, was etwa 300k Gas pro Beweis kostete. Dies öffnet die Tür für Ethereum-dApps, Bonsai schon heute als Skalierungs- und Datenschutzlösung zu nutzen. (Bonsai befindet sich noch in der Alpha-Phase, ist nicht produktionsreif und verwendet ein temporäres SNARK-Setup ohne Zeremonie.)

• Andere: Es gibt zahlreiche weitere Akteure und Forschungsinitiativen. Expansion/Xpansion verwendet einen Ansatz mit eingebetteter DSL, bei dem Entwickler Abfragen über On-Chain-Daten in einer spezialisierten Sprache schreiben können und das System die Beweiserstellung intern handhabt. Cairo von StarkWare und die zkEVM von Polygon sind eher allgemeine ZK-Rollup-VMs, aber ihre Technologie könnte für coprozessorähnliche Zwecke umfunktioniert werden, indem Beweise innerhalb von L1-Contracts verifiziert werden. Wir sehen auch Projekte im Bereich ZKML (ZK Machine Learning), die effektiv als Coprozessoren fungieren, um ML-Modell-Inferenzen oder Trainingsergebnisse On-Chain zu verifizieren. Ein ZKML-Setup kann beispielsweise beweisen, dass „eine neuronale Netzwerkinferenz auf privaten Eingaben die Klassifizierung X ergeben hat“, ohne die Eingaben offenzulegen oder die Berechnung On-Chain durchzuführen. Dies sind Spezialfälle des Coprozessor-Konzepts angewendet auf KI.

Vertrauensannahmen: ZK-Coprozessoren verlassen sich auf die Korrektheit (Soundness) der kryptografischen Beweise. Wenn das Beweissystem sicher ist (und jedes Trusted Setup ehrlich durchgeführt wurde), garantiert ein akzeptierter Beweis, dass die Berechnung korrekt war. Es ist kein zusätzliches Vertrauen in den Prover erforderlich – selbst ein bösartiger Prover kann den Verifier nicht von einer falschen Aussage überzeugen. Es gibt jedoch eine Lebendigkeitsannahme (Liveness Assumption): Jemand muss die Off-Chain-Berechnung tatsächlich durchführen und den Beweis erbringen. In der Praxis könnte dies ein dezentrales Netzwerk (mit Anreizen oder Gebühren für die Arbeit) oder ein einzelner Dienstbetreiber sein. Wenn niemand den Beweis liefert, bleibt die On-Chain-Anfrage möglicherweise ungelöst. Ein weiterer subtiler Vertrauensaspekt ist die Datenverfügbarkeit für Off-Chain-Eingaben, die nicht auf der Blockchain liegen. Wenn die Berechnung von privaten oder externen Daten abhängt, kann der Verifier nicht wissen, ob diese Daten ehrlich bereitgestellt wurden, es sei denn, es werden zusätzliche Maßnahmen (wie Data Commitments oder Oracle-Signaturen) ergriffen. Für reine On-Chain-Datenberechnungen gewährleisten die beschriebenen Mechanismen jedoch eine Vertrauenslosigkeit, die der Chain selbst entspricht (Axiom argumentierte, dass ihre Beweise für historische Abfragen eine „kryptografisch zur Sicherheit von Ethereum äquivalente“ Sicherheit bieten).

Datenschutz (Privacy): Zero-Knowledge-Proofs unterstützen von Natur aus den Datenschutz – der Prover kann Eingaben verborgen halten, während er Aussagen darüber beweist. Im Kontext eines Coprozessors bedeutet dies, dass ein Beweis es einem Contract ermöglichen kann, ein Ergebnis zu verwenden, das aus privaten Daten abgeleitet wurde. Ein Beweis könnte beispielsweise zeigen: „Kredit-Score des Nutzers > 700, daher Kredit genehmigen“, ohne den tatsächlichen Score oder die Rohdaten offenzulegen. Bei Axiom lag der Fokus eher auf öffentlich bekannten Daten (Blockchain-Historie), daher stand Datenschutz dort nicht im Mittelpunkt. Die zkVM von RISC Zero könnte jedoch verwendet werden, um Behauptungen über geheime Daten zu beweisen, die von einem Benutzer bereitgestellt werden: Die Daten bleiben Off-Chain und nur das benötigte Ergebnis gelangt On-Chain. Es ist anzumerken, dass ein ZK-Proof im Gegensatz zu FHE normalerweise keine dauerhafte Vertraulichkeit des Zustands bietet – es ist ein einmaliger Beweis. Wenn ein Workflow die Aufrechterhaltung eines geheimen Zustands über mehrere Transaktionen hinweg erfordert, könnte man dies so aufbauen, dass der Contract ein Commitment zum Zustand speichert und jeder Beweis einen gültigen Zustandsübergang vom alten zum neuen Commitment zeigt, wobei die Geheimnisse verborgen bleiben. Dies ist im Wesentlichen die Funktionsweise von ZK-Rollups für private Transaktionen (wie Aztec oder Zcash). ZK-Coprozessoren können also vollständig private Zustandsmaschinen ermöglichen, aber die Implementierung ist nicht trivial; oft werden sie für einmalige Berechnungen verwendet, bei denen entweder der Input oder der Output (oder beides) nach Bedarf privat sein können.

Entwicklererfahrung: Die Nutzung eines ZK-Coprozessors erfordert in der Regel das Erlernen neuer Werkzeuge. Das Schreiben maßgeschneiderter Schaltungen (Option (1) oben) ist sehr komplex und wird meist nur für eng begrenzte Zwecke getan. Höherwertige Optionen wie DSLs oder ZKVMs erleichtern das Leben, verursachen aber dennoch Overhead: Der Entwickler muss Off-Chain-Code schreiben und bereitstellen sowie die Interaktion verwalten. Im Gegensatz zur FHE-VM, bei der die Verschlüsselung größtenteils im Hintergrund abläuft und der Entwickler normalen Smart-Contract-Code schreibt, muss der Entwickler hier seine Logik aufteilen und für den Off-Chain-Teil möglicherweise in einer anderen Sprache (Rust etc.) schreiben. Initiativen wie die DSLs Noir, Leo, Circom oder der Ansatz von RISC Zero verbessern jedoch rasant die Zugänglichkeit. RISC Zero bietet beispielsweise Templates und eine Foundry-Integration an, sodass ein Entwickler seinen Off-Chain-Code lokal simulieren (auf Korrektheit prüfen) und ihn dann nahtlos über den Bonsai-Callback in Solidity-Tests einbinden kann. Mit der Zeit ist mit Entwicklungs-Frameworks zu rechnen, die abstrahieren, ob ein Logikbaustein per ZK-Proof oder On-Chain ausgeführt wird – der Compiler oder die Tools könnten dies basierend auf den Kosten entscheiden.

FHE-VM vs. ZK-Coprozessor: Vergleich​

Sowohl FHE-VMs als auch ZK-Coprozessoren ermöglichen eine Form von „Berechnung auf privaten Daten mit On-Chain-Garantie“, unterscheiden sich jedoch grundlegend in ihrer Architektur. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen:

| Durchsetzung der Integrität | Konstruktionsbedingt berechnen alle Validatoren den nächsten Zustand homomorph neu. Wenn also ein bösartiger Akteur ein falsches Chiffretext-Ergebnis liefert, werden andere eine Diskrepanz feststellen – der Konsens schlägt fehl, sofern nicht alle das gleiche Ergebnis erhalten. Somit wird die Integrität durch redundante Ausführung erzwungen (wie bei einer normalen Blockchain, nur auf verschlüsselten Daten). Zusätzliche ZK-Proofs werden häufig verwendet, um Geschäftsregeln durchzusetzen (z. B. dass ein Benutzer keine Einschränkung verletzt hat), da Validatoren Klartextbedingungen nicht direkt prüfen können. | Die Integrität wird durch den Verifier-Contract erzwungen, der den ZK-Proof prüft. Solange der Proof verifiziert wird, ist garantiert, dass das Ergebnis mit einer gültigen Ausführung des Off-Chain-Programms konsistent ist. Für die Korrektheit ist keine Honest-Majority-Annahme erforderlich – selbst ein einziger ehrlicher Verifier (der Contract-Code selbst) genügt. Der On-Chain-Contract wird einfach jeden falschen oder fehlenden Proof ablehnen (ähnlich wie er eine ungültige Signatur ablehnen würde). Eine Überlegung: Wenn der Prover abbricht oder sich verzögert, benötigt der Contract unter Umständen eine Fallback-Logik (oder Benutzer müssen es später erneut versuchen), aber er wird keine falschen Ergebnisse akzeptieren. | | Entwicklererfahrung | Vorteile: Es können weitgehend vertraute Smart-Contract-Sprachen (Solidity usw.) mit Erweiterungen verwendet werden. Die Vertraulichkeit wird von der Plattform verwaltet – Entwickler kümmern sich hauptsächlich darum, was verschlüsselt werden soll und wer die Schlüssel hält. Die Komposition von verschlüsselten und normalen Verträgen ist möglich, wodurch die Komponierbarkeit von DeFi erhalten bleibt (nur mit verschlüsselten Variablen). Nachteile: FHE-Einschränkungen müssen verstanden werden – z. B. keine direkten bedingten Sprünge auf geheimen Daten ohne spezielle Handhabung, begrenzte Schaltkreistiefe (obwohl Bootstrapping in TFHE beliebige Berechnungslängen auf Kosten der Zeit ermöglicht). Das Debuggen verschlüsselter Logik kann schwierig sein, da Laufzeitwerte ohne den Schlüssel nicht einfach eingesehen werden können. Zudem erhöhen Schlüsselmanagement und Berechtigungen die Komplexität des Contract-Designs. | Vorteile: Potenziell kann jede Programmiersprache für den Off-Chain-Teil verwendet werden (insbesondere mit einer zkVM). Bestehende Bibliotheken/Code können im Off-Chain-Programm genutzt werden (mit Vorbehalten hinsichtlich der ZK-Kompatibilität). Bei Verwendung einer allgemeinen zkVM benötigt der Entwickler keine speziellen Kryptographie-Kenntnisse – er schreibt normalen Code und erhält einen Proof. Zudem können für rechenintensive Aufgaben Bibliotheken (z. B. Machine-Learning-Code) verwendet werden, die niemals on-chain laufen würden. Nachteile: Entwickler müssen die Off-Chain-Infrastruktur orchestrieren oder einen Proving-Service nutzen. Die Handhabung asynchroner Workflows und deren Integration in die On-Chain-Logik erfordert mehr Designaufwand (z. B. Speichern eines schwebenden Zustands, Warten auf Callback). Das Schreiben effizienter Schaltkreise oder zkVM-Code erfordert möglicherweise das Erlernen neuer Einschränkungen (z. B. keine Fließkommazahlen, Verwendung von Festkommazahlen oder speziellen Primitiven; Vermeidung starker Verzweigungen, die die Proving-Zeit aufblähen; Optimierung der Constraint-Anzahl). Zudem besteht die Last, mit Proof-Fehlern, Timeouts usw. umzugehen, was in regulärem Solidity keine Rolle spielt. Das Ökosystem der Tools wächst, aber es ist für viele ein neues Paradigma. |

Beide Ansätze werden aktiv verbessert, und wir sehen sogar eine Konvergenz: Wie erwähnt, werden ZKPs innerhalb von FHE-VMs für bestimmte Prüfungen verwendet, und umgekehrt schlagen einige Forscher vor, FHE zu verwenden, um Prover-Inputs in ZK privat zu halten (damit ein Cloud-Prover Ihre geheimen Daten nicht sieht). Es ist denkbar, dass zukünftige Systeme beide kombinieren – z. B. FHE off-chain ausführen und dann die Korrektheit dessen on-chain beweisen, oder FHE on-chain nutzen, aber ZK-Proofs für Light-Clients verwenden, um zu zeigen, dass die verschlüsselten Operationen korrekt durchgeführt wurden. Jede Technik hat ihre Stärken: FHE-VMs bieten kontinuierliche Privatsphäre und Echtzeit-Interaktion auf Kosten hoher Rechenleistung, während ZK-Coprozessoren Skalierbarkeit und Flexibilität auf Kosten von Latenz und Komplexität bieten.

Anwendungsfälle und Auswirkungen​

Der Einzug programmierbarer Privatsphäre eröffnet eine Fülle neuer Blockchain-Anwendungen über verschiedene Branchen hinweg. Im Folgenden untersuchen wir, wie FHE-VMs und ZK-Coprozessoren (oder Hybride) verschiedene Bereiche durch privatsphäre-schützende Smart Contracts und eine sichere Datenökonomie stärken können.

Vertrauliches DeFi und Finanzwesen​

Im dezentralen Finanzwesen kann Privatsphäre Front-Running mildern, Handelsstrategien schützen und regulatorische Anforderungen erfüllen, ohne auf Transparenz zu verzichten, wo sie benötigt wird. Confidential DeFi könnte es Benutzern ermöglichen, mit Protokollen zu interagieren, ohne ihre Positionen der Welt preiszugeben.

• Private Transaktionen und verborgene Guthaben: Mit FHE können vertrauliche Token-Transfers (verschlüsselte ERC-20-Guthaben und Transaktionen) oder Shielded Pools auf einer Blockchain L1 implementiert werden. Kein Beobachter kann sehen, wie viele Token Sie halten oder transferiert haben, was das Risiko gezielter Angriffe auf Basis von Beständen eliminiert. ZK-Proofs können sicherstellen, dass Guthaben synchron bleiben und kein Double-Spending auftritt (ähnlich wie bei Zcash, aber auf Smart-Contract-Plattformen). Ein Beispiel ist ein vertraulicher AMM (Automated Market Maker), bei dem Poolreserven und Trades on-chain verschlüsselt sind. Arbitrageure oder Front-Runner können den Pool nicht ausnutzen, da sie die Preis-Slippage erst nach Abschluss des Trades beobachten können, was den MEV reduziert. Erst nach einer gewissen Verzögerung oder über einen zugriffsbeschränkten Mechanismus könnten einige Daten für Prüfzwecke offengelegt werden.

• MEV-resitente Auktionen und Handel: Miner und Bots nutzen die Transparenz von Transaktionen aus, um Trades per Front-Running zu manipulieren. Mit Verschlüsselung könnte man einen verschlüsselten Mempool oder Batch-Auktionen einführen, bei denen Aufträge als Chiffretext eingereicht werden. Erst nachdem die Auktion abgeschlossen ist, werden die Trades entschlüsselt. Dieses Konzept, manchmal als Fair Order Flow bezeichnet, kann durch Threshold-Entschlüsselung (mehrere Validatoren entschlüsseln gemeinsam den Batch) oder durch den Nachweis von Auktionsergebnissen via ZK ohne Offenlegung einzelner Gebote erreicht werden. Beispielsweise könnte ein ZK-Coprozessor einen Batch versiegelter Gebote off-chain entgegennehmen, den Auktionspreis berechnen und nur diesen Preis sowie die Gewinner mit Proofs ausgeben. Dies wahrt die Fairness und die Privatsphäre der unterlegenen Gebote.

• Vertrauliche Kreditvergabe und Derivate: Bei der DeFi-Kreditvergabe möchten Benutzer möglicherweise weder die Größe ihrer Kredite noch ihre Sicherheiten preisgeben (da dies die Marktstimmung beeinflussen oder Ausnutzung provozieren kann). Eine FHE-VM kann ein verschlüsseltes Kreditbuch führen, in dem alle Kreditdetails verschlüsselt sind. Die Smart-Contract-Logik kann dennoch Regeln wie Liquidationsbedingungen durchsetzen, indem sie auf verschlüsselten Gesundheitsfaktoren operiert. Wenn die Besicherungsquote eines Kredits unter einen Schwellenwert fällt, kann der Contract (mithilfe von ZK-Proofs) diesen zur Liquidation markieren, ohne jemals exakte Werte preiszugeben – er könnte lediglich ein Klartext-Flag für "Ja/Nein" erzeugen. Ähnlich könnten geheime Derivat- oder Optionspositionen on-chain verwaltet werden, wobei nur aggregierte Risikokennzahlen offengelegt werden. Dies könnte Copy-Trading verhindern und proprietäre Strategien schützen, was die Beteiligung institutioneller Akteure fördert.

• Konforme Privatsphäre: Nicht alle Finanzkontexte erfordern totale Anonymität; manchmal ist eine selektive Offenlegung für die Regulierung erforderlich. Mit diesen Werkzeugen können wir eine regulierte Privatsphäre erreichen: Trades sind beispielsweise für die Öffentlichkeit privat, aber eine regulierte Börse kann bestimmte Eigenschaften entschlüsseln oder Proofs darüber erhalten. Man könnte via ZK beweisen, dass „dieser Trade keine auf der schwarzen Liste stehende Adresse beinhaltete und beide Parteien KYC-verifiziert sind“, ohne Identitäten gegenüber der Chain offenzulegen. Dieses Gleichgewicht könnte Anti-Geldwäsche-Regeln (AML) erfüllen, während Benutzeridentitäten und Positionen für alle anderen vertraulich bleiben. FHE könnte es einem On-Chain-Compliance-Officer-Contract ermöglichen, verschlüsselte Transaktionen nach Risikosignalen zu scannen (mit einem Entschlüsselungsschlüssel, der beispielsweise nur per Gerichtsbeschluss zugänglich ist).

Digitale Identität und persönliche Daten​

Identitätssysteme werden erheblich von On-Chain-Privatsphäre-Technologien profitieren. Derzeit ist es aufgrund von Datenschutzgesetzen und der Zurückhaltung der Nutzer unpraktisch, persönliche Anmeldedaten oder Attribute in ein öffentliches Ledger einzutragen. Mit FHE und ZK kann eine selbstbestimmte Identität (SSI) privatsphäre-schonend realisiert werden:

• Zero-Knowledge Credentials: Mithilfe von ZK-Proofs (die bereits in einigen Identitätsprojekten üblich sind) kann ein Benutzer Aussagen beweisen wie „Ich bin über 18“, „Ich besitze einen gültigen Führerschein“ oder „Mein Einkommen liegt über 50.000 $ (für das Kredit-Scoring)“, ohne weitere persönliche Informationen preiszugeben. ZK-Coprozessoren können dies verbessern, indem sie komplexere Prüfungen off-chain durchführen, z. B. den Nachweis, dass der Kredit-Score eines Benutzers über einem Schwellenwert liegt, indem eine private Kreditdatenbank abgefragt wird (ähnlich wie Axiom), und nur ein Ja/Nein an die Blockchain ausgegeben wird.

• Vertrauliches KYC in DeFi: Stellen Sie sich ein DeFi-Protokoll vor, das gesetzlich verpflichtet ist, das KYC seiner Nutzer sicherzustellen. Mit einer FHE-VM können die Anmeldedaten eines Benutzers verschlüsselt on-chain gespeichert (oder über eine DID referenziert) werden, und ein Smart Contract kann eine FHE-Berechnung durchführen, um zu verifizieren, dass die KYC-Informationen den Anforderungen entsprechen. Beispielsweise könnte ein Contract homomorph prüfen, ob Name und Sozialversicherungsnummer in einem verschlüsselten Benutzerprofil mit einer Liste sanktionierter Personen (ebenfalls verschlüsselt) übereinstimmen oder ob das Land des Benutzers nicht eingeschränkt ist. Der Contract würde nur ein verschlüsseltes „Bestanden/Nicht bestanden“ erhalten, das von den Netzwerk-Validatoren per Threshold-Entschlüsselung in ein Boolesches Flag umgewandelt werden kann. Nur die Tatsache, ob der Benutzer zugelassen ist oder nicht, wird offengelegt, wodurch die Vertraulichkeit personenbezogener Daten gewahrt bleibt und die DSGVO-Prinzipien eingehalten werden. Diese selektive Offenlegung gewährleistet Compliance und Privatsphäre.

• Attributbasierter Zugriff und selektive Offenlegung: Benutzer könnten eine Reihe von verifizierbaren Credentials (Alter, Staatsbürgerschaft, Fähigkeiten usw.) als verschlüsselte Attribute besitzen. Sie können bestimmte dApps autorisieren, Berechnungen darauf auszuführen, ohne alles offenzulegen. Beispielsweise könnte eine dezentrale Rekrutierungs-dApp Kandidaten filtern, indem sie Suchvorgänge auf verschlüsselten Lebensläufen durchführt (mittels FHE) – z. B. Jahre an Erfahrung zählen, Zertifizierungen prüfen – und nur bei einer Übereinstimmung den Kandidaten off-chain kontaktieren. Die privaten Details des Kandidaten bleiben verschlüsselt, sofern er sich nicht zur Offenlegung entscheidet. ZK-Proofs ermöglichen es Benutzern zudem, selektiv zu beweisen, dass sie eine Kombination von Attributen besitzen (z. B. über 21 und in einer bestimmten Postleitzahl ansässig), ohne die tatsächlichen Werte zu verraten.

• Mehrparteien-Identitätsprüfung: Manchmal muss die Identität eines Benutzers von mehreren Parteien überprüft werden (z. B. Hintergrundprüfung durch Firma A, Bonitätsprüfung durch Firma B). Mit homomorphen und ZK-Tools könnte jeder Verifizierer einen verschlüsselten Score oder eine Genehmigung beisteuern, und ein Smart Contract kann diese zu einer endgültigen Entscheidung aggregieren, ohne die einzelnen Beiträge offenzulegen. Beispielsweise liefern drei Agenturen verschlüsselte „Bestanden/Nicht bestanden“-Bits, und der Contract gibt eine Genehmigung aus, wenn alle drei positiv sind – der Benutzer oder die vertrauende Partei sieht nur das Endergebnis, nicht aber, welche spezifische Agentur ihn eventuell abgelehnt hat. Dies wahrt die Privatsphäre des Datensatzes des Benutzers bei jeder Agentur und kann Voreingenommenheit oder Stigmatisierung reduzieren.

Gesundheitswesen und sensibler Datenaustausch​

Gesundheitsdaten sind hochsensibel und reguliert, doch die Kombination von Daten aus mehreren Quellen kann einen enormen Wert freisetzen (für Forschung, Versicherungen, personalisierte Medizin). Blockchain könnte eine Vertrauensebene für den Datenaustausch bieten, wenn die Privatsphäre gewahrt bleibt. Vertrauliche Smart Contracts könnten neue Gesundheitsdaten-Ökosysteme ermöglichen:

• Sicherer medizinischer Datenaustausch: Patienten könnten Referenzen zu ihren Krankenakten in verschlüsselter Form on-chain speichern. Ein FHE-fähiger Contract könnte es einer Forschungseinrichtung ermöglichen, Analysen auf einer Kohorte von Patientendaten durchzuführen, ohne diese zu entschlüsseln. Beispielsweise könnte ein Contract die durchschnittliche Wirksamkeit eines Medikaments über verschlüsselte Patientenergebnisse berechnen. Nur aggregierte statistische Ergebnisse werden entschlüsselt ausgegeben (und vielleicht nur, wenn eine Mindestanzahl von Patienten enthalten ist, um eine Re-Identifizierung zu verhindern). Patienten könnten Mikrozahlungen für die Bereitstellung ihrer verschlüsselten Daten für die Forschung erhalten, in dem Wissen, dass ihre Privatsphäre gewahrt bleibt, da selbst die Blockchain und die Forscher nur Chiffretext oder aggregierte Proofs sehen. Dies fördert einen Datenmarktplatz für das Gesundheitswesen, der die Privatsphäre respektiert.

• Privatsphäre-schonende Versicherungsansprüche: Die Bearbeitung von Krankenversicherungsansprüchen könnte über Smart Contracts automatisiert werden, die Bedingungen auf medizinischen Daten verifizieren, ohne die Daten dem Versicherer offenzulegen. Ein Anspruch könnte einen verschlüsselten Diagnosecode und verschlüsselte Behandlungskosten enthalten; der Contract prüft mittels FHE die Policenregeln (z. B. Deckung, Selbstbeteiligung) auf diesen verschlüsselten Daten. Er könnte eine Genehmigung und einen Zahlungsbetrag ausgeben, ohne dem Versicherer jemals die tatsächliche Diagnose auf der Blockchain preiszugeben (nur Patient und Arzt besaßen den Schlüssel). ZK-Proofs könnten verwendet werden, um zu zeigen, dass die Daten des Patienten aus den Unterlagen eines zertifizierten Krankenhauses stammen (unter Verwendung von Tools wie Axiom), ohne den Datensatz selbst offenzulegen. Dies schützt die Privatsphäre der Patienten und beugt Betrug vor.

• Berechnungen auf Genom- und persönlichen Daten: Genomdaten sind extrem sensibel (sie sind buchstäblich der DNA-Bauplan eines Menschen). Die Analyse von Genomen kann jedoch wertvolle gesundheitliche Erkenntnisse liefern. Unternehmen könnten FHE-VMs nutzen, um Berechnungen auf verschlüsselten Genomen durchzuführen, die von Benutzern hochgeladen wurden. Ein Smart Contract könnte beispielsweise ein Gen-Umwelt-Risikomodell auf verschlüsselten Genomdaten und verschlüsselten Umweltdaten (etwa von Wearables) ausführen und einen Risikoscore ausgeben, den nur der Benutzer entschlüsseln kann. Die Logik ist im Contract kodiert und läuft homomorph ab, sodass die Genomdaten niemals im Klartext erscheinen. Auf diese Weise erhalten Nutzer Erkenntnisse, ohne Unternehmen rohe DNA-Daten zu geben – was sowohl Datenschutz- als auch Dateneigentumsbedenken mindert.

• Epidemiologie und öffentliche Gesundheit: In Situationen wie Pandemien ist der Datenaustausch für die Modellierung der Krankheitsausbreitung lebenswichtig, aber Datenschutzgesetze können dies behindern. ZK-Coprozessoren könnten es Gesundheitsbehörden ermöglichen, Anfragen wie „Wie viele Personen in Region X wurden in den letzten 24 Stunden positiv getestet?“ über Proofs an ein Netzwerk von Krankenhausdaten zu stellen. Jedes Krankenhaus bewahrt Patientendaten off-chain auf, kann aber dem Contract der Behörde die Anzahl der Positivfälle beweisen, ohne die Identität der Personen preiszugeben. Ähnlich könnte eine Kontaktverfolgung durch den Abgleich verschlüsselter Standortverläufe erfolgen: Contracts können Überschneidungen verschlüsselter Standortverläufe von Patienten berechnen, um Hotspots zu identifizieren, und nur die Hotspot-Standorte ausgeben (und vielleicht eine verschlüsselte Liste betroffener IDs, die nur das Gesundheitsamt entschlüsseln kann). Die rohen Standortverläufe von Einzelpersonen bleiben privat.

Datenmarktplätze und Zusammenarbeit​

Die Fähigkeit, Berechnungen auf Daten durchzuführen, ohne sie offenzulegen, eröffnet neue Geschäftsmodelle rund um den Datenaustausch. Einheiten können an Berechnungen zusammenarbeiten, in dem Wissen, dass ihre proprietären Daten nicht exponiert werden:

• Sichere Datenmarktplätze: Verkäufer können Daten in verschlüsselter Form auf einem Blockchain-Marktplatz zur Verfügung stellen. Käufer können bezahlen, um spezifische Analysen oder Machine-Learning-Modelle über einen Smart Contract auf dem verschlüsselten Datensatz auszuführen, und erhalten entweder das trainierte Modell oder aggregierte Ergebnisse. Die Rohdaten des Verkäufers werden niemals dem Käufer oder der Öffentlichkeit offengelegt – der Käufer erhält möglicherweise nur ein Modell (das dennoch Informationen über Gewichte lecken könnte, was jedoch durch Techniken wie Differential Privacy oder Steuerung der Ausgabegranularität gemildert werden kann). ZK-Proofs können dem Käufer garantieren, dass die Berechnung korrekt über dem versprochenen Datensatz durchgeführt wurde. Dieses Szenario fördert den Datenaustausch: Ein Unternehmen könnte beispielsweise Nutzerverhaltensdaten monetarisieren, indem es zugelassenen Algorithmen erlaubt, darauf unter Verschlüsselung zu laufen, ohne die Daten selbst preiszugeben.

• Föderiertes Lernen & Dezentrale KI: Beim dezentralen maschinellen Lernen möchten mehrere Parteien (z. B. verschiedene Unternehmen oder Geräte) gemeinsam ein Modell auf ihren kombinierten Daten trainieren, ohne Daten untereinander auszutauschen. FHE-VMs glänzen hier: Sie ermöglichen föderiertes Lernen, bei dem die Modell-Updates jeder Partei homomorph durch einen Contract aggregiert werden. Da die Updates verschlüsselt sind, erfährt kein Teilnehmer die Beiträge der anderen. Der Contract könnte sogar Teile der Trainingsschleife (wie Gradientenverfahren-Schritte) on-chain unter Verschlüsselung durchführen und ein aktualisiertes Modell erzeugen, das nur autorisierte Parteien entschlüsseln können. ZK kann dies ergänzen, indem bewiesen wird, dass das Update jeder Partei gemäß dem Trainingsalgorithmus berechnet wurde (was verhindert, dass ein bösartiger Teilnehmer das Modell vergiftet). Dies bedeutet, dass ein globales Modell mit voller Prüfbarkeit on-chain trainiert werden kann, während die Trainingsdaten jedes Mitwirkenden privat bleiben. Zu den Anwendungsfällen gehören das gemeinsame Training von Betrugserkennungsmodellen über Banken hinweg oder die Verbesserung von KI-Assistenten mit Daten vieler Nutzer ohne Zentralisierung der Rohdaten.

• Organisationsübergreifende Analysen: Stellen Sie sich zwei Unternehmen vor, die für eine Partnerschaftskampagne ihre Schnittmenge an Kunden finden wollen, ohne sich gegenseitig ihre gesamten Kundenlisten offenzulegen. Sie könnten jeweils ihre Kunden-ID-Listen verschlüsseln und ein Commitment hochladen. Ein FHE-fähiger Contract kann die Schnittmenge auf den verschlüsselten Mengen berechnen (unter Verwendung von Techniken wie Private Set Intersection via FHE). Das Ergebnis könnte eine verschlüsselte Liste gemeinsamer Kunden-IDs sein, die nur ein gegenseitig vertrauenswürdiger Dritter (oder die Kunden selbst über einen bestimmten Mechanismus) entschlüsseln kann. Alternativ ein ZK-Ansatz: Eine Partei beweist der anderen in Zero-Knowledge, dass „wir N gemeinsame Kunden haben und hier ist eine Verschlüsselung dieser IDs“, zusammen mit einem Proof, dass die Verschlüsselung tatsächlich den gemeinsamen Einträgen entspricht. Auf diese Weise können sie eine Kampagne für diese N Kunden durchführen, ohne jemals ihre vollständigen Listen im Klartext ausgetauscht zu haben. Ähnliche Szenarien: Berechnung von Lieferketten-Metriken über Wettbewerber hinweg, ohne Details einzelner Lieferanten preiszugeben, oder Banken, die Kreditinformationen abgleichen, ohne vollständige Kundendaten zu teilen.

• Sichere Multi-Party Computation (MPC) auf der Blockchain: FHE und ZK bringen MPC-Konzepte im Wesentlichen on-chain. Komplexe Geschäftslogik, die mehrere Organisationen umspannt, kann in einem Smart Contract so kodiert werden, dass die Eingaben jeder Organisation geheim geteilt oder verschlüsselt sind. Der Contract (als MPC-Moderator) erzeugt Ergebnisse wie Gewinnbeteiligungen, Kostenkalkulationen oder gemeinsame Risikobewertungen, denen jeder vertrauen kann. Angenommen, mehrere Energieunternehmen möchten einen Marktplatz für den Stromhandel abrechnen. Sie könnten ihre verschlüsselten Gebote und Angebote in eine Smart-Contract-Auktion einspeisen; der Contract berechnet die Clearingpreise und Zuteilungen auf den verschlüsselten Geboten und gibt die Zuteilung und Kosten jedes Unternehmens nur an dieses Unternehmen aus (via Verschlüsselung mit dessen öffentlichem Schlüssel). Kein Unternehmen sieht die Gebote der anderen, was Wettbewerbsinformationen schützt, aber das Auktionsergebnis ist fair und überprüfbar. Diese Kombination aus Blockchain-Transparenz und MPC-Privatsphäre könnte Konsortien und Unternehmenskonsortien revolutionieren, die sich derzeit auf vertrauenswürdige Dritte verlassen.

Dezentrales maschinelles Lernen (ZKML und FHE-ML)​

Maschinelles Lernen verifizierbar und privat auf Blockchains zu bringen, ist ein aufstrebendes Feld:

• Verifizierbare ML-Inferenz: Mithilfe von ZK-Proofs kann man beweisen, dass „ein Machine-Learning-Modell f bei Eingabe x das Ergebnis y liefert“, ohne entweder x (falls es private Daten sind) oder die internen Abläufe von f (falls die Modellgewichte proprietär sind) preiszugeben. Dies ist entscheidend für KI-Dienste auf der Blockchain – z. B. ein dezentrales KI-Orakel, das Vorhersagen oder Klassifizierungen liefert. Ein ZK-Coprozessor kann das Modell off-chain ausführen (da Modelle groß und teuer in der Auswertung sein können) und einen Proof des Ergebnisses posten. Beispielsweise könnte ein Orakel die Aussage beweisen: „Das bereitgestellte Satellitenbild zeigt eine Baumbedeckung von mindestens 50 %“, um einen Carbon-Credit-Vertrag zu unterstützen, ohne das Satellitenbild oder möglicherweise sogar das Modell preiszugeben. Dies ist als ZKML bekannt, und Projekte arbeiten an der Optimierung schaltkreisfreundlicher neuronaler Netze. Es gewährleistet die Integrität von KI-Ausgaben in Smart Contracts und kann die Vertraulichkeit von Eingabedaten und Modellparametern wahren.

• Training mit Privatsphäre und Prüfbarkeit: Das Training eines ML-Modells ist noch rechenintensiver, aber falls erreichbar, würde es Blockchain-basierte Modell-Marktplätze ermöglichen. Mehrere Datenanbieter könnten zum Training eines Modells unter FHE beitragen, sodass der Trainingsalgorithmus auf verschlüsselten Daten läuft. Das Ergebnis könnte ein verschlüsseltes Modell sein, das nur der Käufer entschlüsseln kann. Während des Trainings könnten periodisch ZK-Proofs geliefert werden, um zu beweisen, dass das Training dem Protokoll folgt (um zu verhindern, dass ein böswilliger Trainer beispielsweise eine Backdoor einbaut). Während ein vollständiges On-Chain-ML-Training angesichts der Kosten noch in weiter Ferne liegt, könnte ein hybrider Ansatz Off-Chain-Berechnungen mit ZK-Proofs für kritische Teile nutzen. Man könnte sich einen dezentralen Kaggle-ähnlichen Wettbewerb vorstellen, bei dem Teilnehmer Modelle auf privaten Datensätzen trainieren und ZK-Proofs der Modellgenauigkeit auf verschlüsselten Testdaten einreichen, um einen Gewinner zu ermitteln – alles ohne die Datensätze oder die Testdaten offenzulegen.

• Personalisierte KI und Dateneigentum: Mit diesen Technologien könnten Benutzer Eigentümer ihrer persönlichen Daten bleiben und dennoch von KI profitieren. Beispielsweise könnte das mobile Gerät eines Benutzers FHE verwenden, um seine Nutzungsdaten zu verschlüsseln und an einen Analyse-Contract zu senden, der ein personalisiertes KI-Modell (wie ein Empfehlungsmodell) nur für diesen Benutzer berechnet. Das Modell ist verschlüsselt, und nur das Gerät des Benutzers kann es lokal entschlüsseln und verwenden. Die Plattform (vielleicht ein soziales Netzwerk) sieht niemals die Rohdaten oder das Modell, aber der Benutzer erhält den KI-Vorteil. Wenn die Plattform aggregierte Erkenntnisse wünscht, könnte sie ZK-Proofs bestimmter aggregierter Muster vom Contract anfordern, ohne auf individuelle Daten zuzugreifen.

Zusätzliche Bereiche​

• Gaming: On-Chain-Spiele haben oft Schwierigkeiten, geheime Informationen zu verbergen (z. B. verdeckte Kartenblätter, Fog-of-War in Strategiespielen). FHE kann Hidden-State-Spiele ermöglichen, bei denen die Spiellogik auf einem verschlüsselten Zustand läuft. Beispielsweise könnte ein Poker-Contract verschlüsselte Karten mischen und austeilen; Spieler erhalten Entschlüsselungen ihrer eigenen Karten, aber der Contract und andere sehen nur Chiffretext. Die Wettlogik kann ZK-Proofs verwenden, um sicherzustellen, dass ein Spieler bei einer Aktion nicht blufft (oder um das gewinnende Blatt am Ende auf nachweislich faire Weise zu enthüllen). Ebenso können Zufalls-Seeds für das NFT-Minting oder Spielergebnisse generiert und als fair bewiesen werden, ohne den Seed offenzulegen (was Manipulation verhindert). Dies kann das Blockchain-Gaming erheblich verbessern, da es dieselbe Dynamik wie traditionelle Spiele unterstützen kann.

• Wahlen und Governance: DAOs könnten Privatsphäre-Technologie für geheime On-Chain-Abstimmungen nutzen, um Stimmenkauf und Druckausübung zu eliminieren. Eine FHE-VM könnte verschlüsselt abgegebene Stimmen auszählen, und nur die Endergebnisse werden entschlüsselt. ZK-Proofs können sicherstellen, dass jede Stimme gültig war (von einem berechtigten Wähler stammt, der nicht doppelt abgestimmt hat), ohne offenzulegen, wer wofür gestimmt hat. Dies bietet Verifizierbarkeit (jeder kann die Proofs und die Auszählung prüfen) bei gleichzeitiger Wahrung des Wahlgeheimnisses – entscheidend für eine unvoreingenommene Governance.

• Sichere Lieferkette und IoT: In Lieferketten möchten Partner möglicherweise den Nachweis bestimmter Eigenschaften (Herkunft, Qualitätsmetriken) erbringen, ohne Wettbewerbern alle Details offenzulegen. Beispielsweise könnte ein IoT-Sensor an einer Lebensmittellieferung kontinuierlich verschlüsselte Temperaturdaten an eine Blockchain senden. Ein Contract könnte mittels FHE prüfen, ob die Temperatur während des gesamten Transports in einem sicheren Bereich blieb. Wenn ein Schwellenwert überschritten wurde, kann er einen Alarm oder eine Strafe auslösen, muss aber nicht das gesamte Temperaturprotokoll öffentlich machen – vielleicht nur einen Proof oder einen aggregierten Wert wie das „90. Perzentil der Temperatur“. Dies schafft Vertrauen in die Automatisierung der Lieferkette unter Wahrung der Vertraulichkeit von Prozessdaten.

Jeder dieser Anwendungsfälle nutzt die Kernfähigkeit: Daten berechnen oder verifizieren, ohne die Daten offenzulegen. Diese Fähigkeit kann die Art und Weise, wie wir mit sensiblen Informationen in dezentralen Systemen umgehen, grundlegend verändern. Sie verringert den Kompromiss zwischen Transparenz und Privatsphäre, der die Blockchain-Adoption in Bereichen, die mit privaten Daten arbeiten, bisher eingeschränkt hat.

Fazit​

Die Blockchain-Technologie tritt in eine neue Ära der programmierbaren Privatsphäre ein, in der Vertraulichkeit von Daten und die Funktionalität von Smart Contracts Hand in Hand gehen. Die Paradigmen der FHE-VM und ZK-Koprozessoren sind zwar technisch verschieden, streben jedoch beide danach, den Umfang von Blockchain-Anwendungen zu erweitern, indem sie entkoppeln, was wir berechnen können und was wir preisgeben müssen.

Fully Homomorphic Encryption Virtual Machines halten Berechnungen On-Chain und verschlüsselt, wodurch Dezentralisierung und Komponierbarkeit gewahrt bleiben, jedoch Fortschritte bei der Effizienz erforderlich sind. Zero-Knowledge-Koprozessoren verlagern rechenintensive Aufgaben Off-Chain und ermöglichen nahezu unbegrenzte Berechnungen unter kryptografischen Garantien. Sie beweisen bereits ihren Wert bei der Skalierung und Verbesserung von Ethereum. Die Wahl zwischen ihnen (und hybriden Ansätzen) hängt vom Anwendungsfall ab: Wenn eine Echtzeit-Interaktion mit privatem Status erforderlich ist, könnte ein FHE-Ansatz geeigneter sein; wenn extrem komplexe Berechnungen oder die Integration in bestehenden Code erforderlich sind, könnte ein ZK-Koprozessor die richtige Wahl sein. In vielen Fällen ergänzen sie sich – tatsächlich sehen wir, wie ZK-Proofs die FHE-Integrität stärken und FHE potenziell ZK unterstützt, indem es private Daten für Prover verarbeitet.

Für Entwickler werden diese Technologien neue Design-Patterns einführen. Wir werden in verschlüsselten Variablen und Proof-Verifizierung als erstklassige Elemente der dApp-Architektur denken. Das Tooling entwickelt sich rasant weiter: High-Level-Sprachen und SDKs abstrahieren kryptografische Details (z. B. machen die Bibliotheken von Zama FHE-Typen so einfach wie native Typen oder die Vorlagen von RISC Zero für Proof-Anfragen). In wenigen Jahren könnte sich das Schreiben eines vertraulichen Smart Contracts fast so unkompliziert anfühlen wie das eines regulären, nur eben mit standardmäßig „integrierter“ Privatsphäre.

Die Auswirkungen auf die Datenwirtschaft sind tiefgreifend. Einzelpersonen und Unternehmen werden eher bereit sein, Daten oder Logik On-Chain zu bringen, wenn sie deren Sichtbarkeit kontrollieren können. Dies kann die Zusammenarbeit zwischen Organisationen, neue Finanzprodukte und KI-Modelle ermöglichen, die zuvor aufgrund von Datenschutzbedenken nicht realisierbar waren. Auch Regulierungsbehörden könnten diese Techniken begrüßen, da sie Compliance-Prüfungen und Audits mit kryptografischen Mitteln ermöglichen (z. B. den Nachweis, dass Steuern korrekt On-Chain gezahlt wurden, ohne alle Transaktionen offenlegen zu müssen).

Wir befinden uns noch in der Anfangsphase – aktuelle FHE-VM-Prototypen haben Leistungsgrenzen, und ZK-Proofs können, obwohl sie viel schneller als früher sind, immer noch ein Flaschenhals für extrem komplexe Aufgaben sein. Aber kontinuierliche Forschungs- und Entwicklungsanstrengungen (einschließlich spezialisierter Hardware, wie Unternehmen wie Optalysys zeigen, die die optische FHE-Beschleunigung vorantreiben) bauen diese Barrieren schnell ab. Die Investitionen, die in diesen Bereich fließen (z. B. der Einhorn-Status von Zama, die Investition von Paradigm in Axiom), unterstreichen die starke Überzeugung, dass Datenschutzfunktionen für das Web3 ebenso grundlegend sein werden wie Transparenz für das Web1/2.

In Zusammenfassung lässt sich sagen, dass programmierbare Privatsphäre über FHE-VMs und ZK-Koprozessoren eine neue Klasse von dApps einläutet, die vertrauenslos, dezentralisiert und vertraulich sind. Von DeFi-Trades, die keine Details preisgeben, über Gesundheitsforschung, die Patientendaten schützt, bis hin zu Machine-Learning-Modellen, die weltweit trainiert werden, ohne Rohdaten offenzulegen – die Möglichkeiten sind enorm. Da diese Technologien reifen, werden Blockchain-Plattformen nicht mehr den Kompromiss zwischen Nutzen und Datenschutz erzwingen und so eine breitere Akzeptanz in Branchen ermöglichen, die Vertraulichkeit erfordern. Die Zukunft von Web3 ist eine, in der *Nutzer und Organisationen sicher mit sensiblen Daten On-Chain transagieren und rechnen können, im Wissen, dass die Blockchain die Integrität verifiziert und gleichzeitig ihre Geheimnisse schützt*.

Quellen: Die Informationen in diesem Bericht stammen aus technischen Dokumentationen und aktuellen Forschungsblogs führender Projekte in diesem Bereich, darunter die FHEVM-Dokumentation von Cypher und Zama, detaillierte Analysen von Trail of Bits zu den Schaltkreisen von Axiom, Entwicklerleitfäden und Blog-Posts von RISC Zero sowie Branchenartikel, die Anwendungsfälle vertraulicher Blockchain-Technologie hervorheben. Diese Quellen und weitere wurden durchgehend zitiert, um weiterführende Lektüre und Belege für die beschriebenen Architekturen und Anwendungen bereitzustellen.

Plume Network: Überblick und Nutzenversprechen​

Plume Network ist eine Blockchain-Plattform, die speziell für Real-World Assets (RWA) entwickelt wurde. Es handelt sich um eine öffentliche, Ethereum-kompatible Chain, die darauf ausgelegt ist, eine breite Palette realer Finanzanlagen zu tokenisieren – von Privatkrediten und Immobilien bis hin zu CO2-Zertifikaten und sogar Sammlerstücken – und sie so nutzbar zu machen wie native Krypto-Assets. Mit anderen Worten, Plume bringt Assets nicht nur On-Chain; es ermöglicht Benutzern, tokenisierte reale Assets in dezentralen Finanzen (DeFi) zu halten und zu nutzen – was bekannte Krypto-Aktivitäten wie Staking, Lending, Borrowing, Swapping und spekulativen Handel mit Assets ermöglicht, die ihren Ursprung in der traditionellen Finanzwelt haben.

Das zentrale Nutzenversprechen von Plume ist es, TradFi und DeFi zu überbrücken, indem traditionell illiquide oder unzugängliche Assets in programmierbare, liquide Token umgewandelt werden. Durch die Integration institutioneller Assets (z. B. Privatkreditfonds, ETFs, Rohstoffe) mit der DeFi-Infrastruktur möchte Plume hochwertige Investitionen – die einst auf große Institutionen oder spezifische Märkte beschränkt waren – permissionless, composable und für Krypto-Benutzer nur einen Klick entfernt machen. Dies eröffnet Krypto-Teilnehmern die Möglichkeit, „echte Renditen“ zu erzielen, die durch stabile reale Cashflows (wie Kreditzinsen, Mieteinnahmen, Anleiherenditen usw.) gedeckt sind, anstatt sich auf inflationäre Token-Belohnungen zu verlassen. Plumes Mission ist es, „RWA Finance (RWAfi)“ voranzutreiben und ein transparentes und offenes Finanzsystem zu schaffen, in dem jeder On-Chain auf Assets wie Privatkredite, Immobilienkredite oder Rohstoffe zugreifen und diese auf neuartige Weise frei nutzen kann.

Zusammenfassend dient Plume Network als „On-Chain-Heimat für Real-World Assets“ und bietet ein Full-Stack-Ökosystem, das Off-Chain-Assets in global zugängliche Finanzinstrumente mit echtem Krypto-nativem Nutzen verwandelt. Benutzer können Stablecoins staken, um Renditen von Top-Fondsmanagern (Apollo, BlackRock, Blackstone usw.) zu erzielen, RWA-gedeckte Token als Sicherheit zu loopen und zu hebeln und RWAs so einfach wie ERC-20-Token zu handeln. Damit positioniert sich Plume als Plattform, die danach strebt, alternative Assets liquider und programmierbarer zu machen und frisches Kapital sowie Investitionsmöglichkeiten in Web3 zu bringen, ohne Transparenz oder Benutzererfahrung zu opfern.

Technologie und Architektur​

Plume Network ist als EVM-kompatible Blockchain mit einer modularen Layer-2-Architektur implementiert. Im Hintergrund funktioniert Plume ähnlich wie ein Ethereum-Rollup (vergleichbar mit der Technologie von Arbitrum) und nutzt Ethereum für Datenverfügbarkeit und Sicherheit. Jede Transaktion auf Plume wird schließlich stapelweise an Ethereum übermittelt, was bedeutet, dass Benutzer eine kleine zusätzliche Gebühr zahlen, um die Kosten für die Veröffentlichung von Calldata auf Ethereum zu decken. Dieses Design nutzt die robuste Sicherheit von Ethereum, während Plume eine eigene Hochdurchsatz-Ausführungsumgebung für RWA-Anwendungsfälle ermöglicht, die jedoch für Vertrauen und Finalität an Ethereum gebunden ist. Plume betreibt einen Sequencer, der Transaktionen aggregiert und diese regelmäßig an Ethereum übermittelt, was der Chain eine schnellere Ausführung und niedrigere Gebühren ermöglicht.

Da Plume EVM-kompatibel ist, können Entwickler Solidity-Smart Contracts auf Plume genauso bereitstellen wie auf Ethereum, mit fast keinen Änderungen. Die Chain unterstützt die Standard-Ethereum-RPC-Methoden und Solidity-Operationen, mit nur geringfügigen Unterschieden (z. B. spiegeln Plumes Blocknummern- und Zeitstempel-Semantik die Konventionen von Arbitrum aufgrund des Layer-2-Designs wider). In der Praxis bedeutet dies, dass Plume bestehende DeFi-Protokolle und Entwickler-Tools problemlos integrieren kann. Die Plume-Dokumentation weist darauf hin, dass Cross-Chain-Messaging zwischen Ethereum (der „Eltern“-Chain) und Plume (der L2) unterstützt wird, wodurch Assets und Daten bei Bedarf zwischen den Chains verschoben werden können.

Bemerkenswerterweise beschreibt sich Plume als eine „modulare Blockchain“, die für RWA-Finanzen optimiert ist. Der modulare Ansatz zeigt sich in seiner Architektur: Es verfügt über dedizierte Komponenten für das Bridging von Assets (genannt Arc für das On-Chain-Bringen beliebiger Assets), für Omnichain-Rendite-Routing (SkyLink) über mehrere Blockchains hinweg und für On-Chain-Daten-Feeds (Nexus, eine „On-Chain-Datenautobahn“). Dies deutet darauf hin, dass Plume ein miteinander verbundenes System aufbaut, in dem Real-World-Asset-Token auf Plume mit Liquidität auf anderen Chains interagieren können und Off-Chain-Daten (wie Asset-Bewertungen, Zinssätze usw.) zuverlässig On-Chain eingespeist werden. Plumes Infrastruktur umfasst auch eine benutzerdefinierte Wallet namens Plume Passport (die „RWAfi Wallet“), die wahrscheinlich die für die RWA-Compliance notwendigen Identitäts-/AML-Prüfungen handhabt, sowie einen nativen Stablecoin (pUSD) für Transaktionen im Ökosystem.

Wichtig ist, dass Plumes aktuelle Iteration oft als Layer-2- oder Rollup-Chain bezeichnet wird – sie ist auf Ethereum für Sicherheit aufgebaut. Das Team hat jedoch ehrgeizige Pläne angedeutet, die Technologie weiterzuentwickeln. Plumes CTO bemerkte, dass sie als modularer L2-Rollup begannen, aber nun „den Stack herunterdrücken“ in Richtung einer vollständig souveränen Layer-1-Architektur, die eine neue Chain von Grund auf mit hoher Leistung, Datenschutzfunktionen „vergleichbar mit Schweizer Banken“ und einem neuartigen kryptoökonomischen Sicherheitsmodell optimiert, um die nächsten Billionen Dollar On-Chain zu sichern. Während die Details spärlich sind, deutet dies darauf hin, dass Plume im Laufe der Zeit zu einer unabhängigeren Chain übergehen oder erweiterte Funktionen wie FHE (Fully Homomorphic Encryption) oder zk-Proofs (die Erwähnung von zkTLS und Datenschutz) integrieren könnte, um institutionelle Anforderungen zu erfüllen. Vorerst nutzt Plumes Mainnet jedoch die Sicherheit von Ethereum und die EVM-Umgebung, um Assets und Benutzer schnell On-Board zu bringen und ein vertrautes, aber verbessertes DeFi-Erlebnis für RWAs zu bieten.

Tokenomics und Anreize​

PLUME ($PLUME) ist der native Utility-Token des Plume Network. Der $PLUME-Token wird verwendet, um Transaktionen, Governance und Netzwerksicherheit auf Plume zu betreiben. Als Gas-Token ist $PLUME erforderlich, um Transaktionsgebühren auf der Plume-Chain zu bezahlen (ähnlich wie ETH Gas auf Ethereum ist). Das bedeutet, dass alle Operationen – Handel, Staking, Bereitstellung von Contracts – $PLUME für Gebühren verbrauchen. Über Gas hinaus hat $PLUME mehrere Utility- und Anreizrollen:

• Governance: $PLUME-Halter können an Governance-Entscheidungen teilnehmen, voraussichtlich über Protokollparameter, Upgrades oder Asset-Onboarding-Entscheidungen abstimmen.
• Staking/Sicherheit: Der Token kann gestaked werden, was wahrscheinlich die Validator- oder Sequencer-Operationen des Netzwerks unterstützt. Staker helfen, die Chain zu sichern und erhalten im Gegenzug Staking-Belohnungen in $PLUME. (Selbst als Rollup kann Plume einen Proof-of-Stake-Mechanismus für seinen Sequencer oder für die eventuelle Dezentralisierung der Blockproduktion verwenden).
• Echte Rendite und DeFi-Nutzen: Plumes Dokumentation erwähnt, dass Benutzer $PLUME über dApps hinweg verwenden können, um „echte Renditen freizuschalten“. Dies deutet darauf hin, dass das Halten oder Staking von $PLUME höhere Renditen in bestimmten RWA-Yield-Farms oder Zugang zu exklusiven Möglichkeiten im Ökosystem ermöglichen könnte.
• Ökosystem-Anreize: $PLUME wird auch verwendet, um Community-Engagement zu belohnen – zum Beispiel könnten Benutzer Token über Community-Quests, Empfehlungsprogramme, Testnet-Teilnahme (wie das „Take Flight“-Entwicklerprogramm oder die Testnet-„Goons“-NFTs) verdienen. Dieses Anreizdesign soll Netzwerkeffekte ankurbeln, indem Token an diejenigen verteilt werden, die die Plattform aktiv nutzen und erweitern.

Token-Angebot & -Verteilung: Plume hat ein festes Gesamtangebot von 10 Milliarden $PLUME-Token. Beim Token Generation Event (Mainnet-Start) beträgt das anfängliche zirkulierende Angebot 20 % des Gesamtangebots (d. h. 2 Milliarden Token). Die Zuteilung ist stark auf Community- und Ökosystementwicklung ausgerichtet:

• 59 % an Community, Ökosystem & Stiftung – dieser große Anteil ist für Grants, Liquiditätsanreize, Community-Belohnungen und einen Stiftungs-Pool reserviert, um das langfristige Wachstum des Ökosystems zu unterstützen. Dies stellt sicher, dass ein Großteil der Token zur Verfügung steht, um die Nutzung anzukurbeln (und signalisiert potenziell das Engagement für Dezentralisierung im Laufe der Zeit).
• 21 % an Frühe Unterstützer – diese Token werden strategischen Investoren und Partnern zugewiesen, die Plumes Entwicklung finanziert haben. (Wie wir sehen werden, hat Plume Kapital von prominenten Krypto-Fonds erhalten; diese Zuteilung wird wahrscheinlich im Laufe der Zeit gemäß den Investorenvereinbarungen freigegeben.)
• 20 % an Kernmitwirkende (Team) – zugewiesen an das Gründerteam und die Kernentwickler, die Plume vorantreiben. Dieser Anteil motiviert das Team und richtet es auf den Erfolg des Netzwerks aus, typischerweise über einen mehrjährigen Zeitraum.

Neben $PLUME umfasst Plumes Ökosystem einen Stablecoin namens Plume USD (pUSD). pUSD ist als RWAfi-Ökosystem-Stablecoin für Plume konzipiert. Er dient als Recheneinheit und primäre Handels-/Sicherheitswährung innerhalb von Plumes DeFi-Apps. Einzigartig ist, dass pUSD vollständig 1:1 durch USDC gedeckt ist – effektiv ein Wrapped USDC für das Plume-Netzwerk. Diese Designentscheidung (Wrapping von USDC) wurde getroffen, um Reibungsverluste für traditionelle Institutionen zu reduzieren: Wenn eine Organisation bereits mit dem Halten und Minten von USDC vertraut ist, kann sie pUSD auf Plume nahtlos unter denselben Rahmenbedingungen minten und verwenden. pUSD wird nativ sowohl auf Ethereum als auch auf Plume gemintet und eingelöst, was bedeutet, dass Benutzer oder Institutionen USDC auf Ethereum einzahlen und pUSD auf Plume erhalten können oder umgekehrt. Durch die 1:1-Bindung von pUSD an USDC (und letztendlich an USD-Reserven) stellt Plume sicher, dass sein Stablecoin vollständig besichert und liquide bleibt, was für RWA-Transaktionen entscheidend ist (wo Vorhersehbarkeit und Stabilität des Tauschmittels erforderlich sind). In der Praxis bietet pUSD eine gemeinsame stabile Liquiditätsschicht für alle RWA-Apps auf Plume – sei es der Kauf tokenisierter Anleihen, die Investition in RWA-Yield-Vaults oder der Handel mit Assets an einer DEX, pUSD ist der Stablecoin, der den Werttausch untermauert.

Insgesamt zielen Plumes Tokenomics darauf ab, Netzwerknutzen mit Wachstumsanreizen in Einklang zu bringen. $PLUME stellt sicher, dass das Netzwerk selbsttragend ist (durch Gebühren und Staking-Sicherheit) und von der Community regiert wird, während große Zuteilungen an Ökosystemfonds und Airdrops die frühe Akzeptanz fördern. Gleichzeitig verankert pUSD das Finanzökosystem in einem vertrauenswürdigen stabilen Asset, was es traditionellem Kapital erleichtert, in Plume einzusteigen, und DeFi-Benutzern, Renditen auf Real-World-Investitionen zu messen.

Gründerteam und Unterstützer​

Plume Network wurde 2022 von einem Trio von Unternehmern mit Hintergründen in Krypto und Finanzen gegründet: Chris Yin (CEO), Eugene Shen (CTO) und Teddy Pornprinya (CBO). Chris Yin wird als visionärer Produktführer des Teams beschrieben, der die Strategie und Vordenkerrolle der Plattform im RWA-Bereich vorantreibt. Eugene Shen leitet als CTO die technische Entwicklung (zuvor hatte er an modularen Blockchain-Architekturen gearbeitet, wie seine Anmerkung über das „Anpassen von Geth“ und den Aufbau von Grund auf zeigt). Teddy Pornprinya, als Chief Business Officer, leitet Partnerschaften, Geschäftsentwicklung und Marketing – er war maßgeblich daran beteiligt, Dutzende von Projekten frühzeitig in das Plume-Ökosystem zu integrieren. Gemeinsam identifizierten die Gründer die Marktlücke für eine RWA-optimierte Chain und gaben ihre früheren Rollen auf, um Plume aufzubauen, wobei das Projekt etwa ein Jahr nach der Konzeption offiziell gestartet wurde.

Plume hat erhebliche Unterstützung sowohl von Krypto-nativen VCs als auch von traditionellen Finanzgiganten erhalten, was ein starkes Vertrauen in seine Vision signalisiert:

• Im Mai 2023 schloss Plume eine 10-Millionen-Dollar-Seed-Runde unter der Leitung von Haun Ventures (dem Fonds der ehemaligen a16z-Partnerin Katie Haun) ab. Weitere Teilnehmer an der Seed-Runde waren Galaxy Digital, Superscrypt (Temaseks Krypto-Arm), A Capital, SV Angel, Portal Ventures und Reciprocal Ventures. Diese vielfältige Investorenbasis verschaffte Plume einen starken Start, indem sie Krypto-Expertise und institutionelle Verbindungen kombinierte.

• Bis Ende 2024 sicherte sich Plume eine 20-Millionen-Dollar-Series-A-Finanzierung, um seine Entwicklung zu beschleunigen. Diese Runde wurde von Top-Investoren wie Brevan Howard Digital, Haun Ventures (erneut), Galaxy und Faction VC unterstützt. Die Einbeziehung von Brevan Howard, einem der weltweit größten Hedgefonds mit einem dedizierten Krypto-Arm, ist besonders bemerkenswert und unterstreicht das wachsende Interesse der Wall Street an RWAs auf der Blockchain.

• Im April 2025 tätigte Apollo Global Management – einer der weltweit größten alternativen Asset Manager – eine strategische Investition in Plume. Apollos Investition belief sich auf einen siebenstelligen (USD) Betrag, der Plume helfen sollte, seine Infrastruktur zu skalieren und mehr traditionelle Finanzprodukte On-Chain zu bringen. Apollos Beteiligung ist eine starke Bestätigung von Plumes Ansatz: Christine Moy, Apollos Head of Digital Assets, sagte, ihre Investition „unterstreicht Apollos Fokus auf Technologien, die den Zugang zu institutionellen Qualitätsprodukten erweitern… Plume repräsentiert eine neue Art von Infrastruktur, die sich auf den Nutzen digitaler Assets, das Engagement von Investoren und Finanzlösungen der nächsten Generation konzentriert“. Mit anderen Worten, Apollo sieht Plume als Schlüssel-Infrastruktur, um private Märkte liquider und über Blockchain zugänglicher zu machen.

• Ein weiterer strategischer Unterstützer ist YZi Labs, ehemals Binance Labs. Anfang 2025 kündigte YZi (der umbenannte Venture-Arm von Binance) ebenfalls eine strategische Investition in Plume Network an. YZi Labs hob Plume als eine „bahnbrechende Layer-2-Blockchain hervor, die für die Skalierung von Real-World Assets entwickelt wurde“, und ihre Unterstützung signalisiert Vertrauen, dass Plume TradFi und DeFi in großem Maßstab überbrücken kann. (Es ist erwähnenswert, dass die Umbenennung von Binance Labs in YZi Labs die Kontinuität ihrer Investitionen in Kerninfrastrukturprojekte wie Plume anzeigt.)

• Plumes Unterstützer umfassen auch traditionelle Fintech- und Krypto-Institutionen durch Partnerschaften (siehe unten) – zum Beispiel sind Mercado Bitcoin (Lateinamerikas größte digitale Asset-Plattform) und Anchorage Digital (ein regulierter Krypto-Verwahrer) Ökosystempartner, die sich effektiv mit Plumes Erfolg verbünden. Zusätzlich hat Grayscale Investments – der weltweit größte digitale Asset Manager – Notiz genommen: Im April 2025 fügte Grayscale offiziell $PLUME zu seiner Liste der Assets „Under Consideration“ für zukünftige Anlageprodukte hinzu. Auf Grayscales Radar zu sein, bedeutet, dass Plume potenziell in institutionelle Krypto-Trusts oder ETFs aufgenommen werden könnte, eine wichtige Anerkennung für ein relativ neues Projekt.

Zusammenfassend lässt sich sagen, dass Plumes Finanzierung und Unterstützung von einem Who’s Who der Top-Investoren stammt: führende Krypto-VCs (Haun, Galaxy, a16z über GFIs Unterstützung von Goldfinch usw.), Hedgefonds und TradFi-Akteure (Brevan Howard, Apollo) sowie Corporate Venture Arms (Binance/YZi). Diese Mischung von Unterstützern bringt nicht nur Kapital, sondern auch strategische Beratung, regulatorische Expertise und Verbindungen zu Real-World-Asset-Originatoren. Sie hat Plume auch mit beträchtlichen Mitteln (mindestens 30 Millionen Dollar+ über Seed- und Series-A-Runden) ausgestattet, um seine spezialisierte Blockchain aufzubauen und Assets On-Board zu bringen. Die starke Unterstützung dient als Vertrauensbeweis, dass Plume als führende Plattform im schnell wachsenden RWA-Sektor positioniert ist.

Ökosystempartner und Integrationen​

Plume war sehr aktiv beim Aufbau von Ökosystempartnerschaften sowohl im Krypto- als auch im traditionellen Finanzbereich und hat ein breites Netzwerk von Integrationen noch vor (und unmittelbar nach) dem Mainnet-Start aufgebaut. Diese Partner stellen die Assets, Infrastruktur und Distribution bereit, die Plumes RWA-Ökosystem funktionsfähig machen:

• Nest Protocol (Nest Credit): Eine RWA-Yield-Plattform, die auf Plume läuft und es Benutzern ermöglicht, Stablecoins in Vaults einzuzahlen und Yield-Bearing-Token zu erhalten, die durch Real-World Assets gedeckt sind. Nest ist im Wesentlichen ein DeFi-Frontend für RWA-Renditen und bietet Produkte wie tokenisierte US-Staatsanleihen, Privatkredite, Mineralrechte usw., abstrahiert aber die Komplexität, sodass sie sich „wie Krypto“ anfühlen. Benutzer tauschen USDC (oder pUSD) gegen von Nest ausgegebene Token, die vollständig durch regulierte, geprüfte Assets gedeckt sind, die von Verwahrern gehalten werden. Nest arbeitet eng mit Plume zusammen – ein Testimonial von Anil Sood von Anemoy (einem Partner) hebt hervor, dass „die Partnerschaft mit Plume unsere Mission beschleunigt, institutionelle RWAs jedem Investor zugänglich zu machen… Diese Zusammenarbeit ist ein Bauplan für die Zukunft der RWA-Innovation.“. In der Praxis ist Nest Plumes nativer Yield-Marktplatz (manchmal auch „Nest Yield“ oder RWA-Staking-Plattform genannt), und viele von Plumes großen Partnerschaften münden in Nest-Vaults.

• Mercado Bitcoin (MB): Die größte digitale Asset-Börse in Lateinamerika (mit Sitz in Brasilien) hat sich mit Plume zusammengetan, um ~40 Millionen US-Dollar an brasilianischen Real-World Assets zu tokenisieren. Diese im Februar 2025 angekündigte Initiative beinhaltet, dass MB Plumes Blockchain nutzt, um Token auszugeben, die brasilianische Asset-Backed Securities, Konsumentenkreditportfolios, Unternehmensschulden und Forderungen repräsentieren. Ziel ist es, globale Investoren mit renditeträchtigen Möglichkeiten in Brasiliens Wirtschaft zu verbinden – und damit brasilianische Kreditmärkte für On-Chain-Investoren weltweit über Plume zu öffnen. Diese brasilianischen RWA-Token werden vom ersten Tag des Plume-Mainnets an auf der Nest-Plattform verfügbar sein und stabile On-Chain-Renditen bieten, die durch brasilianische Kleinunternehmenskredite und Kreditforderungen gedeckt sind. Diese Partnerschaft ist bemerkenswert, da sie Plume eine geografische Reichweite (LATAM) und eine Pipeline von Schwellenländer-Assets verschafft und zeigt, wie Plume als Drehscheibe dienen kann, die regionale Asset-Originatoren mit globaler Liquidität verbindet.

• Superstate: Superstate ist ein Fintech-Startup, das von Robert Leshner (ehemaliger Gründer von Compound) gegründet wurde und sich darauf konzentriert, regulierte US-Staatsanleihenprodukte On-Chain zu bringen. Im Jahr 2024 startete Superstate einen tokenisierten US-Staatsanleihenfonds (als 1940 Act Mutual Fund genehmigt), der sich an Krypto-Benutzer richtet. Plume wurde von Superstate ausgewählt, um seine Multi-Chain-Expansion zu betreiben. In der Praxis bedeutet dies, dass Superstates tokenisierter T-Bill-Fonds (der eine stabile Rendite aus US-Staatsanleihen bietet) auf Plume verfügbar gemacht wird, wo er in Plumes DeFi-Ökosystem integriert werden kann. Leshner selbst sagte: „Durch die Expansion auf Plume – die einzigartige RWAfi-Chain – können wir zeigen, wie zweckgebundene Infrastruktur großartige neue Anwendungsfälle für tokenisierte Assets ermöglichen kann. Wir freuen uns darauf, auf Plume aufzubauen.“. Dies deutet darauf hin, dass Superstate seine Fonds-Token (z. B. einen On-Chain-Anteil eines Staatsanleihenfonds) auf Plume bereitstellen wird, sodass Plume-Benutzer diese halten oder in DeFi verwenden können (vielleicht als Sicherheit für Kredite oder in Nest-Vaults für automatische Renditen). Es ist eine starke Bestätigung, dass Plumes Chain als bevorzugte Heimat für regulierte Asset-Token wie Staatsanleihen angesehen wird.

• Ondo Finance: Ondo ist ein bekanntes DeFi-Projekt, das sich in den RWA-Bereich verlagert hat, indem es tokenisierte Anleihen und Renditeprodukte anbietet (insbesondere Ondos OUSG-Token, der Anteile an einem kurzfristigen US-Staatsanleihenfonds repräsentiert, und USDY, der ein zinstragendes USD-Einlagenprodukt darstellt). Ondo ist unter Plumes Ökosystempartnern aufgeführt, was eine Zusammenarbeit impliziert, bei der Ondos renditeträchtige Token (wie OUSG, USDY) auf Plume verwendet werden können. Tatsächlich stimmen Ondos Produkte eng mit Plumes Zielen überein: Ondo hat rechtliche Vehikel (SPVs) eingerichtet, um die Compliance sicherzustellen, und sein OUSG-Token ist durch BlackRocks tokenisierten Geldmarktfonds (BUIDL) gedeckt, der ~4,5 % APY aus Staatsanleihen bietet. Durch die Integration von Ondo erhält Plume Blue-Chip-RWA-Assets wie US-Staatsanleihen On-Chain. Tatsächlich hatten Ondos RWA-Produkte Ende 2024 einen Marktwert von über 600 Millionen US-Dollar, sodass deren Brücke zu Plume einen erheblichen TVL hinzufügt. Diese Synergie ermöglicht es Plume-Benutzern wahrscheinlich, in Ondos Token zu tauschen oder sie in Nest-Vaults für zusammengesetzte Strategien aufzunehmen.

• Centrifuge: Centrifuge ist ein Pionier in der RWA-Tokenisierung (betreibt eine eigene Polkadot-Parachain für RWA-Pools). Plumes Website listet Centrifuge als Partner auf, was eine Zusammenarbeit oder Integration nahelegt. Dies könnte bedeuten, dass Centrifuges Asset-Pools (Handelsfinanzierungen, Immobilien-Überbrückungskredite usw.) von Plume aus zugänglich sein könnten oder dass Centrifuge Plumes Infrastruktur für die Distribution nutzen wird. Zum Beispiel könnte Plumes SkyLink Omnichain-Rendite Liquidität von Plume in Centrifuge-Pools auf Polkadot leiten, oder Centrifuge könnte bestimmte Assets direkt auf Plume tokenisieren, um eine tiefere DeFi-Komponierbarkeit zu ermöglichen. Angesichts dessen, dass Centrifuge die Kategorie der Privatkredit-RWA mit ~409 Millionen US-Dollar TVL in seinen Pools anführt, ist seine Beteiligung am Plume-Ökosystem von Bedeutung. Sie deutet auf eine branchenweite Bewegung hin zu Interoperabilität zwischen RWA-Plattformen hin, wobei Plume als vereinheitlichende Schicht für RWA-Liquidität über Chains hinweg fungiert.

• Credbull: Credbull ist eine Privatkreditfonds-Plattform, die mit Plume zusammengearbeitet hat, um einen großen tokenisierten Kreditfonds aufzulegen. Laut CoinDesk rollt Credbull einen Privatkreditfonds von bis zu 500 Millionen US-Dollar auf Plume aus, der On-Chain-Investoren eine feste hohe Rendite bietet. Dies beinhaltet wahrscheinlich die Verpackung von Privatkrediten (Darlehen an mittelständische Unternehmen oder andere Kredit-Assets) in ein Vehikel, in das On-Chain-Stablecoin-Halter für eine feste Rendite investieren können. Die Bedeutung ist zweifach: (1) Es fügt Plumes Netzwerk eine riesige Pipeline von Rendite-Assets (~eine halbe Milliarde Dollar) hinzu, und (2) es zeigt, wie Plume echte Asset Manager anzieht, um Produkte auf seiner Chain zu initiieren. In Kombination mit anderen Pipeline-Assets plante Plume, bis Ende 2024 Assets im Wert von etwa 1,25 Milliarden US-Dollar zu tokenisieren, darunter den Credbull-Fonds, plus 300 Millionen US-Dollar an erneuerbaren Energien (Solarparks über Plural Energy), ~120 Millionen US-Dollar an Gesundheitsforderungen (Medicaid-gedeckte Rechnungen) und sogar Öl- und Gas-Mineralrechte. Diese große Pipeline zeigt, dass Plume beim Start nicht leer ist – es kommt mit greifbaren Assets, die sofort einsatzbereit sind.

• Goldfinch: Goldfinch ist ein dezentrales Kreditprotokoll, das unterbesicherte Kredite an Fintech-Kreditgeber weltweit vergab. Im Jahr 2023 verlagerte sich Goldfinch zu „Goldfinch Prime“, das sich an akkreditierte und institutionelle Investoren richtet, indem es On-Chain-Zugang zu führenden Privatkreditfonds bietet. Plume und Goldfinch kündigten eine strategische Partnerschaft an, um die Angebote von Goldfinch Prime auf Plumes Nest-Plattform zu bringen, wodurch Goldfinchs institutionelle Kreditgeschäfte mit Plumes Benutzerbasis verbunden werden. Durch diese Partnerschaft können institutionelle Investoren auf Plume Stablecoins in Fonds staken, die von Apollo, Golub Capital, Aries, Stellus und anderen führenden Privatkreditmanagern verwaltet werden, über Goldfinchs Integration. Der Ehrgeiz ist immens: Gemeinsam repräsentieren diese Manager über 1 Billion US-Dollar an Assets, und die Partnerschaft zielt darauf ab, Teile davon schließlich On-Chain verfügbar zu machen. In der Praxis könnte ein Benutzer auf Plume in einen diversifizierten Pool investieren, der Renditen aus Hunderten von Real-World-Darlehen dieser Kreditfonds erzielt, die alle über Goldfinch Prime tokenisiert sind. Dies verbessert nicht nur Plumes Asset-Diversität, sondern unterstreicht auch Plumes Glaubwürdigkeit, mit erstklassigen RWA-Plattformen zusammenzuarbeiten.

• Infrastrukturpartner (Custody und Konnektivität): Plume hat auch wichtige Infrastrukturakteure integriert. Anchorage Digital, eine regulierte Krypto-Verwahrungsbank, ist ein Partner – die Beteiligung von Anchorage bedeutet wahrscheinlich, dass institutionelle Benutzer ihre tokenisierten Assets oder $PLUME sicher in einer Verwahrungslösung auf Bankniveau verwahren können (ein Muss für große Geldbeträge). Paxos ist ein weiterer gelisteter Partner, was sich auf die Stablecoin-Infrastruktur beziehen könnte (Paxos gibt den USDP-Stablecoin aus und bietet auch Verwahrungs- und Brokerage-Dienste an – möglicherweise könnte Paxos die Reserven für pUSD sichern oder Asset-Tokenisierungs-Pipelines erleichtern). LayerZero wird ebenfalls erwähnt, was darauf hindeutet, dass Plume das Interoperabilitätsprotokoll von LayerZero für Cross-Chain-Messaging verwendet. Dies würde es Assets auf Plume ermöglichen, sich auf andere Chains zu bewegen (und umgekehrt) auf eine vertrauensminimierte Weise, was Plumes Rollup-Bridge ergänzt.

• Weitere DeFi-Integrationen: Plumes Ökosystemseite listet über 180 Protokolle auf, darunter RWA-Spezialisten und Mainstream-DeFi-Projekte. Zum Beispiel sind Namen wie Nucleus Yield (eine Plattform für tokenisierte Renditen) und möglicherweise On-Chain-KYC-Anbieter oder Identitätslösungen Teil der Mischung. Zum Zeitpunkt des Mainnets hatte Plume über 200 integrierte Protokolle in seiner Testnet-Umgebung – was bedeutet, dass viele bestehende dApps (DEXs, Geldmärkte usw.) auf Plume bereitgestellt wurden oder bereit sind, bereitgestellt zu werden. Dies stellt sicher, dass tokenisierte Real-World Assets nach der Tokenisierung sofortigen Nutzen haben: z. B. könnte ein tokenisierter Solarfarm-Einnahmestrom an einer Orderbuch-Börse gehandelt oder als Sicherheit für einen Kredit verwendet oder in einen Index aufgenommen werden – weil die DeFi-„Geld-Lego“-Teile (DEXs, Lending-Plattformen, Asset-Management-Protokolle) von Anfang an auf der Chain verfügbar sind.

Zusammenfassend lässt sich sagen, dass Plumes Ökosystemstrategie aggressiv und umfassend war: Ankerpartnerschaften für Assets sichern (z. B. Fonds von Apollo, BlackRock über Superstate/Ondo, Privatkredite über Goldfinch und Credbull, Schwellenländer-Assets über Mercado Bitcoin), Infrastruktur und Compliance sicherstellen (Anchorage-Verwahrung, Paxos, Identitäts-/AML-Tools) und die DeFi-Primitive übertragen, um ein Aufblühen von Sekundärmärkten und Hebelwirkung zu ermöglichen. Das Ergebnis ist, dass Plume im Jahr 2025 potenziell das am stärksten vernetzte RWA-Netzwerk in Web3 ist – ein Hub, an den verschiedene RWA-Protokolle und Real-World-Institutionen angeschlossen sind. Dieser „Netzwerk-der-Netzwerke“-Effekt könnte einen erheblichen Total Value Locked und Benutzeraktivität antreiben, wie frühe Metriken zeigen (Plumes Testnet verzeichnete in kurzer Zeit über 18 Millionen einzigartige Wallets und über 280 Millionen Transaktionen, hauptsächlich aufgrund von Anreizkampagnen und der Breite der Projekte, die das Wasser testeten).

Roadmap und Entwicklungsmeilensteine​

Plumes Entwicklung verlief rasant, mit einem phasenweisen Ansatz zur Skalierung von Real-World Assets On-Chain:

• Testnet und Community-Wachstum (2023): Plume startete sein incentiviertes Testnet (Codename „Miles“) Mitte bis Ende 2023. Die Testnet-Kampagne war äußerst erfolgreich bei der Gewinnung von Benutzern – über 18 Millionen Testnet-Wallet-Adressen wurden erstellt, die über 280 Millionen Transaktionen ausführten. Dies wurde wahrscheinlich durch Testnet-„Missionen“ und eine Airdrop-Kampagne (Staffel 1 von Plumes Airdrop wurde von frühen Benutzern beansprucht) angetrieben. Das Testnet integrierte auch über 200 Protokolle und verzeichnete 1 Million gemintete NFTs („Goons“), was auf ein lebendiges Testökosystem hindeutet. Dieses massive Testnet war ein Meilenstein, der Plumes technische Skalierbarkeit bewies und Begeisterung (und eine große Community: Plume zählt jetzt ~1 Million Twitter-Follower und Hunderttausende in Discord/Telegram) erzeugte.

• Mainnet-Start (Q1 2025): Plume strebte den Mainnet-Start für Ende 2024 oder Anfang 2025 an. Tatsächlich kündigten Partner wie Mercado Bitcoin im Februar 2025 an, dass ihre tokenisierten Assets „vom ersten Tag des Plume-Mainnet-Starts an“ live gehen würden. Dies impliziert, dass Plume Mainnet um Februar 2025 live ging oder gehen sollte. Der Mainnet-Start ist ein entscheidender Meilenstein, der die Erkenntnisse des Testnets in die Produktion bringt, zusammen mit der anfänglichen Auswahl an Real-World Assets (im Wert von über 1 Milliarde US-Dollar), die zur Tokenisierung bereit sind. Der Start umfasste wahrscheinlich die Veröffentlichung von Plumes Kernprodukten: die Plume Chain (Mainnet), Arc für das Asset-Onboarding, den pUSD Stablecoin und die Plume Passport Wallet sowie anfängliche DeFi-dApps (DEXs, Geldmärkte), die von Partnern bereitgestellt wurden.

• Phasenweises Asset-Onboarding: Plume hat eine „phasenweise Onboarding-Strategie“ für Assets angekündigt, um eine sichere, liquide Umgebung zu gewährleisten. In frühen Phasen kommen einfachere oder risikoärmere Assets (wie vollständig gedeckte Stablecoins, tokenisierte Anleihen) zuerst, zusammen mit kontrollierter Teilnahme (vielleicht Whitelist-Institutionen), um Vertrauen und Liquidität aufzubauen. Jede Phase schaltet dann weitere Anwendungsfälle und Asset-Klassen frei, sobald sich das Ökosystem bewährt hat. Zum Beispiel könnte sich Phase 1 auf On-Chain-Staatsanleihen und Privatkreditfonds-Token konzentrieren (relativ stabile, renditegenerierende Assets). Spätere Phasen könnten exotischere oder renditestärkere Assets wie Einnahmeströme aus erneuerbaren Energien, Immobilien-Equity-Token oder sogar exotische Assets (die Dokumentation erwähnt amüsant „GPUs, Uran, Mineralrechte, Durianfarmen“ als mögliche zukünftige On-Chain-Assets) bringen. Plumes Roadmap erweitert somit das Asset-Menü im Laufe der Zeit, parallel zur Entwicklung der benötigten Markttiefe und des Risikomanagements On-Chain.

• Skalierung und Dezentralisierung: Nach dem Mainnet ist ein wichtiges Entwicklungsziel, die Operationen der Plume-Chain zu dezentralisieren. Derzeit hat Plume ein Sequencer-Modell (wahrscheinlich vom Team oder einigen Nodes betrieben). Im Laufe der Zeit planen sie, einen robusten Validator-/Sequencer-Satz einzuführen, bei dem $PLUME-Staker helfen, das Netzwerk zu sichern, und möglicherweise sogar zu einem vollständig unabhängigen Konsens überzugehen. Die Anmerkung des Gründers über den Aufbau eines optimierten L1 mit einem neuen kryptoökonomischen Modell deutet darauf hin, dass Plume ein neuartiges Proof-of-Stake- oder hybrides Sicherheitsmodell implementieren könnte, um hochwertige RWAs On-Chain zu schützen. Meilensteine in dieser Kategorie wären die Open-Source-Bereitstellung weiterer Teile des Stacks, der Betrieb eines incentivierten Testnets für Node-Betreiber und die Implementierung von Fraud Proofs oder zk-Proofs (wenn man über einen optimistischen Rollup hinausgeht).

• Feature-Upgrades: Plumes Roadmap umfasst auch das Hinzufügen fortgeschrittener Funktionen, die von Institutionen gefordert werden. Dies könnte beinhalten:

  • Datenschutzverbesserungen: z. B. die Integration von Zero-Knowledge-Proofs für vertrauliche Transaktionen oder Identität, damit sensible Finanzdetails von RWAs (wie Kreditnehmerinformationen oder Cashflow-Daten) auf einem öffentlichen Ledger privat gehalten werden können. Die Erwähnung von FHE und zkTLS deutet auf Forschung zur Ermöglichung einer privaten, aber überprüfbaren Asset-Handhabung hin.
  • Compliance und Identität: Plume verfügt bereits über AML-Screening- und Compliance-Module, aber zukünftige Arbeiten werden die On-Chain-Identität verfeinern (vielleicht DID-Integration in Plume Passport), damit RWA-Token Übertragungsbeschränkungen durchsetzen oder nur von berechtigten Investoren gehalten werden können, wenn dies erforderlich ist.
  • Interoperabilität: Weitere Integrationen mit Cross-Chain-Protokollen (Erweiterung von LayerZero) und Bridges, damit Plumes RWA-Liquidität nahtlos in große Ökosysteme wie Ethereum Mainnet, Layer-2s und sogar andere App-Chains fließen kann. Das SkyLink Omnichain-Yield-Produkt ist wahrscheinlich Teil davon und ermöglicht es Benutzern auf anderen Chains, Renditen aus Plumes RWA-Pools zu nutzen.

• Wachstumsziele: Plumes Führung hat öffentlich Ziele wie „bis Q4 2024 Assets im Wert von über 3 Milliarden US-Dollar tokenisieren“ und schließlich noch viel mehr genannt. Während 1,25 Milliarden US-Dollar die kurzfristige Pipeline beim Start waren, ist der Weg zu 3 Milliarden US-Dollar in tokenisierten RWAs ein expliziter Meilenstein. Längerfristig, angesichts der Billionen an institutionellen Assets, die potenziell tokenisierbar sind, wird Plume den Erfolg daran messen, wie viel Real-World-Wert es On-Chain bringt. Eine weitere Metrik ist TVL und Benutzerakzeptanz: Bis April 2025 überschritt der RWA-Tokenisierungsmarkt insgesamt 20 Milliarden US-Dollar TVL, und Plume strebt an, einen erheblichen Anteil davon zu erobern. Wenn seine Partnerschaften reifen (z. B. wenn auch nur 5 % dieser 1-Billion-Dollar-Goldfinch-Pipeline On-Chain kommen), könnte Plumes TVL exponentiell wachsen.

• Jüngste Highlights: Bis Frühjahr 2025 hatte Plume mehrere bemerkenswerte Meilensteine erreicht:

  • Die Apollo-Investition (April 2025) – die nicht nur Finanzierung brachte, sondern auch die Möglichkeit, mit Apollos Portfolio zusammenzuarbeiten (Apollo verwaltet über 600 Milliarden US-Dollar, einschließlich Kredit-, Immobilien- und Private-Equity-Assets, die schließlich tokenisiert werden könnten).
  • Grayscale-Berücksichtigung (April 2025) – die Aufnahme in Grayscales Beobachtungsliste ist ein Meilenstein der Anerkennung und könnte den Weg für ein Plume-Anlageprodukt für Institutionen ebnen.
  • RWA-Marktführerschaft: Plumes Team veröffentlicht regelmäßig die „Plumeberg“-Newsletter, die RWA-Markttrends aufzeigen. In einem feierten sie, dass RWA-Protokolle 10 Milliarden US-Dollar TVL überschritten haben und hoben Plumes Schlüsselrolle in der Erzählung hervor. Sie haben Plume als Kerninfrastruktur positioniert, während der Sektor wächst, was auf einen Meilenstein hindeutet, eine Referenzplattform in der RWA-Diskussion zu werden.

Im Wesentlichen geht es bei Plumes Roadmap um Skalierung nach oben und außen: Skalierung nach oben in Bezug auf Assets (von Hunderten Millionen auf Milliarden tokenisiert) und Skalierung nach außen in Bezug auf Funktionen (Datenschutz, Compliance, Dezentralisierung) und Integrationen (Verbindung zu mehr Assets und Benutzern weltweit). Jedes erfolgreiche Asset-Onboarding (sei es ein brasilianisches Kreditgeschäft oder eine Apollo-Fonds-Tranche) ist ein Entwicklungsmeilenstein, der das Modell beweist. Wenn Plume den Schwung beibehalten kann, könnten zukünftige Meilensteine große Finanzinstitutionen umfassen, die Produkte direkt auf Plume auflegen (z. B. eine Bank, die eine Anleihe auf Plume ausgibt), oder Regierungsbehörden, die Plume für öffentliche Asset-Auktionen nutzen – alles Teil der längerfristigen Vision von Plume als globaler On-Chain-Marktplatz für Real-World-Finanzen.

Metriken und Traktion​

Obwohl noch in den Anfängen, lässt sich die Traktion von Plume Network durch eine Kombination aus Testnet-Metriken, der Pipeline an Partnerschaften und dem allgemeinen Wachstum von RWA On-Chain beurteilen:

• Testnet-Adoption: Plumes incentiviertes Testnet (2023) verzeichnete außerordentliche Beteiligung. Über 18 Millionen einzigartige Adressen und 280 Millionen Transaktionen wurden registriert – Zahlen, die denen vieler Mainnets ähneln oder diese übertreffen. Dies wurde durch eine enthusiastische Community angetrieben, die von Plumes Airdrop-Anreizen und der Anziehungskraft von RWAs angezogen wurde. Es zeigt ein starkes Interesse des Einzelhandels an der Plattform (obwohl viele Spekulanten gewesen sein könnten, die auf Belohnungen abzielten, hat es dennoch eine große Benutzerbasis geschaffen). Zusätzlich haben über 200 DeFi-Protokolle Contracts auf dem Testnet bereitgestellt, was ein breites Entwicklerinteresse signalisiert. Dies hat Plume effektiv schon vor dem Start mit einer großen Benutzer- und Entwickler-Community ausgestattet.

• Community-Größe: Plume baute schnell eine soziale Anhängerschaft von Millionen auf (z. B. 1 Million Follower auf X/Twitter, 450 Tausend in Discord usw.). Sie bezeichnen ihre Community-Mitglieder als „Goons“ – über 1 Million „Goon“-NFTs wurden als Teil der Testnet-Erfolge gemintet. Solch ein gamifiziertes Wachstum spiegelt einen der schnellsten Community-Aufbauten in der jüngeren Web3-Geschichte wider und zeigt, dass die Erzählung von Real-World Assets bei einem breiten Publikum im Krypto-Bereich Anklang findet.

• Ökosystem- und TVL-Pipeline: Beim Mainnet-Start prognostizierte Plume, über 1 Milliarde US-Dollar an tokenisierten oder verfügbaren Real-World Assets am ersten Tag zu haben. In einer Erklärung hob Mitbegründer Chris Yin den proprietären Zugang zu hochrentierlichen, privat gehaltenen Assets hervor, die „exklusiv“ zu Plume kommen. Tatsächlich umfassten die spezifischen Assets:

  • 500 Millionen US-Dollar aus einem Credbull-Privatkreditfonds,
  • 300 Millionen US-Dollar in Solarenergieparks (Plural Energy),
  • 120 Millionen US-Dollar im Gesundheitswesen (Medicaid-Forderungen),
  • plus Mineralrechte und andere exotische Assets. Diese summieren sich auf ~1 Milliarde US-Dollar, und Yin erklärte das Ziel, bis Ende 2024 3 Milliarden US-Dollar tokenisiert zu erreichen. Solche Zahlen würden, wenn sie realisiert werden, Plume zu den Top-Chains für RWA-TVL zählen. Zum Vergleich: Der gesamte RWA-Sektor hatte im April 2025 einen On-Chain-TVL von etwa 20 Milliarden US-Dollar, sodass 3 Milliarden US-Dollar auf einer Plattform einen sehr bedeutenden Anteil ausmachen würden.

• Aktueller TVL / Nutzung: Da der Mainnet-Start noch jung ist, werden konkrete TVL-Zahlen auf Plume noch nicht öffentlich wie auf DeFiLlama gemeldet. Wir wissen jedoch, dass mehrere integrierte Projekte ihren eigenen TVL mitbringen:

  • Ondos Produkte (OUSG usw.) hatten Anfang 2024 einen Marktwert von 623 Millionen US-Dollar – ein Teil davon könnte nun auf Plume liegen oder gespiegelt werden.
  • Die tokenisierten Assets über Mercado Bitcoin (Brasilien) fügen eine Pipeline von 40 Millionen US-Dollar hinzu.
  • Goldfinch Primes Pool könnte große Einlagen anziehen (Goldfinchs ältere Pools vergaben Kredite im Wert von über 100 Millionen US-Dollar; Prime könnte mit Institutionen höher skalieren).
  • Wenn Nest-Vaults mehrere Renditen aggregieren, könnte dies schnell einen dreistelligen Millionen-TVL auf Plume ansammeln, da Stablecoin-Halter 5-10 % Renditen von RWAs suchen. Als qualitative Metrik war die Nachfrage nach RWA-Renditen auch in Bärenmärkten hoch – zum Beispiel verzeichneten tokenisierte Staatsanleihenfonds wie Ondos innerhalb weniger Monate Hunderte von Millionen. Plume, das viele solcher Angebote konzentriert, könnte einen raschen Anstieg des TVL erleben, da DeFi-Benutzer zu „echteren“ Renditen wechseln.

• Transaktionen und Aktivität: Wir könnten relativ geringere On-Chain-Transaktionszahlen auf Plume erwarten, verglichen mit einer Gaming-Chain, da RWA-Transaktionen höherwertig, aber seltener sind (z. B. das Verschieben von Millionen in einem Anleihe-Token im Vergleich zu vielen Mikrotransaktionen). Wenn jedoch der Sekundärhandel anzieht (an einer Orderbuch-Börse oder einem AMM auf Plume), könnten wir eine stetige Aktivität sehen. Die Präsenz von 280 Millionen Test-Transaktionen deutet darauf hin, dass Plume bei Bedarf einen hohen Durchsatz bewältigen kann. Mit Plumes niedrigen Gebühren (die billiger als Ethereum sein sollen) und der Komponierbarkeit fördert es komplexere Strategien (wie das Looping von Sicherheiten, automatisierte Renditestrategien durch Smart Contracts), die Interaktionen antreiben könnten.

• Real-World-Impact: Eine weitere „Metrik“ ist die traditionelle Beteiligung. Plumes Partnerschaft mit Apollo und anderen bedeutet, dass die institutionellen AuM (Assets under Management), die mit Plume verbunden sind, im zweistelligen Milliardenbereich liegen (allein Apollos beteiligte Fonds, BlackRocks BUIDL-Fonds usw. gezählt). Obwohl nicht dieser gesamte Wert On-Chain ist, könnte bereits eine kleine Zuteilung von jedem Plumes On-Chain-Assets schnell anschwellen lassen. Zum Beispiel erreichte BlackRocks BUIDL-Fonds (tokenisierter Geldmarkt) innerhalb eines Jahres 1 Milliarde US-Dollar AuM. Franklin Templetons On-Chain-Staatsgeldmarktfonds erreichte 368 Millionen US-Dollar. Wenn ähnliche Fonds auf Plume starten oder bestehende verbunden werden, spiegeln diese Zahlen das potenzielle Ausmaß wider.

• Sicherheits-/Compliance-Metriken: Es ist erwähnenswert, dass Plume sich als vollständig On-Chain 24/7, permissionless und dennoch compliant bewirbt. Ein Maß für den Erfolg wird null Sicherheitsvorfälle oder Ausfälle in den anfänglichen Kohorten von RWA-Token sein. Metriken wie an Benutzer gelieferte Renditen (z. B. X Betrag an Zinsen, der über Plume-Smart Contracts aus realen Assets ausgezahlt wird) werden Glaubwürdigkeit aufbauen. Plumes Design umfasst Echtzeit-Audits und On-Chain-Verifizierung von Asset-Sicherheiten (einige Partner stellen tägliche Transparenzberichte bereit, wie Ondo für USDY). Im Laufe der Zeit könnten konsistente, verifizierte Renditeauszahlungen und vielleicht Kreditratings On-Chain zu wichtigen Metriken werden, die es zu beobachten gilt.

Zusammenfassend zeigen frühe Indikatoren starkes Interesse und eine robuste Pipeline für Plume. Die Testnet-Zahlen demonstrieren die Traktion in der Krypto-Community, und die Partnerschaften skizzieren einen Weg zu einem signifikanten On-Chain-TVL und einer hohen Nutzung. Während Plume in den stabilen Zustand übergeht, werden wir Metriken wie die Anzahl der Live-Asset-Typen, die Höhe der ausgeschütteten Rendite und die Anzahl der aktiven Benutzer (insbesondere institutionelle) auf der Plattform verfolgen. Angesichts dessen, dass die gesamte RWA-Kategorie schnell wächst (über 22,4 Milliarden US-Dollar TVL im Mai 2025, mit einer monatlichen Wachstumsrate von 9,3 %), sollten Plumes Metriken im Kontext dieses expandierenden Kuchens betrachtet werden. Es besteht eine reale Möglichkeit, dass Plume zu einem führenden RWA-Hub werden könnte, der einen milliardenschweren Marktanteil erobert, wenn es seine Strategie weiterhin umsetzt.

Real-World Assets (RWA) in Web3: Überblick und Bedeutung​

Real-World Assets (RWAs) beziehen sich auf materielle oder finanzielle Vermögenswerte aus der traditionellen Wirtschaft, die auf der Blockchain tokenisiert werden – mit anderen Worten, digitale Token, die Eigentum oder Rechte an realen Vermögenswerten oder Cashflows repräsentieren. Dazu können Assets wie Immobilien, Unternehmensanleihen, Handelsrechnungen, Rohstoffe (Gold, Öl), Aktien oder sogar immaterielle Assets wie CO2-Zertifikate und geistiges Eigentum gehören. Die RWA-Tokenisierung ist wohl einer der wirkungsvollsten Trends im Krypto-Bereich, da sie als Brücke zwischen der traditionellen Finanzwelt (TradFi) und den dezentralen Finanzen (DeFi) dient. Indem reale Vermögenswerte On-Chain gebracht werden, kann die Blockchain-Technologie Transparenz, Effizienz und einen breiteren Zugang zu historisch undurchsichtigen und illiquiden Märkten schaffen.

Die Bedeutung von RWAs in Web3 ist in den letzten Jahren dramatisch gewachsen:

• Sie erschließen neue Quellen für Sicherheiten und Renditen für das Krypto-Ökosystem. Anstatt sich auf spekulativen Token-Handel oder rein krypto-natives Yield Farming zu verlassen, können DeFi-Benutzer in Token investieren, die ihren Wert aus realer Wirtschaftstätigkeit ableiten (z. B. Einnahmen aus einem Immobilienportfolio oder Zinsen aus Krediten). Dies führt „echte Renditen“ und Diversifizierung ein und macht DeFi nachhaltiger.
• Für die traditionelle Finanzwelt verspricht die Tokenisierung, Liquidität und Zugänglichkeit zu erhöhen. Assets wie Gewerbeimmobilien oder Kreditportfolios, die typischerweise begrenzte Käufer und umständliche Abwicklungsprozesse haben, können fraktionalisiert und 24/7 auf globalen Märkten gehandelt werden. Dies kann Finanzierungskosten senken und den Zugang zu Investitionen demokratisieren, die einst Banken oder großen Fonds vorbehalten waren.
• RWAs nutzen auch die Stärken der Blockchain: Transparenz, Programmierbarkeit und Effizienz. Die Abwicklung tokenisierter Wertpapiere kann nahezu sofort und Peer-to-Peer erfolgen, wodurch Zwischenschichten eliminiert und Abwicklungszeiten von Tagen auf Sekunden reduziert werden. Smart Contracts können Zinszahlungen automatisieren oder Vereinbarungen durchsetzen. Darüber hinaus verbessert der unveränderliche Audit-Trail von Blockchains die Transparenz – Investoren können genau sehen, wie ein Asset performt (insbesondere in Verbindung mit Orakeldaten) und darauf vertrauen, dass das Token-Angebot mit realen Assets übereinstimmt (mit On-Chain-Reservenachweisen usw.).
• Wichtig ist, dass die RWA-Tokenisierung als wichtiger Treiber der nächsten Welle der institutionellen Akzeptanz der Blockchain angesehen wird. Im Gegensatz zum weitgehend spekulativen DeFi-Sommer 2020 oder dem NFT-Boom sprechen RWAs direkt den Kern der Finanzbranche an, indem sie vertraute Assets effizienter machen. Ein kürzlich veröffentlichter Bericht von Ripple und BCG prognostizierte, dass der Markt für tokenisierte Assets bis 2033 18,9 Billionen US-Dollar erreichen könnte, was den riesigen adressierbaren Markt unterstreicht. Auch kurzfristig ist das Wachstum rasant – im Mai 2025 betrug der TVL von RWA-Projekten 22,45 Milliarden US-Dollar (plus ~9,3 % in einem Monat) und wird voraussichtlich bis Ende 2025 ~50 Milliarden US-Dollar erreichen. Einige Schätzungen sehen 1–3 Billionen US-Dollar bis 2030 tokenisiert, wobei obere Szenarien bei bis zu 30 Billionen US-Dollar liegen, wenn die Akzeptanz beschleunigt wird.

Kurz gesagt, die RWA-Tokenisierung transformiert die Kapitalmärkte, indem sie traditionelle Assets liquider, grenzenloser und programmierbarer macht. Sie repräsentiert eine Reifung der Krypto-Industrie – die über rein selbstbezogene Assets hinausgeht, um die Realwirtschaft zu finanzieren. Wie eine Analyse es ausdrückte, sind RWAs „schnell dabei, die Brücke zwischen der traditionellen Finanzwelt und der Blockchain-Welt zu werden“, wodurch das lange gehegte Versprechen der Blockchain, die Finanzwelt zu revolutionieren, Realität wird. Deshalb wurden RWAs in den Jahren 2024–2025 als die Wachstumsgeschichte in Web3 angepriesen, die ernsthafte Aufmerksamkeit von großen Asset Managern, Regierungen und Web3-Unternehmern gleichermaßen auf sich zieht.

Wichtige Protokolle und Projekte im RWA-Bereich​

Die RWA-Landschaft in Web3 ist breit gefächert und umfasst verschiedene Projekte, die sich jeweils auf unterschiedliche Asset-Klassen oder Nischen konzentrieren. Hier beleuchten wir einige wichtige Protokolle und Plattformen, die die RWA-Bewegung anführen, zusammen mit ihren Schwerpunkten und jüngsten Fortschritten:

Plume Network: Überblick und Nutzenversprechen​

Plume Network ist eine Blockchain-Plattform, die speziell für Real-World Assets (RWA) entwickelt wurde. Es handelt sich um eine öffentliche, Ethereum-kompatible Chain, die darauf ausgelegt ist, eine breite Palette realer Finanzanlagen zu tokenisieren – von Privatkrediten und Immobilien bis hin zu CO2-Zertifikaten und sogar Sammlerstücken – und sie so nutzbar zu machen wie native Krypto-Assets. Mit anderen Worten, Plume bringt Assets nicht nur On-Chain; es ermöglicht Benutzern, tokenisierte reale Assets in dezentralen Finanzen (DeFi) zu halten und zu nutzen – was bekannte Krypto-Aktivitäten wie Staking, Lending, Borrowing, Swapping und spekulativen Handel mit Assets ermöglicht, die ihren Ursprung in der traditionellen Finanzwelt haben.

Das zentrale Nutzenversprechen von Plume ist es, TradFi und DeFi zu überbrücken, indem traditionell illiquide oder unzugängliche Assets in programmierbare, liquide Token umgewandelt werden. Durch die Integration institutioneller Assets (z. B. Privatkreditfonds, ETFs, Rohstoffe) mit der DeFi-Infrastruktur möchte Plume hochwertige Investitionen – die einst auf große Institutionen oder spezifische Märkte beschränkt waren – permissionless, composable und für Krypto-Benutzer nur einen Klick entfernt machen. Dies eröffnet Krypto-Teilnehmern die Möglichkeit, „echte Renditen“ zu erzielen, die durch stabile reale Cashflows (wie Kreditzinsen, Mieteinnahmen, Anleiherenditen usw.) gedeckt sind, anstatt sich auf inflationäre Token-Belohnungen zu verlassen. Plumes Mission ist es, „RWA Finance (RWAfi)“ voranzutreiben und ein transparentes und offenes Finanzsystem zu schaffen, in dem jeder On-Chain auf Assets wie Privatkredite, Immobilienkredite oder Rohstoffe zugreifen und diese auf neuartige Weise frei nutzen kann.

Zusammenfassend dient Plume Network als „On-Chain-Heimat für Real-World Assets“ und bietet ein Full-Stack-Ökosystem, das Off-Chain-Assets in global zugängliche Finanzinstrumente mit echtem Krypto-nativem Nutzen verwandelt. Benutzer können Stablecoins staken, um Renditen von Top-Fondsmanagern (Apollo, BlackRock, Blackstone usw.) zu erzielen, RWA-gedeckte Token als Sicherheit zu loopen und zu hebeln und RWAs so einfach wie ERC-20-Token zu handeln. Damit positioniert sich Plume als Plattform, die danach strebt, alternative Assets liquider und programmierbarer zu machen und frisches Kapital sowie Investitionsmöglichkeiten in Web3 zu bringen, ohne Transparenz oder Benutzererfahrung zu opfern.

Technologie und Architektur​

Plume Network ist als EVM-kompatible Blockchain mit einer modularen Layer-2-Architektur implementiert. Im Hintergrund funktioniert Plume ähnlich wie ein Ethereum-Rollup (vergleichbar mit der Technologie von Arbitrum) und nutzt Ethereum für Datenverfügbarkeit und Sicherheit. Jede Transaktion auf Plume wird schließlich stapelweise an Ethereum übermittelt, was bedeutet, dass Benutzer eine kleine zusätzliche Gebühr zahlen, um die Kosten für die Veröffentlichung von Calldata auf Ethereum zu decken. Dieses Design nutzt die robuste Sicherheit von Ethereum, während Plume eine eigene Hochdurchsatz-Ausführungsumgebung für RWA-Anwendungsfälle ermöglicht, die jedoch für Vertrauen und Finalität an Ethereum gebunden ist. Plume betreibt einen Sequencer, der Transaktionen aggregiert und diese regelmäßig an Ethereum übermittelt, was der Chain eine schnellere Ausführung und niedrigere Gebühren ermöglicht.

Da Plume EVM-kompatibel ist, können Entwickler Solidity-Smart Contracts auf Plume genauso bereitstellen wie auf Ethereum, mit fast keinen Änderungen. Die Chain unterstützt die Standard-Ethereum-RPC-Methoden und Solidity-Operationen, mit nur geringfügigen Unterschieden (z. B. spiegeln Plumes Blocknummern- und Zeitstempel-Semantik die Konventionen von Arbitrum aufgrund des Layer-2-Designs wider). In der Praxis bedeutet dies, dass Plume bestehende DeFi-Protokolle und Entwickler-Tools problemlos integrieren kann. Die Plume-Dokumentation weist darauf hin, dass Cross-Chain-Messaging zwischen Ethereum (der „Eltern“-Chain) und Plume (der L2) unterstützt wird, wodurch Assets und Daten bei Bedarf zwischen den Chains verschoben werden können.

Bemerkenswerterweise beschreibt sich Plume als eine „modulare Blockchain“, die für RWA-Finanzen optimiert ist. Der modulare Ansatz zeigt sich in seiner Architektur: Es verfügt über dedizierte Komponenten für das Bridging von Assets (genannt Arc für das On-Chain-Bringen beliebiger Assets), für Omnichain-Rendite-Routing (SkyLink) über mehrere Blockchains hinweg und für On-Chain-Daten-Feeds (Nexus, eine „On-Chain-Datenautobahn“). Dies deutet darauf hin, dass Plume ein miteinander verbundenes System aufbaut, in dem Real-World-Asset-Token auf Plume mit Liquidität auf anderen Chains interagieren können und Off-Chain-Daten (wie Asset-Bewertungen, Zinssätze usw.) zuverlässig On-Chain eingespeist werden. Plumes Infrastruktur umfasst auch eine benutzerdefinierte Wallet namens Plume Passport (die „RWAfi Wallet“), die wahrscheinlich die für die RWA-Compliance notwendigen Identitäts-/AML-Prüfungen handhabt, sowie einen nativen Stablecoin (pUSD) für Transaktionen im Ökosystem.

Wichtig ist, dass Plumes aktuelle Iteration oft als Layer-2- oder Rollup-Chain bezeichnet wird – sie ist auf Ethereum für Sicherheit aufgebaut. Das Team hat jedoch ehrgeizige Pläne angedeutet, die Technologie weiterzuentwickeln. Plumes CTO bemerkte, dass sie als modularer L2-Rollup begannen, aber nun „den Stack herunterdrücken“ in Richtung einer vollständig souveränen Layer-1-Architektur, die eine neue Chain von Grund auf mit hoher Leistung, Datenschutzfunktionen „vergleichbar mit Schweizer Banken“ und einem neuartigen kryptoökonomischen Sicherheitsmodell optimiert, um die nächsten Billionen Dollar On-Chain zu sichern. Während die Details spärlich sind, deutet dies darauf hin, dass Plume im Laufe der Zeit zu einer unabhängigeren Chain übergehen oder erweiterte Funktionen wie FHE (Fully Homomorphic Encryption) oder zk-Proofs (die Erwähnung von zkTLS und Datenschutz) integrieren könnte, um institutionelle Anforderungen zu erfüllen. Vorerst nutzt Plumes Mainnet jedoch die Sicherheit von Ethereum und die EVM-Umgebung, um Assets und Benutzer schnell On-Board zu bringen und ein vertrautes, aber verbessertes DeFi-Erlebnis für RWAs zu bieten.

Tokenomics und Anreize​

PLUME ($PLUME) ist der native Utility-Token des Plume Network. Der $PLUME-Token wird verwendet, um Transaktionen, Governance und Netzwerksicherheit auf Plume zu betreiben. Als Gas-Token ist $PLUME erforderlich, um Transaktionsgebühren auf der Plume-Chain zu bezahlen (ähnlich wie ETH Gas auf Ethereum ist). Das bedeutet, dass alle Operationen – Handel, Staking, Bereitstellung von Contracts – $PLUME für Gebühren verbrauchen. Über Gas hinaus hat $PLUME mehrere Utility- und Anreizrollen:

• Governance: $PLUME-Halter können an Governance-Entscheidungen teilnehmen, voraussichtlich über Protokollparameter, Upgrades oder Asset-Onboarding-Entscheidungen abstimmen.
• Staking/Sicherheit: Der Token kann gestaked werden, was wahrscheinlich die Validator- oder Sequencer-Operationen des Netzwerks unterstützt. Staker helfen, die Chain zu sichern und erhalten im Gegenzug Staking-Belohnungen in $PLUME. (Selbst als Rollup kann Plume einen Proof-of-Stake-Mechanismus für seinen Sequencer oder für die eventuelle Dezentralisierung der Blockproduktion verwenden).
• Echte Rendite und DeFi-Nutzen: Plumes Dokumentation erwähnt, dass Benutzer $PLUME über dApps hinweg verwenden können, um „echte Renditen freizuschalten“. Dies deutet darauf hin, dass das Halten oder Staking von $PLUME höhere Renditen in bestimmten RWA-Yield-Farms oder Zugang zu exklusiven Möglichkeiten im Ökosystem ermöglichen könnte.
• Ökosystem-Anreize: $PLUME wird auch verwendet, um Community-Engagement zu belohnen – zum Beispiel könnten Benutzer Token über Community-Quests, Empfehlungsprogramme, Testnet-Teilnahme (wie das „Take Flight“-Entwicklerprogramm oder die Testnet-„Goons“-NFTs) verdienen. Dieses Anreizdesign soll Netzwerkeffekte ankurbeln, indem Token an diejenigen verteilt werden, die die Plattform aktiv nutzen und erweitern.

Token-Angebot & -Verteilung: Plume hat ein festes Gesamtangebot von 10 Milliarden $PLUME-Token. Beim Token Generation Event (Mainnet-Start) beträgt das anfängliche zirkulierende Angebot 20 % des Gesamtangebots (d. h. 2 Milliarden Token). Die Zuteilung ist stark auf Community- und Ökosystementwicklung ausgerichtet:

• 59 % an Community, Ökosystem & Stiftung – dieser große Anteil ist für Grants, Liquiditätsanreize, Community-Belohnungen und einen Stiftungs-Pool reserviert, um das langfristige Wachstum des Ökosystems zu unterstützen. Dies stellt sicher, dass ein Großteil der Token zur Verfügung steht, um die Nutzung anzukurbeln (und signalisiert potenziell das Engagement für Dezentralisierung im Laufe der Zeit).
• 21 % an Frühe Unterstützer – diese Token werden strategischen Investoren und Partnern zugewiesen, die Plumes Entwicklung finanziert haben. (Wie wir sehen werden, hat Plume Kapital von prominenten Krypto-Fonds erhalten; diese Zuteilung wird wahrscheinlich im Laufe der Zeit gemäß den Investorenvereinbarungen freigegeben.)
• 20 % an Kernmitwirkende (Team) – zugewiesen an das Gründerteam und die Kernentwickler, die Plume vorantreiben. Dieser Anteil motiviert das Team und richtet es auf den Erfolg des Netzwerks aus, typischerweise über einen mehrjährigen Zeitraum.

Neben $PLUME umfasst Plumes Ökosystem einen Stablecoin namens Plume USD (pUSD). pUSD ist als RWAfi-Ökosystem-Stablecoin für Plume konzipiert. Er dient als Recheneinheit und primäre Handels-/Sicherheitswährung innerhalb von Plumes DeFi-Apps. Einzigartig ist, dass pUSD vollständig 1:1 durch USDC gedeckt ist – effektiv ein Wrapped USDC für das Plume-Netzwerk. Diese Designentscheidung (Wrapping von USDC) wurde getroffen, um Reibungsverluste für traditionelle Institutionen zu reduzieren: Wenn eine Organisation bereits mit dem Halten und Minten von USDC vertraut ist, kann sie pUSD auf Plume nahtlos unter denselben Rahmenbedingungen minten und verwenden. pUSD wird nativ sowohl auf Ethereum als auch auf Plume gemintet und eingelöst, was bedeutet, dass Benutzer oder Institutionen USDC auf Ethereum einzahlen und pUSD auf Plume erhalten können oder umgekehrt. Durch die 1:1-Bindung von pUSD an USDC (und letztendlich an USD-Reserven) stellt Plume sicher, dass sein Stablecoin vollständig besichert und liquide bleibt, was für RWA-Transaktionen entscheidend ist (wo Vorhersehbarkeit und Stabilität des Tauschmittels erforderlich sind). In der Praxis bietet pUSD eine gemeinsame stabile Liquiditätsschicht für alle RWA-Apps auf Plume – sei es der Kauf tokenisierter Anleihen, die Investition in RWA-Yield-Vaults oder der Handel mit Assets an einer DEX, pUSD ist der Stablecoin, der den Werttausch untermauert.

Insgesamt zielen Plumes Tokenomics darauf ab, Netzwerknutzen mit Wachstumsanreizen in Einklang zu bringen. $PLUME stellt sicher, dass das Netzwerk selbsttragend ist (durch Gebühren und Staking-Sicherheit) und von der Community regiert wird, während große Zuteilungen an Ökosystemfonds und Airdrops die frühe Akzeptanz fördern. Gleichzeitig verankert pUSD das Finanzökosystem in einem vertrauenswürdigen stabilen Asset, was es traditionellem Kapital erleichtert, in Plume einzusteigen, und DeFi-Benutzern, Renditen auf Real-World-Investitionen zu messen.

Gründerteam und Unterstützer​

Plume Network wurde 2022 von einem Trio von Unternehmern mit Hintergründen in Krypto und Finanzen gegründet: Chris Yin (CEO), Eugene Shen (CTO) und Teddy Pornprinya (CBO). Chris Yin wird als visionärer Produktführer des Teams beschrieben, der die Strategie und Vordenkerrolle der Plattform im RWA-Bereich vorantreibt. Eugene Shen leitet als CTO die technische Entwicklung (zuvor hatte er an modularen Blockchain-Architekturen gearbeitet, wie seine Anmerkung über das „Anpassen von Geth“ und den Aufbau von Grund auf zeigt). Teddy Pornprinya, als Chief Business Officer, leitet Partnerschaften, Geschäftsentwicklung und Marketing – er war maßgeblich daran beteiligt, Dutzende von Projekten frühzeitig in das Plume-Ökosystem zu integrieren. Gemeinsam identifizierten die Gründer die Marktlücke für eine RWA-optimierte Chain und gaben ihre früheren Rollen auf, um Plume aufzubauen, wobei das Projekt etwa ein Jahr nach der Konzeption offiziell gestartet wurde.

Plume hat erhebliche Unterstützung sowohl von Krypto-nativen VCs als auch von traditionellen Finanzgiganten erhalten, was ein starkes Vertrauen in seine Vision signalisiert:

• Im Mai 2023 schloss Plume eine 10-Millionen-Dollar-Seed-Runde unter der Leitung von Haun Ventures (dem Fonds der ehemaligen a16z-Partnerin Katie Haun) ab. Weitere Teilnehmer an der Seed-Runde waren Galaxy Digital, Superscrypt (Temaseks Krypto-Arm), A Capital, SV Angel, Portal Ventures und Reciprocal Ventures. Diese vielfältige Investorenbasis verschaffte Plume einen starken Start, indem sie Krypto-Expertise und institutionelle Verbindungen kombinierte.

• Bis Ende 2024 sicherte sich Plume eine 20-Millionen-Dollar-Series-A-Finanzierung, um seine Entwicklung zu beschleunigen. Diese Runde wurde von Top-Investoren wie Brevan Howard Digital, Haun Ventures (erneut), Galaxy und Faction VC unterstützt. Die Einbeziehung von Brevan Howard, einem der weltweit größten Hedgefonds mit einem dedizierten Krypto-Arm, ist besonders bemerkenswert und unterstreicht das wachsende Interesse der Wall Street an RWAs auf der Blockchain.

• Im April 2025 tätigte Apollo Global Management – einer der weltweit größten alternativen Asset Manager – eine strategische Investition in Plume. Apollos Investition belief sich auf einen siebenstelligen (USD) Betrag, der Plume helfen sollte, seine Infrastruktur zu skalieren und mehr traditionelle Finanzprodukte On-Chain zu bringen. Apollos Beteiligung ist eine starke Bestätigung von Plumes Ansatz: Christine Moy, Apollos Head of Digital Assets, sagte, ihre Investition „unterstreicht Apollos Fokus auf Technologien, die den Zugang zu institutionellen Qualitätsprodukten erweitern… Plume repräsentiert eine neue Art von Infrastruktur, die sich auf den Nutzen digitaler Assets, das Engagement von Investoren und Finanzlösungen der nächsten Generation konzentriert“. Mit anderen Worten, Apollo sieht Plume als Schlüssel-Infrastruktur, um private Märkte liquider und über Blockchain zugänglicher zu machen.

• Ein weiterer strategischer Unterstützer ist YZi Labs, ehemals Binance Labs. Anfang 2025 kündigte YZi (der umbenannte Venture-Arm von Binance) ebenfalls eine strategische Investition in Plume Network an. YZi Labs hob Plume als eine „bahnbrechende Layer-2-Blockchain hervor, die für die Skalierung von Real-World Assets entwickelt wurde“, und ihre Unterstützung signalisiert Vertrauen, dass Plume TradFi und DeFi in großem Maßstab überbrücken kann. (Es ist erwähnenswert, dass die Umbenennung von Binance Labs in YZi Labs die Kontinuität ihrer Investitionen in Kerninfrastrukturprojekte wie Plume anzeigt.)

• Plumes Unterstützer umfassen auch traditionelle Fintech- und Krypto-Institutionen durch Partnerschaften (siehe unten) – zum Beispiel sind Mercado Bitcoin (Lateinamerikas größte digitale Asset-Plattform) und Anchorage Digital (ein regulierter Krypto-Verwahrer) Ökosystempartner, die sich effektiv mit Plumes Erfolg verbünden. Zusätzlich hat Grayscale Investments – der weltweit größte digitale Asset Manager – Notiz genommen: Im April 2025 fügte Grayscale offiziell $PLUME zu seiner Liste der Assets „Under Consideration“ für zukünftige Anlageprodukte hinzu. Auf Grayscales Radar zu sein, bedeutet, dass Plume potenziell in institutionelle Krypto-Trusts oder ETFs aufgenommen werden könnte, eine wichtige Anerkennung für ein relativ neues Projekt.

Zusammenfassend lässt sich sagen, dass Plumes Finanzierung und Unterstützung von einem Who’s Who der Top-Investoren stammt: führende Krypto-VCs (Haun, Galaxy, a16z über GFIs Unterstützung von Goldfinch usw.), Hedgefonds und TradFi-Akteure (Brevan Howard, Apollo) sowie Corporate Venture Arms (Binance/YZi). Diese Mischung von Unterstützern bringt nicht nur Kapital, sondern auch strategische Beratung, regulatorische Expertise und Verbindungen zu Real-World-Asset-Originatoren. Sie hat Plume auch mit beträchtlichen Mitteln (mindestens 30 Millionen Dollar+ über Seed- und Series-A-Runden) ausgestattet, um seine spezialisierte Blockchain aufzubauen und Assets On-Board zu bringen. Die starke Unterstützung dient als Vertrauensbeweis, dass Plume als führende Plattform im schnell wachsenden RWA-Sektor positioniert ist.

Ökosystempartner und Integrationen​

Plume war sehr aktiv beim Aufbau von Ökosystempartnerschaften sowohl im Krypto- als auch im traditionellen Finanzbereich und hat ein breites Netzwerk von Integrationen noch vor (und unmittelbar nach) dem Mainnet-Start aufgebaut. Diese Partner stellen die Assets, Infrastruktur und Distribution bereit, die Plumes RWA-Ökosystem funktionsfähig machen:

• Nest Protocol (Nest Credit): Eine RWA-Yield-Plattform, die auf Plume läuft und es Benutzern ermöglicht, Stablecoins in Vaults einzuzahlen und Yield-Bearing-Token zu erhalten, die durch Real-World Assets gedeckt sind. Nest ist im Wesentlichen ein DeFi-Frontend für RWA-Renditen und bietet Produkte wie tokenisierte US-Staatsanleihen, Privatkredite, Mineralrechte usw., abstrahiert aber die Komplexität, sodass sie sich „wie Krypto“ anfühlen. Benutzer tauschen USDC (oder pUSD) gegen von Nest ausgegebene Token, die vollständig durch regulierte, geprüfte Assets gedeckt sind, die von Verwahrern gehalten werden. Nest arbeitet eng mit Plume zusammen – ein Testimonial von Anil Sood von Anemoy (einem Partner) hebt hervor, dass „die Partnerschaft mit Plume unsere Mission beschleunigt, institutionelle RWAs jedem Investor zugänglich zu machen… Diese Zusammenarbeit ist ein Bauplan für die Zukunft der RWA-Innovation.“. In der Praxis ist Nest Plumes nativer Yield-Marktplatz (manchmal auch „Nest Yield“ oder RWA-Staking-Plattform genannt), und viele von Plumes großen Partnerschaften münden in Nest-Vaults.

• Mercado Bitcoin (MB): Die größte digitale Asset-Börse in Lateinamerika (mit Sitz in Brasilien) hat sich mit Plume zusammengetan, um ~40 Millionen US-Dollar an brasilianischen Real-World Assets zu tokenisieren. Diese im Februar 2025 angekündigte Initiative beinhaltet, dass MB Plumes Blockchain nutzt, um Token auszugeben, die brasilianische Asset-Backed Securities, Konsumentenkreditportfolios, Unternehmensschulden und Forderungen repräsentieren. Ziel ist es, globale Investoren mit renditeträchtigen Möglichkeiten in Brasiliens Wirtschaft zu verbinden – und damit brasilianische Kreditmärkte für On-Chain-Investoren weltweit über Plume zu öffnen. Diese brasilianischen RWA-Token werden vom ersten Tag des Plume-Mainnets an auf der Nest-Plattform verfügbar sein und stabile On-Chain-Renditen bieten, die durch brasilianische Kleinunternehmenskredite und Kreditforderungen gedeckt sind. Diese Partnerschaft ist bemerkenswert, da sie Plume eine geografische Reichweite (LATAM) und eine Pipeline von Schwellenländer-Assets verschafft und zeigt, wie Plume als Drehscheibe dienen kann, die regionale Asset-Originatoren mit globaler Liquidität verbindet.

• Superstate: Superstate ist ein Fintech-Startup, das von Robert Leshner (ehemaliger Gründer von Compound) gegründet wurde und sich darauf konzentriert, regulierte US-Staatsanleihenprodukte On-Chain zu bringen. Im Jahr 2024 startete Superstate einen tokenisierten US-Staatsanleihenfonds (als 1940 Act Mutual Fund genehmigt), der sich an Krypto-Benutzer richtet. Plume wurde von Superstate ausgewählt, um seine Multi-Chain-Expansion zu betreiben. In der Praxis bedeutet dies, dass Superstates tokenisierter T-Bill-Fonds (der eine stabile Rendite aus US-Staatsanleihen bietet) auf Plume verfügbar gemacht wird, wo er in Plumes DeFi-Ökosystem integriert werden kann. Leshner selbst sagte: „Durch die Expansion auf Plume – die einzigartige RWAfi-Chain – können wir zeigen, wie zweckgebundene Infrastruktur großartige neue Anwendungsfälle für tokenisierte Assets ermöglichen kann. Wir freuen uns darauf, auf Plume aufzubauen.“. Dies deutet darauf hin, dass Superstate seine Fonds-Token (z. B. einen On-Chain-Anteil eines Staatsanleihenfonds) auf Plume bereitstellen wird, sodass Plume-Benutzer diese halten oder in DeFi verwenden können (vielleicht als Sicherheit für Kredite oder in Nest-Vaults für automatische Renditen). Es ist eine starke Bestätigung, dass Plumes Chain als bevorzugte Heimat für regulierte Asset-Token wie Staatsanleihen angesehen wird.

• Ondo Finance: Ondo ist ein bekanntes DeFi-Projekt, das sich in den RWA-Bereich verlagert hat, indem es tokenisierte Anleihen und Renditeprodukte anbietet (insbesondere Ondos OUSG-Token, der Anteile an einem kurzfristigen US-Staatsanleihenfonds repräsentiert, und USDY, der ein zinstragendes USD-Einlagenprodukt darstellt). Ondo ist unter Plumes Ökosystempartnern aufgeführt, was eine Zusammenarbeit impliziert, bei der Ondos renditeträchtige Token (wie OUSG, USDY) auf Plume verwendet werden können. Tatsächlich stimmen Ondos Produkte eng mit Plumes Zielen überein: Ondo hat rechtliche Vehikel (SPVs) eingerichtet, um die Compliance sicherzustellen, und sein OUSG-Token ist durch BlackRocks tokenisierten Geldmarktfonds (BUIDL) gedeckt, der ~4,5 % APY aus Staatsanleihen bietet. Durch die Integration von Ondo erhält Plume Blue-Chip-RWA-Assets wie US-Staatsanleihen On-Chain. Tatsächlich hatten Ondos RWA-Produkte Ende 2024 einen Marktwert von über 600 Millionen US-Dollar, sodass deren Brücke zu Plume einen erheblichen TVL hinzufügt. Diese Synergie ermöglicht es Plume-Benutzern wahrscheinlich, in Ondos Token zu tauschen oder sie in Nest-Vaults für zusammengesetzte Strategien aufzunehmen.

• Centrifuge: Centrifuge ist ein Pionier in der RWA-Tokenisierung (betreibt eine eigene Polkadot-Parachain für RWA-Pools). Plumes Website listet Centrifuge als Partner auf, was eine Zusammenarbeit oder Integration nahelegt. Dies könnte bedeuten, dass Centrifuges Asset-Pools (Handelsfinanzierungen, Immobilien-Überbrückungskredite usw.) von Plume aus zugänglich sein könnten oder dass Centrifuge Plumes Infrastruktur für die Distribution nutzen wird. Zum Beispiel könnte Plumes SkyLink Omnichain-Rendite Liquidität von Plume in Centrifuge-Pools auf Polkadot leiten, oder Centrifuge könnte bestimmte Assets direkt auf Plume tokenisieren, um eine tiefere DeFi-Komponierbarkeit zu ermöglichen. Angesichts dessen, dass Centrifuge die Kategorie der Privatkredit-RWA mit ~409 Millionen US-Dollar TVL in seinen Pools anführt, ist seine Beteiligung am Plume-Ökosystem von Bedeutung. Sie deutet auf eine branchenweite Bewegung hin zu Interoperabilität zwischen RWA-Plattformen hin, wobei Plume als vereinheitlichende Schicht für RWA-Liquidität über Chains hinweg fungiert.

• Credbull: Credbull ist eine Privatkreditfonds-Plattform, die mit Plume zusammengearbeitet hat, um einen großen tokenisierten Kreditfonds aufzulegen. Laut CoinDesk rollt Credbull einen Privatkreditfonds von bis zu 500 Millionen US-Dollar auf Plume aus, der On-Chain-Investoren eine feste hohe Rendite bietet. Dies beinhaltet wahrscheinlich die Verpackung von Privatkrediten (Darlehen an mittelständische Unternehmen oder andere Kredit-Assets) in ein Vehikel, in das On-Chain-Stablecoin-Halter für eine feste Rendite investieren können. Die Bedeutung ist zweifach: (1) Es fügt Plumes Netzwerk eine riesige Pipeline von Rendite-Assets (~eine halbe Milliarde Dollar) hinzu, und (2) es zeigt, wie Plume echte Asset Manager anzieht, um Produkte auf seiner Chain zu initiieren. In Kombination mit anderen Pipeline-Assets plante Plume, bis Ende 2024 Assets im Wert von etwa 1,25 Milliarden US-Dollar zu tokenisieren, darunter den Credbull-Fonds, plus 300 Millionen US-Dollar an erneuerbaren Energien (Solarparks über Plural Energy), ~120 Millionen US-Dollar an Gesundheitsforderungen (Medicaid-gedeckte Rechnungen) und sogar Öl- und Gas-Mineralrechte. Diese große Pipeline zeigt, dass Plume beim Start nicht leer ist – es kommt mit greifbaren Assets, die sofort einsatzbereit sind.

• Goldfinch: Goldfinch ist ein dezentrales Kreditprotokoll, das unterbesicherte Kredite an Fintech-Kreditgeber weltweit vergab. Im Jahr 2023 verlagerte sich Goldfinch zu „Goldfinch Prime“, das sich an akkreditierte und institutionelle Investoren richtet, indem es On-Chain-Zugang zu führenden Privatkreditfonds bietet. Plume und Goldfinch kündigten eine strategische Partnerschaft an, um die Angebote von Goldfinch Prime auf Plumes Nest-Plattform zu bringen, wodurch Goldfinchs institutionelle Kreditgeschäfte mit Plumes Benutzerbasis verbunden werden. Durch diese Partnerschaft können institutionelle Investoren auf Plume Stablecoins in Fonds staken, die von Apollo, Golub Capital, Aries, Stellus und anderen führenden Privatkreditmanagern verwaltet werden, über Goldfinchs Integration. Der Ehrgeiz ist immens: Gemeinsam repräsentieren diese Manager über 1 Billion US-Dollar an Assets, und die Partnerschaft zielt darauf ab, Teile davon schließlich On-Chain verfügbar zu machen. In der Praxis könnte ein Benutzer auf Plume in einen diversifizierten Pool investieren, der Renditen aus Hunderten von Real-World-Darlehen dieser Kreditfonds erzielt, die alle über Goldfinch Prime tokenisiert sind. Dies verbessert nicht nur Plumes Asset-Diversität, sondern unterstreicht auch Plumes Glaubwürdigkeit, mit erstklassigen RWA-Plattformen zusammenzuarbeiten.

• Infrastrukturpartner (Custody und Konnektivität): Plume hat auch wichtige Infrastrukturakteure integriert. Anchorage Digital, eine regulierte Krypto-Verwahrungsbank, ist ein Partner – die Beteiligung von Anchorage bedeutet wahrscheinlich, dass institutionelle Benutzer ihre tokenisierten Assets oder $PLUME sicher in einer Verwahrungslösung auf Bankniveau verwahren können (ein Muss für große Geldbeträge). Paxos ist ein weiterer gelisteter Partner, was sich auf die Stablecoin-Infrastruktur beziehen könnte (Paxos gibt den USDP-Stablecoin aus und bietet auch Verwahrungs- und Brokerage-Dienste an – möglicherweise könnte Paxos die Reserven für pUSD sichern oder Asset-Tokenisierungs-Pipelines erleichtern). LayerZero wird ebenfalls erwähnt, was darauf hindeutet, dass Plume das Interoperabilitätsprotokoll von LayerZero für Cross-Chain-Messaging verwendet. Dies würde es Assets auf Plume ermöglichen, sich auf andere Chains zu bewegen (und umgekehrt) auf eine vertrauensminimierte Weise, was Plumes Rollup-Bridge ergänzt.

• Weitere DeFi-Integrationen: Plumes Ökosystemseite listet über 180 Protokolle auf, darunter RWA-Spezialisten und Mainstream-DeFi-Projekte. Zum Beispiel sind Namen wie Nucleus Yield (eine Plattform für tokenisierte Renditen) und möglicherweise On-Chain-KYC-Anbieter oder Identitätslösungen Teil der Mischung. Zum Zeitpunkt des Mainnets hatte Plume über 200 integrierte Protokolle in seiner Testnet-Umgebung – was bedeutet, dass viele bestehende dApps (DEXs, Geldmärkte usw.) auf Plume bereitgestellt wurden oder bereit sind, bereitgestellt zu werden. Dies stellt sicher, dass tokenisierte Real-World Assets nach der Tokenisierung sofortigen Nutzen haben: z. B. könnte ein tokenisierter Solarfarm-Einnahmestrom an einer Orderbuch-Börse gehandelt oder als Sicherheit für einen Kredit verwendet oder in einen Index aufgenommen werden – weil die DeFi-„Geld-Lego“-Teile (DEXs, Lending-Plattformen, Asset-Management-Protokolle) von Anfang an auf der Chain verfügbar sind.

Zusammenfassend lässt sich sagen, dass Plumes Ökosystemstrategie aggressiv und umfassend war: Ankerpartnerschaften für Assets sichern (z. B. Fonds von Apollo, BlackRock über Superstate/Ondo, Privatkredite über Goldfinch und Credbull, Schwellenländer-Assets über Mercado Bitcoin), Infrastruktur und Compliance sicherstellen (Anchorage-Verwahrung, Paxos, Identitäts-/AML-Tools) und die DeFi-Primitive übertragen, um ein Aufblühen von Sekundärmärkten und Hebelwirkung zu ermöglichen. Das Ergebnis ist, dass Plume im Jahr 2025 potenziell das am stärksten vernetzte RWA-Netzwerk in Web3 ist – ein Hub, an den verschiedene RWA-Protokolle und Real-World-Institutionen angeschlossen sind. Dieser „Netzwerk-der-Netzwerke“-Effekt könnte einen erheblichen Total Value Locked und Benutzeraktivität antreiben, wie frühe Metriken zeigen (Plumes Testnet verzeichnete in kurzer Zeit über 18 Millionen einzigartige Wallets und über 280 Millionen Transaktionen, hauptsächlich aufgrund von Anreizkampagnen und der Breite der Projekte, die das Wasser testeten).

Roadmap und Entwicklungsmeilensteine​

Plumes Entwicklung verlief rasant, mit einem phasenweisen Ansatz zur Skalierung von Real-World Assets On-Chain:

• Testnet und Community-Wachstum (2023): Plume startete sein incentiviertes Testnet (Codename „Miles“) Mitte bis Ende 2023. Die Testnet-Kampagne war äußerst erfolgreich bei der Gewinnung von Benutzern – über 18 Millionen Testnet-Wallet-Adressen wurden erstellt, die über 280 Millionen Transaktionen ausführten. Dies wurde wahrscheinlich durch Testnet-„Missionen“ und eine Airdrop-Kampagne (Staffel 1 von Plumes Airdrop wurde von frühen Benutzern beansprucht) angetrieben. Das Testnet integrierte auch über 200 Protokolle und verzeichnete 1 Million gemintete NFTs („Goons“), was auf ein lebendiges Testökosystem hindeutet. Dieses massive Testnet war ein Meilenstein, der Plumes technische Skalierbarkeit bewies und Begeisterung (und eine große Community: Plume zählt jetzt ~1 Million Twitter-Follower und Hunderttausende in Discord/Telegram) erzeugte.

• Mainnet-Start (Q1 2025): Plume strebte den Mainnet-Start für Ende 2024 oder Anfang 2025 an. Tatsächlich kündigten Partner wie Mercado Bitcoin im Februar 2025 an, dass ihre tokenisierten Assets „vom ersten Tag des Plume-Mainnet-Starts an“ live gehen würden. Dies impliziert, dass Plume Mainnet um Februar 2025 live ging oder gehen sollte. Der Mainnet-Start ist ein entscheidender Meilenstein, der die Erkenntnisse des Testnets in die Produktion bringt, zusammen mit der anfänglichen Auswahl an Real-World Assets (im Wert von über 1 Milliarde US-Dollar), die zur Tokenisierung bereit sind. Der Start umfasste wahrscheinlich die Veröffentlichung von Plumes Kernprodukten: die Plume Chain (Mainnet), Arc für das Asset-Onboarding, den pUSD Stablecoin und die Plume Passport Wallet sowie anfängliche DeFi-dApps (DEXs, Geldmärkte), die von Partnern bereitgestellt wurden.

• Phasenweises Asset-Onboarding: Plume hat eine „phasenweise Onboarding-Strategie“ für Assets angekündigt, um eine sichere, liquide Umgebung zu gewährleisten. In frühen Phasen kommen einfachere oder risikoärmere Assets (wie vollständig gedeckte Stablecoins, tokenisierte Anleihen) zuerst, zusammen mit kontrollierter Teilnahme (vielleicht Whitelist-Institutionen), um Vertrauen und Liquidität aufzubauen. Jede Phase schaltet dann weitere Anwendungsfälle und Asset-Klassen frei, sobald sich das Ökosystem bewährt hat. Zum Beispiel könnte sich Phase 1 auf On-Chain-Staatsanleihen und Privatkreditfonds-Token konzentrieren (relativ stabile, renditegenerierende Assets). Spätere Phasen könnten exotischere oder renditestärkere Assets wie Einnahmeströme aus erneuerbaren Energien, Immobilien-Equity-Token oder sogar exotische Assets (die Dokumentation erwähnt amüsant „GPUs, Uran, Mineralrechte, Durianfarmen“ als mögliche zukünftige On-Chain-Assets) bringen. Plumes Roadmap erweitert somit das Asset-Menü im Laufe der Zeit, parallel zur Entwicklung der benötigten Markttiefe und des Risikomanagements On-Chain.

• Skalierung und Dezentralisierung: Nach dem Mainnet ist ein wichtiges Entwicklungsziel, die Operationen der Plume-Chain zu dezentralisieren. Derzeit hat Plume ein Sequencer-Modell (wahrscheinlich vom Team oder einigen Nodes betrieben). Im Laufe der Zeit planen sie, einen robusten Validator-/Sequencer-Satz einzuführen, bei dem $PLUME-Staker helfen, das Netzwerk zu sichern, und möglicherweise sogar zu einem vollständig unabhängigen Konsens überzugehen. Die Anmerkung des Gründers über den Aufbau eines optimierten L1 mit einem neuen kryptoökonomischen Modell deutet darauf hin, dass Plume ein neuartiges Proof-of-Stake- oder hybrides Sicherheitsmodell implementieren könnte, um hochwertige RWAs On-Chain zu schützen. Meilensteine in dieser Kategorie wären die Open-Source-Bereitstellung weiterer Teile des Stacks, der Betrieb eines incentivierten Testnets für Node-Betreiber und die Implementierung von Fraud Proofs oder zk-Proofs (wenn man über einen optimistischen Rollup hinausgeht).

• Feature-Upgrades: Plumes Roadmap umfasst auch das Hinzufügen fortgeschrittener Funktionen, die von Institutionen gefordert werden. Dies könnte beinhalten:

  • Datenschutzverbesserungen: z. B. die Integration von Zero-Knowledge-Proofs für vertrauliche Transaktionen oder Identität, damit sensible Finanzdetails von RWAs (wie Kreditnehmerinformationen oder Cashflow-Daten) auf einem öffentlichen Ledger privat gehalten werden können. Die Erwähnung von FHE und zkTLS deutet auf Forschung zur Ermöglichung einer privaten, aber überprüfbaren Asset-Handhabung hin.
  • Compliance und Identität: Plume verfügt bereits über AML-Screening- und Compliance-Module, aber zukünftige Arbeiten werden die On-Chain-Identität verfeinern (vielleicht DID-Integration in Plume Passport), damit RWA-Token Übertragungsbeschränkungen durchsetzen oder nur von berechtigten Investoren gehalten werden können, wenn dies erforderlich ist.
  • Interoperabilität: Weitere Integrationen mit Cross-Chain-Protokollen (Erweiterung von LayerZero) und Bridges, damit Plumes RWA-Liquidität nahtlos in große Ökosysteme wie Ethereum Mainnet, Layer-2s und sogar andere App-Chains fließen kann. Das SkyLink Omnichain-Yield-Produkt ist wahrscheinlich Teil davon und ermöglicht es Benutzern auf anderen Chains, Renditen aus Plumes RWA-Pools zu nutzen.

• Wachstumsziele: Plumes Führung hat öffentlich Ziele wie „bis Q4 2024 Assets im Wert von über 3 Milliarden US-Dollar tokenisieren“ und schließlich noch viel mehr genannt. Während 1,25 Milliarden US-Dollar die kurzfristige Pipeline beim Start waren, ist der Weg zu 3 Milliarden US-Dollar in tokenisierten RWAs ein expliziter Meilenstein. Längerfristig, angesichts der Billionen an institutionellen Assets, die potenziell tokenisierbar sind, wird Plume den Erfolg daran messen, wie viel Real-World-Wert es On-Chain bringt. Eine weitere Metrik ist TVL und Benutzerakzeptanz: Bis April 2025 überschritt der RWA-Tokenisierungsmarkt insgesamt 20 Milliarden US-Dollar TVL, und Plume strebt an, einen erheblichen Anteil davon zu erobern. Wenn seine Partnerschaften reifen (z. B. wenn auch nur 5 % dieser 1-Billion-Dollar-Goldfinch-Pipeline On-Chain kommen), könnte Plumes TVL exponentiell wachsen.

• Jüngste Highlights: Bis Frühjahr 2025 hatte Plume mehrere bemerkenswerte Meilensteine erreicht:

  • Die Apollo-Investition (April 2025) – die nicht nur Finanzierung brachte, sondern auch die Möglichkeit, mit Apollos Portfolio zusammenzuarbeiten (Apollo verwaltet über 600 Milliarden US-Dollar, einschließlich Kredit-, Immobilien- und Private-Equity-Assets, die schließlich tokenisiert werden könnten).
  • Grayscale-Berücksichtigung (April 2025) – die Aufnahme in Grayscales Beobachtungsliste ist ein Meilenstein der Anerkennung und könnte den Weg für ein Plume-Anlageprodukt für Institutionen ebnen.
  • RWA-Marktführerschaft: Plumes Team veröffentlicht regelmäßig die „Plumeberg“-Newsletter, die RWA-Markttrends aufzeigen. In einem feierten sie, dass RWA-Protokolle 10 Milliarden US-Dollar TVL überschritten haben und hoben Plumes Schlüsselrolle in der Erzählung hervor. Sie haben Plume als Kerninfrastruktur positioniert, während der Sektor wächst, was auf einen Meilenstein hindeutet, eine Referenzplattform in der RWA-Diskussion zu werden.

Im Wesentlichen geht es bei Plumes Roadmap um Skalierung nach oben und außen: Skalierung nach oben in Bezug auf Assets (von Hunderten Millionen auf Milliarden tokenisiert) und Skalierung nach außen in Bezug auf Funktionen (Datenschutz, Compliance, Dezentralisierung) und Integrationen (Verbindung zu mehr Assets und Benutzern weltweit). Jedes erfolgreiche Asset-Onboarding (sei es ein brasilianisches Kreditgeschäft oder eine Apollo-Fonds-Tranche) ist ein Entwicklungsmeilenstein, der das Modell beweist. Wenn Plume den Schwung beibehalten kann, könnten zukünftige Meilensteine große Finanzinstitutionen umfassen, die Produkte direkt auf Plume auflegen (z. B. eine Bank, die eine Anleihe auf Plume ausgibt), oder Regierungsbehörden, die Plume für öffentliche Asset-Auktionen nutzen – alles Teil der längerfristigen Vision von Plume als globaler On-Chain-Marktplatz für Real-World-Finanzen.

Metriken und Traktion​

Obwohl noch in den Anfängen, lässt sich die Traktion von Plume Network durch eine Kombination aus Testnet-Metriken, der Pipeline an Partnerschaften und dem allgemeinen Wachstum von RWA On-Chain beurteilen:

• Testnet-Adoption: Plumes incentiviertes Testnet (2023) verzeichnete außerordentliche Beteiligung. Über 18 Millionen einzigartige Adressen und 280 Millionen Transaktionen wurden registriert – Zahlen, die denen vieler Mainnets ähneln oder diese übertreffen. Dies wurde durch eine enthusiastische Community angetrieben, die von Plumes Airdrop-Anreizen und der Anziehungskraft von RWAs angezogen wurde. Es zeigt ein starkes Interesse des Einzelhandels an der Plattform (obwohl viele Spekulanten gewesen sein könnten, die auf Belohnungen abzielten, hat es dennoch eine große Benutzerbasis geschaffen). Zusätzlich haben über 200 DeFi-Protokolle Contracts auf dem Testnet bereitgestellt, was ein breites Entwicklerinteresse signalisiert. Dies hat Plume effektiv schon vor dem Start mit einer großen Benutzer- und Entwickler-Community ausgestattet.

• Community-Größe: Plume baute schnell eine soziale Anhängerschaft von Millionen auf (z. B. 1 Million Follower auf X/Twitter, 450 Tausend in Discord usw.). Sie bezeichnen ihre Community-Mitglieder als „Goons“ – über 1 Million „Goon“-NFTs wurden als Teil der Testnet-Erfolge gemintet. Solch ein gamifiziertes Wachstum spiegelt einen der schnellsten Community-Aufbauten in der jüngeren Web3-Geschichte wider und zeigt, dass die Erzählung von Real-World Assets bei einem breiten Publikum im Krypto-Bereich Anklang findet.

• Ökosystem- und TVL-Pipeline: Beim Mainnet-Start prognostizierte Plume, über 1 Milliarde US-Dollar an tokenisierten oder verfügbaren Real-World Assets am ersten Tag zu haben. In einer Erklärung hob Mitbegründer Chris Yin den proprietären Zugang zu hochrentierlichen, privat gehaltenen Assets hervor, die „exklusiv“ zu Plume kommen. Tatsächlich umfassten die spezifischen Assets:

  • 500 Millionen US-Dollar aus einem Credbull-Privatkreditfonds,
  • 300 Millionen US-Dollar in Solarenergieparks (Plural Energy),
  • 120 Millionen US-Dollar im Gesundheitswesen (Medicaid-Forderungen),
  • plus Mineralrechte und andere exotische Assets. Diese summieren sich auf ~1 Milliarde US-Dollar, und Yin erklärte das Ziel, **bis Ende 2024 3 Milliarden US-Dollar

Einleitung: Die Notwendigkeit verifizierbarer KI auf der Blockchain​

Da KI-Systeme an Einfluss gewinnen, wird die Vertrauenswürdigkeit ihrer Ergebnisse entscheidend. Traditionelle Methoden verlassen sich auf institutionelle Zusicherungen (im Wesentlichen „vertrauen Sie uns einfach“), die keine kryptografischen Garantien bieten. Dies ist besonders problematisch in dezentralen Kontexten wie Blockchains, wo ein Smart Contract oder ein Benutzer einem KI-abgeleiteten Ergebnis vertrauen muss, ohne ein schweres Modell On-Chain erneut ausführen zu können. Zero-Knowledge Machine Learning (zkML) begegnet diesem Problem, indem es die kryptografische Verifizierung von ML-Berechnungen ermöglicht. Im Wesentlichen ermöglicht zkML einem Prover, einen prägnanten Beweis zu generieren, dass „die Ausgabe $Y$ aus der Ausführung des Modells $M$ mit der Eingabe $X$ resultierte“ – ohne $X$ oder die internen Details von $M$ preiszugeben. Diese Zero-Knowledge-Beweise (ZKPs) können von jedem (oder jedem Vertrag) effizient verifiziert werden, wodurch das KI-Vertrauen von „Richtlinie zu Beweis“ verlagert wird.

Die On-Chain-Verifizierbarkeit von KI bedeutet, dass eine Blockchain fortgeschrittene Berechnungen (wie neuronale Netzwerk-Inferenzen) integrieren kann, indem sie einen Beweis für die korrekte Ausführung verifiziert, anstatt die Berechnung selbst durchzuführen. Dies hat weitreichende Implikationen: Smart Contracts können Entscheidungen auf der Grundlage von KI-Vorhersagen treffen, dezentrale autonome Agenten können beweisen, dass sie ihren Algorithmen gefolgt sind, und Cross-Chain- oder Off-Chain-Berechnungsdienste können verifizierbare Ergebnisse anstelle von nicht verifizierbaren Orakeln liefern. Letztendlich bietet zkML einen Weg zu vertrauensloser und datenschutzfreundlicher KI – zum Beispiel, um zu beweisen, dass die Entscheidungen eines KI-Modells korrekt und autorisiert sind, ohne private Daten oder proprietäre Modellgewichte preiszugeben. Dies ist entscheidend für Anwendungen, die von sicherer Gesundheitsanalyse bis hin zu Blockchain-Gaming und DeFi-Orakeln reichen.

Wie zkML funktioniert: Komprimierung von ML-Inferenzen in prägnante Beweise​

Im Allgemeinen kombiniert zkML kryptografische Beweissysteme mit ML-Inferenzen, sodass eine komplexe Modellbewertung in einen kleinen Beweis „komprimiert“ werden kann. Intern wird das ML-Modell (z. B. ein neuronales Netzwerk) als Schaltkreis oder Programm dargestellt, das aus vielen arithmetischen Operationen (Matrixmultiplikationen, Aktivierungsfunktionen usw.) besteht. Anstatt alle Zwischenwerte preiszugeben, führt ein Prover die vollständige Berechnung Off-Chain durch und verwendet dann ein Zero-Knowledge-Beweisprotokoll, um zu bestätigen, dass jeder Schritt korrekt ausgeführt wurde. Der Verifizierer, dem nur der Beweis und einige öffentliche Daten (wie die endgültige Ausgabe und ein Bezeichner für das Modell) vorliegen, kann kryptografisch von der Korrektheit überzeugt werden, ohne das Modell erneut auszuführen.

Um dies zu erreichen, transformieren zkML-Frameworks die Modellberechnung typischerweise in ein für ZKPs geeignetes Format:

• Schaltkreis-Kompilierung: Bei SNARK-basierten Ansätzen wird der Berechnungsgraph des Modells in einen arithmetischen Schaltkreis oder eine Menge von Polynom-Constraints kompiliert. Jede Schicht des neuronalen Netzwerks (Faltungen, Matrixmultiplikationen, nichtlineare Aktivierungen) wird zu einem Teilschaltkreis mit Constraints, die sicherstellen, dass die Ausgaben bei gegebenen Eingaben korrekt sind. Da neuronale Netze nichtlineare Operationen (ReLUs, Sigmoids usw.) beinhalten, die nicht von Natur aus für Polynome geeignet sind, werden Techniken wie Lookup-Tabellen verwendet, um diese effizient zu handhaben. Zum Beispiel kann eine ReLU (Ausgabe = max(0, Eingabe)) durch eine benutzerdefinierte Constraint oder einen Lookup erzwungen werden, der überprüft, ob die Ausgabe der Eingabe entspricht, wenn Eingabe≥0, andernfalls Null. Das Endergebnis ist eine Reihe kryptografischer Constraints, die der Prover erfüllen muss, was implizit beweist, dass das Modell korrekt ausgeführt wurde.
• Ausführungs-Trace & Virtuelle Maschinen: Eine Alternative besteht darin, die Modellinferenz als Programm-Trace zu behandeln, wie es bei zkVM-Ansätzen der Fall ist. Zum Beispiel zielt die JOLT zkVM auf den RISC-V-Befehlssatz ab; man kann das ML-Modell (oder den Code, der es berechnet) nach RISC-V kompilieren und dann beweisen, dass jeder CPU-Befehl ordnungsgemäß ausgeführt wurde. JOLT führt eine „Lookup-Singularität“-Technik ein, die teure arithmetische Constraints durch schnelle Tabellen-Lookups für jede gültige CPU-Operation ersetzt. Jede Operation (Addition, Multiplikation, Bit-Operation usw.) wird über einen Lookup in einer riesigen Tabelle von vorab berechneten gültigen Ergebnissen überprüft, wobei ein spezialisiertes Argument (Lasso/SHOUT) verwendet wird, um dies effizient zu halten. Dies reduziert die Arbeitslast des Provers drastisch: Selbst komplexe 64-Bit-Operationen werden zu einem einzigen Tabellen-Lookup im Beweis anstelle vieler arithmetischer Constraints.
• Interaktive Protokolle (GKR Sum-Check): Ein dritter Ansatz verwendet interaktive Beweise wie GKR (Goldwasser–Kalai–Rotblum), um eine geschichtete Berechnung zu verifizieren. Hier wird die Berechnung des Modells als geschichteter arithmetischer Schaltkreis betrachtet (jede neuronale Netzwerkschicht ist eine Schicht des Schaltkreisgraphen). Der Prover führt das Modell normal aus, beteiligt sich dann aber an einem Sum-Check-Protokoll, um zu beweisen, dass die Ausgaben jeder Schicht bei gegebenen Eingaben korrekt sind. Im Lagrange-Ansatz (DeepProve, als Nächstes detailliert) führen Prover und Verifizierer ein interaktives Polynomprotokoll durch (das über Fiat-Shamir nicht-interaktiv gemacht wird), das die Konsistenz der Berechnungen jeder Schicht überprüft, ohne sie erneut durchzuführen. Diese Sum-Check-Methode vermeidet die Generierung eines monolithischen statischen Schaltkreises; stattdessen verifiziert sie die Konsistenz der Berechnungen schrittweise mit minimalen kryptografischen Operationen (hauptsächlich Hashing oder Polynombewertungen).

Unabhängig vom Ansatz ist das Ergebnis ein prägnanter Beweis (typischerweise einige Kilobyte bis einige zehn Kilobyte), der die Korrektheit der gesamten Inferenz bestätigt. Der Beweis ist Zero-Knowledge, was bedeutet, dass alle geheimen Eingaben (private Daten oder Modellparameter) verborgen bleiben können – sie beeinflussen den Beweis, werden aber den Verifizierern nicht offengelegt. Nur die beabsichtigten öffentlichen Ausgaben oder Behauptungen werden offengelegt. Dies ermöglicht Szenarien wie „beweisen Sie, dass Modell $M$, angewendet auf Patientendaten $X$, die Diagnose $Y$ ergibt, ohne $X$ oder die Gewichte des Modells preiszugeben.“

On-Chain-Verifizierung ermöglichen: Sobald ein Beweis generiert wurde, kann er auf einer Blockchain veröffentlicht werden. Smart Contracts können Verifizierungslogik enthalten, um den Beweis zu überprüfen, oft unter Verwendung vorkompilierter kryptografischer Primitive. Zum Beispiel verfügt Ethereum über Precompiles für BLS12-381-Pairing-Operationen, die in vielen zk-SNARK-Verifizierern verwendet werden, was die On-Chain-Verifizierung von SNARK-Beweisen effizient macht. STARKs (Hash-basierte Beweise) sind größer, können aber dennoch On-Chain mit sorgfältiger Optimierung oder möglicherweise mit einigen Vertrauensannahmen verifiziert werden (StarkWares L2 verifiziert beispielsweise STARK-Beweise auf Ethereum durch einen On-Chain-Verifizierer-Vertrag, wenn auch mit höheren Gaskosten als SNARKs). Der Schlüssel ist, dass die Kette das ML-Modell nicht ausführen muss – sie führt nur eine Verifizierung durch, die viel billiger ist als die ursprüngliche Berechnung. Zusammenfassend lässt sich sagen, dass zkML teure KI-Inferenzen in einen kleinen Beweis komprimiert, den Blockchains (oder jeder Verifizierer) in Millisekunden bis Sekunden überprüfen können.

Lagrange DeepProve: Architektur und Leistung eines zkML-Durchbruchs​

DeepProve von Lagrange Labs ist ein hochmodernes zkML-Inferenz-Framework, das sich auf Geschwindigkeit und Skalierbarkeit konzentriert. DeepProve wurde 2025 eingeführt und stellte ein neues Beweissystem vor, das dramatisch schneller ist als frühere Lösungen wie Ezkl. Sein Design konzentriert sich auf das GKR-interaktive Beweisprotokoll mit Sum-Check und spezialisierte Optimierungen für neuronale Netzwerk-Schaltkreise. So funktioniert DeepProve und erreicht seine Leistung:

• Einmalige Vorverarbeitung: Entwickler beginnen mit einem trainierten neuronalen Netzwerk (derzeit unterstützte Typen umfassen Multilayer-Perceptrons und gängige CNN-Architekturen). Das Modell wird in das ONNX-Format exportiert, eine Standard-Graphdarstellung. Das Tool von DeepProve parst dann das ONNX-Modell und quantisiert es (konvertiert Gewichte in Festkomma-/Ganzzahlform) für effiziente Feldarithmetik. In dieser Phase generiert es auch die Proving- und Verifizierungs-Keys für das kryptografische Protokoll. Dieses Setup wird einmal pro Modell durchgeführt und muss nicht pro Inferenz wiederholt werden. DeepProve betont die einfache Integration: „Exportieren Sie Ihr Modell nach ONNX → einmaliges Setup → Beweise generieren → überall verifizieren“.

• Beweiserstellung (Inferenz + Beweisgenerierung): Nach dem Setup nimmt ein Prover (der von einem Benutzer, einem Dienst oder dem dezentralen Prover-Netzwerk von Lagrange ausgeführt werden könnte) eine neue Eingabe $X$ und führt das Modell $M$ darauf aus, wobei er die Ausgabe $Y$ erhält. Während dieser Ausführung zeichnet DeepProve einen Ausführungs-Trace der Berechnungen jeder Schicht auf. Anstatt jede Multiplikation im Voraus in einen statischen Schaltkreis zu übersetzen (wie es SNARK-Ansätze tun), verwendet DeepProve das linearzeitliche GKR-Protokoll, um jede Schicht im laufenden Betrieb zu verifizieren. Für jede Netzwerkschicht verpflichtet sich der Prover zu den Eingaben und Ausgaben der Schicht (z. B. über kryptografische Hashes oder Polynom-Commitments) und beteiligt sich dann an einem Sum-Check-Argument, um zu beweisen, dass die Ausgaben tatsächlich aus den Eingaben gemäß der Funktion der Schicht resultieren. Das Sum-Check-Protokoll überzeugt den Verifizierer iterativ von der Korrektheit einer Summe von Auswertungen eines Polynoms, das die Berechnung der Schicht kodiert, ohne die tatsächlichen Werte preiszugeben. Nichtlineare Operationen (wie ReLU, Softmax) werden in DeepProve effizient durch Lookup-Argumente behandelt – wenn die Ausgabe einer Aktivierung berechnet wurde, kann DeepProve beweisen, dass jede Ausgabe einem gültigen Eingabe-Ausgabe-Paar aus einer vorab berechneten Tabelle für diese Funktion entspricht. Schicht für Schicht werden Beweise generiert und dann zu einem prägnanten Beweis aggregiert, der den gesamten Vorwärtslauf des Modells abdeckt. Der Großteil der Kryptografie wird minimiert – der Prover von DeepProve führt hauptsächlich normale numerische Berechnungen (die eigentliche Inferenz) sowie einige leichte kryptografische Commitments durch, anstatt ein riesiges System von Constraints zu lösen.

• Verifizierung: Der Verifizierer verwendet den endgültigen prägnanten Beweis zusammen mit einigen öffentlichen Werten – typischerweise dem committed Identifier des Modells (ein kryptografisches Commitment zu den Gewichten von $M$), der Eingabe $X$ (falls nicht privat) und der behaupteten Ausgabe $Y$ – um die Korrektheit zu überprüfen. Die Verifizierung im DeepProve-System beinhaltet die Überprüfung des Transkripts des Sum-Check-Protokolls und der endgültigen Polynom- oder Hash-Commitments. Dies ist aufwendiger als die Verifizierung eines klassischen SNARK (der einige Pairings umfassen könnte), aber es ist wesentlich billiger als das erneute Ausführen des Modells. In den Benchmarks von Lagrange dauert die Verifizierung eines DeepProve-Beweises für ein mittleres CNN in Software etwa 0,5 Sekunden. Das sind ~0,5s, um beispielsweise zu bestätigen, dass ein Faltungsnetzwerk mit Hunderttausenden von Parametern korrekt ausgeführt wurde – über 500-mal schneller als die naive Neuberechnung dieses CNN auf einer GPU zur Verifizierung. (Tatsächlich maß DeepProve eine 521-mal schnellere Verifizierung für CNNs und 671-mal für MLPs im Vergleich zur erneuten Ausführung.) Die Beweisgröße ist klein genug, um On-Chain übertragen zu werden (Zehntausende von KB), und die Verifizierung könnte bei Bedarf in einem Smart Contract durchgeführt werden, obwohl 0,5s Rechenzeit eine sorgfältige Gasoptimierung oder Layer-2-Ausführung erfordern könnten.

Architektur und Tools: DeepProve ist in Rust implementiert und bietet ein Toolkit (die zkml-Bibliothek) für Entwickler. Es unterstützt nativ ONNX-Modellgraphen und ist somit mit Modellen von PyTorch oder TensorFlow (nach dem Export) kompatibel. Der Proving-Prozess zielt derzeit auf Modelle mit bis zu einigen Millionen Parametern ab (Tests umfassen ein dichtes Netzwerk mit 4 Millionen Parametern). DeepProve nutzt eine Kombination kryptografischer Komponenten: ein multilineares Polynom-Commitment (um sich auf Schichtausgaben festzulegen), das Sum-Check-Protokoll zur Verifizierung von Berechnungen und Lookup-Argumente für nichtlineare Operationen. Bemerkenswerterweise erkennt Lagranges Open-Source-Repository an, dass es auf früheren Arbeiten (der Sum-Check- und GKR-Implementierung aus Scrolls Ceno-Projekt) aufbaut, was eine Überschneidung von zkML mit der Zero-Knowledge-Rollup-Forschung anzeigt.

Um Echtzeit-Skalierbarkeit zu erreichen, koppelt Lagrange DeepProve mit seinem Prover Network – einem dezentralen Netzwerk spezialisierter ZK-Prover. Die aufwendige Beweisgenerierung kann an dieses Netzwerk ausgelagert werden: Wenn eine Anwendung eine Inferenz verifiziert haben muss, sendet sie den Auftrag an das Lagrange-Netzwerk, wo viele Operatoren (die auf EigenLayer für Sicherheit gestaked sind) Beweise berechnen und das Ergebnis zurückgeben. Dieses Netzwerk incentiviert die zuverlässige Beweisgenerierung wirtschaftlich (bösartige oder fehlgeschlagene Aufträge führen dazu, dass der Operator slashed wird). Durch die Verteilung der Arbeit auf mehrere Prover (und potenziell die Nutzung von GPUs oder ASICs) verbirgt das Lagrange Prover Network die Komplexität und Kosten vor den Endbenutzern. Das Ergebnis ist ein schneller, skalierbarer und dezentraler zkML-Dienst: „verifizierbare KI-Inferenzen schnell und erschwinglich“.

Leistungsmeilensteine: Die Behauptungen von DeepProve werden durch Benchmarks gegen den bisherigen Stand der Technik, Ezkl, untermauert. Für ein CNN mit ~264.000 Parametern (Modell im CIFAR-10-Maßstab) betrug die Proving-Zeit von DeepProve ~1,24 Sekunden gegenüber ~196 Sekunden für Ezkl – etwa 158-mal schneller. Für ein größeres dichtes Netzwerk mit 4 Millionen Parametern bewies DeepProve eine Inferenz in ~2,3 Sekunden gegenüber ~126,8 Sekunden für Ezkl (~54-mal schneller). Auch die Verifizierungszeiten sanken: DeepProve verifizierte den 264k CNN-Beweis in ~0,6s, während die Verifizierung des Ezkl-Beweises (Halo2-basiert) in diesem Test über 5 Minuten auf der CPU dauerte. Die Beschleunigungen resultieren aus der nahezu linearen Komplexität von DeepProve: Sein Prover skaliert ungefähr O(n) mit der Anzahl der Operationen, während schaltkreisbasierte SNARK-Prover oft einen superlinearen Overhead aufweisen (FFT- und Polynom-Commitments-Skalierung). Tatsächlich kann der Prover-Durchsatz von DeepProve innerhalb einer Größenordnung der reinen Inferenzlaufzeit liegen – neuere GKR-Systeme können <10-mal langsamer sein als die Rohausführung für große Matrixmultiplikationen, eine beeindruckende Leistung in ZK. Dies macht Echtzeit- oder On-Demand-Beweise praktikabler und ebnet den Weg für verifizierbare KI in interaktiven Anwendungen.

Anwendungsfälle: Lagrange arbeitet bereits mit Web3- und KI-Projekten zusammen, um zkML anzuwenden. Beispielhafte Anwendungsfälle sind: verifizierbare NFT-Merkmale (Nachweis, dass eine KI-generierte Evolution eines Spielcharakters oder Sammlerstücks vom autorisierten Modell berechnet wurde), Provenienz von KI-Inhalten (Nachweis, dass ein Bild oder Text von einem bestimmten Modell generiert wurde, um Deepfakes zu bekämpfen), DeFi-Risikomodelle (Nachweis der Ausgabe eines Modells, das finanzielle Risiken bewertet, ohne proprietäre Daten preiszugeben) und private KI-Inferenz im Gesundheitswesen oder Finanzbereich (wo ein Krankenhaus KI-Vorhersagen mit einem Beweis erhalten kann, der die Korrektheit gewährleistet, ohne Patientendaten preiszugeben). Indem KI-Ausgaben verifizierbar und datenschutzfreundlich gemacht werden, öffnet DeepProve die Tür zu „KI, der Sie vertrauen können“ in dezentralen Systemen – von einer Ära des „blinden Vertrauens in Black-Box-Modelle“ zu einer Ära der „objektiven Garantien“.

SNARK-basiertes zkML: Ezkl und der Halo2-Ansatz​

Der traditionelle Ansatz für zkML verwendet zk-SNARKs (Succinct Non-interactive Arguments of Knowledge), um neuronale Netzwerk-Inferenzen zu beweisen. Ezkl (von ZKonduit/Modulus Labs) ist ein führendes Beispiel für diesen Ansatz. Es baut auf dem Halo2-Beweissystem auf (ein SNARK im PLONK-Stil mit Polynom-Commitments über BLS12-381). Ezkl bietet eine Toolchain, mit der ein Entwickler ein PyTorch- oder TensorFlow-Modell nehmen, es nach ONNX exportieren und Ezkl es automatisch in einen benutzerdefinierten arithmetischen Schaltkreis kompilieren lassen kann.

Funktionsweise: Jede Schicht des neuronalen Netzwerks wird in Constraints umgewandelt:

• Lineare Schichten (dicht oder Faltung) werden zu Sammlungen von Multiplikations-Additions-Constraints, die die Skalarprodukte zwischen Eingaben, Gewichten und Ausgaben erzwingen.
• Nichtlineare Schichten (wie ReLU, Sigmoid usw.) werden über Lookups oder stückweise Constraints behandelt, da solche Funktionen nicht polynomial sind. Zum Beispiel kann eine ReLU durch einen booleschen Selektor $b$ implementiert werden, mit Constraints, die sicherstellen, dass $y = x \cdot b$ und $0 \le b \le 1$ und $b=1$ wenn $x>0$ (eine Möglichkeit), oder effizienter durch eine Lookup-Tabelle, die $x \mapsto \max(0,x)$ für einen Bereich von $x$-Werten abbildet. Halo2s Lookup-Argumente ermöglichen das Mapping von 16-Bit (oder kleineren) Wertblöcken, sodass große Domänen (wie alle 32-Bit-Werte) normalerweise in mehrere kleinere Lookups „zerlegt“ werden. Dieses Zerlegen erhöht die Anzahl der Constraints.
• Große Ganzzahloperationen oder Divisionen (falls vorhanden) werden ähnlich in kleine Teile zerlegt. Das Ergebnis ist eine große Menge von R1CS/PLONK-Constraints, die auf die spezifische Modellarchitektur zugeschnitten sind.

Ezkl verwendet dann Halo2, um einen Beweis zu generieren, dass diese Constraints bei gegebenen geheimen Eingaben (Modellgewichte, private Eingaben) und öffentlichen Ausgaben gelten. Tools und Integration: Ein Vorteil des SNARK-Ansatzes ist, dass er auf bekannte Primitive zurückgreift. Halo2 wird bereits in Ethereum-Rollups (z. B. Zcash, zkEVMs) verwendet, ist also kampferprobt und verfügt über einen sofort verfügbaren On-Chain-Verifizierer. Die Beweise von Ezkl verwenden die BLS12-381-Kurve, die Ethereum über Precompiles verifizieren kann, was die Verifizierung eines Ezkl-Beweises in einem Smart Contract unkompliziert macht. Das Team hat auch benutzerfreundliche APIs bereitgestellt; zum Beispiel können Datenwissenschaftler mit ihren Modellen in Python arbeiten und Ezkls CLI verwenden, um Beweise zu erstellen, ohne tiefgehende Kenntnisse von Schaltkreisen zu haben.

Stärken: Der Ansatz von Ezkl profitiert von der Allgemeinheit und dem Ökosystem von SNARKs. Er unterstützt einigermaßen komplexe Modelle und hat bereits „praktische Integrationen (von DeFi-Risikomodellen bis hin zu Gaming-KI)“ erfahren, die reale ML-Aufgaben beweisen. Da er auf der Ebene des Berechnungsdiagramms des Modells arbeitet, kann er ML-spezifische Optimierungen anwenden: z. B. das Beschneiden unbedeutender Gewichte oder das Quantisieren von Parametern, um die Schaltkreisgröße zu reduzieren. Es bedeutet auch, dass die Modellvertraulichkeit natürlich ist – die Gewichte können als private Zeugendaten behandelt werden, sodass der Verifizierer nur sieht, dass irgendein gültiges Modell die Ausgabe erzeugt hat, oder bestenfalls ein Commitment zum Modell. Die Verifizierung von SNARK-Beweisen ist extrem schnell (typischerweise wenige Millisekunden oder weniger On-Chain), und die Beweisgrößen sind klein (einige Kilobyte), was ideal für die Blockchain-Nutzung ist.

Schwächen: Die Leistung ist die Achillesferse. Schaltkreisbasierte Beweiserstellung verursacht große Overheads, insbesondere wenn Modelle wachsen. Es wird angemerkt, dass SNARK-Schaltkreise historisch gesehen eine Million Mal mehr Arbeit für den Prover bedeuten konnten, als nur das Modell selbst auszuführen. Halo2 und Ezkl optimieren dies, aber dennoch erzeugen Operationen wie große Matrixmultiplikationen Tonnen von Constraints. Wenn ein Modell Millionen von Parametern hat, muss der Prover entsprechend Millionen von Constraints verarbeiten und dabei aufwendige FFTs und Multiexponentiationen durchführen. Dies führt zu hohen Proving-Zeiten (oft Minuten oder Stunden für nicht-triviale Modelle) und hohem Speicherverbrauch. Zum Beispiel kann die Beweiserstellung für ein relativ kleines CNN (z. B. einige Hunderttausend Parameter) mit Ezkl auf einer einzelnen Maschine Dutzende von Minuten dauern. Das Team hinter DeepProve zitierte, dass Ezkl Stunden für bestimmte Modellbeweise benötigte, die DeepProve in Minuten erledigen kann. Große Modelle passen möglicherweise nicht einmal in den Speicher oder erfordern eine Aufteilung in mehrere Beweise (die dann eine rekursive Aggregation benötigen). Obwohl Halo2 „moderat optimiert“ ist, führt jede Notwendigkeit, Lookups zu „zerlegen“ oder Operationen mit breiten Bits zu handhaben, zu zusätzlichem Overhead. Zusammenfassend lässt sich sagen, dass die Skalierbarkeit begrenzt ist – Ezkl funktioniert gut für kleine bis mittlere Modelle (und übertraf in Benchmarks tatsächlich einige frühere Alternativen wie naive Stark-basierte VMs), aber es stößt an Grenzen, wenn die Modellgröße einen bestimmten Punkt überschreitet.

Trotz dieser Herausforderungen sind Ezkl und ähnliche SNARK-basierte zkML-Bibliotheken wichtige Meilensteine. Sie bewiesen, dass verifizierte ML-Inferenz On-Chain möglich ist und aktiv genutzt wird. Insbesondere Projekte wie Modulus Labs demonstrierten die Verifizierung eines 18-Millionen-Parameter-Modells On-Chain unter Verwendung von SNARKs (mit starker Optimierung). Die Kosten waren nicht trivial, aber es zeigt die Entwicklung. Darüber hinaus verfügt das Mina Protocol über ein eigenes zkML-Toolkit, das SNARKs verwendet, um Smart Contracts auf Mina (die SNARK-basiert sind) die Verifizierung der ML-Modellausführung zu ermöglichen. Dies deutet auf eine wachsende Multi-Plattform-Unterstützung für SNARK-basierte zkML hin.

STARK-basierte Ansätze: Transparente und programmierbare ZK für ML​

zk-STARKs (Scalable Transparent ARguments of Knowledge) bieten einen weiteren Weg zu zkML. STARKs verwenden Hash-basierte Kryptografie (wie FRI für Polynom-Commitments) und vermeiden jegliches Trusted Setup. Sie arbeiten oft, indem sie eine CPU oder VM simulieren und die Korrektheit des Ausführungs-Traces beweisen. Im Kontext von ML kann man entweder einen benutzerdefinierten STARK für das neuronale Netzwerk erstellen oder eine allgemeine STARK-VM verwenden, um den Modellcode auszuführen.

Allgemeine STARK-VMs (RISC Zero, Cairo): Ein unkomplizierter Ansatz ist, Inferenzcode zu schreiben und ihn in einer STARK-VM auszuführen. Zum Beispiel bietet Risc0 eine RISC-V-Umgebung, in der jeder Code (z. B. eine C++- oder Rust-Implementierung eines neuronalen Netzwerks) ausgeführt und über einen STARK bewiesen werden kann. Ähnlich kann StarkWares Cairo-Sprache beliebige Berechnungen (wie eine LSTM- oder CNN-Inferenz) ausdrücken, die dann vom StarkNet STARK-Prover bewiesen werden. Der Vorteil ist die Flexibilität – man muss keine benutzerdefinierten Schaltkreise für jedes Modell entwerfen. Frühe Benchmarks zeigten jedoch, dass naive STARK-VMs im Vergleich zu optimierten SNARK-Schaltkreisen für ML langsamer waren. In einem Test war ein Halo2-basierter Beweis (Ezkl) etwa 3-mal schneller als ein STARK-basierter Ansatz auf Cairo und sogar 66-mal schneller als eine RISC-V STARK-VM bei einem bestimmten Benchmark im Jahr 2024. Diese Lücke ist auf den Overhead der Simulation jeder Low-Level-Anweisung in einem STARK und die größeren Konstanten in STARK-Beweisen zurückzuführen (Hashing ist schnell, aber man braucht viel davon; STARK-Beweisgrößen sind größer usw.). STARK-VMs verbessern sich jedoch und bieten den Vorteil eines transparenten Setups (kein Trusted Setup) und Post-Quanten-Sicherheit. Mit fortschreitender STARK-freundlicher Hardware und Protokollen werden sich die Proving-Geschwindigkeiten verbessern.

DeepProves Ansatz vs. STARK: Interessanterweise liefert DeepProves Verwendung von GKR und Sum-Check einen Beweis, der im Geiste eher einem STARK ähnelt – es ist ein interaktiver, Hash-basierter Beweis, der keine strukturierte Referenzzeichenfolge benötigt. Der Kompromiss ist, dass seine Beweise größer und die Verifizierung aufwendiger ist als bei einem SNARK. Dennoch zeigt DeepProve, dass ein sorgfältiges Protokolldesign (spezialisiert auf die geschichtete Struktur von ML) sowohl generische STARK-VMs als auch SNARK-Schaltkreise in der Proving-Zeit deutlich übertreffen kann. Wir können DeepProve als einen maßgeschneiderten STARK-ähnlichen zkML-Prover betrachten (obwohl sie den Begriff zkSNARK für Prägnanz verwenden, hat er nicht die kleine konstante Verifizierungsgröße eines traditionellen SNARK, da 0,5s Verifizierung größer ist als die typische SNARK-Verifizierung). Traditionelle STARK-Beweise (wie die von StarkNet) erfordern oft Zehntausende von Feldoperationen zur Verifizierung, während SNARKs vielleicht nur wenige Dutzend verifizieren. Somit ist ein Kompromiss offensichtlich: SNARKs liefern kleinere Beweise und schnellere Verifizierer, während STARKs (oder GKR) eine einfachere Skalierung und kein Trusted Setup auf Kosten der Beweisgröße und Verifizierungsgeschwindigkeit bieten.

Aufkommende Verbesserungen: Die JOLT zkVM (zuvor unter JOLTx besprochen) gibt tatsächlich SNARKs aus (unter Verwendung von PLONKish-Commitments), verkörpert aber Ideen, die auch im STARK-Kontext angewendet werden könnten (Lasso-Lookups könnten theoretisch mit FRI-Commitments verwendet werden). StarkWare und andere erforschen Wege, die Beweiserstellung gängiger Operationen zu beschleunigen (z. B. die Verwendung von Custom Gates oder Hints in Cairo für Big-Int-Operationen usw.). Es gibt auch Circomlib-ML von Privacy&Scaling Explorations (PSE), das Circom-Templates für CNN-Schichten usw. bereitstellt – das ist SNARK-orientiert, aber konzeptionell ähnliche Templates könnten für STARK-Sprachen erstellt werden.

In der Praxis umfassen Nicht-Ethereum-Ökosysteme, die STARKs nutzen, StarkNet (das eine On-Chain-Verifizierung von ML ermöglichen könnte, wenn jemand einen Verifizierer schreibt, obwohl die Kosten hoch sind) und den Bonsai-Dienst von Risc0 (ein Off-Chain-Proving-Dienst, der STARK-Beweise ausgibt, die auf verschiedenen Chains verifiziert werden können). Ab 2025 haben die meisten zkML-Demos auf der Blockchain SNARKs bevorzugt (aufgrund der Verifizierereffizienz), aber STARK-Ansätze bleiben attraktiv wegen ihrer Transparenz und ihres Potenzials in Hochsicherheits- oder quantenresistenten Umgebungen. Zum Beispiel könnte ein dezentrales Computernetzwerk STARKs verwenden, um jedem die Verifizierung der Arbeit ohne Trusted Setup zu ermöglichen, was für die Langlebigkeit nützlich ist. Auch könnten einige spezialisierte ML-Aufgaben STARK-freundliche Strukturen nutzen: z. B. Berechnungen, die stark XOR-/Bit-Operationen verwenden, könnten in STARKs (da diese in der Booleschen Algebra und beim Hashing günstig sind) schneller sein als in der SNARK-Feldarithmetik.

Zusammenfassung von SNARK vs. STARK für ML:

• Leistung: SNARKs (wie Halo2) haben einen enormen Prover-Overhead pro Gate, profitieren aber von leistungsstarken Optimierungen und kleinen Konstanten für die Verifizierung; STARKs (generisch) haben einen größeren konstanten Overhead, skalieren aber linearer und vermeiden teure Kryptografie wie Pairings. DeepProve zeigt, dass die Anpassung des Ansatzes (Sum-Check) eine nahezu lineare Proving-Zeit (schnell) mit einem STARK-ähnlichen Beweis ergibt. JOLT zeigt, dass selbst eine allgemeine VM durch intensive Nutzung von Lookups schneller gemacht werden kann. Empirisch gesehen, für Modelle bis zu Millionen von Operationen: Ein gut optimierter SNARK (Ezkl) kann dies bewältigen, benötigt aber möglicherweise Dutzende von Minuten, während DeepProve (GKR) dies in Sekunden erledigen kann. STARK-VMs waren 2024 wahrscheinlich dazwischen oder schlechter als SNARKs, es sei denn, sie waren spezialisiert (Risc0 war in Tests langsamer, Cairo war ohne benutzerdefinierte Hints langsamer).
• Verifizierung: SNARK-Beweise verifizieren am schnellsten (Millisekunden, und minimale Daten On-Chain ~ einige Hundert Byte bis wenige KB). STARK-Beweise sind größer (Dutzende von KB) und benötigen aufgrund vieler Hashing-Schritte länger (Zehntausende von ms bis Sekunden) zur Verifizierung. In Blockchain-Begriffen könnte eine SNARK-Verifizierung z. B. ~200k Gas kosten, während eine STARK-Verifizierung Millionen von Gas kosten könnte – oft zu hoch für L1, akzeptabel auf L2 oder mit prägnanten Verifizierungsschemata.
• Setup und Sicherheit: SNARKs wie Groth16 erfordern ein Trusted Setup pro Schaltkreis (unfreundlich für beliebige Modelle), aber universelle SNARKs (PLONK, Halo2) haben ein einmaliges Setup, das für jeden Schaltkreis bis zu einer bestimmten Größe wiederverwendet werden kann. STARKs benötigen kein Setup und verwenden nur Hash-Annahmen (plus klassische Polynomkomplexitätsannahmen) und sind post-quantensicher. Dies macht STARKs attraktiv für die Langlebigkeit – Beweise bleiben sicher, selbst wenn Quantencomputer auftauchen, während aktuelle SNARKs (BLS12-381-basiert) durch Quantenangriffe gebrochen würden.

Wir werden diese Unterschiede in Kürze in einer Vergleichstabelle zusammenfassen.

FHE für ML (FHE-o-ML): Private Berechnung vs. verifizierbare Berechnung​

Vollständig Homomorphe Verschlüsselung (FHE) ist eine kryptografische Technik, die es ermöglicht, Berechnungen direkt auf verschlüsselten Daten durchzuführen. Im Kontext von ML kann FHE eine Form der datenschutzfreundlichen Inferenz ermöglichen: Zum Beispiel kann ein Client verschlüsselte Eingaben an einen Modell-Host senden, der Host führt das neuronale Netzwerk auf dem Chiffretext aus, ohne ihn zu entschlüsseln, und sendet ein verschlüsseltes Ergebnis zurück, das der Client entschlüsseln kann. Dies gewährleistet die Datenvertraulichkeit – der Modelleigentümer erfährt nichts über die Eingabe (und potenziell erfährt der Client nur die Ausgabe, nicht die internen Details des Modells, wenn er nur die Ausgabe erhält). FHE allein erzeugt jedoch keinen Korrektheitsbeweis auf die gleiche Weise wie ZKPs. Der Client muss darauf vertrauen, dass der Modelleigentümer die Berechnung tatsächlich ehrlich durchgeführt hat (der Chiffretext könnte manipuliert worden sein). Normalerweise, wenn der Client das Modell hat oder eine bestimmte Verteilung der Ausgaben erwartet, kann offensichtlicher Betrug erkannt werden, aber subtile Fehler oder die Verwendung einer falschen Modellversion wären allein aus der verschlüsselten Ausgabe nicht ersichtlich.

Kompromisse bei der Leistung: FHE ist bekanntermaßen rechenintensiv. Die Ausführung von Deep-Learning-Inferenzen unter FHE führt zu Verlangsamungen um Größenordnungen. Frühe Experimente (z. B. CryptoNets im Jahr 2016) benötigten Dutzende von Sekunden, um ein winziges CNN auf verschlüsselten Daten zu evaluieren. Bis 2024 haben Verbesserungen wie CKKS (für ungefähre Arithmetik) und bessere Bibliotheken (Microsoft SEAL, Zamas Concrete) diesen Overhead reduziert, er bleibt jedoch groß. Zum Beispiel berichtete ein Benutzer, dass die Verwendung von Zamas Concrete-ML zur Ausführung eines CIFAR-10-Klassifikators 25–30 Minuten pro Inferenz auf seiner Hardware dauerte. Nach Optimierungen erreichte Zamas Team ~40 Sekunden für diese Inferenz auf einem 192-Core-Server. Selbst 40s sind extrem langsam im Vergleich zu einer Klartext-Inferenz (die vielleicht 0,01s dauert), was einen Overhead von ~$10^3$–$10^4\times$ zeigt. Größere Modelle oder höhere Präzision erhöhen die Kosten weiter. Zusätzlich verbrauchen FHE-Operationen viel Speicher und erfordern gelegentliches Bootstrapping (einen Rauschunterdrückungsschritt), was rechenintensiv ist. Zusammenfassend lässt sich sagen, dass Skalierbarkeit ein großes Problem ist – modernste FHE könnte ein kleines CNN oder eine einfache logistische Regression bewältigen, aber die Skalierung auf große CNNs oder Transformer liegt jenseits der aktuellen praktischen Grenzen.

Datenschutzvorteile: Der große Reiz von FHE ist der Datenschutz. Die Eingabe kann während des gesamten Prozesses vollständig verschlüsselt bleiben. Das bedeutet, dass ein nicht vertrauenswürdiger Server auf den privaten Daten eines Clients rechnen kann, ohne etwas darüber zu erfahren. Umgekehrt könnte man, wenn das Modell sensibel (proprietär) ist, die Modellparameter verschlüsseln und den Client die FHE-Inferenz auf seiner Seite durchführen lassen – dies ist jedoch weniger verbreitet, da der Client, wenn er die aufwendige FHE-Berechnung durchführen muss, die Idee der Auslagerung an einen leistungsstarken Server zunichtemacht. Typischerweise ist das Modell öffentlich oder wird vom Server im Klartext gehalten, und die Daten werden mit dem Schlüssel des Clients verschlüsselt. Der Modellschutz ist in diesem Szenario standardmäßig nicht gegeben (der Server kennt das Modell; der Client erfährt Ausgaben, aber nicht die Gewichte). Es gibt exotischere Setups (wie sichere Zwei-Parteien-Berechnung oder Multi-Key-FHE), bei denen sowohl Modell als auch Daten voneinander privat gehalten werden können, aber diese verursachen noch mehr Komplexität. Im Gegensatz dazu kann zkML über ZKPs Modellschutz und Datenschutz gleichzeitig gewährleisten – der Prover kann sowohl das Modell als auch die Daten als geheime Zeugen haben und dem Verifizierer nur das Notwendige offenbaren.

Keine On-Chain-Verifizierung erforderlich (und keine möglich): Bei FHE wird das Ergebnis verschlüsselt an den Client übermittelt. Der Client entschlüsselt es dann, um die tatsächliche Vorhersage zu erhalten. Wenn wir dieses Ergebnis On-Chain verwenden wollen, müsste der Client (oder wer auch immer den Entschlüsselungsschlüssel besitzt) das Klartext-Ergebnis veröffentlichen und andere davon überzeugen, dass es korrekt ist. Aber an diesem Punkt ist Vertrauen wieder im Spiel – es sei denn, es wird mit einem ZKP kombiniert. Im Prinzip könnte man FHE und ZKP kombinieren: z. B. FHE verwenden, um Daten während der Berechnung privat zu halten, und dann einen ZK-Beweis generieren, dass das Klartext-Ergebnis einer korrekten Berechnung entspricht. Die Kombination beider bedeutet jedoch, dass man die Leistungsstrafe von FHE und ZKP zahlt – extrem unpraktisch mit der heutigen Technologie. In der Praxis dienen FHE-of-ML und zkML also unterschiedlichen Anwendungsfällen:

• FHE-of-ML: Ideal, wenn das Ziel die Vertraulichkeit zwischen zwei Parteien (Client und Server) ist. Zum Beispiel kann ein Cloud-Dienst ein ML-Modell hosten, und Benutzer können es mit ihren sensiblen Daten abfragen, ohne die Daten der Cloud preiszugeben (und wenn das Modell sensibel ist, es vielleicht über FHE-freundliche Kodierungen bereitstellen). Dies ist großartig für datenschutzfreundliche ML-Dienste (medizinische Vorhersagen usw.). Der Benutzer muss dem Dienst immer noch vertrauen, dass er das Modell getreu ausführt (da kein Beweis vorliegt), aber zumindest wird jegliches Datenleck verhindert. Einige Projekte wie Zama erforschen sogar eine „FHE-fähige EVM (fhEVM)“, bei der Smart Contracts auf verschlüsselten Eingaben operieren könnten, aber die Verifizierung dieser Berechnungen On-Chain würde erfordern, dass der Vertrag die korrekte Berechnung irgendwie durchsetzt – eine offene Herausforderung, die wahrscheinlich ZK-Beweise oder spezialisierte sichere Hardware erfordert.
• zkML (ZKPs): Ideal, wenn das Ziel Verifizierbarkeit und öffentliche Auditierbarkeit ist. Wenn Sie sicherstellen möchten, dass „Modell $M$ korrekt auf $X$ evaluiert wurde und $Y$ erzeugte“, sind ZKPs die Lösung. Sie bieten auch Datenschutz als Bonus (Sie können $X$ oder $Y$ oder $M$ bei Bedarf verbergen, indem Sie sie als private Eingaben für den Beweis behandeln), aber ihr Hauptmerkmal ist der Beweis der korrekten Ausführung.

Eine komplementäre Beziehung: Es ist erwähnenswert, dass ZKPs den Verifizierer schützen (sie erfahren nichts über Geheimnisse, nur dass die Berechnung korrekt durchgeführt wurde), während FHE die Daten des Provers vor der rechnenden Partei schützt. In einigen Szenarien könnten diese kombiniert werden – zum Beispiel könnte ein Netzwerk nicht vertrauenswürdiger Knoten FHE verwenden, um auf den privaten Daten der Benutzer zu rechnen und dann ZK-Beweise an die Benutzer (oder Blockchain) liefern, dass die Berechnungen gemäß dem Protokoll durchgeführt wurden. Dies würde sowohl Datenschutz als auch Korrektheit abdecken, aber die Leistungskosten sind mit den heutigen Algorithmen enorm. Kurzfristig praktikabler sind Hybride wie Trusted Execution Environments (TEE) plus ZKP oder Funktionale Verschlüsselung plus ZKP – diese liegen außerhalb unseres Rahmens, zielen aber darauf ab, etwas Ähnliches zu bieten (TEEs halten Daten/Modell während der Berechnung geheim, dann kann ein ZKP bestätigen, dass das TEE das Richtige getan hat).

Zusammenfassend lässt sich sagen, dass FHE-of-ML die Vertraulichkeit von Eingaben/Ausgaben priorisiert, während zkML die verifizierbare Korrektheit (mit möglicher Privatsphäre) priorisiert. Tabelle 1 unten vergleicht die wichtigsten Eigenschaften:

Tabelle 1: Vergleich von zk-SNARK-, zk-STARK- und FHE-Ansätzen für maschinelles Lernen (Leistungs- und Datenschutzkompromisse).

Anwendungsfälle und Implikationen für Web3-Anwendungen​

Die Konvergenz von KI und Blockchain über zkML erschließt leistungsstarke neue Anwendungsmuster in Web3:

• Dezentrale autonome Agenten & On-Chain-Entscheidungsfindung: Smart Contracts oder DAOs können KI-gesteuerte Entscheidungen mit Korrektheitsgarantien integrieren. Stellen Sie sich zum Beispiel eine DAO vor, die ein neuronales Netzwerk verwendet, um Marktbedingungen zu analysieren, bevor sie Trades ausführt. Mit zkML kann der Smart Contract der DAO einen zkSNARK-Beweis verlangen, dass das autorisierte ML-Modell (mit einem bekannten Hash-Commitment) auf den neuesten Daten ausgeführt wurde und die empfohlene Aktion erzeugte, bevor die Aktion akzeptiert wird. Dies verhindert, dass böswillige Akteure eine gefälschte Vorhersage einschleusen – die Kette verifiziert die KI-Berechnung. Im Laufe der Zeit könnten sogar vollständig On-Chain autonome Agenten (Contracts, die Off-Chain-KI abfragen oder vereinfachte Modelle enthalten) Entscheidungen in DeFi oder Spielen treffen, wobei alle ihre Schritte über zk-Beweise als korrekt und richtlinienkonform nachgewiesen werden. Dies erhöht das Vertrauen in autonome Agenten, da ihr „Denken“ transparent und verifizierbar ist und nicht als Black-Box fungiert.

• Verifizierbare Computemärkte: Projekte wie Lagrange schaffen effektiv verifizierbare Berechnungsmarktplätze – Entwickler können aufwendige ML-Inferenzen an ein Netzwerk von Provern auslagern und erhalten einen Beweis mit dem Ergebnis zurück. Dies ist vergleichbar mit dezentralem Cloud Computing, aber mit integriertem Vertrauen: Sie müssen dem Server nicht vertrauen, nur dem Beweis. Es ist ein Paradigmenwechsel für Orakel und Off-Chain-Berechnungen. Protokolle wie Ethereums kommender DSC (dezentraler Sequencing Layer) oder Orakelnetzwerke könnten dies nutzen, um Daten-Feeds oder Analyse-Feeds mit kryptografischen Garantien bereitzustellen. Zum Beispiel könnte ein Orakel „das Ergebnis von Modell X auf Eingabe Y“ liefern, und jeder kann den beigefügten Beweis On-Chain verifizieren, anstatt dem Wort des Orakels zu vertrauen. Dies könnte verifizierbare KI-as-a-Service auf der Blockchain ermöglichen: Jeder Vertrag kann eine Berechnung anfordern (wie „bewerten Sie diese Kreditrisiken mit meinem privaten Modell“) und die Antwort nur mit einem gültigen Beweis akzeptieren. Projekte wie Gensyn erforschen dezentrale Trainings- und Inferenzmarktplätze unter Verwendung dieser Verifizierungstechniken.

• NFTs und Gaming – Provenienz und Evolution: In Blockchain-Spielen oder NFT-Sammlerstücken kann zkML beweisen, dass Merkmale oder Spielzüge von legitimen KI-Modellen generiert wurden. Zum Beispiel könnte ein Spiel einer KI erlauben, die Attribute eines NFT-Haustiers zu entwickeln. Ohne ZK könnte ein cleverer Benutzer die KI oder das Ergebnis manipulieren, um ein überlegenes Haustier zu erhalten. Mit zkML kann das Spiel einen Beweis verlangen, dass „die neuen Werte des Haustiers vom offiziellen Evolutionsmodell auf den alten Werten des Haustiers berechnet wurden“, wodurch Betrug verhindert wird. Ähnlich bei generativen Kunst-NFTs: Ein Künstler könnte ein generatives Modell als Commitment veröffentlichen; später, beim Minten von NFTs, beweisen, dass jedes Bild von diesem Modell mit einem bestimmten Seed erzeugt wurde, wodurch die Authentizität garantiert wird (und dies sogar, ohne das genaue Modell der Öffentlichkeit preiszugeben, wodurch das geistige Eigentum des Künstlers geschützt wird). Diese Provenienzverifizierung gewährleistet Authentizität auf eine Weise, die der verifizierbaren Zufälligkeit ähnelt – nur hier ist es verifizierbare Kreativität.

• Datenschutzfreundliche KI in sensiblen Bereichen: zkML ermöglicht die Bestätigung von Ergebnissen, ohne Eingaben preiszugeben. Im Gesundheitswesen könnten Patientendaten von einem Cloud-Anbieter durch ein KI-Diagnosemodell laufen; das Krankenhaus erhält eine Diagnose und einen Beweis, dass das Modell (das privat von einem Pharmaunternehmen gehalten werden könnte) korrekt auf den Patientendaten ausgeführt wurde. Die Patientendaten bleiben privat (nur eine verschlüsselte oder committed Form wurde im Beweis verwendet), und die Modellgewichte bleiben proprietär – dennoch ist das Ergebnis vertrauenswürdig. Regulierungsbehörden oder Versicherungen könnten auch überprüfen, dass nur genehmigte Modelle verwendet wurden. Im Finanzwesen könnte ein Unternehmen einem Auditor oder einer Regulierungsbehörde beweisen, dass sein Risikomodell auf seine internen Daten angewendet wurde und bestimmte Metriken erzeugte, ohne die zugrunde liegenden sensiblen Finanzdaten preiszugeben. Dies ermöglicht Compliance und Aufsicht mit kryptografischen Zusicherungen anstelle von manuellem Vertrauen.

• Cross-Chain- und Off-Chain-Interoperabilität: Da Zero-Knowledge-Beweise grundsätzlich portabel sind, kann zkML Cross-Chain-KI-Ergebnisse erleichtern. Eine Kette könnte eine KI-intensive Anwendung Off-Chain ausführen; sie kann einen Beweis des Ergebnisses an eine andere Blockchain senden, die ihn vertrauenslos akzeptiert. Betrachten Sie zum Beispiel eine Multi-Chain-DAO, die eine KI verwendet, um Stimmungen in sozialen Medien zu aggregieren (Off-Chain-Daten). Die KI-Analyse (komplexes NLP auf großen Datenmengen) wird Off-Chain von einem Dienst durchgeführt, der dann einen Beweis an eine kleine Blockchain (oder mehrere Chains) sendet, dass „die Analyse korrekt durchgeführt wurde und der Stimmungs-Score = 0,85 ergab“. Alle Chains können dieses Ergebnis in ihrer Governance-Logik verifizieren und verwenden, ohne dass jede die Analyse erneut durchführen muss. Diese Art der interoperablen verifizierbaren Berechnung ist das, was Lagranges Netzwerk unterstützen will, indem es mehrere Rollups oder L1s gleichzeitig bedient. Es beseitigt die Notwendigkeit von Trusted Bridges oder Orakel-Annahmen beim Verschieben von Ergebnissen zwischen Chains.

• KI-Ausrichtung und Governance: Aus einer zukunftsorientierteren Perspektive wurde zkML als Werkzeug für KI-Governance und -Sicherheit hervorgehoben. Lagranges Vision Statements argumentieren beispielsweise, dass mit zunehmender Leistungsfähigkeit von KI-Systemen (sogar superintelligenten) kryptografische Verifizierung unerlässlich sein wird, um sicherzustellen, dass sie vereinbarten Regeln folgen. Indem KI-Modelle Beweise für ihre Argumentation oder Constraints erbringen müssen, behalten Menschen ein gewisses Maß an Kontrolle – „man kann nicht vertrauen, was man nicht verifizieren kann“. Obwohl dies spekulativ ist und sowohl soziale als auch technische Aspekte umfasst, könnte die Technologie durchsetzen, dass ein autonom agierender KI-Agent immer noch beweist, dass er ein genehmigtes Modell verwendet und nicht manipuliert wurde. Dezentrale KI-Netzwerke könnten On-Chain-Beweise verwenden, um Beiträge zu verifizieren (z. B. kann ein Netzwerk von Knoten, die gemeinsam ein Modell trainieren, beweisen, dass jedes Update getreu berechnet wurde). Somit könnte zkML eine Rolle dabei spielen, sicherzustellen, dass KI-Systeme gegenüber menschlich definierten Protokollen rechenschaftspflichtig bleiben, selbst in dezentralen oder unkontrollierten Umgebungen.

Zusammenfassend lässt sich sagen, dass zkML und verifizierbare On-Chain-KI eine Konvergenz von fortschrittlicher Kryptografie und maschinellem Lernen darstellen, die das Vertrauen, die Transparenz und den Datenschutz in KI-Anwendungen verbessern wird. Durch den Vergleich der wichtigsten Ansätze – zk-SNARKs, zk-STARKs und FHE – sehen wir ein Spektrum von Kompromissen zwischen Leistung und Datenschutz, die jeweils für unterschiedliche Szenarien geeignet sind. SNARK-basierte Frameworks wie Ezkl und Innovationen wie Lagranges DeepProve haben es ermöglicht, substanzielle neuronale Netzwerk-Inferenzen mit praktischem Aufwand zu beweisen, was die Tür für reale Implementierungen verifizierbarer KI öffnet. STARK-basierte und VM-basierte Ansätze versprechen größere Flexibilität und Post-Quanten-Sicherheit, was mit der Reifung des Feldes wichtig werden wird. FHE, obwohl keine Lösung für die Verifizierbarkeit, adressiert den komplementären Bedarf an vertraulicher ML-Berechnung und kann in Kombination mit ZKPs oder in spezifischen privaten Kontexten Benutzer befähigen, KI zu nutzen, ohne den Datenschutz zu opfern.

Die Implikationen für Web3 sind erheblich: Wir können Smart Contracts erwarten, die auf KI-Vorhersagen reagieren, wissend, dass diese korrekt sind; Märkte für Berechnungen, auf denen Ergebnisse vertrauenslos verkauft werden; digitale Identitäten (wie Worldcoins Proof-of-Personhood über Iris-KI), die durch zkML geschützt sind, um zu bestätigen, dass jemand ein Mensch ist, ohne sein biometrisches Bild preiszugeben; und generell eine neue Klasse von „nachweisbarer Intelligenz“, die Blockchain-Anwendungen bereichert. Viele Herausforderungen bleiben bestehen – Leistung für sehr große Modelle, Entwicklerergonomie und der Bedarf an spezialisierter Hardware –, aber die Richtung ist klar. Wie ein Bericht feststellte, „können die heutigen ZKPs kleine Modelle unterstützen, aber mittlere bis große Modelle sprengen das Paradigma“; jedoch verschieben schnelle Fortschritte (50- bis 150-fache Beschleunigungen mit DeepProve gegenüber dem Stand der Technik) diese Grenze nach außen. Mit fortlaufender Forschung (z. B. zur Hardwarebeschleunigung und verteilten Beweiserstellung) können wir erwarten, dass zunehmend größere und komplexere KI-Modelle beweisbar werden. zkML könnte sich bald von Nischen-Demos zu einer wesentlichen Komponente vertrauenswürdiger KI-Infrastruktur entwickeln und sicherstellen, dass KI, wenn sie allgegenwärtig wird, dies auf eine Weise tut, die prüfbar, dezentralisiert und auf den Datenschutz und die Sicherheit der Benutzer ausgerichtet ist.