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 hinsichtlich Vertraulichkeit und Integrität schützt. Praktisch gesehen fungiert eine TEE als isolierte „Enklave“ innerhalb der CPU – eine Art Black Box, in der sensible Berechnungen abgeschirmt vom restlichen System ausgeführt werden können. Code, der innerhalb einer TEE-Enklave läuft, ist so geschützt, dass selbst ein kompromittiertes Betriebssystem oder ein Hypervisor die Daten oder den Code der Enklave nicht lesen oder manipulieren kann. Zu den wichtigsten Sicherheitsmerkmalen von TEEs gehören:

• Isolation: Der Speicher der Enklave ist von anderen Prozessen und sogar vom OS-Kernel isoliert. Selbst wenn ein Angreifer volle Administratorrechte auf der Maschine erlangt, kann er den Enklavenspeicher 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 Laufzeitzustands wird erkannt, wodurch kompromittierte Ergebnisse verhindert werden.
• Vertraulichkeit: Daten innerhalb der Enklave bleiben im Speicher verschlüsselt und werden nur zur Verwendung innerhalb der CPU entschlüsselt, sodass geheime Daten nicht im Klartext an die Außenwelt gelangen.
• Remote Attestierung: Die TEE kann kryptografische Nachweise (Attestierungen) erbringen, 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. erwarteten Code auf echter Hardware ausführt), bevor sie sie mit geheimen Daten versorgen.

Konzeptdiagramm einer Trusted Execution Environment als sichere Enklaven-„Black Box“ für die Ausführung von Smart Contracts. Verschlüsselte Eingaben (Daten und Vertrags-Code) 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 alle außerhalb der TEE vertraulich bleiben.

Im Hintergrund 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 (in die Hardware eingebrannt oder von einem sicheren Co-Prozessor verwaltet), um Daten im laufenden Betrieb zu verschlüsseln/entschlüsseln. Jeder Versuch externer Software, den Enklavenspeicher zu lesen, erhält nur verschlüsselte Bytes. Dieser einzigartige Schutz auf CPU-Ebene ermöglicht es selbst Code auf Benutzerebene, private Speicherbereiche (Enklaven) zu definieren, die privilegierte Malware oder sogar ein bösartiger Systemadministrator nicht ausspionieren 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 sichere Elemente oder Hardware-Sicherheitsmodule.

Wichtige Hardware-Implementierungen: Es gibt mehrere Hardware-TEE-Technologien, jede mit unterschiedlichen Architekturen, aber einem ä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 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 und aus der Enklave zu übertragen. SGX bietet eine starke Isolation für Enklaven und unterstützt die Remote-Attestierung über den Attestation Service (IAS) von Intel. Viele Blockchain-Projekte – insbesondere Secret Network und Oasis Network – bauten datenschutzfreundliche Smart-Contract-Funktionalitäten auf SGX-Enklaven auf. 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 Speicher und Peripheriegeräte hat, während die Normal World das reguläre Betriebssystem und Anwendungen ausführt. Der Wechsel zwischen den Welten wird 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. Im 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 können. TrustZone-Enklaven sind jedoch typischerweise grobkörniger (auf OS- oder VM-Ebene) und in aktuellen Web3-Projekten nicht so weit verbreitet 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, um kryptografische Schlüssel zu verwalten und Speicherverschlüsselung durchzuführen, sodass der Speicher einer VM selbst für den Host-Hypervisor vertraulich bleibt. Dies macht SEV gut geeignet für Cloud- oder Server-Anwendungsfälle: Zum Beispiel könnte ein Blockchain-Node oder ein Off-Chain-Worker innerhalb einer vollständig verschlüsselten VM laufen und seine Daten vor einem bösartigen Cloud-Anbieter schützen. Das Design von SEV bedeutet weniger Entwicklungsaufwand für die Code-Partitionierung (Sie können 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 sich auf einen zentralisierten Dienst verlassen zu müssen. SEV ist hochrelevant für den TEE-Einsatz in Cloud-basierter Blockchain-Infrastruktur.

Weitere 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 sichere Enklaven-Chips in Mobilgeräten (wie Apples Secure Enclave, obwohl diese typischerweise nicht für beliebigen Code offen sind). Jede TEE hat ihr eigenes Entwicklungsmodell und ihre eigenen Vertrauensannahmen, aber alle teilen die Kernidee der hardware-isolierten sicheren Ausführung.

2. Anwendungen von TEEs in Web3​

Trusted Execution Environments sind zu einem leistungsstarken Werkzeug geworden, um einige der größten Herausforderungen von Web3 zu bewältigen. Durch die Bereitstellung einer sicheren, privaten Berechnungsebene ermöglichen TEEs neue Möglichkeiten für Blockchain-Anwendungen in den Bereichen Datenschutz, Skalierbarkeit, Oracle-Sicherheit und Integrität. Im Folgenden untersuchen wir die wichtigsten Anwendungsbereiche:

Datenschutzfreundliche Smart Contracts​

Eine der prominentesten 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 Finanztransaktionen, geheime Abstimmungen, Verarbeitung personenbezogener Daten). TEEs bieten eine Lösung, indem sie als datenschutzfreundliche 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, innerhalb der Enklave verarbeitet werden, wo sie für die Außenwelt verschlüsselt bleiben, und dann kann die Enklave ein verschlüsseltes oder gehashtes Ergebnis zurück an die Kette ausgeben. Nur autorisierte Parteien mit dem Entschlüsselungsschlüssel (oder die Vertragslogik selbst) können auf das Klartext-Ergebnis zugreifen. Zum Beispiel verwendet das Secret Network Intel SGX in seinen Konsens-Nodes, um CosmWasm-Smart Contracts auf verschlüsselten Eingaben auszuführen, sodass Dinge wie Kontostände, Transaktionsbeträge oder der Vertragsstatus vor der Öffentlichkeit verborgen bleiben können, während sie dennoch in Berechnungen nutzbar sind. Dies hat geheime DeFi-Anwendungen ermöglicht – z. B. private Token-Swaps, bei denen die Beträge vertraulich sind, oder geheime Auktionen, bei denen Gebote verschlüsselt sind und erst nach Auktionsende offengelegt werden. Ein weiteres Beispiel ist Oasis Networks Parcel und vertrauliches ParaTime, das die Tokenisierung von Daten und deren Verwendung in Smart Contracts unter Vertraulichkeitsbeschränkungen ermöglicht, wodurch Anwendungsfälle wie Kredit-Scoring oder medizinische Daten auf der Blockchain mit Datenschutz-Compliance ermöglicht werden.

Datenschutzfreundliche Smart Contracts über 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 halten. Zum Beispiel könnte eine Bank einen TEE-fähigen Vertrag verwenden, um Kreditanträge oder Handelsabrechnungen abzuwickeln, 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 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, wobei nur verschlüsselte Ausgaben die Enklave verlassen, was den Aufsichtsbehörden die Gewissheit gibt, dass Daten geschützt sind.

Über die Vertraulichkeit hinaus tragen TEEs auch dazu bei, die Fairness in Smart Contracts durchzusetzen. Zum Beispiel könnte eine dezentrale Börse ihre Matching-Engine innerhalb einer TEE betreiben, um zu verhindern, dass Miner oder Validatoren ausstehende Aufträge sehen und Trades unfair vorwegnehmen (Front-Running). Zusammenfassend bringen TEEs eine dringend benötigte Datenschutzschicht in Web3 und ermöglichen Anwendungen wie vertrauliches DeFi, private Abstimmungen/Governance und Unternehmensverträge, die zuvor auf öffentlichen Ledgern undurchführbar waren.

Skalierbarkeit und Off-Chain-Berechnung​

Eine weitere entscheidende Rolle von TEEs ist die Verbesserung der Blockchain-Skalierbarkeit, indem rechenintensive Aufgaben Off-Chain in eine sichere Umgebung ausgelagert werden. Blockchains kämpfen mit komplexen oder rechenintensiven Aufgaben aufgrund von Leistungsgrenzen und Kosten der On-Chain-Ausführung. TEE-fähige Off-Chain-Berechnungen ermöglichen es, diese Aufgaben außerhalb der Hauptkette durchzuführen (wodurch kein Block-Gas verbraucht oder der On-Chain-Durchsatz verlangsamt wird), während gleichzeitig Vertrauensgarantien hinsichtlich der Korrektheit der Ergebnisse erhalten bleiben. Im Grunde kann eine TEE als verifizierbarer Off-Chain-Rechenbeschleuniger für Web3 dienen.

Zum Beispiel verwendet die iExec-Plattform TEEs, um einen dezentralen Cloud-Computing-Marktplatz zu schaffen, auf dem Entwickler Berechnungen Off-Chain ausführen und Ergebnisse erhalten können, denen die Blockchain vertraut. Eine dApp kann eine Berechnung (z. B. eine komplexe KI-Modellinferenz oder eine Big-Data-Analyse) von iExec-Worker-Nodes anfordern. Diese Worker-Nodes führen die Aufgabe innerhalb einer SGX-Enklave aus und erzeugen ein Ergebnis zusammen mit einer Attestierung, dass der korrekte Code in einer echten Enklave ausgeführt wurde. Das Ergebnis wird dann On-Chain zurückgegeben, und der Smart Contract kann die Attestierung der Enklave überprüfen, bevor er die Ausgabe akzeptiert. Diese Architektur ermöglicht die Verarbeitung hoher Arbeitslasten Off-Chain, ohne das Vertrauen zu opfern, und steigert so effektiv den Durchsatz. Die Integration des iExec Orchestrator mit Chainlink demonstriert dies: Ein Chainlink-Oracle ruft externe Daten ab, übergibt dann eine komplexe Berechnung an die TEE-Worker von iExec (z. B. Aggregation oder Bewertung der Daten), und schließlich wird das sichere Ergebnis On-Chain geliefert. Anwendungsfälle umfassen Dinge wie dezentrale Versicherungsberechnungen (wie iExec demonstrierte), bei denen viele Daten Off-Chain und kostengünstig verarbeitet werden können, wobei nur das Endergebnis an die Blockchain geht.

TEE-basierte Off-Chain-Berechnungen untermauern auch einige Layer-2-Skalierungslösungen. Oasis Labs' früher Prototyp Ekiden (der Vorläufer des Oasis Network) verwendete SGX-Enklaven, um die Transaktionsausführung Off-Chain parallel auszuführen und dann nur Zustands-Roots an die Hauptkette zu übergeben, was effektiv Rollup-Ideen ähnelt, aber Hardware-Vertrauen nutzt. 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 Sanders Networks kommendes Op-Succinct L2, das TEEs und zkSNARKs kombiniert: TEEs führen Transaktionen privat und schnell aus, und dann werden ZK-Proofs generiert, um die Korrektheit dieser Ausführungen gegenüber Ethereum zu beweisen. Dieser hybride Ansatz nutzt die TEE-Geschwindigkeit und die ZK-Verifizierbarkeit 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-Anweisungen verwenden, nur mit Isolation), sodass sie für komplexe Logik um Größenordnungen schneller sind als rein kryptografische Alternativen wie homomorphe Verschlüsselung oder Zero-Knowledge-Proofs. Durch die Auslagerung von Aufgaben an Enklaven können Blockchains komplexere Anwendungen (wie maschinelles Lernen, Bild-/Audioverarbeitung, große Analysen) verarbeiten, die On-Chain unpraktisch wären. Die Ergebnisse werden mit einer Attestierung zurückgegeben, die der On-Chain-Vertrag oder Benutzer als von einer vertrauenswürdigen Enklave stammend verifizieren können, wodurch die Datenintegrität und Korrektheit erhalten bleibt. Dieses Modell wird oft als „verifizierbare Off-Chain-Berechnung“ bezeichnet, und TEEs sind ein Eckpfeiler vieler solcher Designs (z. B. verwendet Hyperledger Avalons Trusted Compute Framework, entwickelt von Intel, iExec und anderen, TEEs, um EVM-Bytecode Off-Chain mit einem On-Chain veröffentlichten Korrektheitsnachweis auszuführen).

Sichere Oracles und Datenintegrität​

Oracles verbinden Blockchains mit realen Daten, führen aber Vertrauensherausforderungen ein: Wie kann ein Smart Contract darauf vertrauen, dass ein Off-Chain-Datenfeed korrekt und unverfälscht ist? TEEs bieten eine Lösung, indem sie als sichere Sandbox für Oracle-Nodes dienen. Ein TEE-basiertes Oracle-Node kann Daten von externen Quellen (APIs, Webdienste) abrufen und diese innerhalb einer Enklave verarbeiten, die garantiert, dass die Daten weder vom Node-Betreiber noch von Malware auf dem Node manipuliert wurden. Die Enklave kann dann die Wahrheit der von ihr 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 die Attestierung der Enklave zu brechen (was die Blockchain erkennen wird).

Ein bemerkenswertes Beispiel ist Town Crier, ein an der Cornell University 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 an einen Vertrag zusammen mit einem Nachweis (einer Enklaven-Signatur), dass die Daten direkt von der Quelle stammten und nicht gefälscht wurden. Chainlink erkannte den Wert dessen 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: Zum Beispiel beinhalten Chainlinks DECO und Fair Sequencing Services TEEs, um Datenvertraulichkeit und faire Reihenfolge sicherzustellen. Wie in einer Analyse festgestellt wurde, „revolutionierte TEE die Oracle-Sicherheit, indem es eine manipulationssichere Umgebung für die Datenverarbeitung bereitstellte... selbst die Node-Betreiber können die Daten während der Verarbeitung nicht manipulieren“. Dies ist besonders entscheidend für hochwertige Finanzdaten-Feeds (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, sensible oder proprietäre Daten zu verarbeiten, die nicht im Klartext auf einer Blockchain veröffentlicht werden könnten. Zum Beispiel könnte ein Oracle-Netzwerk Enklaven verwenden, um private Daten (wie vertrauliche Aktienauftragsbücher oder persönliche Gesundheitsdaten) zu aggregieren und nur abgeleitete Ergebnisse oder validierte Nachweise an die Blockchain zu übermitteln, 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 ist für die Tokenisierung von Real World Assets (RWA), Kredit-Scoring, Versicherungen und andere datenintensive On-Chain-Dienste.

Zum Thema Cross-Chain-Bridges verbessern TEEs ebenfalls die Integrität. Bridges verlassen sich oft auf eine Reihe von Validatoren oder eine Multi-Sig, um Assets zu verwahren und Übertragungen zwischen Ketten 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 vor Manipulationen schützen. Selbst wenn das Betriebssystem eines Validators kompromittiert ist, sollte der Angreifer nicht in der Lage sein, private Schlüssel zu extrahieren oder Nachrichten aus der Enklave zu fälschen. TEEs können erzwingen, dass Bridge-Transaktionen genau gemäß den Protokollregeln verarbeitet werden, wodurch das Risiko verringert wird, dass menschliche Bediener oder Malware betrügerische Übertragungen einschleusen. Darüber hinaus können TEEs atomare Swaps und Cross-Chain-Transaktionen in einer sicheren Enklave ermöglichen, die entweder beide Seiten abschließt oder sauber abbricht, wodurch Szenarien verhindert werden, in denen Gelder aufgrund von Störungen stecken bleiben. Mehrere Bridge-Projekte und Konsortien haben TEE-basierte Sicherheit erforscht, um die Plage der Bridge-Hacks der letzten Jahre zu mildern.

Datenintegrität und Verifizierbarkeit Off-Chain​

In allen 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 Attestierung) und sicherstellen kann, dass der Code ohne Störungen 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, vorausgesetzt, die Attestierung ist korrekt. Diese Integritätsgarantie ist der Grund, warum TEEs manchmal als „Vertrauensanker“ für Off-Chain-Daten und -Berechnungen bezeichnet werden.

Es ist jedoch zu beachten, 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 die Attestierung gefälscht wird, könnte die Integrität fehlschlagen. Dennoch erschweren TEEs (wenn sie auf dem neuesten Stand gehalten werden) in der Praxis bestimmte Angriffe erheblich. Zum Beispiel könnte eine DeFi-Kreditplattform eine TEE verwenden, um Kreditscores aus den privaten Daten eines Benutzers Off-Chain zu berechnen, und der Smart Contract würde den Score nur akzeptieren, wenn er von einer gültigen Enklaven-Attestierung begleitet wird. Auf diese Weise weiß der Vertrag, dass der Score vom genehmigten Algorithmus auf echten Daten berechnet wurde, anstatt dem Benutzer oder einem Oracle blind zu vertrauen.

TEEs spielen auch eine Rolle in aufkommenden dezentralen Identitäts- (DID) und Authentifizierungssystemen. 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 preisgegeben werden. Zum Beispiel könnte eine TEE auf einem mobilen Gerät die biometrische Authentifizierung handhaben und eine Blockchain-Transaktion signieren, wenn die biometrische Überprüfung erfolgreich ist, alles ohne die Biometrie des Benutzers preiszugeben. Dies bietet sowohl Sicherheit als auch Datenschutz im Identitätsmanagement – eine wesentliche Komponente, wenn Web3 Dinge wie Pässe, Zertifikate oder KYC-Daten auf benutzerautonome Weise handhaben soll.

Zusammenfassend dienen TEEs als vielseitiges Werkzeug in Web3: Sie ermöglichen Vertraulichkeit für On-Chain-Logik, erlauben Skalierung durch sichere Off-Chain-Berechnungen, schützen die Integrität von Oracles und Bridges und eröffnen neue Anwendungsbereiche (von privater Identität bis hin zu konformer Datenfreigabe). Als Nächstes werden wir uns spezifische Projekte ansehen, die diese Fähigkeiten nutzen.

3. Bemerkenswerte Web3-Projekte, die TEEs nutzen​

Eine Reihe führender Blockchain-Projekte haben ihre Kernangebote um Trusted Execution Environments herum aufgebaut. Im Folgenden tauchen wir in einige bemerkenswerte ein und untersuchen, wie jedes die TEE-Technologie nutzt und welchen einzigartigen Wert es hinzufügt:

Secret Network​

Secret Network ist eine Layer-1-Blockchain (auf Basis des Cosmos SDK), die Pionierarbeit bei datenschutzfreundlichen Smart Contracts mittels TEEs geleistet hat. Alle Validator-Nodes im Secret Network betreiben Intel SGX-Enklaven, die den Smart-Contract-Code ausführen, sodass der Vertragsstatus sowie Eingaben/Ausgaben selbst für die Node-Betreiber verschlüsselt bleiben. Dies macht Secret zu einer der ersten Privacy-First Smart Contract-Plattformen – Datenschutz ist kein optionales Add-on, sondern eine Standardfunktion des Netzwerks auf Protokollebene.

Im Modell von Secret Network übermitteln Benutzer verschlüsselte Transaktionen, die Validatoren zur Ausführung in ihre SGX-Enklave laden. Die Enklave entschlüsselt die Eingaben, führt den Vertrag (geschrieben in einer modifizierten CosmWasm-Laufzeitumgebung) aus und erzeugt verschlüsselte Ausgaben, die in die Blockchain geschrieben werden. Nur Benutzer mit dem korrekten Viewing Key (oder der Vertrag selbst mit seinem internen Schlüssel) können die tatsächlichen Daten entschlüsseln und einsehen. Dies ermöglicht 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, wodurch Front-Running gemindert und Handelsstrategien geschützt werden. Liquiditätsanbieter und Händler können agieren, ohne jeden ihrer Schritte an Wettbewerber zu senden.
• Geheime Auktionen: Auktionsverträge, bei denen Gebote bis zum Auktionsende geheim gehalten werden, um strategisches Verhalten basierend auf den Geboten anderer zu verhindern.
• Private Abstimmung und Governance: Token-Inhaber können über Vorschläge abstimmen, ohne ihre Stimmabgabe preiszugeben, während die Auszählung weiterhin verifiziert werden kann – was eine faire, einschüchterungsfreie Governance gewährleistet.
• Datenmarktplätze: Sensible Datensätze können transaktiert und in Berechnungen verwendet werden, ohne die Rohdaten Käufern oder Nodes preiszugeben.

Secret Network integriert TEEs im Wesentlichen auf Protokollebene, um ein einzigartiges Wertversprechen zu schaffen: Es bietet programmierbaren Datenschutz. Zu den Herausforderungen, die sie angehen, gehören die Koordination der Enklaven-Attestierung über einen dezentralen Validatoren-Satz hinweg und die Verwaltung der Schlüsselverteilung, damit Verträge Eingaben entschlüsseln können, während sie diese vor Validatoren geheim halten. Nach allen Berichten hat Secret die Machbarkeit TEE-gestützter Vertraulichkeit auf einer öffentlichen Blockchain bewiesen und sich als führend in diesem Bereich etabliert.

Oasis Network​

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

Die Nutzung von TEEs durch Oasis konzentriert sich auf vertrauliche Berechnungen in großem Maßstab. Durch die Isolation der rechenintensiven Aufgaben in parallelisierbaren ParaTimes (die auf vielen Nodes laufen können) erreichen sie einen hohen Durchsatz, und durch die Verwendung von TEEs innerhalb dieser ParaTime-Nodes stellen sie sicher, dass die Berechnungen sensible Daten enthalten können, ohne diese preiszugeben. Zum Beispiel 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 Node verschlüsselt (da sie in der Enklave verarbeitet werden), und nur der Score wird ausgegeben. Währenddessen zeichnet der Oasis-Konsens lediglich den Nachweis auf, dass die Berechnung korrekt erfolgte.

Technisch gesehen hat Oasis zusätzliche Sicherheitsebenen über das reine SGX hinaus hinzugefügt. Sie implementierten einen „geschichteten Vertrauensanker“: unter Verwendung von Intels SGX Quoting Enclave und einem benutzerdefinierten, leichtgewichtigen Kernel, um die Hardware-Vertrauenswürdigkeit zu überprüfen und die Systemaufrufe der Enklave zu isolieren (sandboxing). Dies reduziert die Angriffsfläche (durch Filtern, welche OS-Aufrufe Enklaven tätigen können) und schützt vor bestimmten bekannten SGX-Angriffen. Oasis führte auch Funktionen wie dauerhafte Enklaven (damit Enklaven ihren Zustand über Neustarts hinweg beibehalten können) und sichere Protokollierung ein, um Rollback-Angriffe zu mindern (bei denen ein Node versuchen könnte, einen alten Enklaven-Zustand erneut abzuspielen). Diese Innovationen wurden in ihren technischen Papieren beschrieben und sind ein Grund, warum Oasis als forschungsgetriebenes Projekt im Bereich TEE-basierter Blockchain-Berechnungen angesehen wird.

Aus Ökosystem-Perspektive hat sich Oasis für Dinge wie privates DeFi (das Banken die Teilnahme ermöglicht, ohne Kundendaten preiszugeben) und Datentokenisierung (wo Einzelpersonen oder Unternehmen Daten vertraulich an KI-Modelle weitergeben und über die Blockchain entschädigt werden können) positioniert. Sie haben auch mit Unternehmen an Pilotprojekten zusammengearbeitet (zum Beispiel mit BMW zum Thema Datenschutz und mit anderen zum Austausch 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 wichtigen 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 hochleistungsfähige Rechenservices bereitzustellen. Es ist eine Parachain auf Polkadot, was bedeutet, dass es von Polkadots Sicherheit und Interoperabilität profitiert, aber es führt seine eigene neuartige Laufzeitumgebung für Off-Chain-Berechnungen in sicheren Enklaven ein.

Die Kernidee von Sanders ist es, ein großes Netzwerk von Worker-Nodes (genannt Sanders-Miner) zu unterhalten, die Aufgaben innerhalb von TEEs (bisher speziell Intel SGX) ausführen und verifizierbare Ergebnisse produzieren. Diese Aufgaben können von der Ausführung von Smart-Contract-Segmenten bis hin zu allgemeinen Berechnungen reichen, die von Benutzern angefordert werden. Da die Worker in SGX laufen, stellt Sanders sicher, 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 sie nicht einsehen oder manipulieren kann.

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

• Web3-Analysen und KI: Ein Projekt könnte Benutzerdaten analysieren oder KI-Algorithmen in Sanders-Enklaven ausführen, sodass Rohdaten der Benutzer verschlüsselt bleiben (Datenschutz), während nur aggregierte Erkenntnisse die Enklave verlassen.
• Game-Backends und Metaverse: Sanders kann intensive Spiellogik oder Simulationen virtueller Welten Off-Chain verarbeiten, indem es nur Commitments oder Hashes an die Blockchain sendet, was ein reichhaltigeres Gameplay ohne Vertrauen in einen einzelnen Server ermöglicht.
• On-Chain-Dienste: Sanders hat eine Off-Chain-Berechnungsplattform namens Sanders Cloud aufgebaut. Zum Beispiel kann sie als Backend für Bots, dezentrale Webdienste oder sogar ein Off-Chain-Orderbuch dienen, das Trades mit TEE-Attestierung an einen DEX-Smart Contract veröffentlicht.

Sanders betont, dass es vertrauliche Berechnungen horizontal skalieren kann: Mehr Kapazität benötigt? Fügen Sie weitere TEE-Worker-Nodes hinzu. Dies unterscheidet sich von einer einzelnen Blockchain, bei der die Rechenkapazität durch 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 integriert sich in Polkadots Konsens (z. B. Staking und Slashing für schlechte Ergebnisse) und erforscht sogar eine Kombination von TEE mit Zero-Knowledge-Proofs (wie erwähnt, verwendet ihr kommendes L2 TEE, um die Ausführung zu beschleunigen und ZKP, um sie prägnant auf Ethereum zu verifizieren). Dieser hybride Ansatz hilft, das Risiko einer einzelnen TEE-Kompromittierung zu mindern, indem er kryptografische Verifizierung hinzufügt.

Zusammenfassend nutzt Sanders Network TEEs, um eine dezentrale, vertrauliche Cloud für Web3 bereitzustellen, die Off-Chain-Berechnungen mit Sicherheitsgarantien ermöglicht. Dies eröffnet eine Klasse von Blockchain-Anwendungen, die sowohl hohe Rechenleistung als auch Datenvertraulichkeit benötigen und die Lücke zwischen On-Chain- und Off-Chain-Welten schließen.

iExec​

iExec ist ein dezentraler Marktplatz für Cloud-Computing-Ressourcen, der auf Ethereum aufgebaut ist. Im Gegensatz zu den drei vorherigen (die eigene Chains oder Parachains sind) operiert iExec als Layer-2- oder Off-Chain-Netzwerk, das mit Ethereum-Smart Contracts koordiniert. TEEs (insbesondere Intel SGX) sind ein Eckpfeiler von iExecs Ansatz, Vertrauen in Off-Chain-Berechnungen herzustellen.

Das iExec-Netzwerk besteht aus Worker-Nodes, die von verschiedenen Anbietern bereitgestellt werden. Diese Worker können von Benutzern (dApp-Entwicklern, Datenanbietern usw.) angeforderte Aufgaben ausführen. Um sicherzustellen, dass diese Off-Chain-Berechnungen vertrauenswürdig sind, führte iExec ein Framework namens „Trusted Off-Chain Computing“ ein: 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 Node ausgeführt wurde. iExec hat sich mit Intel zusammengetan, um diese vertrauenswürdige Computing-Funktion einzuführen, und ist sogar dem Confidential Computing Consortium beigetreten, um Standards voranzutreiben. Ihr Konsensprotokoll, genannt 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 kann die Attestierung einer einzelnen Enklave ausreichen, wenn der Code deterministisch ist und das Vertrauen in SGX hoch ist; für eine höhere Sicherheit kann iExec Aufgaben über mehrere TEEs replizieren und einen Konsens oder eine Mehrheitsentscheidung 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-Node könnte Rohdaten abrufen und 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ückzugeben. Dies erweitert die Möglichkeiten von Oracles über das bloße Weiterleiten von Daten hinaus – sie können nun berechnete Dienste (wie das Aufrufen eines KI-Modells oder das Aggregieren vieler Quellen) anbieten, wobei TEE die Ehrlichkeit gewährleistet.
• KI und DePIN (Dezentrales Physisches Infrastrukturnetzwerk): iExec positioniert sich als Vertrauensschicht für dezentrale KI-Anwendungen. Zum Beispiel kann eine dApp, die ein Machine-Learning-Modell verwendet, das Modell in einer Enklave ausführen, um sowohl das Modell (wenn es proprietär ist) als auch die eingegebenen Benutzerdaten zu schützen. Im Kontext von DePIN (wie verteilten IoT-Netzwerken) können TEEs auf Edge-Geräten verwendet werden, um Sensorwerte und Berechnungen auf diesen Werten zu vertrauen.
• Sichere Datenmonetarisierung: Datenanbieter können ihre Datensätze auf dem iExec-Marktplatz in verschlüsselter Form zur Verfügung stellen. Käufer können ihre Algorithmen zur Ausführung auf den Daten innerhalb einer TEE senden (sodass die Rohdaten des Datenanbieters niemals offengelegt werden, ihr geistiges Eigentum geschützt wird und die Details des Algorithmus ebenfalls 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, oft als sicherer Datenaustausch bezeichnet, wird durch die Vertraulichkeit von TEEs ermöglicht.

Insgesamt stellt iExec die Verbindung zwischen Ethereum-Smart Contracts und sicherer Off-Chain-Ausführung her. Es demonstriert, wie TEE-„Worker“ vernetzt werden können, um eine dezentrale Cloud zu bilden, komplett mit einem Marktplatz (der iExecs RLC-Token zur Zahlung verwendet) und Konsensmechanismen. Durch die Leitung der Trusted Compute-Arbeitsgruppe der Enterprise Ethereum Alliance und die Mitwirkung an Standards (wie Hyperledger Avalon) treibt iExec auch die breitere Akzeptanz von TEEs in Unternehmens-Blockchain-Szenarien voran.

Andere Projekte und Ökosysteme​

Über die vier oben genannten hinaus gibt es noch einige weitere Projekte, die erwähnenswert sind:

• Integritee – eine weitere Polkadot-Parachain, ähnlich wie Sanders (tatsächlich entstand sie aus der TEE-Arbeit der Energy Web Foundation). Integritee nutzt TEEs, um „Parachain-as-a-Service“ für Unternehmen zu schaffen, indem es On-Chain- und Off-Chain-Enklaven-Verarbeitung kombiniert.
• Automata Network – ein Middleware-Protokoll für Web3-Datenschutz, das TEEs für private Transaktionen, anonyme Abstimmungen und MEV-resistente Transaktionsverarbeitung nutzt. Automata läuft als Off-Chain-Netzwerk und bietet Dienste wie ein privates RPC-Relay an und wurde erwähnt, TEEs für Dinge wie geschützte Identität und gaslose private Transaktionen zu verwenden.
• Hyperledger Sawtooth (PoET) – im Unternehmensbereich führte Sawtooth einen Konsensalgorithmus namens Proof of Elapsed Time ein, der auf SGX basierte. Jeder Validator betreibt eine Enklave, die eine zufällige Zeit wartet und einen Nachweis erzeugt; derjenige mit der kürzesten Wartezeit „gewinnt“ den Block, eine faire Lotterie, die von SGX durchgesetzt wird. Obwohl Sawtooth kein Web3-Projekt im eigentlichen Sinne ist (eher eine Unternehmens-Blockchain), ist es eine kreative Nutzung von TEEs für den Konsens.
• Unternehmens-/Konsortialketten – Viele Blockchain-Lösungen für Unternehmen (z. B. ConsenSys Quorum, IBM Blockchain) integrieren TEEs, um vertrauliche Konsortialtransaktionen zu ermöglichen, bei denen nur autorisierte Nodes bestimmte Daten sehen. Zum Beispiel verwendet der Trusted Compute Framework (TCF)-Entwurf 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 untermauern sogar Konsensalgorithmen. Als Nächstes betrachten wir die umfassenderen Vorteile und Herausforderungen der Verwendung von TEEs in dezentralen Umgebungen.

4. Vorteile und Herausforderungen von TEEs in dezentralen Umgebungen​

Die Einführung von Trusted Execution Environments in Blockchain-Systemen bringt erhebliche technische Vorteile sowie bemerkenswerte Herausforderungen und Kompromisse mit sich. Wir werden beide Seiten untersuchen: was TEEs dezentralen Anwendungen bieten und welche Probleme oder Risiken sich aus ihrer Verwendung ergeben.

Vorteile und technische Stärken​

• Starke Sicherheit & Datenschutz: Der größte Vorteil sind die Garantien für Vertraulichkeit und Integrität. TEEs ermöglichen die Ausführung von sensiblem Code mit der Gewissheit, dass er nicht von externer Malware ausspioniert oder verändert wird. Dies schafft ein Vertrauensniveau in Off-Chain-Berechnungen, das zuvor nicht verfügbar war. Für die Blockchain bedeutet dies, dass private Daten genutzt werden können (wodurch die Funktionalität von dApps verbessert wird), ohne die Sicherheit zu opfern. Selbst in nicht vertrauenswürdigen Umgebungen (Cloud-Server, von Dritten betriebene Validator-Nodes) schützen TEEs Geheimnisse. Dies ist besonders vorteilhaft für die Verwaltung privater Schlüssel, Benutzerdaten und proprietärer Algorithmen innerhalb von Krypto-Systemen. Zum Beispiel könnte eine Hardware-Wallet oder ein Cloud-Signaturdienst eine TEE verwenden, um Blockchain-Transaktionen intern zu signieren, sodass der private Schlüssel niemals im Klartext offengelegt wird, was Komfort mit Sicherheit verbindet.

• Nahezu native Leistung: Im Gegensatz zu rein kryptografischen Ansätzen zur sicheren Berechnung (wie ZK-Proofs oder homomorphe Verschlüsselung) ist der TEE-Overhead relativ gering. Code läuft direkt auf der CPU, sodass eine Berechnung innerhalb einer Enklave ungefähr so schnell ist wie außerhalb (mit etwas Overhead für Enklaven-Übergänge und Speicherverschlüsselung, typischerweise einstellige prozentuale Verlangsamungen bei SGX). Dies bedeutet, dass TEEs rechenintensive Aufgaben effizient bewältigen können, was Anwendungsfälle (wie Echtzeit-Datenfeeds, komplexe Smart Contracts, maschinelles Lernen) ermöglicht, die bei kryptografischen Protokollen um Größenordnungen langsamer wären. Die geringe Latenz von Enklaven macht sie dort geeignet, wo eine schnelle Reaktion erforderlich ist (z. B. Hochfrequenz-Handelsbots, die durch TEEs gesichert sind, oder interaktive Anwendungen und Spiele, bei denen die Benutzererfahrung unter hohen Verzögerungen leiden würde).

• Verbesserte Skalierbarkeit (durch Auslagerung): Indem TEEs es ermöglichen, rechenintensive Berechnungen sicher Off-Chain durchzuführen, helfen sie, Überlastungen und Gaskosten auf Hauptketten zu reduzieren. Sie ermöglichen Layer-2-Designs und Seitenprotokolle, 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 On-Chain) kann den Durchsatz und die Skalierbarkeit dezentraler Anwendungen drastisch verbessern. Zum Beispiel könnte eine DEX das Matchmaking in einer TEE Off-Chain durchführen und nur die gematchten Trades On-Chain veröffentlichen, wodurch der Durchsatz erhöht und das On-Chain-Gas reduziert wird.

• Bessere Benutzererfahrung & Funktionalität: Mit TEEs können dApps Funktionen wie Vertraulichkeit oder komplexe Analysen anbieten, die mehr Benutzer (einschließlich Institutionen) anziehen. TEEs ermöglichen auch gaslose oder Meta-Transaktionen, indem sie diese sicher Off-Chain ausführen und dann Ergebnisse übermitteln, wie in Automatas Verwendung von TEEs zur Reduzierung des Gasverbrauchs für private Transaktionen festgestellt. Darüber hinaus kann das Speichern sensibler Zustände Off-Chain in einer Enklave die On-Chain veröffentlichten Daten reduzieren, was gut für den Datenschutz der Benutzer und die Netzwerkeffizienz ist (weniger On-Chain-Daten zum Speichern/Verifizieren).

• Kompatibilität mit anderen Technologien: Interessanterweise können TEEs andere Technologien ergänzen (nicht streng genommen ein Vorteil, der TEEs allein innewohnt, sondern in Kombination). Sie können als Bindeglied dienen, das hybride Lösungen zusammenhält: z. B. das Ausführen eines Programms in einer Enklave und gleichzeitig das Generieren eines ZK-Proofs seiner Ausführung, wobei die Enklave bei Teilen des Beweisprozesses hilft, 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 TEE liegt darin, andere zu unterstützen, nicht sie zu ersetzen“).

Vertrauensannahmen und Sicherheitslücken​

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

• Hardware-Vertrauen und Zentralisierung: Durch die Verwendung von TEEs vertraut man zwangsläufig dem Siliziumhersteller und der Sicherheit seines Hardware-Designs und seiner Lieferkette. Die Verwendung von Intel SGX bedeutet beispielsweise, darauf zu vertrauen, dass Intel keine Hintertüren hat, dass die Fertigung sicher ist und dass der Mikrocode der CPU die Enklaven-Isolation korrekt implementiert. Dies ist ein stärker zentralisiertes Vertrauensmodell im Vergleich zur reinen Kryptografie (die auf mathematischen Annahmen basiert, die unter allen Benutzern verteilt sind). Darüber hinaus basiert die Attestierung für SGX historisch auf der Kontaktaufnahme mit Intels Attestation Service, was bedeutet, dass Enklaven weltweit betroffen sein könnten, wenn Intel offline ginge oder beschließen würde, Schlüssel zu widerrufen. Diese Abhängigkeit von der Infrastruktur eines einzelnen Unternehmens wirft Bedenken auf: Es könnte ein Single Point of Failure sein oder sogar Ziel staatlicher Regulierung (z. B. könnten US-Exportkontrollen theoretisch einschränken, wer starke TEEs verwenden darf). AMD SEV mildert dies, indem es eine dezentralere Attestierung ermöglicht (VM-Besitzer können ihre VMs attestieren), vertraut aber immer noch dem Chip und der Firmware von AMD. Das Zentralisierungsrisiko wird oft als etwas der Dezentralisierung der Blockchain Entgegengesetztes angeführt. Projekte wie Keystone (Open-Source-TEE) und andere erforschen Wege, die Abhängigkeit von proprietären Black Boxes zu reduzieren, aber diese sind noch nicht Mainstream.

• Seitenkanal- und andere Schwachstellen: Eine TEE ist kein Allheilmittel; sie kann durch indirekte Mittel angegriffen werden. Seitenkanalangriffe nutzen die Tatsache aus, dass selbst wenn der direkte Speicherzugriff blockiert ist, der Betrieb einer Enklave das System subtil beeinflussen könnte (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-Leckage) über Plundervolt (Spannungsfehlerinjektion über privilegierte Anweisungen) bis hin zu SGAxe (Extrahieren von Attestierungsschlüsseln) und anderen. Diese ausgeklügelten Angriffe zeigen, dass TEEs kompromittiert werden können, ohne kryptografische Schutzmaßnahmen brechen zu müssen – stattdessen durch Ausnutzung mikroarchitektonischer Verhaltensweisen oder Implementierungsfehler. 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. kann das Entkapseln des Chips, das Abgreifen von Bussen usw. die meisten kommerziellen TEEs überwinden).

  Die Reaktionen der Anbieter auf Seitenkanal-Entdeckungen waren Mikrocode-Patches und Enklaven-SDK-Updates, um bekannte Lecks zu mindern (manchmal auf Kosten der Leistung). Aber es bleibt ein Katz-und-Maus-Spiel. Für Web3 bedeutet dies, dass, wenn jemand einen neuen Seitenkanal auf SGX findet, ein „sicherer“ DeFi-Vertrag, der in SGX läuft, potenziell ausgenutzt werden könnte (z. B. um geheime Daten preiszugeben 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 dagegen zu stärken (z. B. durch das Design von Enklaven-Code mit konstanten Zeitoperationen, die Vermeidung von geheimnisabhängigen Speicherzugriffsmustern und die Verwendung von Techniken wie Oblivious RAM). Einige Projekte ergänzen TEEs auch mit sekundären Prüfungen – z. B. durch Kombination mit ZK-Proofs oder durch das Ausführen mehrerer Enklaven auf verschiedenen Hardware-Anbietern, um das Risiko eines einzelnen Chip-Kompromisses zu reduzieren.

• Leistungs- und Ressourcenbeschränkungen: Obwohl TEEs für CPU-gebundene Aufgaben mit nahezu nativer Geschwindigkeit laufen, bringen sie einige Overheads und Grenzen mit sich. Das Umschalten in eine Enklave (ein ECALL) und aus ihr heraus (OCALL) ist mit Kosten verbunden, ebenso wie die Ver-/Entschlüsselung von Speicherseiten. Dies kann die Leistung bei sehr häufigen Enklaven-Grenzüberschreitungen beeinträchtigen. Enklaven haben oft auch Speichergrößenbeschränkungen. Zum Beispiel hatte frühes SGX einen begrenzten Enclave Page Cache, und wenn Enklaven mehr Speicher verwendeten, mussten Seiten (mit Verschlüsselung) ausgelagert werden, was die Leistung massiv verlangsamte. Selbst neuere TEEs erlauben oft nicht die einfache Nutzung des gesamten System-RAMs – es gibt einen sicheren Speicherbereich, der möglicherweise begrenzt ist. Dies bedeutet, dass sehr große Berechnungen oder Datensätze schwierig vollständig innerhalb einer TEE zu handhaben sein könnten. 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 den Speicher optimieren und möglicherweise Workloads aufteilen.

• Komplexität von Attestierung und Schlüsselverwaltung: Die Verwendung von TEEs in einer dezentralen Umgebung erfordert robuste Attestierungs-Workflows: Jeder Node muss anderen beweisen, dass er eine authentische Enklave mit erwartetem Code ausführt. Das Einrichten dieser On-Chain-Attestierungsprüfung kann komplex sein. Es beinhaltet normalerweise das Hardcodieren des öffentlichen Attestierungsschlüssels oder Zertifikats des Anbieters in das Protokoll und das Schreiben von Verifizierungslogik in Smart Contracts oder Off-Chain-Clients. Dies führt zu Overhead im Protokolldesign, und Änderungen (wie Intel, das sein Attestierungs-Signaturschlüsselformat von EPID auf DCAP ändert) können Wartungsaufwand verursachen. Zusätzlich 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 in der Enklaven-Schlüsselverwaltung könnten die Sicherheit untergraben (z. B. wenn eine Enklave versehentlich einen Entschlüsselungsschlüssel durch einen Fehler preisgibt, brechen alle ihre Vertraulichkeitsversprechen zusammen). Best Practices beinhalten die Verwendung der Sealing-APIs der TEE, um Schlüssel sicher zu speichern und Schlüssel bei Bedarf zu rotieren, aber auch dies erfordert eine sorgfältige Entwicklung durch die Entwickler.

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

Kompatibilität und Ökosystem-Einschränkungen​

• Begrenzte Kompatibilität mit anderen Verträgen: Auf einer öffentlichen Smart-Contract-Plattform wie Ethereum können Verträge andere Verträge leicht aufrufen, und der gesamte Zustand ist offen, was DeFi-Geld-Legos und eine reichhaltige Komposition ermöglicht. In einem TEE-basierten Vertragsmodell kann der private Zustand nicht frei geteilt oder komponiert werden, ohne die Vertraulichkeit zu verletzen. Wenn zum Beispiel Vertrag A in einer Enklave mit Vertrag B interagieren muss und beide geheime Daten enthalten, wie arbeiten sie dann zusammen? Entweder müssen sie ein komplexes sicheres Mehrparteienprotokoll durchführen (was die Einfachheit von TEEs teilweise aufhebt) oder sie werden zu einer Enklave kombiniert (was die Modularität reduziert). Dies ist eine Herausforderung, der sich Secret Network und andere stellen müssen: Cross-Contract-Aufrufe mit Datenschutz sind nicht trivial. Einige Lösungen beinhalten, dass eine einzelne Enklave die Ausführung mehrerer Verträge handhabt, sodass sie intern gemeinsame Geheimnisse verwalten kann, aber das kann das System monolithischer machen. Daher ist die Kompatibilität privater Verträge begrenzter als die öffentlicher, oder erfordert neue Designmuster. Ähnlich erfordert die Integration von TEE-basierten Modulen in bestehende Blockchain-dApps ein sorgfältiges Interface-Design – oft wird nur das Ergebnis einer Enklave On-Chain veröffentlicht, was ein Snark oder ein Hash sein könnte, und andere Verträge können nur diese begrenzten Informationen verwenden. Dies ist sicherlich ein Kompromiss; Projekte wie Secret bieten Viewing Keys und erlauben das Teilen von Geheimnissen nach dem Need-to-know-Prinzip, aber es ist nicht so nahtlos wie die normale On-Chain-Kompatibilität.

• Standardisierung und Interoperabilität: Das TEE-Ökosystem verfügt derzeit nicht über einheitliche Standards über verschiedene Anbieter hinweg. Intel SGX, AMD SEV, ARM TrustZone haben alle unterschiedliche Programmiermodelle und Attestierungsmethoden. Diese Fragmentierung bedeutet, dass eine für SGX-Enklaven geschriebene dApp nicht trivial 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-Nodes (z. B. Validatoren auf Mobilgeräten) unterstützen möchten, würde dies zusätzliche Entwicklung und möglicherweise 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 so weit. Der Mangel an Standards wirkt sich auch auf die Entwickler-Tools aus – man mag das SGX SDK als ausgereift empfinden, muss sich dann aber an eine andere TEE mit einem anderen SDK anpassen. Diese Interoperabilitätsherausforderung kann die Akzeptanz verlangsamen und die Kosten erhöhen.

• Entwickler-Lernkurve: Das Erstellen von Anwendungen, die innerhalb von TEEs laufen, erfordert spezialisiertes Wissen, das viele Blockchain-Entwickler möglicherweise nicht besitzen. Oft sind Low-Level-C/C++-Programmierung (für SGX/TrustZone) oder Kenntnisse über Speichersicherheit und seitenkanalresistente Codierung erforderlich. Das Debuggen von Enklaven-Code ist bekanntermaßen schwierig (man kann aus Sicherheitsgründen während der Ausführung nicht einfach in eine Enklave hineinsehen!). Obwohl Frameworks und höhere Programmiersprachen (wie die Verwendung von Rust durch Oasis für ihre vertrauliche Laufzeitumgebung oder sogar Tools zum Ausführen von WebAssembly in Enklaven) existieren, ist die Entwicklererfahrung immer noch rauer als bei der typischen Smart-Contract-Entwicklung oder Off-Chain-Web2-Entwicklung. Diese steile Lernkurve und unreife Tools können Entwickler abschrecken oder zu Fehlern führen, wenn sie nicht sorgfältig gehandhabt werden. Es gibt auch den Aspekt, dass Hardware zum Testen benötigt wird – das Ausführen von SGX-Code erfordert eine SGX-fähige CPU oder einen Emulator (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 knapper macht als beispielsweise in der etablierten 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). Es gibt auch Overhead im Betrieb: Firmware auf dem neuesten Stand halten (für Sicherheitspatches), Attestierungsnetzwerke verwalten usw., was kleine Projekte als belastend empfinden könnten. Wenn jeder Node eine bestimmte CPU haben muss, könnte dies den potenziellen Validatoren-Pool reduzieren (nicht jeder hat die erforderliche Hardware), wodurch die Dezentralisierung beeinträchtigt und möglicherweise eine höhere Nutzung von Cloud-Hosting verursacht wird.

Zusammenfassend lässt sich sagen, dass TEEs zwar leistungsstarke Funktionen freischalten, aber auch Vertrauenskompromisse (Hardware-Vertrauen vs. Mathematik-Vertrauen), potenzielle Sicherheitslücken (insbesondere Seitenkanäle) und Integrationshürden in einem dezentralen Kontext mit sich bringen. Projekte, die TEEs verwenden, müssen diese Probleme sorgfältig umgehen – indem sie eine tiefgehende Verteidigung einsetzen (nicht davon ausgehen, dass die TEE unzerbrechlich ist), die vertrauenswürdige Computing-Basis minimal halten und transparent über die Vertrauensannahmen gegenüber den Benutzern sind (damit klar ist, dass man beispielsweise zusätzlich zum Blockchain-Konsens der Hardware von Intel vertraut).

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

Trusted Execution Environments sind ein Ansatz, um Datenschutz und Sicherheit in Web3 zu erreichen, aber es gibt andere wichtige Techniken, darunter Zero-Knowledge Proofs (ZKPs), Fully Homomorphic Encryption (FHE) und Secure Multi-Party Computation (MPC). Jede dieser Technologien hat 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 Kompromisse in Bezug auf Leistung, Vertrauen und Entwicklerfreundlichkeit zu vergleichen:

Um die Alternativen kurz zu definieren:

• ZKPs: Kryptografische Beweise (wie zk-SNARKs, zk-STARKs), die es einer Partei ermöglichen, anderen zu beweisen, dass eine Aussage wahr ist (z. B. „Ich kenne ein Geheimnis, das diese Berechnung erfüllt“), ohne preiszugeben, warum sie wahr ist (indem die geheime Eingabe verborgen bleibt). In der Blockchain werden ZKPs für private Transaktionen (z. B. Zcash, Aztec) und für die Skalierbarkeit (Rollups, die Beweise für die korrekte Ausführung veröffentlichen) verwendet. Sie gewährleisten starken Datenschutz (es werden keine geheimen Daten preisgegeben, nur Beweise) und Integrität, die durch Mathematik garantiert wird, aber die Generierung dieser Beweise kann rechnerisch aufwendig sein, und die Schaltkreise müssen sorgfältig entworfen werden.
• FHE: Verschlüsselungsschema, das beliebige Berechnungen auf verschlüsselten Daten ermöglicht, sodass das Ergebnis nach der Entschlüsselung mit dem Ergebnis der Berechnung auf Klartextdaten übereinstimmt. Theoretisch bietet FHE ultimative Privatsphäre – Daten bleiben jederzeit verschlüsselt – und man muss niemandem die Rohdaten anvertrauen. Aber FHE ist für allgemeine Berechnungen extrem langsam (obwohl es sich durch Forschung verbessert); es wird aufgrund der Leistung immer noch hauptsächlich experimentell oder spezialisiert eingesetzt.
• MPC: Protokolle, bei denen mehrere Parteien gemeinsam eine Funktion über ihre privaten Eingaben berechnen, ohne diese Eingaben einander preiszugeben. Es beinhaltet oft die Geheimnisverteilung von Daten unter den Parteien und die Durchführung kryptografischer Operationen, sodass die Ausgabe korrekt ist, aber individuelle Eingaben verborgen bleiben. MPC kann Vertrauen verteilen (kein einzelner Punkt sieht alle Daten) und kann für bestimmte Operationen effizient sein, verursacht aber typischerweise einen Kommunikations- und Koordinations-Overhead und kann für große Netzwerke komplex zu implementieren sein.

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

Zitationen: Der obige Vergleich stützt sich auf Quellen wie die Analyse von Sanders Network und andere, die hervorheben, dass TEEs in Geschwindigkeit und Benutzerfreundlichkeit überzeugen, während ZK und FHE auf maximale Vertrauenslosigkeit auf Kosten hoher Rechenleistung abzielen und MPC Vertrauen verteilt, aber Netzwerk-Overhead einführt.

Aus der Tabelle werden einige wichtige Kompromisse deutlich:

• Leistung: TEEs haben einen großen Vorteil in Bezug auf Rohgeschwindigkeit und geringe Latenz. MPC kann oft moderate Komplexität mit einer gewissen Verlangsamung bewältigen, ZK ist langsam in der Erzeugung, aber schnell in der Verifizierung (asynchrone Nutzung), und FHE ist derzeit bei weitem die langsamste Option für beliebige Aufgaben (obwohl es für begrenzte Operationen wie einfache Additionen/Multiplikationen in Ordnung ist). 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 (vertrauen 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 vertrauen der Hardware und dem Anbieter. 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, besser mit dem dezentralen Ethos übereinzustimmen – keine besonderen Entitäten, denen man vertrauen muss, nur rechnerische Härte. MPC liegt dazwischen: Vertrauen ist dezentralisiert, aber nicht eliminiert (wenn N von M Nodes kolludieren, bricht der Datenschutz zusammen). Für maximale Vertrauenslosigkeit (z. B. ein wirklich zensurresistentes, dezentrales System) könnte man sich daher kryptografischen Lösungen zuwenden. Andererseits sind viele praktische Systeme damit einverstanden, anzunehmen, dass Intel ehrlich ist oder dass eine Reihe wichtiger Validatoren nicht kolludieren wird, und tauschen ein wenig Vertrauen gegen enorme Effizienzgewinne ein.

• Sicherheit/Schwachstellen: TEEs können, wie besprochen, durch Hardwarefehler 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 (auch 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 gehen von „ehrlichen, aber neugierigen“ Teilnehmern aus und könnten fehlschlagen, wenn jemand offen betrügt). Im Blockchain-Kontext könnte ein TEE-Bruch katastrophaler sein (alle Enklaven-basierten Verträge könnten gefährdet sein, bis sie gepatcht sind), während ein kryptografischer ZK-Bruch (wie die Entdeckung eines Fehlers in einer von einem ZK-Rollup verwendeten Hash-Funktion) ebenfalls katastrophal sein könnte, aber angesichts der einfacheren Annahme im Allgemeinen als weniger wahrscheinlich angesehen wird. Die Angriffsfläche ist sehr unterschiedlich: TEEs müssen sich um Dinge wie Leistungsanalyse kümmern, während ZK sich um mathematische Durchbrüche kümmern muss.

• Datenschutz: FHE und ZK bieten die stärksten Datenschutzgarantien – Daten bleiben kryptografisch geschützt. MPC stellt sicher, dass Daten geheim geteilt werden, sodass keine einzelne Partei sie sieht (obwohl einige Informationen durchsickern könnten, wenn Ausgaben öffentlich sind oder Protokolle nicht sorgfältig entworfen wurden). TEE hält Daten von außen privat, aber innerhalb der Enklave werden Daten entschlüsselt; wenn jemand irgendwie die Kontrolle über die Enklave erlangt, geht die Datenvertraulichkeit verloren. Außerdem erlauben TEEs dem Code typischerweise, alles mit den Daten zu tun (einschließlich unbeabsichtigter Leckage durch Seitenkanäle oder das Netzwerk, wenn der Code bösartig ist). TEEs erfordern also, dass Sie auch dem Enklaven-Code vertrauen, nicht nur der Hardware. Im Gegensatz dazu beweisen ZKPs Eigenschaften des Codes, ohne jemals Geheimnisse preiszugeben, sodass Sie dem Code nicht einmal vertrauen müssen (außer dass er tatsächlich die bewiesene Eigenschaft besitzt). Wenn eine Enklaven-Anwendung einen Fehler hätte, der Daten in eine Protokolldatei leckte, würde die TEE-Hardware dies nicht verhindern – während ein ZK-Beweissystem einfach nichts außer dem beabsichtigten Beweis preisgeben würde. Dies ist eine Nuance: TEEs schützen vor externen Angreifern, aber nicht unbedingt vor Logikfehlern im Enklaven-Programm selbst, während ZKs Design einen deklarativeren Ansatz erzwingt (man beweist genau das, was beabsichtigt ist und nichts weiter).

• Kompatibilität & Integration: TEEs lassen sich recht einfach in bestehende Systeme integrieren – man kann ein bestehendes Programm nehmen, es in eine Enklave legen und einige Sicherheitsvorteile erzielen, ohne das Programmiermodell zu stark zu ändern. ZK und FHE erfordern oft das Umschreiben des Programms in einen Schaltkreis oder eine restriktive Form, was ein enormer Aufwand sein kann. Zum Beispiel beinhaltet das Schreiben einer einfachen KI-Modellverifizierung in ZK die Transformation in eine Reihe von arithmetischen Operationen und Einschränkungen, was weit entfernt davon ist, einfach TensorFlow in einer TEE auszuführen und das Ergebnis zu attestieren. MPC kann ebenfalls ein benutzerdefiniertes Protokoll pro Anwendungsfall erfordern. Aus Sicht der Entwicklerproduktivität und Kosten sind TEEs daher attraktiv. Wir haben gesehen, dass TEEs in einigen Bereichen schneller angenommen wurden, gerade weil man bestehende Software-Ökosysteme nutzen kann (viele Bibliotheken laufen mit geringfügigen Anpassungen in Enklaven). ZK/MPC erfordern spezialisiertes Ingenieurwissen, das knapp ist. Die Kehrseite ist jedoch, dass TEEs eine Lösung liefern, die oft stärker isoliert ist (man muss dieser Enklave oder dieser Gruppe von Nodes vertrauen), während ZK einen Beweis liefert, den jeder On-Chain überprüfen kann, was ihn hochgradig kompatibel macht (jeder Vertrag kann einen zk-Proof verifizieren). ZK-Ergebnisse sind also portabel – sie erzeugen einen kleinen Beweis, den beliebig viele andere Verträge oder Benutzer nutzen können, um Vertrauen zu gewinnen. TEE-Ergebnisse liegen normalerweise in Form einer Attestierung vor, die an eine bestimmte Hardware gebunden und möglicherweise nicht prägnant ist; sie sind möglicherweise nicht so leicht teilbar oder kettenunabhängig (obwohl man eine Signatur des Ergebnisses veröffentlichen und Verträge so programmieren kann, dass sie diese akzeptieren, wenn sie den öffentlichen Schlüssel der Enklave kennen).

In der Praxis sehen wir hybride Ansätze: Zum Beispiel argumentiert Sanders Network, dass TEE, MPC und ZK jeweils in verschiedenen Bereichen glänzen und sich gegenseitig ergänzen können. Ein konkreter Fall ist die dezentrale Identität: Man könnte ZK-Proofs verwenden, um eine Identitätsberechtigung zu beweisen, ohne sie preiszugeben, aber diese Berechtigung könnte durch einen TEE-basierten Prozess überprüft und ausgestellt worden sein, der Ihre Dokumente privat geprüft hat. Oder betrachten Sie die Skalierung: ZK-Rollups liefern prägnante Beweise für viele Transaktionen, aber die Generierung dieser Beweise könnte durch die Verwendung von TEEs beschleunigt werden, um einige Berechnungen schneller durchzuführen (und dann nur eine kleinere Aussage zu beweisen). Die Kombination kann manchmal die Vertrauensanforderung an TEEs reduzieren (z. B. TEEs für die Leistung verwenden, aber die endgültige Korrektheit immer noch über einen ZK-Proof oder über ein On-Chain-Challenge-Spiel überprüfen, sodass eine kompromittierte TEE nicht betrügen kann, ohne erwischt zu werden). MPC kann mit TEEs kombiniert werden, indem der Rechen-Node jeder Partei eine TEE ist, was eine zusätzliche Schicht hinzufügt, sodass selbst wenn einige Parteien kolludieren, sie die Daten der anderen immer noch nicht sehen können, es sei denn, sie brechen auch die Hardware-Sicherheit.

Zusammenfassend bieten TEEs einen sehr praktischen und sofortigen Weg zu sicherer Berechnung mit moderaten Annahmen (Hardware-Vertrauen), während ZK und FHE einen eher theoretischen und vertrauenslosen Weg zu hohen Rechenkosten bieten und MPC einen verteilten Vertrauensweg mit Netzwerkkosten. Die richtige Wahl in Web3 hängt von den Anwendungsanforderungen ab:

• Wenn Sie schnelle, komplexe Berechnungen mit privaten Daten benötigen (wie KI, große Datensätze) – sind TEEs (oder MPC mit wenigen Parteien) derzeit der einzig praktikable Weg.
• Wenn Sie maximale Dezentralisierung und Verifizierbarkeit benötigen – glänzen ZK-Proofs (zum Beispiel bevorzugen private Kryptowährungstransaktionen ZKP wie bei Zcash, weil Benutzer nichts außer Mathematik vertrauen wollen).
• Wenn Sie kollaboratives Computing zwischen mehreren Stakeholdern benötigen – ist MPC natürlich geeignet (wie Mehrparteien-Schlüsselverwaltung oder Auktionen).
• Wenn Sie extrem sensible Daten haben und langfristiger Datenschutz ein Muss ist – könnte FHE attraktiv sein, wenn sich die Leistung verbessert, denn selbst wenn jemand Jahre später Ihre Chiffretexte erhält, erfahren sie ohne den Schlüssel nichts; wohingegen ein Enklaven-Kompromiss Geheimnisse rückwirkend preisgeben könnte, wenn Protokolle geführt wurden.

Es ist erwähnenswert, dass der Blockchain-Bereich all diese Technologien parallel aktiv erforscht. Wir werden wahrscheinlich Kombinationen sehen: z. B. Layer-2-Lösungen, die TEEs integrieren, um Transaktionen zu sequenzieren und dann einen ZKP zu verwenden, um zu beweisen, dass die TEE die Regeln befolgt hat (ein Konzept, das in einigen Ethereum-Forschungen untersucht wird), oder MPC-Netzwerke, die TEEs in jedem Node verwenden, um die Komplexität der MPC-Protokolle zu reduzieren (da jeder Node intern sicher ist und mehrere Parteien simulieren kann).

Letztendlich ist die Wahl zwischen TEEs, ZK, MPC und FHE keine Nullsummenentscheidung – jede zielt auf unterschiedliche Punkte im Dreieck von Sicherheit, Leistung und Vertrauenslosigkeit ab. Wie ein Artikel es formulierte, stehen alle vier vor einem „unmöglichen Dreieck“ aus Leistung, Kosten und Sicherheit – keine einzelne Lösung ist in allen Aspekten überlegen. Das optimale Design verwendet oft das richtige Werkzeug für den richtigen Teil des Problems.

6. Akzeptanz in wichtigen Blockchain-Ökosystemen​

Trusted Execution Environments haben in verschiedenen Blockchain-Ökosystemen unterschiedliche Akzeptanzgrade erfahren, oft beeinflusst durch die Prioritäten dieser Gemeinschaften und die Einfachheit der Integration. Hier bewerten wir, wie TEEs in einigen der wichtigsten Ökosysteme genutzt (oder erforscht) werden: Ethereum, Cosmos und Polkadot, sowie andere.

Ethereum (und allgemeine Layer-1s)​

Auf dem Ethereum-Mainnet selbst sind TEEs nicht Teil des Kernprotokolls, wurden aber in Anwendungen und Layer-2s eingesetzt. Ethereums Philosophie stützt sich auf kryptografische Sicherheit (z. B. aufkommende ZK-Rollups), aber TEEs haben Rollen in Oracles und Off-Chain-Ausführung für Ethereum gefunden:

• Oracle-Dienste: Wie besprochen, 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 verfügbar, die zusätzliches Vertrauen erfordern. Auch API3 (ein weiteres Oracle-Projekt) hat die Verwendung von Intel SGX erwähnt, um APIs auszuführen und Daten zu signieren, um die Authentizität zu gewährleisten. Diese Dienste speisen Daten mit stärkeren Zusicherungen in Ethereum-Verträge ein.

• Layer-2 und Rollups: In der Ethereum-Community gibt es laufende Forschung und Debatten über die Verwendung von TEEs in Rollup-Sequencern oder Validatoren. Zum Beispiel haben das Konzept „ZK-Portal“ von ConsenSys und andere die Verwendung von TEEs vorgeschlagen, um die korrekte Reihenfolge in optimistischen Rollups durchzusetzen oder den Sequencer vor Zensur zu schützen. Der von uns gesehene Medium-Artikel deutet sogar darauf hin, dass TEE bis 2025 zu einer Standardfunktion in einigen L2s für Dinge wie den Schutz vor Hochfrequenzhandel werden könnte. Projekte wie Catalyst (eine Hochfrequenzhandels-DEX) und Flashbots (für MEV-Relays) haben TEEs untersucht, um eine faire Reihenfolge von Transaktionen durchzusetzen, bevor sie die Blockchain erreichen.

• Enterprise Ethereum: In Konsortial- oder Permissioned-Ethereum-Netzwerken sind TEEs weiter verbreitet. Das Trusted Compute Framework (TCF) der Enterprise Ethereum Alliance war im Grunde ein Entwurf zur Integration von TEEs in Ethereum-Clients. Hyperledger Avalon (ehemals EEA TCF) ermöglicht die Ausführung von Teilen von Ethereum-Smart Contracts Off-Chain in einer TEE und deren anschließende Verifizierung On-Chain. Mehrere Unternehmen wie IBM, Microsoft und iExec haben dazu beigetragen. Während dies auf öffentlichem Ethereum nicht üblich geworden ist, können in privaten Implementierungen (z. B. einer Gruppe von Banken, die Quorum oder Besu verwenden) TEEs eingesetzt werden, sodass selbst Konsortialmitglieder die Daten der anderen nicht sehen, sondern nur autorisierte Ergebnisse. Dies kann die Datenschutzanforderungen in einem 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 umstieg; es wurde später zum Secret Network auf Cosmos). Ein weiteres war Decentralized Cloud Services (DCS) in frühen Ethereum-Diskussionen. In jüngerer Zeit ermöglicht OAuth (Oasis Ethereum ParaTime) Solidity-Verträgen, mit Vertraulichkeit zu laufen, indem es das TEE-Backend von Oasis nutzt, aber auf Ethereum abrechnet. Auch einige Ethereum-basierte dApps wie medizinische Datenfreigabe oder Gaming haben mit TEEs experimentiert, indem sie eine Off-Chain-Enklavenkomponente hatten, die mit ihren Verträgen interagiert.

Die Akzeptanz von Ethereum ist also eher indirekt – es hat das Protokoll nicht geändert, um TEEs zu erfordern, aber es verfügt über eine Vielzahl optionaler Dienste und Erweiterungen, die TEEs für diejenigen nutzen, die sie benötigen. Wichtig ist, dass Ethereum-Forscher vorsichtig bleiben: Vorschläge, einen „TEE-only Shard“ zu erstellen oder TEEs tief zu integrieren, stießen in der Community aufgrund von Vertrauensbedenken auf Skepsis. Stattdessen werden TEEs eher als „Co-Prozessoren“ für Ethereum denn als Kernkomponenten angesehen.

Cosmos-Ökosystem​

Das Cosmos-Ökosystem ist durch sein modulares SDK und seine souveränen Chains experimentierfreundlich, und Secret Network (oben behandelt) ist ein Paradebeispiel für die TEE-Akzeptanz in Cosmos. Secret Network ist tatsächlich eine Cosmos SDK-Chain mit Tendermint-Konsens, die so modifiziert wurde, dass sie SGX in ihren Validatoren vorschreibt. Es ist eine der prominentesten Cosmos-Zonen nach dem Haupt-Cosmos Hub, was eine signifikante Akzeptanz der TEE-Technologie in dieser Community anzeigt. Der Erfolg von Secret bei der Bereitstellung von Interchain-Datenschutz (durch seine IBC-Verbindungen kann Secret als Datenschutz-Hub für andere Cosmos-Chains dienen) ist ein bemerkenswerter Fall der TEE-Integration auf L1.

Ein weiteres Cosmos-bezogenes Projekt ist Oasis Network (obwohl nicht auf dem Cosmos SDK aufgebaut, wurde es von einigen der gleichen Personen entworfen, die zu Tendermint beigetragen haben und teilt ein ähnliches Ethos modularer Architektur). Oasis ist eigenständig, kann aber über Bridges usw. mit Cosmos verbunden werden. Sowohl Secret als auch Oasis zeigen, dass im Cosmos-Land die Idee von „Datenschutz als Funktion“ über TEEs genügend Anklang gefunden hat, um dedizierte Netzwerke zu rechtfertigen.

Cosmos hat sogar ein Konzept von „Datenschutzanbietern“ für Interchain-Anwendungen – z. B. kann eine App auf einer Kette einen Vertrag im Secret Network über IBC aufrufen, um eine vertrauliche Berechnung durchzuführen und dann das Ergebnis zurückzuerhalten. Diese Kompatibilität entsteht jetzt.

Zusätzlich hat das Projekt Anoma (nicht streng Cosmos, aber im Sinne der Interoperabilität verwandt) über die Verwendung von TEEs für absichtsbasierte Architekturen gesprochen, obwohl dies eher theoretisch ist.

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

Polkadot und Substrate​

Polkadots Design ermöglicht es Parachains, sich zu spezialisieren, und tatsächlich hostet Polkadot mehrere Parachains, die TEEs verwenden:

• Sanders Network: Bereits beschrieben; eine Parachain, die eine TEE-basierte Compute-Cloud anbietet. Sanders ist als Parachain live und bietet Dienste für andere Chains über XCMP (Cross-Chain Message Passing) an. Zum Beispiel kann ein anderes Polkadot-Projekt eine vertrauliche Aufgabe an Sanders' Worker auslagern und einen Beweis oder ein Ergebnis zurückerhalten. Sanders' native Token-Ökonomie incentiviert den Betrieb von TEE-Nodes, und es hat eine beträchtliche Community, was eine starke Akzeptanz signalisiert.
• Integritee: Eine weitere Parachain, die sich auf Unternehmens- und Datenschutzlösungen mittels TEEs konzentriert. Integritee ermöglicht es Teams, ihre eigenen privaten Side-Chains (genannt Teewasms) zu implementieren, bei denen die Ausführung in Enklaven erfolgt. Sie zielt auf Anwendungsfälle wie die vertrauliche Datenverarbeitung für Unternehmen ab, die sich weiterhin an die Polkadot-Sicherheit binden möchten.
• /Root oder Crust?: Es gab Ideen, TEEs für dezentralen Speicher oder Zufallsbaken in einigen Polkadot-bezogenen Projekten zu verwenden. Zum Beispiel plante Crust Network (dezentraler Speicher) ursprünglich einen TEE-basierten Proof-of-Storage (obwohl es später zu einem anderen Design wechselte). Und Polkadots zufällige Parachain (Entropy) zog TEEs vs. VRFs in Betracht.

Polkadots Abhängigkeit von On-Chain-Governance und Upgrades bedeutet, dass Parachains neue Technologien schnell integrieren können. Sowohl Sanders als auch Integritee haben Upgrades durchlaufen, um ihre TEE-Integration zu verbessern (wie die Unterstützung neuer SGX-Funktionen oder die Verfeinerung von Attestierungsmethoden). Die Web3 Foundation finanzierte auch frühere Bemühungen bei Substrate-basierten TEE-Projekten wie SubstraTEE (einem frühen Prototyp, der Off-Chain-Vertragsausführung in TEEs mit On-Chain-Verifizierung zeigte).

Das Polkadot-Ökosystem zeigt somit mehrere unabhängige Teams, die auf TEE-Technologie setzen, was einen positiven Akzeptanztrend anzeigt. Es wird zu einem Verkaufsargument für Polkadot, dass „wenn Sie vertrauliche Smart Contracts oder Off-Chain-Berechnungen benötigen, wir Parachains dafür haben“.

Andere Ökosysteme und allgemeine Akzeptanz​

• Unternehmen und Konsortien: Außerhalb des öffentlichen Kryptobereichs haben Hyperledger und Unternehmensketten TEEs für permissionierte Umgebungen stetig übernommen. Zum Beispiel testete der Basler Ausschuss eine TEE-basierte Handelsfinanzierungs-Blockchain. Das allgemeine Muster ist: Wo Datenschutz oder Datenvertraulichkeit ein Muss sind und die Teilnehmer bekannt sind (sodass sie möglicherweise sogar gemeinsam in Hardware-Sicherheitsmodule investieren), finden TEEs ein komfortables Zuhause. Diese mögen in Krypto-Nachrichten keine Schlagzeilen machen, aber in Sektoren wie Lieferkette, Bankenkonsortien oder Netzwerken zum Austausch von Gesundheitsdaten sind TEEs oft die erste Wahl (als Alternative dazu, einfach einem Dritten zu vertrauen oder schwere Kryptografie zu verwenden).

• Layer-1s außerhalb von Ethereum: Einige neuere L1s haben mit TEEs experimentiert. NEAR Protocol hatte ein frühes Konzept eines TEE-basierten Shards für private Verträge (noch nicht implementiert). Celo zog TEEs für Light-Client-Proofs in Betracht (ihre Plumo-Proofs basieren jetzt auf Snarks, aber sie untersuchten SGX, um Kettendaten für Mobilgeräte zu einem bestimmten Zeitpunkt 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, aber zum Bootstrapping von Vertrauen (nicht für die Vertragsausführung, da ihre „Chain Key“-Kryptografie dies handhabt).

• Bitcoin: Obwohl Bitcoin selbst keine TEEs verwendet, gab es Nebenprojekte. Zum Beispiel **TEE-basierte Verwahrungslösungen

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 – jede Transaktion und jeder Vertragsstatus ist allen Teilnehmern zugänglich. Diese Offenheit schafft Probleme wie MEV (Miner Extractable Value)-Angriffe, Copy-Trading und die Offenlegung sensibler Geschäftslogik. Programmierbare Privatsphäre zielt darauf ab, diese Probleme zu lösen, indem sie Berechnungen auf privaten Daten ermöglicht, ohne die Daten selbst preiszugeben. Zwei aufkommende kryptografische Paradigmen machen dies möglich: Fully Homomorphic Encryption Virtual Machines (FHE-VM) und Zero-Knowledge (ZK) Koprozessoren. Diese Ansätze ermöglichen Off-Chain- oder verschlüsselte Berechnungen mit On-Chain-Verifizierung, wodurch die Vertraulichkeit gewahrt und gleichzeitig die vertrauenslose Korrektheit beibehalten wird. In diesem Bericht tauchen wir tief in die Architekturen von FHE-VMs und ZK-Koprozessoren ein, vergleichen ihre Kompromisse und untersuchen Anwendungsfälle in den Bereichen Finanzen, Identität, Gesundheitswesen, Datenmärkte und dezentrales maschinelles Lernen.

Fully Homomorphic Encryption Virtual Machine (FHE-VM)​

Fully Homomorphic Encryption (FHE) ermöglicht beliebige Berechnungen auf verschlüsselten Daten, ohne diese jemals zu entschlüsseln. Eine FHE Virtual Machine integriert diese Fähigkeit in Blockchain-Smart Contracts und ermöglicht so einen verschlüsselten Vertragsstatus und eine verschlüsselte Logik. In einer FHE-fähigen Blockchain (oft als fhEVM für EVM-kompatible Designs bezeichnet) bleiben alle Eingaben, der Vertragsspeicher und die Ausgaben während der gesamten Ausführung verschlüsselt. Dies bedeutet, dass Validatoren Transaktionen verarbeiten und den Status aktualisieren können, ohne sensible Werte zu erfahren, wodurch eine On-Chain-Ausführung mit Datenvertraulichkeit erreicht wird.

Architektur und Design von 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. Zum Beispiel führt Zamas FHEVM verschlüsselte Ganzzahlen (euint8, euint32 usw.), verschlüsselte Booleans (ebool) und sogar verschlüsselte Arrays als erstklassige Typen ein. Smart-Contract-Sprachen wie Solidity werden durch Bibliotheken oder neue Opcodes erweitert, sodass Entwickler arithmetische (add, mul usw.), logische Operationen und Vergleiche direkt auf Chiffretexten 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.

Verschlüsselter Statusspeicher wird unterstützt, sodass Vertragsvariablen 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 einziger globaler FHE-Schlüssel verwendet (unten diskutiert).
2. On-Chain homomorphe Berechnung: Miner/Validatoren führen den Vertrag mit verschlüsselten Opcodes aus. Sie führen dieselben deterministischen homomorphen Operationen auf den Chiffretexten durch, sodass ein Konsens über den verschlüsselten neuen Status erzielt werden kann. Entscheidend ist, dass Validatoren niemals Klartextdaten sehen – sie sehen nur „Kauderwelsch“-Chiffretext, können ihn 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 Ausgabechiffretext entschlüsseln. Andernfalls bleiben die Ergebnisse verschlüsselt und können als Eingaben für weitere Transaktionen verwendet werden (was aufeinanderfolgende Berechnungen auf persistentem verschlüsseltem Status ermöglicht).

Eine wichtige Designüberlegung ist das Schlüsselmanagement. Ein Ansatz sind benutzerspezifische Schlüssel, bei denen jeder Benutzer seinen geheimen Schlüssel besitzt und nur er die für ihn relevanten Ausgaben entschlüsseln kann. Dies maximiert die Privatsphäre (niemand sonst kann Ihre Daten jemals entschlüsseln), aber homomorphe Operationen können Daten, die unter verschiedenen Schlüsseln verschlüsselt sind, nicht ohne komplexe Multi-Schlüssel-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 Vertragsdaten, und eine verteilte Gruppe von Validatoren hält Anteile des Schwellenwert-Entschlüsselungsschlüssels. Die öffentlichen Verschlüsselungs- und Auswertungsschlüssel werden On-Chain veröffentlicht, sodass jeder Daten an das Netzwerk verschlüsseln kann; der private Schlüssel wird unter Validatoren aufgeteilt, die bei Bedarf im Rahmen eines Schwellenwertschemas gemeinsam entschlüsseln können. Um zu verhindern, dass die Kollusion von Validatoren die Privatsphäre gefährdet, verwendet Zama ein Schwellenwert-FHE-Protokoll (basierend auf ihrer Forschung Noah’s Ark) mit „Rauschflutung“, um partielle Entschlüsselungen sicher zu machen. Nur wenn ein ausreichendes Quorum von Validatoren kooperiert, kann ein Klartext wiederhergestellt werden, zum Beispiel um eine Leseanfrage zu bedienen. Im Normalbetrieb sieht jedoch kein einzelner Knoten jemals Klartext – Daten bleiben jederzeit On-Chain verschlüsselt.

Zugriffskontrolle ist eine weitere entscheidende Komponente. FHE-VM-Implementierungen umfassen detaillierte Kontrollen, um zu verwalten, wer (falls überhaupt) Entschlüsselungen auslösen oder auf bestimmte verschlüsselte Felder zugreifen kann. Zum Beispiel unterstützt Cyphers fhEVM Access Control Lists für Chiffretexte, die es Entwicklern ermöglichen, anzugeben, welche Adressen oder Verträge mit bestimmten Daten interagieren oder diese erneut verschlüsseln können. Einige Frameworks unterstützen die Neuverschlüsselung: die Fähigkeit, einen verschlüsselten Wert von einem Benutzerschlüssel auf den eines anderen zu übertragen, ohne Klartext preiszugeben. Dies ist nützlich für Dinge wie Datenmarktplätze, bei denen ein Datenbesitzer einen Datensatz mit seinem Schlüssel verschlüsseln und nach dem Kauf auf den Schlüssel des Käufers neu verschlüsseln kann – alles On-Chain, ohne jemals öffentlich zu entschlüsseln.

Gewährleistung von Korrektheit und Privatsphäre​

Man könnte fragen: Wenn alle Daten verschlüsselt sind, wie setzen wir die Korrektheit der Vertragslogik durch? Wie kann die Kette ungültige Operationen verhindern, wenn sie die Werte nicht „sehen“ kann? FHE allein liefert keinen Korrektheitsbeweis – Validatoren können die homomorphen Schritte ausführen, aber sie können nicht von Natur aus erkennen, ob die verschlüsselte Eingabe eines Benutzers gültig war oder ob eine bedingte Verzweigung 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 typischerweise einen ZK-Beweis für bestimmte Klartextbedingungen liefern, wann immer dies erforderlich ist. Zamas Design verwendet zum Beispiel einen ZK Proof of Plaintext Knowledge (ZKPoK), der jede verschlüsselte Eingabe begleitet. Dies beweist, dass der Benutzer den Klartext kennt, der seinem Chiffretext entspricht, und dass er die erwarteten Kriterien erfüllt, ohne den Klartext selbst preiszugeben. Solche „zertifizierten Chiffretexte“ verhindern, dass ein böswilliger Benutzer eine fehlerhafte Verschlüsselung oder einen Wert außerhalb des Bereichs übermittelt. Ähnlich können Benutzer für Operationen, die eine Entscheidung erfordern (z. B. sicherstellen, dass Kontostand ≥ Abhebungsbetrag), einen ZK-Beweis liefern, dass diese Bedingung für die Klartexte erfüllt ist, bevor die verschlüsselte Operation ausgeführt wird. Auf diese Weise entschlüsselt oder sieht die Kette die Werte nicht, gewinnt aber die Gewissheit, dass die verschlüsselten Transaktionen den Regeln folgen.

Ein weiterer Ansatz bei FHE-Rollups besteht darin, die 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, ein Threshold Service Network, verschlüsselte Ergebnisse entschlüsseln oder verifizieren kann, und jede falsche Berechnung mit einem Betrugsbeweis angefochten werden kann. Im Allgemeinen stellt die Kombination von FHE + ZK oder Betrugsbeweisen sicher, dass die verschlüsselte Ausführung vertrauenslos bleibt. Validatoren entschlüsseln entweder nur gemeinsam, wenn sie dazu autorisiert sind, oder sie verifizieren Beweise, dass jeder verschlüsselte Statusübergang gültig war, ohne Klartext sehen zu müssen.

Leistungsüberlegungen: FHE-Operationen sind rechenintensiv – um viele Größenordnungen langsamer als normale Arithmetik. Zum Beispiel kostet eine einfache 64-Bit-Addition auf Ethereum ~3 Gas, während eine Addition auf einer verschlüsselten 64-Bit-Ganzzahl (euint64) unter Zamas FHEVM grob 188.000 Gas kostet. Selbst eine 8-Bit-Addition kann ~94k Gas kosten. Dieser enorme Overhead bedeutet, dass eine einfache Implementierung auf bestehenden Knoten unpraktisch langsam und kostspielig wäre. FHE-VM-Projekte begegnen dem mit optimierten kryptografischen Bibliotheken (wie Zamas TFHE-rs-Bibliothek für binäres Gate-Bootstrapping) und benutzerdefinierten EVM-Modifikationen zur Leistungssteigerung. Zum Beispiel fügt Cyphers modifizierter Geth-Client neue Opcodes hinzu und optimiert die Ausführung homomorpher Anweisungen in C++/Assembly, um den Overhead zu minimieren. Dennoch erfordert das Erreichen eines nutzbaren Durchsatzes Beschleunigung. Laufende Arbeiten umfassen die Verwendung von GPUs, FPGAs und sogar spezialisierten photonischen Chips, um FHE-Berechnungen zu beschleunigen. Zama berichtet, dass sich ihre FHE-Leistung seit 2024 um das Hundertfache verbessert hat und Tausende von TPS mit GPU/FPGA-Beschleunigung anstrebt. Dedizierte FHE-Koprozessor-Server (wie Optalysys’ LightLocker Node) können an Validatorknoten angeschlossen werden, um verschlüsselte Operationen auf Hardware auszulagern, und unterstützen >100 verschlüsselte ERC-20-Transfers pro Sekunde pro Knoten. Mit der Verbesserung von Hardware und Algorithmen wird sich die Lücke zwischen FHE und einfacher Berechnung verringern, wodurch private Verträge praktischere Geschwindigkeiten erreichen können.

Kompatibilität: Ein Hauptziel von FHE-VM-Designs ist es, mit bestehenden Entwicklungsworkflows kompatibel zu bleiben. Cyphers und Zamas fhEVM-Implementierungen ermöglichen es Entwicklern, Verträge 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 erfolgen. Dies senkt die Eintrittsbarriere: Entwickler müssen keine Kryptografieexperten sein, um einen vertraulichen Smart Contract zu schreiben. Zum Beispiel kann eine einfache Addition zweier Zahlen als euint32 c = a + b; geschrieben werden, und die FHEVM kümmert sich im Hintergrund um die verschlüsselungsspezifischen Details. Die Verträge können sogar mit normalen Verträgen interoperieren – z. B. könnte ein verschlüsselter Vertrag bei Bedarf ein entschlüsseltes Ergebnis an einen Standardvertrag ausgeben, was eine Mischung aus privaten und öffentlichen Teilen in einem Ökosystem ermöglicht.

Aktuelle FHE-VM-Projekte​

Mehrere Projekte sind Pioniere in diesem Bereich. Zama (ein Pariser FHE-Startup) entwickelte das Kernkonzept und die Bibliotheken der FHEVM (TFHE-rs und eine fhevm-solidity-Bibliothek). Sie beabsichtigen nicht, eine eigene Kette zu starten, sondern Infrastruktur für andere bereitzustellen. Inco ist eine L1-Blockchain (aufgebaut auf Cosmos SDK mit Evmos), die Zamas FHEVM integriert hat, um eine modulare vertrauliche Kette zu schaffen. Ihre Testnetze (Gentry und Paillier genannt) zeigen 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 verwendet. Es entschied sich für einen optimistischen (Betrugsbeweis-)Ansatz anstelle eines ZK-Rollups aufgrund der hohen Kosten, FHE und ZK für jeden Block zusammen zu verwenden. Fhenix verwendet dieselbe TFHE-rs-Bibliothek (mit einigen Modifikationen) und führt ein Threshold Service Network zur dezentralen Handhabung von Entschlüsselungen ein. 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 auf, das sich auf KI und Privatsphäre konzentriert und eine fhEVM mit Funktionen wie geheimen Speichern und Unterstützung für föderiertes Lernen verwendet. Das Ökosystem ist noch jung, wächst aber schnell, angetrieben durch erhebliche Finanzierungen – z. B. wurde Zama bis 2025 mit über 130 Millionen US-Dollar zu einem „Einhorn“, um die FHE-Technologie voranzutreiben.

Zusammenfassend ermöglicht eine FHE-VM datenschutzfreundliche Smart Contracts, 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 im Status offengelegt – während der bestehende Blockchain-Konsens für die Integrität genutzt wird. Die Kosten sind eine erhöhte Rechenlast für Validatoren und Komplexität im Schlüsselmanagement und der Beweisintegration. Als Nächstes untersuchen wir ein alternatives Paradigma, das die Berechnung vollständig Off-Chain auslagert und die Kette nur zur Verifizierung verwendet: den Zero-Knowledge-Koprozessor.

Zero-Knowledge-Koprozessoren (ZK-Koprozessoren)​

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

Architektur und Workflow​

In einem typischen Setup identifiziert ein dApp-Entwickler Teile seiner Anwendungslogik, die für die On-Chain-Ausführung zu teuer oder komplex sind (z. B. große Berechnungen über historische Daten, aufwendige Algorithmen, ML-Modellinferenz usw.). Er implementiert diese Teile als Off-Chain-Programm (in einer Hochsprache oder einem Schaltungs-DSL), das einen Zero-Knowledge Proof seiner Ausführung erzeugen kann. Die On-Chain-Komponente ist ein Verifizierer-Smart-Contract, der Beweise prüft und die Ergebnisse dem Rest des Systems zur Verfügung stellt. Der Ablauf lässt sich wie folgt zusammenfassen:

1. Anfrage – Der On-Chain-Vertrag löst eine Anfrage für eine bestimmte Off-Chain-Berechnung aus. Dies kann durch eine Benutzertransaktion oder durch einen Vertrag, der die Schnittstelle des ZK-Koprozessors aufruft, initiiert werden. Zum Beispiel könnte ein DeFi-Vertrag „proveInterestRate(currentState)“ aufrufen oder ein Benutzer „queryHistoricalData(query)“.
2. Off-Chain-Ausführung & Beweiserstellung – Ein Off-Chain-Dienst (der je nach Design ein dezentrales Netzwerk von Provern oder ein vertrauenswürdiger Dienst sein könnte) nimmt die Anfrage entgegen. Er sammelt alle erforderlichen Daten (On-Chain-Status, Off-Chain-Eingaben usw.) und führt die Berechnung in einer speziellen ZK Virtual Machine (ZKVM) oder Schaltung aus. Während der Ausführung wird eine Beweisspur generiert. Am Ende erstellt der Dienst einen prägnanten Beweis (z. B. einen SNARK oder STARK), der bescheinigt, dass „die Berechnung der Funktion F auf der Eingabe X das Ergebnis Y liefert“ und optional die Datenintegrität bescheinigt (mehr dazu unten).
3. On-Chain-Verifizierung – Der Beweis und das Ergebnis werden an die Blockchain zurückgegeben (oft über eine Callback-Funktion). Der Verifizierer-Vertrag prüft die Gültigkeit des Beweises mittels effizienter kryptografischer Verifizierung (Pairing-Checks usw.). Wenn gültig, kann der Vertrag nun dem Ergebnis Y als korrekt vertrauen. Das Ergebnis kann im Status gespeichert, als Ereignis ausgegeben oder in weitere Vertragslogik eingespeist werden. Wenn der Beweis ungültig ist oder nicht innerhalb einer bestimmten Zeit bereitgestellt wird, kann die Anfrage als fehlgeschlagen betrachtet werden (und möglicherweise wird eine Fallback- oder Timeout-Logik ausgelöst).

Kritisch ist, dass die On-Chain-Gaskosten für die Verifizierung konstant sind (oder 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 liegen (ein Bruchteil eines Ethereum-Blocks), aber dieser Beweis könnte Millionen von Off-Chain durchgeführten Rechenschritten repräsentieren. Wie ein Entwickler witzelte: „Möchten Sie eine digitale Signatur beweisen? ~15 $. Möchten Sie eine Million Signaturen beweisen? Auch ~15$.“. Diese Skalierbarkeit ist ein großer Gewinn: dApps können komplexe Funktionalitäten (Big-Data-Analysen, aufwendige Finanzmodelle usw.) anbieten, ohne die Blockchain zu überlasten.

Die Hauptkomponenten eines ZK-Koprozessor-Systems sind:

• Beweisgenerierungsumgebung: Dies kann eine allgemeine ZKVM (die beliebige Programme ausführen kann) oder benutzerdefinierte Schaltungen sein, die auf spezifische Berechnungen zugeschnitten sind. Ansätze variieren:

  • Einige Projekte verwenden handgefertigte Schaltungen für jede unterstützte Abfrage oder Funktion (maximale Effizienz für diese Funktion).
  • Andere bieten eine Domain-Specific Language (DSL) oder eine Embedded DSL an, die Entwickler verwenden, um ihre Off-Chain-Logik zu schreiben, die dann in Schaltungen kompiliert wird (Balance zwischen Benutzerfreundlichkeit und Leistung).
  • Der flexibelste Ansatz ist eine zkVM: eine virtuelle Maschine (oft basierend auf RISC-Architekturen), in der Programme in Standardsprachen (Rust, C usw.) geschrieben und automatisch bewiesen werden können. Dies opfert Leistung (die Simulation einer CPU in einer Schaltung fügt Overhead hinzu) für maximale Entwicklererfahrung.

• Datenzugriff und Integrität: Eine einzigartige Herausforderung besteht darin, die Off-Chain-Berechnung mit den richtigen Daten zu versorgen, insbesondere wenn diese Daten auf der Blockchain liegen (vergangene Blöcke, Vertragszustände usw.). Eine naive Lösung besteht darin, den Prover von einem Archivknoten lesen zu lassen und ihm zu vertrauen – dies führt jedoch zu Vertrauensannahmen. ZK-Koprozessoren beweisen stattdessen typischerweise, dass alle verwendeten On-Chain-Daten tatsächlich authentisch waren, indem sie auf Merkle-Beweise oder Status-Commitments verweisen. Zum Beispiel könnte das Abfrageprogramm eine Blocknummer und einen Merkle-Beweis eines Speicherplatzes oder einer Transaktion entgegennehmen, und die Schaltung wird diesen Beweis gegen einen bekannten Block-Header-Hash verifizieren. Es gibt drei Muster:

  1. Inline-Daten: Die benötigten Daten On-Chain ablegen (als Eingabe für den Verifizierer), damit sie direkt überprüft werden können. Dies ist für große Daten sehr kostspielig und untergräbt den ganzen Sinn.
  2. Einem Orakel vertrauen: Einen Orakel-Dienst die Daten an den Beweis liefern lassen und dafür bürgen. Dies ist einfacher, führt aber das Vertrauen in eine dritte Partei wieder ein.
  3. Dateninklusion über ZK beweisen: Beweise für die Dateninklusion in der Kettengeschichte innerhalb der Zero-Knowledge-Schaltung selbst integrieren. Dies nutzt die Tatsache, dass jeder Ethereum-Block-Header den gesamten vorherigen Status (über den Status-Root) und die Transaktionshistorie festschreibt. Durch die Verifizierung von Merkle-Patricia-Beweisen der Daten innerhalb der Schaltung versichert der Ausgabebeweis dem Vertrag, dass „diese Berechnung echte Blockchain-Daten von Block N verwendet hat“ ohne zusätzliche Vertrauenswürdigkeit.

  Der dritte Ansatz ist der vertrauensloseste und wird von fortgeschrittenen ZK-Koprozessoren wie Axiom und Xpansion verwendet (er erhöht zwar die Beweiskosten, ist aber aus Sicherheitsgründen vorzuziehen). Zum Beispiel modelliert Axioms System die Blockstruktur, den Status-Trie und den Transaktions-Trie von Ethereum in seinen Schaltungen, sodass es Aussagen wie „das Konto X hatte zum Block N den Saldo Y“ oder „eine Transaktion mit bestimmten Eigenschaften erfolgte in Block N“ beweisen kann. Es nutzt die Tatsache, dass man, gegeben einen kürzlich vertrauenswürdigen Block-Hash, die Inklusion historischer Daten rekursiv beweisen kann, ohne einer externen Partei zu vertrauen.

• Verifizierer-Vertrag: Dieser On-Chain-Vertrag enthält den Verifizierungsschlüssel und die Logik zum Akzeptieren oder Ablehnen von Beweisen. Für SNARKs wie Groth16 oder PLONK könnte der Verifizierer einige elliptische Kurvenpaarungen durchführen; für STARKs könnte er einige Hash-Berechnungen durchführen. Leistungsoptimierungen wie Aggregation und Rekursion können die On-Chain-Last minimieren. Zum Beispiel verwendet RISC Zeros Bonsai einen STARK-zu-SNARK-Wrapper: Es betreibt eine STARK-basierte VM Off-Chain für Geschwindigkeit, generiert dann aber einen kleinen SNARK-Beweis, der die Gültigkeit des STARK bescheinigt. Dies reduziert die Beweisgröße von Hunderten von Kilobytes auf wenige Hundert Bytes, wodurch die On-Chain-Verifizierung machbar und kostengünstig wird. Der Solidity-Verifizierer prüft dann einfach den SNARK (was eine Operation mit konstanter Zeit ist).

In Bezug auf die Bereitstellung können ZK-Koprozessoren 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 Anfragen an Axioms Prover-Netzwerk senden und Beweise On-Chain erhalten. Axioms Slogan war, Ethereum-Verträgen „vertrauenslosen Zugriff auf alle On-Chain-Daten und beliebige expressive Berechnungen darüber“ zu ermöglichen. Es fungiert effektiv als Abfrageorakel, dessen Antworten durch ZKPs anstelle von Vertrauen verifiziert werden. Andere, wie RISC Zeros Bonsai, bieten eine offenere Plattform: Jeder Entwickler kann ein Programm (kompiliert zu einer RISC-V-kompatiblen ZKVM) hochladen und Bonsais Beweisdienst über einen Relay-Vertrag nutzen. Das Relay-Muster, wie in Abbildung 1 dargestellt, beinhaltet einen Vertrag, der Anfragen und Antworten vermittelt: Der dApp-Vertrag ruft das Relay auf, um einen Beweis anzufordern, der Off-Chain-Dienst lauscht darauf (z. B. über Ereignis oder direkten Aufruf), berechnet den Beweis, und dann ruft das Relay eine Callback-Funktion auf dem dApp-Vertrag mit dem Ergebnis und dem Beweis auf. Dieses asynchrone Modell ist notwendig, da die Beweiserstellung je nach Komplexität Sekunden bis Minuten dauern kann. Es führt eine Latenz ein (und eine Lebendigkeitsannahme, dass der Prover antworten wird), während FHE-VM-Berechnungen synchron innerhalb eines Blocks stattfinden. Die Gestaltung der Anwendung zur Handhabung dieses asynchronen Workflows (möglicherweise ähnlich wie bei Oracle-Antworten) ist Teil der Verwendung eines ZK-Koprozessors.

Bemerkenswerte ZK-Koprozessor-Projekte​

• Axiom: Axiom ist ein ZK-Koprozessor, der auf Ethereum zugeschnitten ist und sich ursprünglich auf das Beweisen historischer On-Chain-Datenabfragen konzentrierte. Es verwendet das Halo2-Beweis-Framework (ein Plonk-ähnlicher SNARK), um Beweise zu erstellen, die Ethereums kryptografische Strukturen integrieren. In Axioms System kann ein Entwickler Dinge abfragen wie „wie war der Status von Vertrag X in Block N?“ oder eine Berechnung über alle Transaktionen in einem Bereich durchführen. Unter der Haube mussten Axioms Schaltungen Ethereums Status-/Trie-Logik implementieren, sogar elliptische Kurvenoperationen und SNARK-Verifizierung innerhalb der Schaltung durchführen, um Rekursion zu unterstützen. Trail of Bits bemerkte in einem Audit die Komplexität von Axioms Halo2-Schaltungen, die ganze Blöcke und Zustände modellieren. Nach dem Audit verallgemeinerte Axiom ihre Technologie zu einer OpenVM, die die Beweisführung beliebigen Rust-Codes mit derselben Halo2-basierten Infrastruktur ermöglicht. (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, wodurch ein zustandsloser Zugriff auf beliebige historische Daten mit kryptografischer Integrität ermöglicht wird. Sie haben auch die Sicherheit betont, indem sie unterbeschränkte Schaltungsfehler gefunden und behoben und die Korrektheit sichergestellt haben. Obwohl Axioms ursprüngliches Produkt während ihrer Neuausrichtung eingestellt wurde, bleibt ihr Ansatz ein Meilenstein bei ZK-Koprozessoren.

• RISC Zero Bonsai: RISC Zero ist eine ZKVM, die auf der RISC-V-Architektur basiert. Ihre zkVM kann beliebige Programme (geschrieben in Rust, C++ und anderen Sprachen, die nach RISC-V kompiliert werden) ausführen und einen STARK-Beweis der Ausführung erzeugen. Bonsai ist RISC Zeros Cloud-Dienst, der diese Beweiserstellung bei Bedarf bereitstellt und als Koprozessor für Smart Contracts fungiert. Um es zu verwenden, 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 Verifizierer-Vertrag bereit. Wenn der Vertrag diese Berechnung benötigt, ruft er das Bonsai-Relay auf, das die Beweisgenerierung auslöst und das Ergebnis über einen Callback zurückgibt. Eine demonstrierte Anwendungsbeispiel war die Off-Chain-Governance-Berechnung: RISC Zero zeigte eine DAO, die Bonsai verwendete, um Stimmen zu zählen und komplexe Abstimmungsmetriken Off-Chain zu berechnen, und dann einen Beweis zu veröffentlichen, damit der On-Chain-Governor-Vertrag dem Ergebnis mit minimalen Gaskosten vertrauen konnte. Die Technologie von RISC Zero betont, dass Entwickler vertraute Programmierparadigmen verwenden können – zum Beispiel eine Rust-Funktion schreiben, um etwas zu berechnen – und die schwere Arbeit der Schaltungserstellung von der zkVM übernommen wird. Allerdings können Beweise groß sein, daher 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 Ethereum Sepolia Testnet, was in der Größenordnung von 300.000 Gas pro Beweis kostete. Dies öffnet die Tür für Ethereum-dApps, Bonsai heute als Skalierungs- und Datenschutzlösung zu nutzen. (Bonsai ist noch in der Alpha-Phase, nicht produktionsreif und verwendet ein temporäres SNARK-Setup ohne Zeremonie.)

• Andere: Es gibt zahlreiche weitere Akteure und Forschungsinitiativen. Expansion/Xpansion (wie in einem Blog erwähnt) verwendet einen eingebetteten DSL-Ansatz, bei dem Entwickler Abfragen über On-Chain-Daten mit einer spezialisierten Sprache schreiben können, und es die Beweisgenerierung intern handhabt. StarkWares Cairo und Polygons zkEVM sind allgemeinere ZK-Rollup-VMs, aber ihre Technologie könnte für koprozessorähnliche Anwendungen wiederverwendet werden, indem Beweise in L1-Verträgen verifiziert werden. Wir sehen auch Projekte im Bereich ZKML (ZK Machine Learning), die effektiv als Koprozessoren fungieren, um ML-Modellinferenzen oder Trainingsergebnisse On-Chain zu verifizieren. Zum Beispiel kann ein zkML-Setup beweisen, dass „eine neuronale Netzwerk-Inferenz auf privaten Eingaben die Klassifizierung X erzeugt hat“, ohne die Eingaben offenzulegen oder die Berechnung On-Chain durchzuführen. Dies sind Sonderfälle des Koprozessorkonzepts, die auf KI angewendet werden.

Vertrauensannahmen: ZK-Koprozessoren verlassen sich auf die Korrektheit der kryptografischen Beweise. Wenn das Beweissystem sicher ist (und ein eventuelles Trusted Setup ehrlich durchgeführt wird), dann garantiert ein akzeptierter Beweis, dass die Berechnung korrekt war. Es ist kein zusätzliches Vertrauen in den Prover erforderlich – selbst ein böswilliger Prover kann den Verifizierer nicht von einer falschen Aussage überzeugen. Es gibt jedoch eine Lebendigkeitsannahme: 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 Verifizierer nicht wissen, ob diese Daten ehrlich bereitgestellt wurden, es sei denn, es werden zusätzliche Maßnahmen (wie Daten-Commitments oder Orakel-Signaturen) verwendet. Aber für rein On-Chain-Datenberechnungen stellen die beschriebenen Mechanismen eine Vertrauenslosigkeit sicher, die der Kette selbst entspricht (Axiom argumentierte, dass ihre Beweise für historische Abfragen „kryptografisch äquivalente Sicherheit wie Ethereum“ bieten).

Privatsphäre: Zero-Knowledge Proofs unterstützen auch von Natur aus die Privatsphäre – der Prover kann Eingaben verborgen halten, während er Aussagen darüber beweist. Im Kontext eines Koprozessors bedeutet dies, dass ein Beweis einem Vertrag ermöglichen kann, ein Ergebnis zu verwenden, das aus privaten Daten abgeleitet wurde. Zum Beispiel könnte ein Beweis zeigen: „Der Kredit-Score des Benutzers > 700, also Kredit genehmigen“, ohne den tatsächlichen Kredit-Score oder Rohdaten preiszugeben. Axioms Anwendungsfall betraf eher öffentlich bekannte Daten (Blockchain-Historie), daher lag der Fokus dort nicht auf der Privatsphäre. Aber RISC Zeros zkVM könnte 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 geht On-Chain. Es ist erwähnenswert, dass ein ZK-Beweis im Gegensatz zu FHE normalerweise keine fortlaufende Vertraulichkeit des Status bietet – es ist ein einmaliger Beweis. Wenn ein Workflow die Aufrechterhaltung eines geheimen Status über Transaktionen hinweg erfordert, könnte man dies aufbauen, indem der Vertrag ein Commitment auf den Status speichert und jeder Beweis einen gültigen Statusübergang vom alten Commitment zum neuen zeigt, wobei Geheimnisse verborgen bleiben. Dies ist im Wesentlichen die Funktionsweise von zk-Rollups für private Transaktionen (wie Aztec oder Zcash). ZK-Koprozessoren 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 die Eingabe oder die Ausgabe (oder beides) bei Bedarf privat sein kann.

Entwicklererfahrung: Die Verwendung eines ZK-Koprozessors erfordert typischerweise das Erlernen neuer Tools. Das Schreiben benutzerdefinierter Schaltungen (Option (1) oben) ist ziemlich komplex und wird normalerweise nur für eng definierte Zwecke durchgeführt. Höherwertige Optionen wie DSLs oder zkVMs erleichtern das Leben, fügen aber dennoch Overhead hinzu: Der Entwickler muss Off-Chain-Code schreiben und bereitstellen und die Interaktion verwalten. Im Gegensatz zur FHE-VM, wo die Verschlüsselung größtenteils im Hintergrund abläuft und der Entwickler normalen Smart-Contract-Code schreibt, muss der Entwickler hier seine Logik partitionieren und möglicherweise in einer anderen Sprache (Rust usw.) für den Off-Chain-Teil schreiben. Initiativen wie Noir, Leo, Circom DSLs oder RISC Zeros Ansatz verbessern jedoch schnell die Zugänglichkeit. Zum Beispiel bietet RISC Zero Vorlagen und Foundry-Integration, sodass ein Entwickler seinen Off-Chain-Code lokal simulieren (zur Korrektheit) und ihn dann nahtlos über den Bonsai-Callback in Solidity-Tests einbinden kann. Im Laufe der Zeit können wir Entwicklungsframeworks erwarten, die abstrahieren, ob ein Logikteil über ZK-Beweis oder On-Chain ausgeführt wird – der Compiler oder die Tools könnten dies basierend auf den Kosten entscheiden.

FHE-VM vs. ZK-Koprozessor: Vergleich​

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

Programmable Privacy in Blockchain: Off‑Chain Compute with On‑Chain Verification

Public blockchains provide transparency and integrity at the cost of privacy – every transaction and contract state is exposed to all participants. This openness creates problems like MEV (Miner Extractable Value) attacks, copy-trading, and leakage of sensitive business logic. Programmable privacy aims to solve these issues by allowing computations on private data without revealing the data itself. Two emerging cryptographic paradigms are making this possible: Fully Homomorphic Encryption Virtual Machines (FHE-VM) and Zero-Knowledge (ZK) Coprocessors. These approaches enable off-chain or encrypted computation with on-chain verification, preserving confidentiality while retaining trustless correctness. In this report, we dive deep into FHE-VM and ZK-coprocessor architectures, compare their trade-offs, and explore use cases across finance, identity, healthcare, data markets, and decentralized machine learning.

Fully Homomorphic Encryption Virtual Machine (FHE-VM)​

Fully Homomorphic Encryption (FHE) allows arbitrary computations on encrypted data without ever decrypting it. An FHE Virtual Machine integrates this capability into blockchain smart contracts, enabling encrypted contract state and logic. In an FHE-enabled blockchain (often called an fhEVM for EVM-compatible designs), all inputs, contract storage, and outputs remain encrypted throughout execution. This means validators can process transactions and update state without learning any sensitive values, achieving on-chain execution with data confidentiality.

Architecture and Design of FHE-VM​

A typical FHE-VM extends a standard smart contract runtime (like the Ethereum Virtual Machine) with native support for encrypted data types and operations. For example, Zama’s FHEVM introduces encrypted integers (euint8, euint32, etc.), encrypted booleans (ebool), and even encrypted arrays as first-class types. Smart contract languages like Solidity are augmented via libraries or new opcodes so developers can perform arithmetic (add, mul, etc.), logical operations, and comparisons directly on ciphertexts. Under the hood, these operations invoke FHE primitives (e.g. using the TFHE library) to manipulate encrypted bits and produce encrypted results.

Encrypted state storage is supported so that contract variables remain encrypted in the blockchain state. The execution flow is typically:

1. Client-Side Encryption: Users encrypt their inputs locally using the public FHE key before sending transactions. The encryption key is public (for encryption and evaluation), while the decryption key remains secret. In some designs, each user manages their own key; in others, a single global FHE key is used (discussed below).
2. On-Chain Homomorphic Computation: Miners/validators execute the contract with encrypted opcodes. They perform the same deterministic homomorphic operations on the ciphertexts, so consensus can be reached on the encrypted new state. Crucially, validators never see plaintext data – they just see “gibberish” ciphertext but can still process it consistently.
3. Decryption (Optional): If a result needs to be revealed or used off-chain, an authorized party with the private key can decrypt the output ciphertext. Otherwise, results remain encrypted and can be used as inputs to further transactions (allowing consecutive computations on persistent encrypted state).

A major design consideration is key management. One approach is per-user keys, where each user holds their secret key and only they can decrypt outputs relevant to them. This maximizes privacy (no one else can ever decrypt your data), but homomorphic operations cannot mix data encrypted under different keys without complex multi-key protocols. Another approach, used by Zama’s FHEVM, is a global FHE key: a single public key encrypts all contract data and a distributed set of validators holds shares of the threshold decryption key. The public encryption and evaluation keys are published on-chain, so anyone can encrypt data to the network; the private key is split among validators who can collectively decrypt if needed under a threshold scheme. To prevent validator collusion from compromising privacy, Zama employs a threshold FHE protocol (based on their Noah’s Ark research) with “noise flooding” to make partial decryptions secure. Only if a sufficient quorum of validators cooperates can a plaintext be recovered, for example to serve a read request. In normal operation, however, no single node ever sees plaintext – data remains encrypted on-chain at all times.

Access control is another crucial component. FHE-VM implementations include fine-grained controls to manage who (if anyone) can trigger decryptions or access certain encrypted fields. For instance, Cypher’s fhEVM supports Access Control Lists on ciphertexts, allowing developers to specify which addresses or contracts can interact with or re-encrypt certain data. Some frameworks support re-encryption: the ability to transfer an encrypted value from one user’s key to another’s without exposing plaintext. This is useful for things like data marketplaces, where a data owner can encrypt a dataset with their key, and upon purchase, re-encrypt it to the buyer’s key – all on-chain, without ever decrypting publicly.

Ensuring Correctness and Privacy​

One might ask: if all data is encrypted, how do we enforce correctness of contract logic? How can the chain prevent invalid operations if it can’t “see” the values? FHE by itself doesn’t provide a proof of correctness – validators can perform the homomorphic steps, but they can’t inherently tell if a user’s encrypted input was valid or if a conditional branch should be taken, etc., without decrypting. Zero-knowledge proofs (ZKPs) can complement FHE to solve this gap. In an FHE-VM, typically users must provide a ZK proof attesting to certain plaintext conditions whenever needed. Zama’s design, for example, uses a ZK Proof of Plaintext Knowledge (ZKPoK) to accompany each encrypted input. This proves that the user knows the plaintext corresponding to their ciphertext and that it meets expected criteria, without revealing the plaintext itself. Such “certified ciphertexts” prevent a malicious user from submitting a malformed encryption or an out-of-range value. Similarly, for operations that require a decision (e.g. ensure account balance ≥ withdrawal amount), the user can supply a ZK proof that this condition holds true on the plaintexts before the encrypted operation is executed. In this way, the chain doesn’t decrypt or see the values, but it gains confidence that the encrypted transactions follow the rules.

Another approach in FHE rollups is to perform off-chain validation with ZKPs. Fhenix (an L2 rollup using FHE) opts for an optimistic model where a separate network component called a Threshold Service Network can decrypt or verify encrypted results, and any incorrect computation can be challenged with a fraud-proof. In general, combining FHE + ZK or fraud proofs ensures that encrypted execution remains trustless. Validators either collectively decrypt only when authorized, or they verify proofs that each encrypted state transition was valid without needing to see plaintext.

Performance considerations: FHE operations are computationally heavy – many orders of magnitude slower than normal arithmetic. For example, a simple 64-bit addition on Ethereum costs ~3 gas, whereas an addition on an encrypted 64-bit integer (euint64) under Zama’s FHEVM costs roughly 188,000 gas. Even an 8-bit add can cost ~94k gas. This enormous overhead means a straightforward implementation on existing nodes would be impractically slow and costly. FHE-VM projects tackle this with optimized cryptographic libraries (like Zama’s TFHE-rs library for binary gate bootstrapping) and custom EVM modifications for performance. For instance, Cypher’s modified Geth client adds new opcodes and optimizes homomorphic instruction execution in C++/assembly to minimize overhead. Nevertheless, achieving usable throughput requires acceleration. Ongoing work includes using GPUs, FPGAs, and even specialized photonic chips to speed up FHE computations. Zama reports their FHE performance improved 100× since 2024 and is targeting thousands of TPS with GPU/FPGA acceleration. Dedicated FHE co-processor servers (such as Optalysys’s LightLocker Node) can plug into validator nodes to offload encrypted operations to hardware, supporting >100 encrypted ERC-20 transfers per second per node. As hardware and algorithms improve, the gap between FHE and plain computation will narrow, enabling private contracts to approach more practical speeds.

Compatibility: A key goal of FHE-VM designs is to remain compatible with existing development workflows. Cypher’s and Zama’s fhEVM implementations allow developers to write contracts in Solidity with minimal changes – using a library to declare encrypted types and operations. The rest of the Ethereum toolchain (Remix, Hardhat, etc.) can still be used, as the underlying modifications are mostly at the client/node level. This lowers the barrier to entry: developers don’t need to be cryptography experts to write a confidential smart contract. For example, a simple addition of two numbers can be written as euint32 c = a + b; and the FHEVM will handle the encryption-specific details behind the scenes. The contracts can even interoperate with normal contracts – e.g. an encrypted contract could output a decrypted result to a standard contract if desired, allowing a mix of private and public parts in one ecosystem.

Aktuelle FHE-VM-Projekte​

Mehrere Projekte sind Pioniere in diesem Bereich. Zama (ein Pariser FHE-Startup) entwickelte das Kernkonzept und die Bibliotheken der FHEVM (TFHE-rs und eine fhevm-solidity-Bibliothek). Sie beabsichtigen nicht, eine eigene Kette zu starten, sondern Infrastruktur für andere bereitzustellen. Inco ist eine L1-Blockchain (aufgebaut auf Cosmos SDK mit Evmos), die Zamas FHEVM integriert hat, um eine modulare vertrauliche Kette zu schaffen. Ihre Testnetze (Gentry und Paillier genannt) zeigen 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 verwendet. Es entschied sich für einen optimistischen (Betrugsbeweis-)Ansatz anstelle eines ZK-Rollups aufgrund der hohen Kosten, FHE und ZK für jeden Block zusammen zu verwenden. Fhenix verwendet dieselbe TFHE-rs-Bibliothek (mit einigen Modifikationen) und führt ein Threshold Service Network zur dezentralen Handhabung von Entschlüsselungen ein. 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 auf, das sich auf KI und Privatsphäre konzentriert und eine fhEVM mit Funktionen wie geheimen Speichern und Unterstützung für föderiertes Lernen verwendet. Das Ökosystem ist noch jung, wächst aber schnell, angetrieben durch erhebliche Finanzierungen – z. B. wurde Zama bis 2025 mit über 130 Millionen US-Dollar zu einem „Einhorn“, um die FHE-Technologie voranzutreiben.

Zusammenfassend ermöglicht eine FHE-VM datenschutzfreundliche Smart Contracts, 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 im Status offengelegt – während der bestehende Blockchain-Konsens für die Integrität genutzt wird. Die Kosten sind eine erhöhte Rechenlast für Validatoren und Komplexität im Schlüsselmanagement und der Beweisintegration. Als Nächstes untersuchen wir ein alternatives Paradigma, das die Berechnung vollständig Off-Chain auslagert und die Kette nur zur Verifizierung verwendet: den Zero-Knowledge-Koprozessor.

Zero-Knowledge-Koprozessoren (ZK-Koprozessoren)​

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

Architektur und Workflow​

In einem typischen Setup identifiziert ein dApp-Entwickler Teile seiner Anwendungslogik, die für die On-Chain-Ausführung zu teuer oder komplex sind (z. B. große Berechnungen über historische Daten, aufwendige Algorithmen, ML-Modellinferenz usw.). Er implementiert diese Teile als Off-Chain-Programm (in einer Hochsprache oder einem Schaltungs-DSL), das einen Zero-Knowledge Proof seiner Ausführung erzeugen kann. Die On-Chain-Komponente ist ein Verifizierer-Smart-Contract, der Beweise prüft und die Ergebnisse dem Rest des Systems zur Verfügung stellt. Der Ablauf lässt sich wie folgt zusammenfassen:

1. Anfrage – Der On-Chain-Vertrag löst eine Anfrage für eine bestimmte Off-Chain-Berechnung aus. Dies kann durch eine Benutzertransaktion oder durch einen Vertrag, der die Schnittstelle des ZK-Koprozessors aufruft, initiiert werden. Zum Beispiel könnte ein DeFi-Vertrag „proveInterestRate(currentState)“ aufrufen oder ein Benutzer „queryHistoricalData(query)“.
2. Off-Chain-Ausführung & Beweiserstellung – Ein Off-Chain-Dienst (der je nach Design ein dezentrales Netzwerk von Provern oder ein vertrauenswürdiger Dienst sein könnte) nimmt die Anfrage entgegen. Er sammelt alle erforderlichen Daten (On-Chain-Status, Off-Chain-Eingaben usw.) und führt die Berechnung in einer speziellen ZK Virtual Machine (ZKVM) oder Schaltung aus. Während der Ausführung wird eine Beweisspur generiert. Am Ende erstellt der Dienst einen prägnanten Beweis (z. B. einen SNARK oder STARK), der bescheinigt, dass „die Berechnung der Funktion F auf der Eingabe X das Ergebnis Y liefert“ und optional die Datenintegrität bescheinigt (mehr dazu unten).
3. On-Chain-Verifizierung – Der Beweis und das Ergebnis werden an die Blockchain zurückgegeben (oft über eine Callback-Funktion). Der Verifizierer-Vertrag prüft die Gültigkeit des Beweises mittels effizienter kryptografischer Verifizierung (Pairing-Checks usw.). Wenn gültig, kann der Vertrag nun dem Ergebnis Y als korrekt vertrauen. Das Ergebnis kann im Status gespeichert, als Ereignis ausgegeben oder in weitere Vertragslogik eingespeist werden. Wenn der Beweis ungültig ist oder nicht innerhalb einer bestimmten Zeit bereitgestellt wird, kann die Anfrage als fehlgeschlagen betrachtet werden (und möglicherweise wird eine Fallback- oder Timeout-Logik ausgelöst).

Kritisch ist, dass die On-Chain-Gaskosten für die Verifizierung konstant sind (oder 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 liegen (ein Bruchteil eines Ethereum-Blocks), aber dieser Beweis könnte Millionen von Off-Chain durchgeführten Rechenschritten repräsentieren. Wie ein Entwickler witzelte: „Möchten Sie eine digitale Signatur beweisen? ~15 $. Möchten Sie eine Million Signaturen beweisen? Auch ~15$.“. Diese Skalierbarkeit ist ein großer Gewinn: dApps können komplexe Funktionalitäten (Big-Data-Analysen, aufwendige Finanzmodelle usw.) anbieten, ohne die Blockchain zu überlasten.

Die Hauptkomponenten eines ZK-Koprozessor-Systems sind:

• Beweisgenerierungsumgebung: Dies kann eine allgemeine ZKVM (die beliebige Programme ausführen kann) oder benutzerdefinierte Schaltungen sein, die auf spezifische Berechnungen zugeschnitten sind. Ansätze variieren:

  • Einige Projekte verwenden handgefertigte Schaltungen für jede unterstützte Abfrage oder Funktion (maximale Effizienz für diese Funktion).
  • Andere bieten eine Domain-Specific Language (DSL) oder eine Embedded DSL an, die Entwickler verwenden, um ihre Off-Chain-Logik zu schreiben, die dann in Schaltungen kompiliert wird (Balance zwischen Benutzerfreundlichkeit und Leistung).
  • Der flexibelste Ansatz ist eine zkVM: eine virtuelle Maschine (oft basierend auf RISC-Architekturen), in der Programme in Standardsprachen (Rust, C usw.) geschrieben und automatisch bewiesen werden können. Dies opfert Leistung (die Simulation einer CPU in einer Schaltung fügt Overhead hinzu) für maximale Entwicklererfahrung.

• Datenzugriff und Integrität: Eine einzigartige Herausforderung besteht darin, die Off-Chain-Berechnung mit den richtigen Daten zu versorgen, insbesondere wenn diese Daten auf der Blockchain liegen (vergangene Blöcke, Vertragszustände usw.). Eine naive Lösung besteht darin, den Prover von einem Archivknoten lesen zu lassen und ihm zu vertrauen – dies führt jedoch zu Vertrauensannahmen. ZK-Koprozessoren beweisen stattdessen typischerweise, dass alle verwendeten On-Chain-Daten tatsächlich authentisch waren, indem sie auf Merkle-Beweise oder Status-Commitments verweisen. Zum Beispiel könnte das Abfrageprogramm eine Blocknummer und einen Merkle-Beweis eines Speicherplatzes oder einer Transaktion entgegennehmen, und die Schaltung wird diesen Beweis gegen einen bekannten Block-Header-Hash verifizieren. Es gibt drei Muster:

  1. Inline-Daten: Die benötigten Daten On-Chain ablegen (als Eingabe für den Verifizierer), damit sie direkt überprüft werden können. Dies ist für große Daten sehr kostspielig und untergräbt den ganzen Sinn.
  2. Einem Orakel vertrauen: Einen Orakel-Dienst die Daten an den Beweis liefern lassen und dafür bürgen. Dies ist einfacher, führt aber das Vertrauen in eine dritte Partei wieder ein.
  3. Dateninklusion über ZK beweisen: Beweise für die Dateninklusion in der Kettengeschichte innerhalb der Zero-Knowledge-Schaltung selbst integrieren. Dies nutzt die Tatsache, dass jeder Ethereum-Block-Header den gesamten vorherigen Status (über den Status-Root) und die Transaktionshistorie festschreibt. Durch die Verifizierung von Merkle-Patricia-Beweisen der Daten innerhalb der Schaltung versichert der Ausgabebeweis dem Vertrag, dass „diese Berechnung echte Blockchain-Daten von Block N verwendet hat“ ohne zusätzliche Vertrauenswürdigkeit.

  Der dritte Ansatz ist der vertrauensloseste und wird von fortgeschrittenen ZK-Koprozessoren wie Axiom und Xpansion verwendet (er erhöht zwar die Beweiskosten, ist aber aus Sicherheitsgründen vorzuziehen). Zum Beispiel modelliert Axioms System die Blockstruktur, den Status-Trie und den Transaktions-Trie von Ethereum in seinen Schaltungen, sodass es Aussagen wie „das Konto X hatte zum Block N den Saldo Y“ oder „eine Transaktion mit bestimmten Eigenschaften erfolgte in Block N“ beweisen kann. Es nutzt die Tatsache, dass man, gegeben einen kürzlich vertrauenswürdigen Block-Hash, die Inklusion historischer Daten rekursiv beweisen kann, ohne einer externen Partei zu vertrauen.

• Verifizierer-Vertrag: Dieser On-Chain-Vertrag enthält den Verifizierungsschlüssel und die Logik zum Akzeptieren oder Ablehnen von Beweisen. Für SNARKs wie Groth16 oder PLONK könnte der Verifizierer einige elliptische Kurvenpaarungen durchführen; für STARKs könnte er einige Hash-Berechnungen durchführen. Leistungsoptimierungen wie Aggregation und Rekursion können die On-Chain-Last minimieren. Zum Beispiel verwendet RISC Zeros Bonsai einen STARK-zu-SNARK-Wrapper: Es betreibt eine STARK-basierte VM Off-Chain für Geschwindigkeit, generiert dann aber einen kleinen SNARK-Beweis, der die Gültigkeit des STARK bescheinigt. Dies reduziert die Beweisgröße von Hunderten von Kilobytes auf wenige Hundert Bytes, wodurch die On-Chain-Verifizierung machbar und kostengünstig wird. Der Solidity-Verifizierer prüft dann einfach den SNARK (was eine Operation mit konstanter Zeit ist).

In Bezug auf die Bereitstellung können ZK-Koprozessoren 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 Anfragen an Axioms Prover-Netzwerk senden und Beweise On-Chain erhalten. Axioms Slogan war, Ethereum-Verträgen „vertrauenslosen Zugriff auf alle On-Chain-Daten und beliebige expressive Berechnungen darüber“ zu ermöglichen. Es fungiert effektiv als Abfrageorakel, dessen Antworten durch ZKPs anstelle von Vertrauen verifiziert werden. Andere, wie RISC Zeros Bonsai, bieten eine offenere Plattform: Jeder Entwickler kann ein Programm (kompiliert zu einer RISC-V-kompatiblen ZKVM) hochladen und Bonsais Beweisdienst über einen Relay-Vertrag nutzen. Das Relay-Muster, wie in Abbildung 1 dargestellt, beinhaltet einen Vertrag, der Anfragen und Antworten vermittelt: Der dApp-Vertrag ruft das Relay auf, um einen Beweis anzufordern, der Off-Chain-Dienst lauscht darauf (z. B. über Ereignis oder direkten Aufruf), berechnet den Beweis, und dann ruft das Relay eine Callback-Funktion auf dem dApp-Vertrag mit dem Ergebnis und dem Beweis auf. Dieses asynchrone Modell ist notwendig, da die Beweiserstellung je nach Komplexität Sekunden bis Minuten dauern kann. Es führt eine Latenz ein (und eine Lebendigkeitsannahme, dass der Prover antworten wird), während FHE-VM-Berechnungen synchron innerhalb eines Blocks stattfinden. Die Gestaltung der Anwendung zur Handhabung dieses asynchronen Workflows (möglicherweise ähnlich wie bei Oracle-Antworten) ist Teil der Verwendung eines ZK-Koprozessors.

Bemerkenswerte ZK-Koprozessor-Projekte​

• Axiom: Axiom ist ein ZK-Koprozessor, der auf Ethereum zugeschnitten ist und sich ursprünglich auf das Beweisen historischer On-Chain-Datenabfragen konzentrierte. Es verwendet das Halo2-Beweis-Framework (ein Plonk-ähnlicher SNARK), um Beweise zu erstellen, die Ethereums kryptografische Strukturen integrieren. In Axioms System kann ein Entwickler Dinge abfragen wie „wie war der Status von Vertrag X in Block N?“ oder eine Berechnung über alle Transaktionen in einem Bereich durchführen. Unter der Haube mussten Axioms Schaltungen Ethereums Status-/Trie-Logik implementieren, sogar elliptische Kurvenoperationen und SNARK-Verifizierung innerhalb der Schaltung durchführen, um Rekursion zu unterstützen. Trail of Bits bemerkte in einem Audit die Komplexität von Axioms Halo2-Schaltungen, die ganze Blöcke und Zustände modellieren. Nach dem Audit verallgemeinerte Axiom ihre Technologie zu einer OpenVM, die die Beweisführung beliebigen Rust-Codes mit derselben Halo2-basierten Infrastruktur ermöglicht. (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, wodurch ein zustandsloser Zugriff auf beliebige historische Daten mit kryptografischer Integrität ermöglicht wird. Sie haben auch die Sicherheit betont, indem sie unterbeschränkte Schaltungsfehler gefunden und behoben und die Korrektheit sichergestellt haben. Obwohl Axioms ursprüngliches Produkt während ihrer Neuausrichtung eingestellt wurde, bleibt ihr Ansatz ein Meilenstein bei ZK-Koprozessoren.

• RISC Zero Bonsai: RISC Zero ist eine ZKVM, die auf der RISC-V-Architektur basiert. Ihre zkVM kann beliebige Programme (geschrieben in Rust, C++ und anderen Sprachen, die nach RISC-V kompiliert werden) ausführen und einen STARK-Beweis der Ausführung erzeugen. Bonsai ist RISC Zeros Cloud-Dienst, der diese Beweiserstellung bei Bedarf bereitstellt und als Koprozessor für Smart Contracts fungiert. Um es zu verwenden, 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 Verifizierer-Vertrag bereit. Wenn der Vertrag diese Berechnung benötigt, ruft er das Bonsai-Relay auf, das die Beweisgenerierung auslöst und das Ergebnis über einen Callback zurückgibt. Eine demonstrierte Anwendungsbeispiel war die Off-Chain-Governance-Berechnung: RISC Zero zeigte eine DAO, die Bonsai verwendete, um Stimmen zu zählen und komplexe Abstimmungsmetriken Off-Chain zu berechnen, und dann einen Beweis zu veröffentlichen, damit der On-Chain-Governor-Vertrag dem Ergebnis mit minimalen Gaskosten vertrauen konnte. Die Technologie von RISC Zero betont, dass Entwickler vertraute Programmierparadigmen verwenden können – zum Beispiel eine Rust-Funktion schreiben, um etwas zu berechnen – und die schwere Arbeit der Schaltungserstellung von der zkVM übernommen wird. Allerdings können Beweise groß sein, daher 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 Ethereum Sepolia Testnet, was in der Größenordnung von 300.000 Gas pro Beweis kostete. Dies öffnet die Tür für Ethereum-dApps, Bonsai heute als Skalierungs- und Datenschutzlösung zu nutzen. (Bonsai ist noch in der Alpha-Phase, nicht produktionsreif und verwendet ein temporäres SNARK-Setup ohne Zeremonie.)

• Andere: Es gibt zahlreiche weitere Akteure und Forschungsinitiativen. Expansion/Xpansion (wie in einem Blog erwähnt) verwendet einen eingebetteten DSL-Ansatz, bei dem Entwickler Abfragen über On-Chain-Daten mit einer spezialisierten Sprache schreiben können, und es die Beweisgenerierung intern handhabt. StarkWares Cairo und Polygons zkEVM sind allgemeinere ZK-Rollup-VMs, aber ihre Technologie könnte für koprozessorähnliche Anwendungen wiederverwendet werden, indem Beweise in L1-Verträgen verifiziert werden. Wir sehen auch Projekte im Bereich ZKML (ZK Machine Learning), die effektiv als Koprozessoren fungieren, um ML-Modellinferenzen oder Trainingsergebnisse On-Chain zu verifizieren. Zum Beispiel kann ein zkML-Setup beweisen, dass „eine neuronale Netzwerk-Inferenz auf privaten Eingaben die Klassifizierung X erzeugt hat“, ohne die Eingaben offenzulegen oder die Berechnung On-Chain durchzuführen. Dies sind Sonderfälle des Koprozessorkonzepts, die auf KI angewendet werden.

Vertrauensannahmen: ZK-Koprozessoren verlassen sich auf die Korrektheit der kryptografischen Beweise. Wenn das Beweissystem sicher ist (und ein eventuelles Trusted Setup ehrlich durchgeführt wird), dann garantiert ein akzeptierter Beweis, dass die Berechnung korrekt war. Es ist kein zusätzliches Vertrauen in den Prover erforderlich – selbst ein böswilliger Prover kann den Verifizierer nicht von einer falschen Aussage überzeugen. Es gibt jedoch eine Lebendigkeitsannahme: 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 Verifizierer nicht wissen, ob diese Daten ehrlich bereitgestellt wurden, es sei denn, es werden zusätzliche Maßnahmen (wie Daten-Commitments oder Orakel-Signaturen) verwendet. Aber für rein On-Chain-Datenberechnungen stellen die beschriebenen Mechanismen eine Vertrauenslosigkeit sicher, die der Kette selbst entspricht (Axiom argumentierte, dass ihre Beweise für historische Abfragen „kryptografisch äquivalente Sicherheit wie Ethereum“ bieten).

Privatsphäre: Zero-Knowledge Proofs unterstützen auch von Natur aus die Privatsphäre – der Prover kann Eingaben verborgen halten, während er Aussagen darüber beweist. Im Kontext eines Koprozessors bedeutet dies, dass ein Beweis einem Vertrag ermöglichen kann, ein Ergebnis zu verwenden, das aus privaten Daten abgeleitet wurde. Zum Beispiel könnte ein Beweis zeigen: „Der Kredit-Score des Benutzers > 700, also Kredit genehmigen“, ohne den tatsächlichen Kredit-Score oder Rohdaten preiszugeben. Axioms Anwendungsfall betraf eher öffentlich bekannte Daten (Blockchain-Historie), daher lag der Fokus dort nicht auf der Privatsphäre. Aber RISC Zeros zkVM könnte 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 geht On-Chain. Es ist erwähnenswert, dass ein ZK-Beweis im Gegensatz zu FHE normalerweise keine fortlaufende Vertraulichkeit des Status bietet – es ist ein einmaliger Beweis. Wenn ein Workflow die Aufrechterhaltung eines geheimen Status über Transaktionen hinweg erfordert, könnte man dies aufbauen, indem der Vertrag ein Commitment auf den Status speichert und jeder Beweis einen gültigen Statusübergang vom alten Commitment zum neuen zeigt, wobei Geheimnisse verborgen bleiben. Dies ist im Wesentlichen die Funktionsweise von zk-Rollups für private Transaktionen (wie Aztec oder Zcash). ZK-Koprozessoren 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 die Eingabe oder die Ausgabe (oder beides) bei Bedarf privat sein kann.

Entwicklererfahrung: Die Verwendung eines ZK-Koprozessors erfordert typischerweise das Erlernen neuer Tools. Das Schreiben benutzerdefinierter Schaltungen (Option (1) oben) ist ziemlich komplex und wird normalerweise nur für eng definierte Zwecke durchgeführt. Höherwertige Optionen wie DSLs oder zkVMs erleichtern das Leben, fügen aber dennoch Overhead hinzu: Der Entwickler muss Off-Chain-Code schreiben und bereitstellen und die Interaktion verwalten. Im Gegensatz zur FHE-VM, wo die Verschlüsselung größtenteils im Hintergrund abläuft und der Entwickler normalen Smart-Contract-Code schreibt, muss der Entwickler hier seine Logik partitionieren und möglicherweise in einer anderen Sprache (Rust usw.) für den Off-Chain-Teil schreiben. Initiativen wie Noir, Leo, Circom DSLs oder RISC Zeros Ansatz verbessern jedoch schnell die Zugänglichkeit. Zum Beispiel bietet RISC Zero Vorlagen und Foundry-Integration, sodass ein Entwickler seinen Off-Chain-Code lokal simulieren (zur Korrektheit) und ihn dann nahtlos über den Bonsai-Callback in Solidity-Tests einbinden kann. Im Laufe der Zeit können wir Entwicklungsframeworks erwarten, die abstrahieren, ob ein Logikteil über ZK-Beweis oder On-Chain ausgeführt wird – der Compiler oder die Tools könnten dies basierend auf den Kosten entscheiden.

FHE-VM vs. ZK-Koprozessor: Vergleich​

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

Programmierbare Privatsphäre in der Blockchain: Off-Chain-Berechnung mit On-Chain-Verifizierung

Öffentliche Blockchains bieten Transparenz und Integrität auf Kosten der Privatsphäre – jede Transaktion und jeder Vertragsstatus ist allen Teilnehmern zugänglich. Diese Offenheit schafft Probleme wie MEV (Miner Extractable Value)-Angriffe, Copy-Trading und die Offenlegung sensibler Geschäftslogik. Programmierbare Privatsphäre zielt darauf ab, diese Probleme zu lösen, indem sie Berechnungen auf privaten Daten ermöglicht, ohne die Daten selbst preiszugeben. Zwei aufkommende kryptografische Paradigmen machen dies möglich: Fully Homomorphic Encryption Virtual Machines (FHE-VM) und Zero-Knowledge (ZK) Koprozessoren. Diese Ansätze ermöglichen Off-Chain- oder verschlüsselte Berechnungen mit On-Chain-Verifizierung, wodurch die Vertraulichkeit gewahrt und gleichzeitig die vertrauenslose Korrektheit beibehalten wird. In diesem Bericht tauchen wir tief in die Architekturen von FHE-VMs und ZK-Koprozessoren ein, vergleichen ihre Kompromisse und untersuchen Anwendungsfälle in den Bereichen Finanzen, Identität, Gesundheitswesen, Datenmärkte und dezentrales maschinelles Lernen.

Fully Homomorphic Encryption Virtual Machine (FHE-VM)​

Fully Homomorphic Encryption (FHE) ermöglicht beliebige Berechnungen auf verschlüsselten Daten, ohne diese jemals zu entschlüsseln. Eine FHE Virtual Machine integriert diese Fähigkeit in Blockchain-Smart Contracts und ermöglicht so einen verschlüsselten Vertragsstatus und eine verschlüsselte Logik. In einer FHE-fähigen Blockchain (oft als fhEVM für EVM-kompatible Designs bezeichnet) bleiben alle Eingaben, der Vertragsspeicher und die Ausgaben während der gesamten Ausführung verschlüsselt. Dies bedeutet, dass Validatoren Transaktionen verarbeiten und den Status aktualisieren können, ohne sensible Werte zu erfahren, wodurch eine On-Chain-Ausführung mit Datenvertraulichkeit erreicht wird.

Architektur und Design von 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. Zum Beispiel führt Zamas FHEVM verschlüsselte Ganzzahlen (euint8, euint32 usw.), verschlüsselte Booleans (ebool) und sogar verschlüsselte Arrays als erstklassige Typen ein. Smart-Contract-Sprachen wie Solidity werden durch Bibliotheken oder neue Opcodes erweitert, sodass Entwickler arithmetische (add, mul usw.), logische Operationen und Vergleiche direkt auf Chiffretexten 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.

Verschlüsselter Statusspeicher wird unterstützt, sodass Vertragsvariablen 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 einziger globaler FHE-Schlüssel verwendet (unten diskutiert).
2. On-Chain homomorphe Berechnung: Miner/Validatoren führen den Vertrag mit verschlüsselten Opcodes aus. Sie führen dieselben deterministischen homomorphen Operationen auf den Chiffretexten durch, sodass ein Konsens über den verschlüsselten neuen Status erzielt werden kann. Entscheidend ist, dass Validatoren niemals Klartextdaten sehen – sie sehen nur „Kauderwelsch“-Chiffretext, können ihn 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 Ausgabechiffretext entschlüsseln. Andernfalls bleiben die Ergebnisse verschlüsselt und können als Eingaben für weitere Transaktionen verwendet werden (was aufeinanderfolgende Berechnungen auf persistentem verschlüsseltem Status ermöglicht).

Eine wichtige Designüberlegung ist das Schlüsselmanagement. Ein Ansatz sind benutzerspezifische Schlüssel, bei denen jeder Benutzer seinen geheimen Schlüssel besitzt und nur er die für ihn relevanten Ausgaben entschlüsseln kann. Dies maximiert die Privatsphäre (niemand sonst kann Ihre Daten jemals entschlüsseln), aber homomorphe Operationen können Daten, die unter verschiedenen Schlüsseln verschlüsselt sind, nicht ohne komplexe Multi-Schlüssel-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 Vertragsdaten und eine verteilte Gruppe von Validatoren hält Anteile des Schwellenwert-Entschlüsselungsschlüssels. Die öffentlichen Verschlüsselungs- und Auswertungsschlüssel werden On-Chain veröffentlicht, sodass jeder Daten an das Netzwerk verschlüsseln kann; der private Schlüssel wird unter Validatoren aufgeteilt, die bei Bedarf im Rahmen eines Schwellenwertschemas gemeinsam entschlüsseln können. Um zu verhindern, dass die Kollusion von Validatoren die Privatsphäre gefährdet, verwendet Zama ein Schwellenwert-FHE-Protokoll (basierend auf ihrer Forschung Noah’s Ark) mit „Rauschflutung“, um partielle Entschlüsselungen sicher zu machen. Nur wenn ein ausreichendes Quorum von Validatoren kooperiert, kann ein Klartext wiederhergestellt werden, zum Beispiel um eine Leseanfrage zu bedienen. Im Normalbetrieb sieht jedoch kein einzelner Knoten jemals Klartext – Daten bleiben jederzeit On-Chain verschlüsselt.

Zugriffskontrolle ist eine weitere entscheidende Komponente. FHE-VM-Implementierungen umfassen detaillierte Kontrollen, um zu verwalten, wer (falls überhaupt) Entschlüsselungen auslösen oder auf bestimmte verschlüsselte Felder zugreifen kann. Zum Beispiel unterstützt Cyphers fhEVM Access Control Lists für Chiffretexte, die es Entwicklern ermöglichen, anzugeben, welche Adressen oder Verträge mit bestimmten Daten interagieren oder diese erneut verschlüsseln können. Einige Frameworks unterstützen die Neuverschlüsselung: die Fähigkeit, einen verschlüsselten Wert von einem Benutzerschlüssel auf den eines anderen zu übertragen, ohne Klartext preiszugeben. Dies ist nützlich für Dinge wie Datenmarktplätze, bei denen ein Datenbesitzer einen Datensatz mit seinem Schlüssel verschlüsseln und nach dem Kauf auf den Schlüssel des Käufers neu verschlüsseln kann – alles On-Chain, ohne jemals öffentlich zu entschlüsseln.

Gewährleistung von Korrektheit und Privatsphäre​

Man könnte fragen: Wenn alle Daten verschlüsselt sind, wie setzen wir die Korrektheit der Vertragslogik durch? Wie kann die Kette ungültige Operationen verhindern, wenn sie die Werte nicht „sehen“ kann? FHE allein liefert keinen Korrektheitsbeweis – Validatoren können die homomorphen Schritte ausführen, aber sie können nicht von Natur aus erkennen, ob die verschlüsselte Eingabe eines Benutzers gültig war oder ob eine bedingte Verzweigung 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 typischerweise einen ZK-Beweis für bestimmte Klartextbedingungen liefern, wann immer dies erforderlich ist. Zamas Design verwendet zum Beispiel einen ZK Proof of Plaintext Knowledge (ZKPoK), der jede verschlüsselte Eingabe begleitet. Dies beweist, dass der Benutzer den Klartext kennt, der seinem Chiffretext entspricht, und dass er die erwarteten Kriterien erfüllt, ohne den Klartext selbst preiszugeben. Solche „zertifizierten Chiffretexte“ verhindern, dass ein böswilliger Benutzer eine fehlerhafte Verschlüsselung oder einen Wert außerhalb des Bereichs übermittelt. Ähnlich können Benutzer für Operationen, die eine Entscheidung erfordern (z. B. sicherstellen, dass Kontostand ≥ Abhebungsbetrag), einen ZK-Beweis liefern, dass diese Bedingung für die Klartexte erfüllt ist, bevor die verschlüsselte Operation ausgeführt wird. Auf diese Weise entschlüsselt oder sieht die Kette die Werte nicht, gewinnt aber die Gewissheit, dass die verschlüsselten Transaktionen den Regeln folgen.

Ein weiterer Ansatz bei FHE-Rollups besteht darin, die Off-Chain-Validierung mit ZKPs durchzuführen. Fhenix (ein L2-Rollup, das FHE verwendet) opts für ein optimistisches Modell, bei dem eine separate Netzwerkkomponente namens Threshold Service Network verschlüsselte Ergebnisse entschlüsseln oder verifizieren kann, und jede falsche Berechnung mit einem Betrugsbeweis angefochten werden kann. Im Allgemeinen stellt die Kombination von FHE + ZK oder Betrugsbeweisen sicher, dass die verschlüsselte Ausführung vertrauenslos bleibt. Validatoren entschlüsseln entweder nur gemeinsam, wenn sie dazu autorisiert sind, oder sie verifizieren Beweise, dass jeder verschlüsselte Statusübergang gültig war, ohne Klartext sehen zu müssen.

Leistungsüberlegungen: FHE-Operationen sind rechenintensiv – um viele Größenordnungen langsamer als normale Arithmetik. Zum Beispiel kostet eine einfache 64-Bit-Addition auf Ethereum ~3 Gas, während eine Addition auf einer verschlüsselten 64-Bit-Ganzzahl (euint64) unter Zamas FHEVM grob 188.000 Gas kostet. Selbst eine 8-Bit-Addition kann ~94k Gas kosten. Dieser enorme Overhead bedeutet, dass eine einfache Implementierung auf bestehenden Knoten unpraktisch langsam und kostspielig wäre. FHE-VM-Projekte begegnen dem mit optimierten kryptografischen Bibliotheken (wie Zamas TFHE-rs-Bibliothek für binäres Gate-Bootstrapping) und benutzerdefinierten EVM-Modifikationen zur Leistungssteigerung. Zum Beispiel fügt Cyphers modifizierter Geth-Client neue Opcodes hinzu und optimiert die Ausführung homomorpher Anweisungen in C++/Assembly, um den Overhead zu minimieren. Dennoch erfordert das Erreichen eines nutzbaren Durchsatzes Beschleunigung. Laufende Arbeiten umfassen die Verwendung von GPUs, FPGAs und sogar spezialisierten photonischen Chips, um FHE-Berechnungen zu beschleunigen. Zama berichtet, dass sich ihre FHE-Leistung seit 2024 um das Hundertfache verbessert hat und Tausende von TPS mit GPU/FPGA-Beschleunigung anstrebt. Dedizierte FHE-Koprozessor-Server (wie Optalysys’ LightLocker Node) können an Validatorknoten angeschlossen werden, um verschlüsselte Operationen auf Hardware auszulagern, und unterstützen >100 verschlüsselte ERC-20-Transfers pro Sekunde pro Knoten. Mit der Verbesserung von Hardware und Algorithmen wird sich die Lücke zwischen FHE und einfacher Berechnung verringern, wodurch private Verträge praktischere Geschwindigkeiten erreichen können.

Kompatibilität: Ein Hauptziel von FHE-VM-Designs ist es, mit bestehenden Entwicklungsworkflows kompatibel zu bleiben. Cyphers und Zamas fhEVM-Implementierungen ermöglichen es Entwicklern, Verträge 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 erfolgen. Dies senkt die Eintrittsbarriere: Entwickler müssen keine Kryptografieexperten sein, um einen vertraulichen Smart Contract zu schreiben. Zum Beispiel kann eine einfache Addition zweier Zahlen als euint32 c = a + b; geschrieben werden, und die FHEVM kümmert sich im Hintergrund um die verschlüsselungsspezifischen Details. Die Verträge können sogar mit normalen Verträgen interoperieren – z. B. könnte ein verschlüsselter Vertrag bei Bedarf ein entschlüsseltes Ergebnis an einen Standardvertrag ausgeben, was eine Mischung aus privaten und öffentlichen Teilen in einem Ökosystem ermöglicht.

Aktuelle FHE-VM-Projekte​

Mehrere Projekte sind Pioniere in diesem Bereich. Zama (ein Pariser FHE-Startup) entwickelte das Kernkonzept und die Bibliotheken der FHEVM (TFHE-rs und eine fhevm-solidity-Bibliothek). Sie beabsichtigen nicht, eine eigene Kette zu starten, sondern Infrastruktur für andere bereitzustellen. Inco ist eine L1-Blockchain (aufgebaut auf Cosmos SDK mit Evmos), die Zamas FHEVM integriert hat, um eine modulare vertrauliche Kette zu schaffen. Ihre Testnetze (Gentry und Paillier genannt) zeigen 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 verwendet. Es entschied sich für einen optimistischen (Betrugsbeweis-)Ansatz anstelle eines ZK-Rollups aufgrund der hohen Kosten, FHE und ZK für jeden Block zusammen zu verwenden. Fhenix verwendet dieselbe TFHE-rs-Bibliothek (mit einigen Modifikationen) und führt ein Threshold Service Network zur dezentralen Handhabung von Entschlüsselungen ein. 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 auf, das sich auf KI und Privatsphäre konzentriert und eine fhEVM mit Funktionen wie geheimen Speichern und Unterstützung für föderiertes Lernen verwendet. Das Ökosystem ist noch jung, wächst aber schnell, angetrieben durch erhebliche Finanzierungen – z. B. wurde Zama bis 2025 mit über 130 Millionen US-Dollar zu einem „Einhorn“, um die FHE-Technologie voranzutreiben.

Zusammenfassend ermöglicht eine FHE-VM datenschutzfreundliche Smart Contracts, 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 im Status offengelegt – während der bestehende Blockchain-Konsens für die Integrität genutzt wird. Die Kosten sind eine erhöhte Rechenlast für Validatoren und Komplexität im Schlüsselmanagement und der Beweisintegration. Als Nächstes untersuchen wir ein alternatives Paradigma, das die Berechnung vollständig Off-Chain auslagert und die Kette nur zur Verifizierung verwendet: den Zero-Knowledge-Koprozessor.

Zero-Knowledge-Koprozessoren (ZK-Koprozessoren)​

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

Architektur und Workflow​

In einem typischen Setup identifiziert ein dApp-Entwickler Teile seiner Anwendungslogik, die für die On-Chain-Ausführung zu teuer oder komplex sind (z. B. große Berechnungen über historische Daten, aufwendige Algorithmen, ML-Modellinferenz usw.). Er implementiert diese Teile als Off-Chain-Programm (in einer Hochsprache oder einem Schaltungs-DSL), das einen Zero-Knowledge Proof seiner Ausführung erzeugen kann. Die On-Chain-Komponente ist ein Verifizierer-Smart-Contract, der Beweise prüft und die Ergebnisse dem Rest des Systems zur Verfügung stellt. Der Ablauf lässt sich wie folgt zusammenfassen:

1. Anfrage – Der On-Chain-Vertrag löst eine Anfrage für eine bestimmte Off-Chain-Berechnung aus. Dies kann durch eine Benutzertransaktion oder durch einen Vertrag, der die Schnittstelle des ZK-Koprozessors aufruft, initiiert werden. Zum Beispiel könnte ein DeFi-Vertrag „proveInterestRate(currentState)“ aufrufen oder ein Benutzer „queryHistoricalData(query)“.
2. Off-Chain-Ausführung & Beweiserstellung – Ein Off-Chain-Dienst (der je nach Design ein dezentrales Netzwerk von Provern oder ein vertrauenswürdiger Dienst sein könnte) nimmt die Anfrage entgegen. Er sammelt alle erforderlichen Daten (On-Chain-Status, Off-Chain-Eingaben usw.) und führt die Berechnung in einer speziellen ZK Virtual Machine (ZKVM) oder Schaltung aus. Während der Ausführung wird eine Beweisspur generiert. Am Ende erstellt der Dienst einen prägnanten Beweis (z. B. einen SNARK oder STARK), der bescheinigt, dass „die Berechnung der Funktion F auf der Eingabe X das Ergebnis Y liefert“ und optional die Datenintegrität bescheinigt (mehr dazu unten).
3. On-Chain-Verifizierung – Der Beweis und das Ergebnis werden an die Blockchain zurückgegeben (oft über eine Callback-Funktion). Der Verifizierer-Vertrag prüft die Gültigkeit des Beweises mittels effizienter kryptografischer Verifizierung (Pairing-Checks usw.). Wenn gültig, kann der Vertrag nun dem Ergebnis Y als korrekt vertrauen. Das Ergebnis kann im Status gespeichert, als Ereignis ausgegeben oder in weitere Vertragslogik eingespeist werden. Wenn der Beweis ungültig ist oder nicht innerhalb einer bestimmten Zeit bereitgestellt wird, kann die Anfrage als fehlgeschlagen betrachtet werden (und möglicherweise wird eine Fallback- oder Timeout-Logik ausgelöst).

Kritisch ist, dass die On-Chain-Gaskosten für die Verifizierung konstant sind (oder 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 liegen (ein Bruchteil eines Ethereum-Blocks), aber dieser Beweis könnte Millionen von Off-Chain durchgeführten Rechenschritten repräsentieren. Wie ein Entwickler witzelte: „Möchten Sie eine digitale Signatur beweisen? ~15 $. Möchten Sie eine Million Signaturen beweisen? Auch ~15$.“. Diese Skalierbarkeit ist ein großer Gewinn: dApps können komplexe Funktionalitäten (Big-Data-Analysen, aufwendige Finanzmodelle usw.) anbieten, ohne die Blockchain zu überlasten.

Die Hauptkomponenten eines ZK-Koprozessor-Systems sind:

• Beweisgenerierungsumgebung: Dies kann eine allgemeine ZKVM (die beliebige Programme ausführen kann) oder benutzerdefinierte Schaltungen sein, die auf spezifische Berechnungen zugeschnitten sind. Ansätze variieren:

  • Einige Projekte verwenden handgefertigte Schaltungen für jede unterstützte Abfrage oder Funktion (maximale Effizienz für diese Funktion).
  • Andere bieten eine Domain-Specific Language (DSL) oder eine Embedded DSL an, die Entwickler verwenden, um ihre Off-Chain-Logik zu schreiben, die dann in Schaltungen kompiliert wird (Balance zwischen Benutzerfreundlichkeit und Leistung).
  • Der flexibelste Ansatz ist eine zkVM: eine virtuelle Maschine (oft basierend auf RISC-Architekturen), in der Programme in Standardsprachen (Rust, C usw.) geschrieben und automatisch bewiesen werden können. Dies opfert Leistung (die Simulation einer CPU in einer Schaltung fügt Overhead hinzu) für maximale Entwicklererfahrung.

• Datenzugriff und Integrität: Eine einzigartige Herausforderung besteht darin, die Off-Chain-Berechnung mit den richtigen Daten zu versorgen, insbesondere wenn diese Daten auf der Blockchain liegen (vergangene Blöcke, Vertragszustände usw.). Eine naive Lösung besteht darin, den Prover von einem Archivknoten lesen zu lassen und ihm zu vertrauen – dies führt jedoch zu Vertrauensannahmen. ZK-Koprozessoren beweisen stattdessen typischerweise, dass alle verwendeten On-Chain-Daten tatsächlich authentisch waren, indem sie auf Merkle-Beweise oder Status-Commitments verweisen. Zum Beispiel könnte das Abfrageprogramm eine Blocknummer und einen Merkle-Beweis eines Speicherplatzes oder einer Transaktion entgegennehmen, und die Schaltung wird diesen Beweis gegen einen bekannten Block-Header-Hash verifizieren. Es gibt drei Muster:

  1. Inline-Daten: Die benötigten Daten On-Chain ablegen (als Eingabe für den Verifizierer), damit sie direkt überprüft werden können. Dies ist für große Daten sehr kostspielig und untergräbt den ganzen Sinn.
  2. Einem Orakel vertrauen: Einen Orakel-Dienst die Daten an den Beweis liefern lassen und dafür bürgen. Dies ist einfacher, führt aber das Vertrauen in eine dritte Partei wieder ein.
  3. Dateninklusion über ZK beweisen: Beweise für die Dateninklusion in der Kettengeschichte innerhalb der Zero-Knowledge-Schaltung selbst integrieren. Dies nutzt die Tatsache, dass jeder Ethereum-Block-Header den gesamten vorherigen Status (über den Status-Root) und die Transaktionshistorie festschreibt. Durch die Verifizierung von Merkle-Patricia-Beweisen der Daten innerhalb der Schaltung versichert der Ausgabebeweis dem Vertrag, dass „diese Berechnung echte Blockchain-Daten von Block N verwendet hat“ ohne zusätzliche Vertrauenswürdigkeit.

  Der dritte Ansatz ist der vertrauensloseste und wird von fortgeschrittenen ZK-Koprozessoren wie Axiom und Xpansion verwendet (er erhöht zwar die Beweiskosten, ist aber aus Sicherheitsgründen vorzuziehen). Zum Beispiel modelliert Axioms System die Blockstruktur, den Status-Trie und den Transaktions-Trie von Ethereum in seinen Schaltungen, sodass es Aussagen wie „das Konto X hatte zum Block N den Saldo Y“ oder „eine Transaktion mit bestimmten Eigenschaften erfolgte in Block N“ beweisen kann. Es nutzt die Tatsache, dass man, gegeben einen kürzlich vertrauenswürdigen Block-Hash, die Inklusion historischer Daten rekursiv beweisen kann, ohne einer externen Partei zu vertrauen.

• Verifizierer-Vertrag: Dieser On-Chain-Vertrag enthält den Verifizierungsschlüssel und die Logik zum Akzeptieren oder Ablehnen von Beweisen. Für SNARKs wie Groth16 oder PLONK könnte der Verifizierer einige elliptische Kurvenpaarungen durchführen; für STARKs könnte er einige Hash-Berechnungen durchführen. Leistungsoptimierungen wie Aggregation und Rekursion können die On-Chain-Last minimieren. Zum Beispiel verwendet RISC Zeros Bonsai einen STARK-zu-SNARK-Wrapper: Es betreibt eine STARK-basierte VM Off-Chain für Geschwindigkeit, generiert dann aber einen kleinen SNARK-Beweis, der die Gültigkeit des STARK bescheinigt. Dies reduziert die Beweisgröße von Hunderten von Kilobytes auf wenige Hundert Bytes, wodurch die On-Chain-Verifizierung machbar und kostengünstig wird. Der Solidity-Verifizierer prüft dann einfach den SNARK (was eine Operation mit konstanter Zeit ist).

In Bezug auf die Bereitstellung können ZK-Koprozessoren 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 Anfragen an Axioms Prover-Netzwerk senden und Beweise On-Chain erhalten. Axioms Slogan war, Ethereum-Verträgen „vertrauenslosen Zugriff auf alle On-Chain-Daten und beliebige expressive Berechnungen darüber“ zu ermöglichen. Es fungiert effektiv als Abfrageorakel, dessen Antworten durch ZKPs anstelle von Vertrauen verifiziert werden. Andere, wie RISC Zeros Bonsai, bieten eine offenere Plattform: Jeder Entwickler kann ein Programm (kompiliert zu einer RISC-V-kompatiblen ZKVM) hochladen und Bonsais Beweisdienst über einen Relay-Vertrag nutzen. Das Relay-Muster, wie in Abbildung 1 dargestellt, beinhaltet einen Vertrag, der Anfragen und Antworten vermittelt: Der dApp-Vertrag ruft das Relay auf, um einen Beweis anzufordern, der Off-Chain-Dienst lauscht darauf (z. B. über Ereignis oder direkten Aufruf), berechnet den Beweis, und dann ruft das Relay eine Callback-Funktion auf dem dApp-Vertrag mit dem Ergebnis und dem Beweis auf. Dieses asynchrone Modell ist notwendig, da die Beweiserstellung je nach Komplexität Sekunden bis Minuten dauern kann. Es führt eine Latenz ein (und eine Lebendigkeitsannahme, dass der Prover antworten wird), während FHE-VM-Berechnungen synchron innerhalb eines Blocks stattfinden. Die Gestaltung der Anwendung zur Handhabung dieses asynchronen Workflows (möglicherweise ähnlich wie bei Oracle-Antworten) ist Teil der Verwendung eines ZK-Koprozessors.

Bemerkenswerte ZK-Koprozessor-Projekte​

• Axiom: Axiom ist ein ZK-Koprozessor, der auf Ethereum zugeschnitten ist und sich ursprünglich auf das Beweisen historischer On-Chain-Datenabfragen konzentrierte. Es verwendet das Halo2-Beweis-Framework (ein Plonk-ähnlicher SNARK), um Beweise zu erstellen, die Ethereums kryptografische Strukturen integrieren. In Axioms System kann ein Entwickler Dinge abfragen wie „wie war der Status von Vertrag X in Block N?“ oder eine Berechnung über alle Transaktionen in einem Bereich durchführen. Unter der Haube mussten Axioms Schaltungen Ethereums Status-/Trie-Logik implementieren, sogar elliptische Kurvenoperationen und SNARK-Verifizierung innerhalb der Schaltung durchführen, um Rekursion zu unterstützen. Trail of Bits bemerkte in einem Audit die Komplexität von Axioms Halo2-Schaltungen, die ganze Blöcke und Zustände modellieren. Nach dem Audit verallgemeinerte Axiom ihre Technologie zu einer OpenVM, die die Beweisführung beliebigen Rust-Codes mit derselben Halo2-basierten Infrastruktur ermöglicht. (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, wodurch ein zustandsloser Zugriff auf beliebige historische Daten mit kryptografischer Integrität ermöglicht wird. Sie haben auch die Sicherheit betont, indem sie unterbeschränkte Schaltungsfehler gefunden und behoben und die Korrektheit sichergestellt haben. Obwohl Axioms ursprüngliches Produkt während ihrer Neuausrichtung eingestellt wurde, bleibt ihr Ansatz ein Meilenstein bei ZK-Koprozessoren.

• RISC Zero Bonsai: RISC Zero ist eine ZKVM, die auf der RISC-V-Architektur basiert. Ihre zkVM kann beliebige Programme (geschrieben in Rust, C++ und anderen Sprachen, die nach RISC-V kompiliert werden) ausführen und einen STARK-Beweis der Ausführung erzeugen. Bonsai ist RISC Zeros Cloud-Dienst, der diese Beweiserstellung bei Bedarf bereitstellt und als Koprozessor für Smart Contracts fungiert. Um es zu verwenden, 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 Verifizierer-Vertrag bereit. Wenn der Vertrag diese Berechnung benötigt, ruft er das Bonsai-Relay auf, das die Beweisgenerierung auslöst und das Ergebnis über einen Callback zurückgibt. Eine demonstrierte Anwendungsbeispiel war die Off-Chain-Governance-Berechnung: RISC Zero zeigte eine DAO, die Bonsai verwendete, um Stimmen zu zählen und komplexe Abstimmungsmetriken Off-Chain zu berechnen, und dann einen Beweis zu veröffentlichen, damit der On-Chain-Governor-Vertrag dem Ergebnis mit minimalen Gaskosten vertrauen konnte. Die Technologie von RISC Zero betont, dass Entwickler vertraute Programmierparadigmen verwenden können – zum Beispiel eine Rust-Funktion schreiben, um etwas zu berechnen – und die schwere Arbeit der Schaltungserstellung von der zkVM übernommen wird. Allerdings können Beweise groß sein, daher 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 Ethereum Sepolia Testnet, was in der Größenordnung von 300.000 Gas pro Beweis kostete. Dies öffnet die Tür für Ethereum-dApps, Bonsai heute als Skalierungs- und Datenschutzlösung zu nutzen. (Bonsai ist noch in der Alpha-Phase, nicht produktionsreif und verwendet ein temporäres SNARK-Setup ohne Zeremonie.)

• Andere: Es gibt zahlreiche weitere Akteure und Forschungsinitiativen. Expansion/Xpansion (wie in einem Blog erwähnt) verwendet einen eingebetteten DSL-Ansatz, bei dem Entwickler Abfragen über On-Chain-Daten mit einer spezialisierten Sprache schreiben können, und es die Beweisgenerierung intern handhabt. StarkWares Cairo und Polygons zkEVM sind allgemeinere ZK-Rollup-VMs, aber ihre Technologie könnte für koprozessorähnliche Anwendungen wiederverwendet werden, indem Beweise in L1-Verträgen verifiziert werden. Wir sehen auch Projekte im Bereich ZKML (ZK Machine Learning), die effektiv als Koprozessoren fungieren, um ML-Modellinferenzen oder Trainingsergebnisse On-Chain zu verifizieren. Zum Beispiel kann ein zkML-Setup beweisen, dass „eine neuronale Netzwerk-Inferenz auf privaten Eingaben die Klassifizierung X erzeugt hat“, ohne die Eingaben offenzulegen oder die Berechnung On-Chain durchzuführen. Dies sind Sonderfälle des Koprozessorkonzepts, die auf KI angewendet werden.

Vertrauensannahmen: ZK-Koprozessoren verlassen sich auf die Korrektheit der kryptografischen Beweise. Wenn das Beweissystem sicher ist (und ein eventuelles Trusted Setup ehrlich durchgeführt wird), dann garantiert ein akzeptierter Beweis, dass die Berechnung korrekt war. Es ist kein zusätzliches Vertrauen in den Prover erforderlich – selbst ein böswilliger Prover kann den Verifizierer nicht von einer falschen Aussage überzeugen. Es gibt jedoch eine Lebendigkeitsannahme: 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 Verifizierer nicht wissen, ob diese Daten ehrlich bereitgestellt wurden, es sei denn, es werden zusätzliche Maßnahmen (wie Daten-Commitments oder Orakel-Signaturen) verwendet. Aber für rein On-Chain-Datenberechnungen stellen die beschriebenen Mechanismen eine Vertrauenslosigkeit sicher, die der Kette selbst entspricht (Axiom argumentierte, dass ihre Beweise für historische Abfragen „kryptografisch äquivalente Sicherheit wie Ethereum“ bieten).

Privatsphäre: Zero-Knowledge Proofs unterstützen auch von Natur aus die Privatsphäre – der Prover kann Eingaben verborgen halten, während er Aussagen darüber beweist. Im Kontext eines Koprozessors bedeutet dies, dass ein Beweis einem Vertrag ermöglichen kann, ein Ergebnis zu verwenden, das aus privaten Daten abgeleitet wurde. Zum Beispiel könnte ein Beweis zeigen: „Der Kredit-Score des Benutzers > 700, also Kredit genehmigen“, ohne den tatsächlichen Kredit-Score oder Rohdaten preiszugeben. Axioms Anwendungsfall betraf eher öffentlich bekannte Daten (Blockchain-Historie), daher lag der Fokus dort nicht auf der Privatsphäre. Aber RISC Zeros zkVM könnte 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 geht On-Chain. Es ist erwähnenswert, dass ein ZK-Beweis im Gegensatz zu FHE normalerweise keine fortlaufende Vertraulichkeit des Status bietet – es ist ein einmaliger Beweis. Wenn ein Workflow die Aufrechterhaltung eines geheimen Status über Transaktionen hinweg erfordert, könnte man dies aufbauen, indem der Vertrag ein Commitment auf den Status speichert und jeder Beweis einen gültigen Statusübergang vom alten Commitment zum neuen zeigt, wobei Geheimnisse verborgen bleiben. Dies ist im Wesentlichen die Funktionsweise von zk-Rollups für private Transaktionen (wie Aztec oder Zcash). ZK-Koprozessoren 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 die Eingabe oder die Ausgabe (oder beides) bei Bedarf privat sein kann.

Entwicklererfahrung: Die Verwendung eines ZK-Koprozessors erfordert typischerweise das Erlernen neuer Tools. Das Schreiben benutzerdefinierter Schaltungen (Option (1) oben) ist ziemlich komplex und wird normalerweise nur für eng definierte Zwecke durchgeführt. Höherwertige Optionen wie DSLs oder zkVMs erleichtern das Leben, fügen aber dennoch Overhead hinzu: Der Entwickler muss Off-Chain-Code schreiben und bereitstellen und die Interaktion verwalten. Im Gegensatz zur FHE-VM, wo die Verschlüsselung größtenteils im Hintergrund abläuft und der Entwickler normalen Smart-Contract-Code schreibt, muss der Entwickler hier seine Logik partitionieren und möglicherweise in einer anderen Sprache (Rust usw.) für den Off-Chain-Teil schreiben. Initiativen wie Noir, Leo, Circom DSLs oder RISC Zeros Ansatz verbessern jedoch schnell die Zugänglichkeit. Zum Beispiel bietet RISC Zero Vorlagen und Foundry-Integration, sodass ein Entwickler seinen Off-Chain-Code lokal simulieren (zur Korrektheit) und ihn dann nahtlos über den Bonsai-Callback in Solidity-Tests einbinden kann. Im Laufe der Zeit können wir Entwicklungsframeworks erwarten, die abstrahieren, ob ein Logikteil über ZK-Beweis oder On-Chain ausgeführt wird – der Compiler oder die Tools könnten dies basierend auf den Kosten entscheiden.

FHE-VM vs. ZK-Koprozessor: Vergleich​

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

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.

Eines der Kernversprechen der Blockchain-Technologie wie Ethereum ist ein gewisses Maß an Anonymität. Teilnehmer, bekannt als Validatoren, sollen hinter einem Schleier kryptografischer Pseudonyme agieren, um ihre reale Identität und damit ihre Sicherheit zu schützen.

Eine aktuelle Forschungsarbeit mit dem Titel „Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue“ von Forschern der ETH Zürich und anderer Institutionen enthüllt jedoch einen kritischen Fehler in dieser Annahme. Sie demonstrieren eine einfache, kostengünstige Methode, um den öffentlichen Bezeichner eines Validators direkt mit der IP-Adresse der Maschine zu verknüpfen, auf der er läuft.

Kurz gesagt, Ethereum-Validatoren sind bei weitem nicht so anonym, wie viele glauben. Die Ergebnisse waren so bedeutend, dass die Forscher von der Ethereum Foundation eine Bug Bounty erhielten, was die Schwere des Datenlecks anerkannte.

Wie die Schwachstelle funktioniert: Ein Fehler im Gossip​

Um die Schwachstelle zu verstehen, benötigen wir zunächst ein grundlegendes Bild davon, wie Ethereum-Validatoren kommunizieren. Das Netzwerk besteht aus über einer Million Validatoren, die ständig über den Zustand der Kette „abstimmen“. Diese Abstimmungen werden als Attestierungen bezeichnet und über ein Peer-to-Peer-Netzwerk ($P2P$-Netzwerk) an alle anderen Knoten übertragen.

Bei so vielen Validatoren würde die Übertragung jeder Abstimmung an alle anderen das Netzwerk sofort überlasten. Um dies zu lösen, implementierten die Designer von Ethereum eine clevere Skalierungslösung: Das Netzwerk ist in 64 verschiedene Kommunikationskanäle, bekannt als Subnetze, unterteilt.

• Standardmäßig abonniert jeder Knoten (der Computer, auf dem die Validator-Software läuft) nur zwei dieser 64 Subnetze. Seine Hauptaufgabe ist es, alle Nachrichten, die er auf diesen beiden Kanälen sieht, gewissenhaft weiterzuleiten.
• Wenn ein Validator eine Abstimmung abgeben muss, wird seine Attestierung zufällig einem der 64 Subnetze zur Übertragung zugewiesen.

Hier liegt die Schwachstelle. Stellen Sie sich einen Knoten vor, dessen Aufgabe es ist, den Datenverkehr für die Kanäle 12 und 13 zu verwalten. Den ganzen Tag leitet er treu Nachrichten nur von diesen beiden Kanälen weiter. Doch dann sendet er Ihnen plötzlich eine Nachricht, die zu Kanal 45 gehört.

Das ist ein starker Hinweis. Warum sollte ein Knoten eine Nachricht von einem Kanal verarbeiten, für den er nicht zuständig ist? Die logischste Schlussfolgerung ist, dass der Knoten selbst diese Nachricht generiert hat. Dies impliziert, dass der Validator, der die Attestierung für Kanal 45 erstellt hat, auf genau dieser Maschine läuft.

Die Forscher nutzten genau dieses Prinzip aus. Indem sie eigene Abhörknoten einrichteten, überwachten sie die Subnetze, von denen ihre Peers Attestierungen sendeten. Wenn ein Peer eine Nachricht von einem Subnetz sendete, das er nicht offiziell abonniert hatte, konnten sie mit hoher Sicherheit ableiten, dass der Peer den ursprünglichen Validator hostete.

Die Methode erwies sich als schockierend effektiv. Mit nur vier Knoten über drei Tage lokalisierte das Team erfolgreich die IP-Adressen von über 161.000 Validatoren, was mehr als 15 % des gesamten Ethereum-Netzwerks entspricht.

Warum das wichtig ist: Die Risiken der Enttarnung​

Die Preisgabe der IP-Adresse eines Validators ist keine triviale Angelegenheit. Sie öffnet die Tür für gezielte Angriffe, die einzelne Betreiber und die Gesundheit des Ethereum-Netzwerks insgesamt bedrohen.

1. Gezielte Angriffe und Belohnungsdiebstahl Ethereum kündigt einige Minuten im Voraus an, welcher Validator den nächsten Block vorschlagen soll. Ein Angreifer, der die IP-Adresse dieses Validators kennt, kann einen Denial-of-Service (DDoS)-Angriff starten, ihn mit Datenverkehr überfluten und offline schalten. Wenn der Validator sein Vier-Sekunden-Fenster zum Vorschlagen des Blocks verpasst, geht die Gelegenheit an den nächsten Validator in der Reihe über. Wenn der Angreifer dieser nächste Validator ist, kann er dann die Blockbelohnungen und wertvollen Transaktionsgebühren (MEV) beanspruchen, die dem Opfer zugestanden hätten.

2. Bedrohungen der Netzwerk-Verfügbarkeit und -Sicherheit Ein gut ausgestatteter Angreifer könnte diese „Sniping“-Angriffe wiederholt durchführen, wodurch die gesamte Blockchain verlangsamt oder zum Stillstand gebracht werden könnte (ein Liveness-Angriff oder Verfügbarkeitsangriff). In einem schwerwiegenderen Szenario könnte ein Angreifer diese Informationen nutzen, um ausgeklügelte Netzwerk-Partitionierungsangriffe zu starten, die potenziell dazu führen könnten, dass verschiedene Teile des Netzwerks über die Historie der Kette uneinig sind und somit deren Integrität gefährdet wird (ein Safety-Angriff oder Sicherheitsangriff).

3. Eine zentralisierte Realität enthüllen Die Forschung beleuchtete auch einige unbequeme Wahrheiten über die Dezentralisierung des Netzwerks:

• Extreme Konzentration: Das Team fand Peers, die eine erstaunliche Anzahl von Validatoren hosteten, darunter eine IP-Adresse, die über 19.000 betrieb. Der Ausfall einer einzelnen Maschine könnte einen überproportionalen Einfluss auf das Netzwerk haben.
• Abhängigkeit von Cloud-Diensten: Rund 90 % der lokalisierten Validatoren laufen auf Cloud-Anbietern wie AWS und Hetzner, nicht auf den Computern von Solo-Home-Stakern. Dies stellt einen erheblichen Zentralisierungspunkt dar.
• Versteckte Abhängigkeiten: Viele große Staking-Pools behaupten, ihre Betreiber seien unabhängig. Die Forschung fand jedoch Fälle, in denen Validatoren aus verschiedenen, konkurrierenden Pools auf derselben physischen Maschine liefen, was versteckte systemische Risiken birgt.

Gegenmaßnahmen: Wie können sich Validatoren schützen?​

Glücklicherweise gibt es Möglichkeiten, sich gegen diese Enttarnungstechnik zu verteidigen. Die Forscher schlugen mehrere Gegenmaßnahmen vor:

• Mehr Rauschen erzeugen: Ein Validator kann sich entscheiden, mehr als zwei Subnetze – oder sogar alle 64 – zu abonnieren. Dies erschwert es einem Beobachter erheblich, zwischen weitergeleiteten und selbst generierten Nachrichten zu unterscheiden.
• Mehrere Knoten verwenden: Ein Betreiber kann die Validator-Aufgaben auf verschiedene Maschinen mit unterschiedlichen IPs aufteilen. Zum Beispiel könnte ein Knoten Attestierungen verwalten, während ein separater, privater Knoten nur zum Vorschlagen von Blöcken mit hohem Wert verwendet wird.
• Privates Peering: Validatoren können vertrauenswürdige, private Verbindungen mit anderen Knoten herstellen, um ihre Nachrichten weiterzuleiten und so ihren wahren Ursprung innerhalb einer kleinen, vertrauenswürdigen Gruppe zu verschleiern.
• Anonyme Broadcasting-Protokolle: Fortgeschrittenere Lösungen wie Dandelion, das den Ursprung einer Nachricht verschleiert, indem es sie über einen zufälligen „Stamm“ leitet, bevor sie weit verbreitet wird, könnten implementiert werden.

Fazit​

Diese Forschung veranschaulicht eindringlich den inhärenten Kompromiss zwischen Leistung und Datenschutz in verteilten Systemen. In seinem Bestreben zu skalieren, hat Ethereums $P2P$-Netzwerk ein Design angenommen, das die Anonymität seiner kritischsten Teilnehmer beeinträchtigt.

Indem die Forscher diese Schwachstelle ans Licht brachten, haben sie der Ethereum-Community das Wissen und die Werkzeuge an die Hand gegeben, die zur Behebung erforderlich sind. Ihre Arbeit ist ein entscheidender Schritt zum Aufbau eines robusteren, sichereren und wirklich dezentralen Netzwerks für die Zukunft.