97 Posts getaggt mit "Blockchain"

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):

Aspekt	Ika (Paralleles MPC-Netzwerk)	Lit Protocol (PKI & Compute)	Threshold Network (tBTC & TSS)	Zama (FHE-Netzwerk)
Start & Status	Gegründet 2022; Testnet 2024; Mainnet auf Sui im Dez. 2024 (Anfang 2025) gestartet. Token $IKA live auf Sui.	Gestartet 2021; Lit-Nodes-Netzwerk live. Token $LIT (gestartet 2021). Baut „Chronicle“-Rollup zur Skalierung.	Netzwerk ging 2022 nach Keep/NuCypher-Fusion live. Token $T regiert DAO. tBTC v2 für Bitcoin-Bridging gestartet.	In Entwicklung (kein öffentliches Netzwerk ab 2025). Große VC-Runden für F&E gesammelt. Noch kein Token (FHE-Tools im Alpha-Stadium).
Kernfokus/Anwendungsfall	Cross-Chain-Interoperabilität und Verwahrung: Schwellenwert-Signatur zur Kontrolle nativer Vermögenswerte über Chains hinweg (z. B. BTC, ETH) über dWallets. Ermöglicht DeFi, Multi-Chain-dApps usw.	Dezentrales Schlüsselmanagement & Zugriffskontrolle: Schwellenwert-Verschlüsselung/-Entschlüsselung und bedingte Signatur über PKPs (Programmierbare Schlüsselpaare). Beliebt für Inhaltszugriffskontrolle, Cross-Chain-Automatisierung mit JavaScript „Lit Actions“.	Schwellenwert-Kryptographie-Dienste: z. B. tBTC dezentrale Bitcoin-zu-Ethereum-Bridge; Schwellenwert-ECDSA für digitale Vermögensverwahrung; Schwellenwert-Proxy-Re-Encryption (PRE) für Datenprivatsphäre.	Datenschutzfreundliche Berechnung: Fully Homomorphic Encryption (FHE) zur Ermöglichung verschlüsselter Datenverarbeitung und privater Smart Contracts. Fokus auf Vertraulichkeit (z. B. privates DeFi, On-Chain-ML) statt Cross-Chain-Kontrolle.
Architektur	Fork der Sui-Blockchain (DAG-Konsens Mysticeti) für MPC modifiziert. Keine Benutzer-Smart Contracts auf Ika; verwendet Off-Chain-2PC-MPC-Protokoll zwischen ~N Validatoren + Benutzeranteil. Hoher Durchsatz (10k TPS) Design.	Dezentrales Netzwerk + L2: Lit-Nodes betreiben MPC und auch eine TEE-basierte JS-Laufzeitumgebung. „Chronicle“ Arbitrum Rollup wird verwendet, um den Status zu verankern und Nodes zu koordinieren. Verwendet 2/3-Schwelle für Konsens bei Schlüsseloperationen.	Dezentrales Netzwerk auf Ethereum: Node-Betreiber sind mit $T gestaked und zufällig in Signatur-Gruppen ausgewählt (z. B. 100 Nodes für tBTC). Verwendet Off-Chain-Protokolle (GG18 usw.) mit On-Chain-Ethereum-Smart Contracts zur Koordination und Einzahlungsabwicklung.	FHE-Toolkits auf bestehenden Chains: Zamas Technologie (z. B. Concrete, TFHE-Bibliotheken) ermöglicht FHE auf Ethereum (fhEVM). Pläne für ein Schwellenwert-Schlüsselverwaltungssystem (TKMS) für FHE-Schlüssel. Wird wahrscheinlich mit L1s integrieren oder als Layer-2 für private Berechnungen laufen.
Sicherheitsmodell	2PC-MPC, nicht-kollusiv: Schlüsselanteil des Benutzers + Schwelle von N Validatoren (2/3 BFT) für jede Signatur erforderlich. Keine einzelne Entität besitzt jemals den vollständigen Schlüssel. BFT-Konsens toleriert <33 % bösartige Akteure. Von Symbolic (2024) geprüft.	Schwellenwert + TEE: Erfordert 2/3 der Lit-Nodes zur Signatur/Entschlüsselung. Verwendet Trusted Execution Environments auf jedem Node, um benutzerdefinierten Code (Lit Actions) sicher auszuführen. Sicherheit hängt von Node-Ehrlichkeit und Hardware-Sicherheit ab.	Schwellenwert-Multi-Party: z. B. für tBTC muss eine zufällig ausgewählte Gruppe von ~100 Nodes eine Schwelle (z. B. 51) erreichen, um BTC-Transaktionen zu signieren. Wirtschaftliche Anreize ($T Staking, Slashing) zur Aufrechterhaltung einer ehrlichen Mehrheit. DAO-gesteuert; Sicherheitsvorfälle würden über Governance behandelt.	FHE-basiert: Sicherheit basiert auf der kryptographischen Härte von FHE (Learning with Errors usw.) – Daten bleiben jederzeit verschlüsselt. Zamas TKMS deutet auf die Verwendung von Schwellenwert-Kryptographie zur Verwaltung von FHE-Schlüsseln hin. Noch kein Live-Netzwerk; Sicherheit wird von Akademikern überprüft.
Leistung	Latenz im Sub-Sekunden-Bereich, ~10.000 Signaturen/Sek. theoretisch. Skaliert auf Hunderte oder Tausende von Nodes ohne größere Leistungseinbußen (Broadcast- & Batching-Ansatz). Geeignet für Echtzeit-dApp-Nutzung (Handel, Gaming).	Moderate Latenz (höher aufgrund von TEE- und Konsens-Overhead). Lit hat ~50 Nodes; verwendet „Shadow Splicing“ zur Skalierung, aber eine große Node-Anzahl kann die Leistung beeinträchtigen. Gut für Aufgaben mit moderater Häufigkeit (Zugriff öffnen, gelegentliche Tx-Signatur). Chronicle L2 hilft beim Batching.	Geringerer Durchsatz, höhere Latenz: tBTC-Minting kann Minuten dauern (Warten auf Bitcoin-Bestätigungen + Schwellenwert-Signatur) und verwendet kleine Gruppen zum Signieren. Thresholds Fokus liegt auf Qualität (Sicherheit) statt Quantität – gut für Bridging-Transaktionen und Zugriffskontrolle, nicht für Tausende von TPS ausgelegt.	Hohe Berechnungs-Latenz: FHE ist derzeit viel langsamer als Klartext-Berechnung (Größenordnungen). Zama optimiert, aber das Ausführen privater Smart Contracts wird langsamer und kostspieliger sein als normale. Nicht auf Hochfrequenzaufgaben ausgerichtet; zielt auf komplexe Berechnungen ab, bei denen Datenschutz von größter Bedeutung ist.
Dezentralisierung	Hoch – Permissionless Validatoren-Set, Hunderte von Validatoren möglich. Delegated PoS (Sui-Stil) gewährleistet offene Teilnahme und dezentrale Governance im Laufe der Zeit. Benutzer immer involviert (kann nicht umgangen werden).	Mittel – derzeit ~30-50 Kern-Nodes, die vom Lit-Team und Partnern betrieben werden. Pläne zur weiteren Dezentralisierung. Nodes erledigen anspruchsvolle Aufgaben (MPC + TEE), daher ist die Skalierung nicht trivial. Governance noch nicht vollständig dezentralisiert (Lit DAO existiert, aber früh).	Hoch – großer Pool von Stakern; die eigentliche Signatur erfolgt jedoch durch ausgewählte Gruppen (nicht das gesamte Netzwerk auf einmal). Das Netzwerk ist so dezentralisiert wie seine Stake-Verteilung. Gesteuert von Threshold DAO (Token-Inhaber-Abstimmungen) – ausgereifte Dezentralisierung in der Governance.	N/A (für Netzwerk) – Zama ist derzeit eher ein unternehmensgesteuertes Projekt. Wenn fhEVM oder Netzwerke starten, wahrscheinlich anfänglich zentralisiert oder mit einer begrenzten Anzahl von Nodes (angesichts der Komplexität). Im Laufe der Zeit könnte die Ausführung von FHE-Transaktionen dezentralisiert werden, aber das ist 2025 noch Neuland.
Token und Anreize	$IKA (Sui-basiert) für Gasgebühren, Staking und potenziell Governance. Anreiz: Gebühren für den Betrieb von Validatoren verdienen; Token-Wert steigt mit Netzwerknutzung. Sui Foundation-Unterstützung verleiht Ökosystemwert.	$LIT Token – für Governance und möglicherweise Gebühren für fortgeschrittene Dienste verwendet. Lit Actions derzeit kostenlos für Entwickler (kein Gas); langfristig könnte ein Gebührenmodell eingeführt werden. $LIT incentiviert den Node-Betrieb (Staker), aber die genaue Token-Ökonomie entwickelt sich.	$T Token – von Nodes gestaked, regiert die DAO-Treasury und Protokoll-Upgrades. Nodes verdienen in $T und Gebühren (in ETH oder tBTC-Gebühren). $T sichert das Netzwerk (Slashing bei Fehlverhalten). Auch in Liquiditätsprogrammen für tBTC-Adoption verwendet.	Kein Token (noch) – Zama ist VC-finanziert; könnte einen Token einführen, wenn sie einen Netzwerkdienst starten (könnte für die Bezahlung privater Berechnungen oder das Staking zur Sicherung von Netzwerken, die FHE-Smart Contracts ausführen, verwendet werden). Derzeit verwenden Entwickler Zamas Tools ohne Token.
Wichtige Unterstützer	Sui Foundation (strategischer Investor); VCs: Node Capital, Blockchange, Lemniscap, Collider; Angels wie Naval Ravikant. Starke Unterstützung vom Sui-Ökosystem.	Unterstützt von 1kx, Pantera, Coinbase Ventures, Framework usw. (13 Millionen US-Dollar im Jahr 2022 gesammelt). Hat eine wachsende Entwickler-Community über Lit DAO. Partnerschaften mit Ceramic, NFT-Projekten für Zugriffskontrolle.	Entstanden aus Keep & NuCypher-Communities (früher unterstützt von a16z, Polychain). Threshold wird von DAO betrieben; keine neue VC-Finanzierung nach der Fusion (Zuschüsse vom Ethereum Community Fund usw.). Partnerschaften: arbeitet mit Curve, Aave (tBTC-Integrationen).	Unterstützt von a16z, SoftBank, Multicoin Capital (73 Millionen US-Dollar in Series A gesammelt). Enge Verbindungen zur Ethereum Foundation-Forschung (Rand Hindi, CEO, ist ein ausgesprochener FHE-Befürworter in Ethereum). Zusammenarbeit mit Projekten wie Optalysys für Hardware-Beschleunigung.

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:

Aspekt	FHE-VM (Verschlüsselte On-Chain-Ausführung)	ZK-Koprozessor (Off-Chain-Beweisführung)
Wo die Berechnung stattfindet	Direkt On-Chain (alle Knoten führen homomorphe Operationen auf Chiffretexten aus).	Off-Chain (ein Prover oder Netzwerk führt das Programm aus; nur ein Beweis wird On-Chain verifiziert).
Datenvertraulichkeit	Vollständige Verschlüsselung: Daten bleiben jederzeit On-Chain verschlüsselt; Validatoren sehen niemals Klartext. Nur Inhaber von Entschlüsselungsschlüsseln können Ausgaben entschlüsseln.	Zero-Knowledge: private Eingaben des Provers werden niemals On-Chain offengelegt; der Beweis offenbart keine Geheimnisse über das hinaus, was in den öffentlichen Ausgaben enthalten ist. Daten, die in der Berechnung verwendet werden und den On-Chain-Status beeinflussen müssen, müssen jedoch in der Ausgabe oder im Commitment kodiert sein. Geheimnisse bleiben standardmäßig Off-Chain.
Vertrauensmodell	Vertrauen in die Konsensausführung und Kryptographie: Wenn die Mehrheit der Validatoren dem Protokoll folgt, ist die verschlüsselte Ausführung deterministisch und korrekt. Für die Korrektheit der Berechnung ist kein externes Vertrauen erforderlich (alle Knoten berechnen sie neu). Für die Privatsphäre muss der Sicherheit des FHE-Schemas vertraut werden (typischerweise basierend auf Gitterhärte). In einigen Designs muss auch darauf vertraut werden, dass keine Kollusion von genügend Validatoren auftreten kann, um Schwellenwertschlüssel zu missbrauchen.	Vertrauen in die Sicherheit des Beweissystems (Korrektheit von SNARK/STARK). Wenn der Beweis verifiziert wird, ist das Ergebnis mit kryptografischer Sicherheit korrekt. Off-Chain-Prover können die Mathematik nicht betrügen. Es gibt eine Lebendigkeitsannahme an Prover, die Arbeit tatsächlich zu erledigen. Bei Verwendung eines Trusted Setup (z. B. SNARK SRS) muss darauf vertraut werden, dass es ehrlich generiert wurde, oder transparente/Setup-freie Systeme verwendet werden.
On-Chain-Latenz	Ergebnisse sind sofort in derselben Transaktion/demselben Block verfügbar, da die Berechnung während der Ausführung stattfindet. Keine zusätzlichen Round-Trips – synchroner Betrieb. Längere Blockverarbeitungszeiten könnten jedoch die Blockchain-Latenz erhöhen, wenn FHE-Operationen langsam sind.	Von Natur aus asynchron. Erfordert typischerweise eine Transaktion zur Anforderung und eine spätere Transaktion (oder einen Callback) zur Bereitstellung des Beweises/Ergebnisses. Dies führt zu Verzögerungen (möglicherweise Sekunden bis Stunden, abhängig von der Beweiskomplexität und der Beweishardware). Nicht geeignet für die sofortige Finalität einer einzelnen Transaktion – eher ein asynchrones Jobmodell. ---
title: "Programmable Privacy in Blockchain: Off‑Chain Compute with On‑Chain Verification"
tags: [blockchain, privacy, cryptography, FHE, ZK]
keywords:
[
programmable privacy,
blockchain,
off-chain compute,
on-chain verification,
FHE-VM,
ZK coprocessors,
]
description: "Explore how programmable privacy in blockchain leverages Fully Homomorphic Encryption and Zero-Knowledge Coprocessors to enable secure off-chain computation with on-chain verification, addressing privacy challenges like MEV attacks and sensitive data exposure."
authors: [dora]
image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=Programmable%20Privacy%20in%20Blockchain%3A%20Off%E2%80%91Chain%20Compute%20with%20On%E2%80%91Chain%20Verification%22%0A---%0A%0A%23%20Programmable%20Privacy%20in%20Blockchain%3A%20Off%E2%80%91Chain%20Compute%20with%20On%E2%80%91Chain%20Verification%0A%0A!%5B%5D(https%3A%2F%2Fopengraph-image.blockeden.xyz%2Fapi%2Fog-blockeden-xyz%3Ftitle%3DProgrammable%20Privacy%20in%20Blockchain%3A%20Off%E2%80%91Chain%20Compute%20with%20On%E2%80%91Chain%20Verification)

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:

Aspekt	FHE-VM (Verschlüsselte On-Chain-Ausführung)	ZK-Koprozessor (Off-Chain-Beweisführung)
Wo die Berechnung stattfindet	Direkt On-Chain (alle Knoten führen homomorphe Operationen auf Chiffretexten aus).	Off-Chain (ein Prover oder Netzwerk führt das Programm aus; nur ein Beweis wird On-Chain verifiziert).
Datenvertraulichkeit	Vollständige Verschlüsselung: Daten bleiben jederzeit On-Chain verschlüsselt; Validatoren sehen niemals Klartext. Nur Inhaber von Entschlüsselungsschlüsseln können Ausgaben entschlüsseln.	Zero-Knowledge: private Eingaben des Provers werden niemals On-Chain offengelegt; der Beweis offenbart keine Geheimnisse über das hinaus, was in den öffentlichen Ausgaben enthalten ist. Daten, die in der Berechnung verwendet werden und den On-Chain-Status beeinflussen müssen, müssen jedoch in der Ausgabe oder im Commitment kodiert sein. Geheimnisse bleiben standardmäßig Off-Chain.
Vertrauensmodell	Vertrauen in die Konsensausführung und Kryptographie: Wenn die Mehrheit der Validatoren dem Protokoll folgt, ist die verschlüsselte Ausführung deterministisch und korrekt. Für die Korrektheit der Berechnung ist kein externes Vertrauen erforderlich (alle Knoten berechnen sie neu). Für die Privatsphäre muss der Sicherheit des FHE-Schemas vertraut werden (typischerweise basierend auf Gitterhärte). In einigen Designs muss auch darauf vertraut werden, dass keine Kollusion von genügend Validatoren auftreten kann, um Schwellenwertschlüssel zu missbrauchen.	Vertrauen in die Sicherheit des Beweissystems (Korrektheit von SNARK/STARK). Wenn der Beweis verifiziert wird, ist das Ergebnis mit kryptografischer Sicherheit korrekt. Off-Chain-Prover können die Mathematik nicht betrügen. Es gibt eine Lebendigkeitsannahme an Prover, die Arbeit tatsächlich zu erledigen. Bei Verwendung eines Trusted Setup (z. B. SNARK SRS) muss darauf vertraut werden, dass es ehrlich generiert wurde, oder transparente/Setup-freie Systeme verwendet werden. ---
title: "Programmable Privacy in Blockchain: Off‑Chain Compute with On‑Chain Verification"
tags: [blockchain, privacy, cryptography, FHE, ZK]
keywords:
[
programmable privacy,
blockchain,
off-chain compute,
on-chain verification,
FHE-VM,
ZK coprocessors,
]
description: "Explore how programmable privacy in blockchain leverages Fully Homomorphic Encryption and Zero-Knowledge Coprocessors to enable secure off-chain computation with on-chain verification, addressing privacy challenges like MEV attacks and sensitive data exposure."
authors: [dora]
image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=Programmable%20Privacy%20in%20Blockchain%3A%20Off%E2%80%91Chain%20Compute%20with%20On%E2%80%91Chain%20Verification%22%0A---%0A%0A%23%20Programmierbare%20Privatsph%C3%A4re%20in%20der%20Blockchain%3A%20Off-Chain-Berechnung%20mit%20On-Chain-Verifizierung%0A%0A!%5B%5D(https%3A%2F%2Fopengraph-image.blockeden.xyz%2Fapi%2Fog-blockeden-xyz%3Ftitle%3DProgrammable%20Privacy%20in%20Blockchain%3A%20Off%E2%80%91Chain%20Compute%20with%20On%E2%80%91Chain%20Verification)

Ö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:

Aspekt	FHE-VM (Verschlüsselte On-Chain-Ausführung)	ZK-Koprozessor (Off-Chain-Beweisführung)
Wo die Berechnung stattfindet	Direkt On-Chain (alle Knoten führen homomorphe Operationen auf Chiffretexten aus).	Off-Chain (ein Prover oder Netzwerk führt das Programm aus; nur ein Beweis wird On-Chain verifiziert).
Datenvertraulichkeit	Vollständige Verschlüsselung: Daten bleiben jederzeit On-Chain verschlüsselt; Validatoren sehen niemals Klartext. Nur Inhaber von Entschlüsselungsschlüsseln können Ausgaben entschlüsseln.	Zero-Knowledge: private Eingaben des Provers werden niemals On-Chain offengelegt; der Beweis offenbart keine Geheimnisse über das hinaus, was in den öffentlichen Ausgaben enthalten ist. Daten, die in der Berechnung verwendet werden und den On-Chain-Status beeinflussen müssen, müssen jedoch in der Ausgabe oder im Commitment kodiert sein. Geheimnisse bleiben standardmäßig Off-Chain.
Vertrauensmodell	Vertrauen in die Konsensausführung und Kryptographie: Wenn die Mehrheit der Validatoren dem Protokoll folgt, ist die verschlüsselte Ausführung deterministisch und korrekt. Für die Korrektheit der Berechnung ist kein externes Vertrauen erforderlich (alle Knoten berechnen sie neu). Für die Privatsphäre muss der Sicherheit des FHE-Schemas vertraut werden (typischerweise basierend auf Gitterhärte). In einigen Designs muss auch darauf vertraut werden, dass keine Kollusion von genügend Validatoren auftreten kann, um Schwellenwertschlüssel zu missbrauchen.	Vertrauen in die Sicherheit des Beweissystems (Korrektheit von SNARK/STARK). Wenn der Beweis verifiziert wird, ist das Ergebnis mit kryptografischer Sicherheit korrekt. Off-Chain-Prover können die Mathematik nicht betrügen. Es gibt eine Lebendigkeitsannahme an Prover, die Arbeit tatsächlich zu erledigen. Bei Verwendung eines Trusted Setup (z. B. SNARK SRS) muss darauf vertraut werden, dass es ehrlich generiert wurde, oder transparente/Setup-freie Systeme verwendet werden.

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:

Projekt / Protokoll	Fokus & Asset-Typen	Blockchain	Bemerkenswerte Metriken / Highlights
Centrifuge	Dezentrale Verbriefung von Privatkrediten – Tokenisierung von Real-World-Zahlungs-Assets wie Rechnungen, Handelsforderungen, Immobilien-Überbrückungskrediten, Lizenzgebühren usw. über Asset-Pools (Tinlake). Investoren erzielen Renditen aus der Finanzierung dieser Assets.	Polkadot-Parachain (Centrifuge Chain) mit Ethereum-dApp (Tinlake)-Integration	TVL ≈ 409 Millionen US-Dollar in Pools; Pionier im RWA-DeFi mit MakerDAO (Centrifuge-Pools sichern bestimmte DAI-Kredite). Partner mit Institutionen wie New Silver und FortunaFi für die Asset-Originierung. Start von Centrifuge V3 für einfachere Cross-Chain-RWA-Liquidität.
Maple Finance	Institutionelle Kreditplattform – ursprünglich unterbesicherte Krypto-Kredite (an Handelsfirmen), jetzt auf RWA-basierte Kreditvergabe umgestellt. Bietet Pools an, in denen akkreditierte Kreditgeber USDC an Kreditnehmer vergeben (jetzt oft durch Real-World-Sicherheiten oder Einnahmen gedeckt). Startete einen Cash Management Pool für On-Chain-US-Staatsanleiheninvestitionen und Maple Direct für überbesicherte BTC/ETH-Kredite.	Ethereum (V2 & Maple 2.0), zuvor Solana (eingestellt)	2,46 Milliarden US-Dollar an insgesamt vergebenen Krediten bis heute; Umstellung auf vollständig besicherte Kreditvergabe nach Ausfällen bei unbesicherten Krediten. Maples neuer Treasury-Pool ermöglicht Nicht-US-Investoren, ~5 % auf T-Bills über USDC zu verdienen. Sein nativer Token MPL (bald Umwandlung in SYRUP) erfasst Protokollgebühren; Maple rangiert auf Platz 2 im Privatkredit-RWA-TVL und ist einer der wenigen mit einem liquiden Token. Plume Network und Real-World Assets (RWA) in Web3

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:

Ansatz	Prover-Leistung (Inferenz & Beweis)	Beweisgröße & Verifizierung	Datenschutzmerkmale	Trusted Setup?	Post-Quanten-sicher?
zk-SNARK (Halo2, Groth16, PLONK, etc)	Hoher Prover-Overhead (bis zu 10^6-fach der normalen Laufzeit ohne Optimierungen; in der Praxis 10^3–10^5-fach). Optimiert für spezifische Modelle/Schaltkreise; Proving-Zeit in Minuten für mittlere Modelle, Stunden für große. Neuere zkML-SNARKs (DeepProve mit GKR) verbessern dies erheblich (nahezu linearer Overhead, z. B. Sekunden statt Minuten für Modelle mit Millionen von Parametern).	Sehr kleine Beweise (oft < 100 KB, manchmal ~einige KB). Verifizierung ist schnell: wenige Pairings oder Polynom-Evaluierungen (typischerweise < 50 ms On-Chain). DeepProves GKR-basierte Beweise sind größer (Zehntausende–Hunderte von KB) und verifizieren in ~0,5 s (immer noch viel schneller als das erneute Ausführen des Modells).	Datenvertraulichkeit: Ja – Eingaben können im Beweis privat sein (nicht offengelegt). Modellschutz: Ja – Prover kann sich zu Modellgewichten committen und diese nicht offenlegen. Ausgabeverbergen: Optional – Beweis kann eine Aussage sein, ohne die Ausgabe preiszugeben (z. B. „Ausgabe hat Eigenschaft P“). Wenn die Ausgabe selbst jedoch On-Chain benötigt wird, wird sie typischerweise öffentlich. Insgesamt bieten SNARKs volle Zero-Knowledge-Flexibilität (verbergen Sie, welche Teile Sie möchten).	Abhängig vom Schema. Groth16/EZKL erfordern ein Trusted Setup pro Schaltkreis; PLONK/Halo2 verwenden ein universelles Setup (einmalig). DeepProves Sum-Check GKR ist transparent (kein Setup) – ein Bonus dieses Designs.	Klassische SNARKs (BLS12-381-Kurven) sind nicht PQ-sicher (anfällig für Quantenangriffe auf den elliptischen Kurven-Diskreten Logarithmus). Einige neuere SNARKs verwenden PQ-sichere Commitments, aber Halo2/PLONK, wie in Ezkl verwendet, sind nicht PQ-sicher. GKR (DeepProve) verwendet Hash-Commitments (z. B. Poseidon/Merkle), die als PQ-sicher vermutet werden (basierend auf der Hash-Preimage-Resistenz).
zk-STARK (FRI, Hash-basierter Beweis)	Prover-Overhead ist hoch, aber die Skalierung ist linearer. Typischerweise 10^2–10^4-mal langsamer als nativ für große Aufgaben, mit Raum zur Parallelisierung. Allgemeine STARK-VMs (Risc0, Cairo) zeigten 2024 eine langsamere Leistung im Vergleich zu SNARK für ML (z. B. 3- bis 66-mal langsamer als Halo2 in einigen Fällen). Spezialisierte STARKs (oder GKR) können einen linearen Overhead erreichen und SNARKs für große Schaltkreise übertreffen.	Beweise sind größer: oft Zehntausende von KB (wachsend mit Schaltkreisgröße/log(n)). Verifizierer muss mehrere Hash- und FFT-Prüfungen durchführen – Verifizierungszeit ~O(n^ε) für kleines ε (z. B. ~50 ms bis 500 ms je nach Beweisgröße). On-Chain ist dies kostspieliger (StarkWares L1-Verifizierer kann Millionen von Gas pro Beweis verbrauchen). Einige STARKs unterstützen rekursive Beweise zur Komprimierung der Größe, auf Kosten der Prover-Zeit.	Daten- & Modellschutz: Ein STARK kann Zero-Knowledge gemacht werden, indem Trace-Daten randomisiert werden (Hinzufügen von Blinding zu Polynom-Evaluierungen), sodass er private Eingaben ähnlich wie SNARK verbergen kann. Viele STARK-Implementierungen konzentrieren sich auf Integrität, aber zk-STARK-Varianten ermöglichen Datenschutz. Ja, sie können Eingaben/Modelle wie SNARKs verbergen. Ausgabeverbergen: theoretisch ebenfalls möglich (Prover deklariert die Ausgabe nicht als öffentlich), aber selten verwendet, da die Ausgabe normalerweise das ist, was wir offenlegen/verifizieren wollen.	Kein Trusted Setup. Transparenz ist ein Kennzeichen von STARKs – erfordert nur eine gemeinsame Zufallszeichenfolge (die Fiat-Shamir ableiten kann). Dies macht sie attraktiv für den offenen Einsatz (jedes Modell, jederzeit, keine Zeremonie pro Modell).	Ja, STARKs basieren auf Hash- und informationstheoretischen Sicherheitsannahmen (wie Random Oracle und der Schwierigkeit bestimmter Codewort-Dekodierungen in FRI). Diese gelten als sicher gegen Quantengegner. STARK-Beweise sind somit PQ-resistent, ein Vorteil für die Zukunftssicherheit verifizierbarer KI.
FHE für ML (Vollständig Homomorphe Verschlüsselung angewendet auf Inferenz)	Prover = Partei, die Berechnungen auf verschlüsselten Daten durchführt. Die Berechnungszeit ist extrem hoch: 10^3–10^5-mal langsamer als Klartext-Inferenz ist üblich. High-End-Hardware (Multi-Core-Server, FPGA usw.) kann dies mildern. Einige Optimierungen (Inferenz mit geringer Präzision, gestufte FHE-Parameter) können den Overhead reduzieren, aber es gibt einen grundlegenden Leistungseinbruch. FHE ist derzeit praktisch für kleine Modelle oder einfache lineare Modelle; tiefe Netzwerke bleiben über Spielzeuggrößen hinaus eine Herausforderung.	Kein Beweis generiert. Das Ergebnis ist eine verschlüsselte Ausgabe. Verifizierung im Sinne der Korrektheitsprüfung wird von FHE allein nicht bereitgestellt – man vertraut der rechnenden Partei, nicht zu betrügen. (Wenn mit sicherer Hardware kombiniert, könnte man eine Bestätigung erhalten; andernfalls könnte ein bösartiger Server ein falsches verschlüsseltes Ergebnis zurückgeben, das der Client zu einer falschen Ausgabe entschlüsseln würde, ohne den Unterschied zu kennen).	Datenvertraulichkeit: Ja – die Eingabe ist verschlüsselt, sodass die rechnende Partei nichts darüber erfährt. Modellschutz: Wenn der Modelleigentümer die Berechnung auf verschlüsselten Eingaben durchführt, ist das Modell auf seiner Seite im Klartext (nicht geschützt). Wenn die Rollen vertauscht sind (Client hält Modell verschlüsselt und Server rechnet), könnte das Modell verschlüsselt bleiben, aber dieses Szenario ist weniger verbreitet. Es gibt Techniken wie sicheres Zwei-Parteien-ML, die FHE/MPC kombinieren, um beides zu schützen, aber diese gehen über reines FHE hinaus. Ausgabeverbergen: Standardmäßig ist die Ausgabe der Berechnung verschlüsselt (nur entschlüsselbar durch die Partei mit dem geheimen Schlüssel, normalerweise den Eingabeinhaber). Die Ausgabe ist also vor dem rechnenden Server verborgen. Wenn wir die Ausgabe öffentlich machen wollen, kann der Client sie entschlüsseln und offenlegen.	Kein Setup erforderlich. Jeder Benutzer generiert sein eigenes Schlüsselpaar für die Verschlüsselung. Vertrauen basiert darauf, dass die Schlüssel geheim bleiben.	Die Sicherheit von FHE-Schemata (z. B. BFV, CKKS, TFHE) basiert auf Gitterproblemen (Learning With Errors), die als resistent gegen Quantenangriffe gelten (zumindest ist kein effizienter Quantenalgorithmus bekannt). FHE wird daher im Allgemeinen als post-quantensicher angesehen.

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.

Wir freuen uns, eine bedeutende Erweiterung des API-Marktplatzes von BlockEden.xyz bekannt zu geben, mit der Hinzufügung von drei hochmodernen Blockchain-Netzwerken: Base, Berachain und Blast. Diese neuen Angebote spiegeln unser Engagement wider, Entwicklern umfassenden Zugang zu den innovativsten Blockchain-Infrastrukturen zu ermöglichen und eine nahtlose Entwicklung über mehrere Ökosysteme hinweg zu gewährleisten.

Base: Coinbases Ethereum L2-Lösung​

Base ist eine von Coinbase entwickelte Ethereum Layer 2 (L2)-Lösung, die darauf abzielt, Millionen von Nutzern in das Onchain-Ökosystem zu bringen. Als sichere, kostengünstige und entwicklerfreundliche Ethereum L2 kombiniert Base die robuste Sicherheit von Ethereum mit den Skalierbarkeitsvorteilen von Optimistic Rollups.

Unser neuer Base API-Endpunkt ermöglicht Entwicklern:

• Zugriff auf die Infrastruktur von Base, ohne eigene Nodes verwalten zu müssen
• Nutzung von Hochleistungs-RPC-Verbindungen mit 99,9 % Verfügbarkeit
• Entwicklung von Anwendungen, die von der Sicherheit von Ethereum mit geringeren Gebühren profitieren
• Nahtlose Interaktion mit Bases wachsendem Ökosystem von Anwendungen

Base ist besonders attraktiv für Entwickler, die verbraucherorientierte Anwendungen erstellen möchten, die die Sicherheit von Ethereum erfordern, aber zu einem Bruchteil der Kosten.

Berachain: Performance trifft auf EVM-Kompatibilität​

Berachain verfolgt einen einzigartigen Ansatz für die Blockchain-Infrastruktur, der hohe Leistung mit vollständiger Ethereum Virtual Machine (EVM)-Kompatibilität kombiniert. Als aufstrebendes Netzwerk, das bei Entwicklern große Aufmerksamkeit erregt, bietet Berachain:

• EVM-Kompatibilität mit verbessertem Durchsatz
• Erweiterte Smart-Contract-Funktionen
• Ein wachsendes Ökosystem innovativer DeFi-Anwendungen
• Einzigartige Konsensmechanismen, optimiert für Transaktionsgeschwindigkeit

Unsere Berachain API bietet Entwicklern sofortigen Zugang zu diesem vielversprechenden Netzwerk und ermöglicht es Teams, Anwendungen ohne die Komplexität der Infrastrukturverwaltung zu erstellen und zu testen.

Blast: Die erste Native Yield L2​

Blast zeichnet sich als die erste Ethereum L2 mit nativem Yield für ETH und Stablecoins aus. Dieser innovative Ansatz zur Yield-Generierung macht Blast besonders interessant für DeFi-Entwickler und Anwendungen, die auf Kapitaleffizienz ausgerichtet sind.

Zu den Hauptvorteilen unserer Blast API gehören:

• Direkter Zugang zu Blasts nativen Yield-Mechanismen
• Unterstützung für die Entwicklung von Yield-optimierten Anwendungen
• Vereinfachte Integration mit Blasts einzigartigen Funktionen
• Hochleistungs-RPC-Verbindungen für nahtlose Interaktionen

Blasts Fokus auf nativem Yield stellt eine spannende Richtung für Ethereum L2-Lösungen dar und könnte neue Standards für die Kapitaleffizienz im Ökosystem setzen.

Nahtloser Integrationsprozess​

Der Einstieg in diese neuen Netzwerke ist mit BlockEden.xyz unkompliziert:

1. Besuchen Sie unseren API-Marktplatz und wählen Sie Ihr gewünschtes Netzwerk aus
2. Erstellen Sie einen API-Schlüssel über Ihr BlockEden.xyz-Dashboard
3. Integrieren Sie den Endpunkt in Ihre Entwicklungsumgebung mithilfe unserer umfassenden Dokumentation
4. Beginnen Sie mit Zuversicht zu entwickeln, unterstützt durch unsere 99,9 % Verfügbarkeitsgarantie

Warum BlockEden.xyz für diese Netzwerke wählen?​

BlockEden.xyz zeichnet sich weiterhin durch mehrere Kernangebote aus:

• Hohe Verfügbarkeit: Unsere Infrastruktur gewährleistet 99,9 % Verfügbarkeit über alle unterstützten Netzwerke hinweg
• Entwicklerzentrierter Ansatz: Umfassende Dokumentation und Support für nahtlose Integration
• Vereinheitlichte Erfahrung: Zugriff auf mehrere Blockchain-Netzwerke über eine einzige, konsistente Schnittstelle
• Wettbewerbsfähige Preise: Unser Compute Unit Credit (CUC)-System gewährleistet kosteneffiziente Skalierung

Ausblick​

Die Hinzufügung von Base, Berachain und Blast zu unserem API-Marktplatz unterstreicht unser fortwährendes Engagement, das vielfältige und sich entwickelnde Blockchain-Ökosystem zu unterstützen. Während diese Netzwerke weiter reifen und Entwickler anziehen, wird BlockEden.xyz die zuverlässige Infrastruktur bereitstellen, die für den Aufbau der nächsten Generation dezentraler Anwendungen erforderlich ist.

Wir laden Entwickler ein, diese neuen Angebote zu erkunden und uns Feedback zu geben, während wir unsere Dienste weiter verbessern. Ihr Beitrag ist von unschätzbarem Wert, um unseren API-Marktplatz zu verfeinern und zu erweitern, um Ihren sich entwickelnden Anforderungen gerecht zu werden.

Bereit, auf Base, Berachain oder Blast zu entwickeln? Besuchen Sie noch heute den BlockEden.xyz API-Marktplatz und erstellen Sie Ihren Zugangsschlüssel, um Ihre Reise zu beginnen!

Für die neuesten Updates und Ankündigungen verbinden Sie sich mit uns auf Twitter oder treten Sie unserer Community auf Discord bei.

In der sich schnell entwickelnden Landschaft der Blockchain-Technologie hat ein bekannter Name mit einer kühnen Vision die Bühne betreten. Sony, der Unterhaltungs- und Technologieriese, hat Soneium ins Leben gerufen – eine Ethereum Layer-2-Blockchain, die darauf ausgelegt ist, die Lücke zwischen modernsten Web3-Innovationen und Mainstream-Internetdiensten zu schließen. Aber was genau ist Soneium, und warum sollte es Sie interessieren? Tauchen wir ein.

Was ist Soneium?​

Soneium ist eine Layer-2-Blockchain, die auf Ethereum aufbaut und von Sony Block Solutions Labs entwickelt wurde – einem Joint Venture zwischen der Sony Group und Startale Labs. Nach einer erfolgreichen Testnet-Phase im Januar 2025 gestartet, zielt Soneium darauf ab, „das offene Internet, das Grenzen überschreitet, zu verwirklichen“, indem es die Blockchain-Technologie zugänglich, skalierbar und praktisch für den täglichen Gebrauch macht.

Man kann es als Sonys Versuch sehen, Blockchain so benutzerfreundlich zu gestalten, wie es PlayStations und Walkmans einst für Gaming und Musik taten.

Die Technologie hinter Soneium​

Für die Technikbegeisterten unter uns: Soneium basiert auf dem OP Stack von Optimism, was bedeutet, dass es dasselbe Optimistic-Rollup-Framework wie andere beliebte Layer-2-Lösungen verwendet. Einfach ausgedrückt? Es verarbeitet Transaktionen Off-Chain und sendet nur periodisch komprimierte Daten zurück an Ethereum, wodurch Transaktionen schneller und günstiger werden, während die Sicherheit erhalten bleibt.

Soneium ist vollständig kompatibel mit der Ethereum Virtual Machine (EVM), sodass Entwickler, die mit Ethereum vertraut sind, ihre Anwendungen problemlos auf der Plattform bereitstellen können. Es tritt auch dem „Superchain“-Ökosystem von Optimism bei, was eine einfache Kommunikation mit anderen Layer-2-Netzwerken wie Base von Coinbase ermöglicht.

Was macht Soneium besonders?​

Obwohl es bereits mehrere Layer-2-Lösungen auf dem Markt gibt, zeichnet sich Soneium durch seinen Fokus auf Unterhaltung, kreative Inhalte und Fan-Engagement aus – Bereiche, in denen Sony jahrzehntelange Erfahrung und enorme Ressourcen besitzt.

Stellen Sie sich vor, Sie kaufen ein Kinoticket und erhalten ein exklusives digitales Sammlerstück, das Zugang zu Bonusinhalten gewährt. Oder Sie besuchen ein virtuelles Konzert, bei dem Ihr NFT-Ticket zu einem Erinnerungsstück mit besonderen Vorteilen wird. Dies sind die Arten von Erlebnissen, die Sony auf Soneium aufbauen möchte.

Die Plattform ist darauf ausgelegt, Folgendes zu unterstützen:

• Gaming-Erlebnisse mit schnelleren Transaktionen für In-Game-Assets
• NFT-Marktplätze für digitale Sammlerstücke
• Fan-Engagement-Apps, in denen Communities mit Kreativen interagieren können
• Finanztools für Kreative und Fans
• Blockchain-Lösungen für Unternehmen

Sonys Partnerschaften stärken Soneium​

Sony geht nicht allein vor. Das Unternehmen hat strategische Partnerschaften geschmiedet, um die Entwicklung und Akzeptanz von Soneium zu fördern:

• Startale Labs, ein in Singapur ansässiges Blockchain-Startup unter der Leitung von Sota Watanabe (Mitbegründer des Astar Network), ist Sonys wichtigster technischer Partner
• Die Optimism Foundation stellt die zugrunde liegende Technologie bereit
• Circle stellt sicher, dass USD Coin (USDC) als primäre Währung im Netzwerk dient
• Samsung hat über seinen Venture-Arm eine strategische Investition getätigt
• Alchemy, Chainlink, Pyth Network und The Graph bieten wesentliche Infrastrukturdienste

Sony nutzt auch seine internen Abteilungen – darunter Sony Pictures, Sony Music Entertainment und Sony Music Publishing –, um Web3-Fan-Engagement-Projekte auf Soneium zu pilotieren. Zum Beispiel hat die Plattform bereits NFT-Kampagnen für das „Ghost in the Shell“-Franchise und verschiedene Musikkünstler unter Sonys Label veranstaltet.

Frühe Erfolgszeichen​

Obwohl erst wenige Monate alt, hat Soneium vielversprechende Fortschritte gezeigt:

• In seiner Testnet-Phase wurden über 15 Millionen aktive Wallets und über 47 Millionen Transaktionen verzeichnet
• Innerhalb des ersten Monats nach dem Mainnet-Start zog Soneium über 248.000 On-Chain-Konten und etwa 1,8 Millionen Adressen an, die mit dem Netzwerk interagierten
• Die Plattform hat erfolgreich mehrere NFT-Drops gestartet, darunter eine Zusammenarbeit mit dem Web3-Musiklabel Coop Records

Um das Wachstum anzukurbeln, starteten Sony und Astar Network eine 100-Tage-Incentive-Kampagne mit einem Belohnungspool von 100 Millionen Token, um Nutzer zu ermutigen, Apps auszuprobieren, Liquidität bereitzustellen und auf der Plattform aktiv zu sein.

Sicherheit und Skalierbarkeit: Ein Balanceakt​

Sicherheit ist für Sony von größter Bedeutung, insbesondere da das Unternehmen seine vertrauenswürdige Marke in den Blockchain-Bereich trägt. Soneium erbt die Sicherheit von Ethereum und fügt eigene Schutzmaßnahmen hinzu.

Interessanterweise hat Sony einen etwas kontroversen Ansatz gewählt, indem es bestimmte Smart Contracts und Token, die als Verletzung des geistigen Eigentums gelten, auf eine schwarze Liste gesetzt hat. Obwohl dies Fragen zur Dezentralisierung aufgeworfen hat, argumentiert Sony, dass eine gewisse Kuratierung notwendig ist, um Kreative zu schützen und Vertrauen bei Mainstream-Nutzern aufzubauen.

Im Hinblick auf die Skalierbarkeit ist es der eigentliche Zweck von Soneium, den Durchsatz von Ethereum zu verbessern. Durch die Off-Chain-Verarbeitung von Transaktionen kann es ein viel höheres Transaktionsvolumen zu wesentlich geringeren Kosten bewältigen – entscheidend für die Massenadoption von Anwendungen wie Spielen oder großen NFT-Drops.

Der Weg nach vorn​

Sony hat eine mehrphasige Roadmap für Soneium skizziert:

1. Erstes Jahr: Onboarding von Web3-Enthusiasten und Early Adopters
2. Innerhalb von zwei Jahren: Integration von Sony-Produkten wie Sony Bank, Sony Music und Sony Pictures
3. Innerhalb von drei Jahren: Expansion auf Unternehmen und allgemeine Anwendungen jenseits des Sony-Ökosystems

Das Unternehmen führt schrittweise seine NFT-gesteuerte Fan-Marketing-Plattform ein, die es Marken und Künstlern ermöglichen wird, problemlos NFTs an Fans auszugeben und Vorteile wie exklusive Inhalte und Event-Zugang anzubieten.

Während Soneium derzeit ETH für Gasgebühren verwendet und ASTR (den Token des Astar Network) für Anreize nutzt, gibt es Spekulationen über einen potenziellen nativen Soneium-Token in der Zukunft.

Wie Soneium im Vergleich zu anderen Layer-2-Netzwerken abschneidet​

Im überfüllten Layer-2-Markt steht Soneium im Wettbewerb mit etablierten Akteuren wie Arbitrum, Optimism und Polygon. Sony erarbeitet sich jedoch eine einzigartige Position, indem es sein Unterhaltungsimperium nutzt und sich auf kreative Anwendungsfälle konzentriert.

Im Gegensatz zu rein gemeinschaftsgetriebenen Layer-2-Netzwerken profitiert Soneium von Sonys Markenvertrauen, dem Zugang zu Content-IP und einer potenziell riesigen Nutzerbasis aus bestehenden Sony-Diensten.

Der Kompromiss ist eine geringere Dezentralisierung (zumindest anfänglich) im Vergleich zu Netzwerken wie Optimism und Arbitrum, die Token ausgegeben und eine Community-Governance implementiert haben.

Das Gesamtbild​

Sonys Soneium stellt einen bedeutenden Schritt in Richtung Massenadoption von Blockchain dar. Indem sich das Unternehmen auf Inhalte und Fan-Engagement konzentriert – Bereiche, in denen Sony herausragt –, positioniert es Soneium als Brücke zwischen Web3-Enthusiasten und alltäglichen Verbrauchern.

Wenn Sony auch nur einen Bruchteil seiner Millionen von Kunden erfolgreich in Web3-Teilnehmer umwandeln kann, könnte Soneium zu einer der ersten wirklich Mainstream-Blockchain-Plattformen werden.

Das Experiment hat gerade erst begonnen, aber das Potenzial ist enorm. Während die Grenzen zwischen Unterhaltung, Technologie und Blockchain weiter verschwimmen, könnte Soneium an der Spitze dieser Konvergenz stehen und die Blockchain-Technologie den Massen zugänglich machen, einen Gaming-Avatar oder Musik-NFT nach dem anderen.

Die Geschwindigkeitsrevolution, auf die Ethereum gewartet hat?​

In der Welt der Blockchain-Skalierungslösungen, in der viel auf dem Spiel steht, ist ein neuer Anwärter aufgetaucht, der sowohl Begeisterung als auch Kontroversen hervorruft. MegaETH positioniert sich als Ethereums Antwort auf ultraschnelle Chains wie Solana – mit dem Versprechen einer Latenz im Sub-Millisekundenbereich und erstaunlichen 100.000 Transaktionen pro Sekunde (TPS).

Doch diese Behauptungen gehen mit erheblichen Kompromissen einher. MegaETH geht kalkulierte Opfer ein, um „Ethereum wieder großartig zu machen“, und wirft wichtige Fragen zum Gleichgewicht zwischen Performance, Sicherheit und Dezentralisierung auf.

Als Infrastrukturanbieter, die viele vielversprechende Lösungen kommen und gehen gesehen haben, haben wir bei BlockEden.xyz diese Analyse durchgeführt, um Entwicklern und Buildern zu helfen, zu verstehen, was MegaETH einzigartig macht – und welche Risiken zu berücksichtigen sind, bevor man darauf aufbaut.

Was macht MegaETH anders?​

MegaETH ist eine Ethereum Layer-2-Lösung, die die Blockchain-Architektur mit einem einzigen Fokus neu konzipiert hat: Echtzeit-Performance.

Während die meisten L2-Lösungen Ethereums ~15 TPS um den Faktor 10-100x verbessern, strebt MegaETH eine Verbesserung um den Faktor 1.000-10.000x an – Geschwindigkeiten, die es in eine eigene Kategorie einordnen würden.

Revolutionärer technischer Ansatz​

MegaETH erreicht seine außergewöhnliche Geschwindigkeit durch radikale technische Entscheidungen:

1. Architektur mit einem einzigen Sequencer: Im Gegensatz zu den meisten L2s, die mehrere Sequencer verwenden oder eine Dezentralisierung planen, verwendet MegaETH einen einzigen Sequencer zur Anordnung von Transaktionen und wählt bewusst Performance über Dezentralisierung.

2. Optimierter State Trie: Ein vollständig neu gestaltetes State-Speichersystem, das Terabyte-große State-Daten effizient verarbeiten kann, selbst auf Nodes mit begrenztem RAM.

3. JIT-Bytecode-Kompilierung: Just-in-Time-Kompilierung von Ethereum-Smart-Contract-Bytecode, die die Ausführung näher an die „Bare-Metal“-Geschwindigkeit bringt.

4. Parallele Ausführungspipeline: Ein Multi-Core-Ansatz, der Transaktionen in parallelen Streams verarbeitet, um den Durchsatz zu maximieren.

5. Mikroblöcke: Ziel sind Blockzeiten von ~1 ms durch kontinuierliche „Streaming“-Blockproduktion anstelle von Batch-Verarbeitung.

6. EigenDA-Integration: Verwendung der Datenverfügbarkeitslösung von EigenLayer anstelle des Postens aller Daten an Ethereum L1, wodurch Kosten gesenkt und gleichzeitig die Sicherheit durch Ethereum-konforme Validierung aufrechterhalten wird.

Diese Architektur liefert Performance-Metriken, die für eine Blockchain fast unmöglich erscheinen:

• Latenz im Sub-Millisekundenbereich (10 ms Ziel)
• 100.000+ TPS Durchsatz
• EVM-Kompatibilität für einfaches Portieren von Anwendungen

Überprüfung der Behauptungen: Der aktuelle Status von MegaETH​

Stand März 2025 ist das öffentliche Testnet von MegaETH live. Die erste Bereitstellung begann am 6. März mit einem schrittweisen Rollout, beginnend mit Infrastrukturpartnern und dApp-Teams, bevor es für eine breitere Benutzeraufnahme geöffnet wurde.

Frühe Testnet-Metriken zeigen:

• ~1,68 Giga-Gas pro Sekunde Durchsatz
• ~15 ms Blockzeiten (deutlich schneller als andere L2s)
• Unterstützung für parallele Ausführung, die die Performance schließlich noch weiter steigern wird

Das Team hat angedeutet, dass das Testnet in einem etwas gedrosselten Modus läuft, mit Plänen, zusätzliche Parallelisierung zu ermöglichen, die den Gas-Durchsatz auf etwa 3,36 Ggas/Sekunde verdoppeln könnte, um ihrem letztendlichen Ziel von 10 Ggas/Sekunde (10 Milliarden Gas pro Sekunde) näherzukommen.

Das Sicherheits- und Vertrauensmodell​

Der Ansatz von MegaETH zur Sicherheit stellt eine erhebliche Abweichung von der Blockchain-Orthodoxie dar. Im Gegensatz zu Ethereums vertrauensminimiertem Design mit Tausenden von Validierungs-Nodes, umfasst MegaETH eine zentralisierte Ausführungsschicht mit Ethereum als Sicherheitsanker.

Die „Kann nicht böse sein“-Philosophie​

MegaETH verwendet ein Optimistic Rollup Sicherheitsmodell mit einigen einzigartigen Merkmalen:

1. Fraud-Proof-System: Wie andere Optimistic Rollups ermöglicht MegaETH Beobachtern, ungültige State-Übergänge durch Fraud Proofs, die an Ethereum übermittelt werden, anzufechten.

2. Verifier-Nodes: Unabhängige Nodes replizieren die Berechnungen des Sequencers und würden Fraud Proofs initiieren, wenn Diskrepanzen gefunden werden.

3. Ethereum-Settlement: Alle Transaktionen werden schließlich auf Ethereum abgewickelt und erben dessen Sicherheit für den finalen State.

Dies schafft, was das Team einen „Kann nicht böse sein“-Mechanismus nennt – der Sequencer kann keine ungültigen Blöcke produzieren oder den State falsch ändern, ohne erwischt und bestraft zu werden.

Der Zentralisierungs-Kompromiss​

Der kontroverse Aspekt: MegaETH läuft mit einem einzigen Sequencer und hat explizit „keine Pläne, den Sequencer jemals zu dezentralisieren“. Dies birgt zwei erhebliche Risiken:

1. Liveness-Risiko: Wenn der Sequencer offline geht, könnte das Netzwerk anhalten, bis es sich erholt oder ein neuer Sequencer ernannt wird.

2. Zensurrisiko: Der Sequencer könnte theoretisch bestimmte Transaktionen oder Benutzer kurzfristig zensieren (obwohl Benutzer letztendlich über L1 aussteigen könnten).

MegaETH argumentiert, dass diese Risiken akzeptabel sind, weil:

• Das L2 für die endgültige Sicherheit an Ethereum gekoppelt ist
• Die Datenverfügbarkeit von mehreren Nodes in EigenDA gehandhabt wird
• Jede Zensur oder jeder Betrug von der Community gesehen und angefochten werden kann

Anwendungsfälle: Wenn ultraschnelle Ausführung zählt​

Die Echtzeit-Fähigkeiten von MegaETH ermöglichen Anwendungsfälle, die auf langsameren Blockchains bisher unpraktisch waren:

1. Hochfrequenzhandel und DeFi​

MegaETH ermöglicht DEXs mit nahezu sofortiger Handelsausführung und Orderbuch-Updates. Projekte, die bereits darauf aufbauen, sind:

• GTE: Ein Echtzeit-Spot-DEX, der zentrale Limit-Orderbücher und AMM-Liquidität kombiniert
• Teko Finance: Ein Geldmarkt für Hebel-Kreditvergabe mit schnellen Margin-Updates
• Cap: Ein Stablecoin und Yield-Engine, der Arbitrage über Märkte hinweg betreibt
• Avon: Ein Kreditprotokoll mit Orderbuch-basiertem Kredit-Matching

Diese DeFi-Anwendungen profitieren vom Durchsatz von MegaETH, um mit minimaler Slippage und hochfrequenten Updates zu arbeiten.

2. Gaming und Metaverse​

Die Finalität im Sub-Sekundenbereich macht vollständig On-Chain-Spiele ohne Wartezeiten auf Bestätigungen praktikabel:

• Awe: Ein Open-World-3D-Spiel mit On-Chain-Aktionen
• Biomes: Ein On-Chain-Metaverse ähnlich wie Minecraft
• Mega Buddies und Mega Cheetah: Sammel-Avatar-Serien

Solche Anwendungen können Echtzeit-Feedback in Blockchain-Spielen liefern und schnelles Gameplay sowie On-Chain-PvP-Kämpfe ermöglichen.

3. Unternehmensanwendungen​

Die Performance von MegaETH macht es für Unternehmensanwendungen geeignet, die einen hohen Durchsatz erfordern:

• Infrastruktur für Sofortzahlungen
• Echtzeit-Risikomanagementsysteme
• Lieferkettenverifizierung mit sofortiger Finalität
• Hochfrequenz-Auktionssysteme

Der Hauptvorteil in all diesen Fällen ist die Fähigkeit, rechenintensive Anwendungen mit sofortigem Feedback auszuführen, während sie weiterhin mit Ethereums Ökosystem verbunden sind.

Das Team hinter MegaETH​

MegaETH wurde von einem Team mit beeindruckenden Referenzen mitbegründet:

• Li Yilong: PhD in Informatik von Stanford, spezialisiert auf Low-Latency-Computersysteme
• Yang Lei: PhD vom MIT, Forschung zu dezentralen Systemen und Ethereum-Konnektivität
• Shuyao Kong: Ehemaliger Head of Global Business Development bei ConsenSys

Das Projekt hat namhafte Unterstützer angezogen, darunter die Ethereum-Mitbegründer Vitalik Buterin und Joseph Lubin als Angel-Investoren. Vitaliks Beteiligung ist besonders bemerkenswert, da er selten in spezifische Projekte investiert.

Weitere Investoren sind Sreeram Kannan (Gründer von EigenLayer), VC-Firmen wie Dragonfly Capital, Figment Capital und Robot Ventures, sowie einflussreiche Persönlichkeiten der Community wie Cobie.

Token-Strategie: Der Soulbound NFT-Ansatz​

MegaETH führte eine innovative Token-Verteilungsmethode durch „Soulbound NFTs“ namens „The Fluffle“ ein. Im Februar 2025 wurden 10.000 nicht übertragbare NFTs geschaffen, die mindestens 5 % der gesamten MegaETH-Token-Versorgung repräsentieren.

Wichtige Aspekte der Tokenomics:

• 5.000 NFTs wurden für je 1 ETH verkauft (Einnahmen von ~$13-14 Millionen)
• Die anderen 5.000 NFTs wurden Ökosystemprojekten und Buildern zugewiesen
• Die NFTs sind Soulbound (können nicht übertragen werden), was eine langfristige Ausrichtung gewährleistet
• Implizite Bewertung von rund $540 Millionen, extrem hoch für ein Pre-Launch-Projekt
• Das Team hat ungefähr $30-40 Millionen an Venture-Finanzierung erhalten

Es wird erwartet, dass der MegaETH-Token schließlich als native Währung für Transaktionsgebühren und möglicherweise für Staking und Governance dienen wird.

Wie MegaETH im Vergleich zu Wettbewerbern abschneidet​

Vs. andere Ethereum L2s​

Im Vergleich zu Optimism, Arbitrum und Base ist MegaETH deutlich schneller, geht aber größere Kompromisse bei der Dezentralisierung ein:

• Performance: MegaETH zielt auf 100.000+ TPS ab, im Vergleich zu Arbitrums ~250 ms Transaktionszeiten und geringerem Durchsatz
• Dezentralisierung: MegaETH verwendet einen einzigen Sequencer im Vergleich zu den Plänen anderer L2s für dezentrale Sequencer
• Datenverfügbarkeit: MegaETH verwendet EigenDA im Vergleich zu anderen L2s, die Daten direkt an Ethereum posten

Vs. Solana und Hochleistungs-L1s​

MegaETH zielt darauf ab, „Solana in seinem eigenen Spiel zu schlagen“, während es die Sicherheit von Ethereum nutzt:

• Durchsatz: MegaETH zielt auf 100.000+ TPS ab, im Vergleich zu Solanas theoretischen 65.000 TPS (praktisch typischerweise einige Tausend)
• Latenz: MegaETH ~10 ms im Vergleich zu Solanas ~400 ms Finalität
• Dezentralisierung: MegaETH hat 1 Sequencer im Vergleich zu Solanas ~1.900 Validatoren

Vs. ZK-Rollups (StarkNet, zkSync)​

Während ZK-Rollups stärkere Sicherheitsgarantien durch Gültigkeitsnachweise bieten:

• Geschwindigkeit: MegaETH bietet eine schnellere Benutzererfahrung, ohne auf die ZK-Proof-Generierung warten zu müssen
• Vertrauenslosigkeit: ZK-Rollups erfordern kein Vertrauen in die Ehrlichkeit eines Sequencers und bieten stärkere Sicherheit
• Zukunftspläne: MegaETH könnte schließlich ZK-Proofs integrieren und zu einer hybriden Lösung werden

Die Positionierung von MegaETH ist klar: Es ist die schnellste Option innerhalb des Ethereum-Ökosystems und opfert einen Teil der Dezentralisierung, um Web2-ähnliche Geschwindigkeiten zu erreichen.

Die Infrastruktur-Perspektive: Was Builder beachten sollten​

Als Infrastrukturanbieter, der Entwickler mit Blockchain-Nodes verbindet, sieht BlockEden.xyz sowohl Chancen als auch Herausforderungen im Ansatz von MegaETH:

Potenzielle Vorteile für Builder​

1. Außergewöhnliche Benutzererfahrung: Anwendungen können sofortiges Feedback und hohen Durchsatz bieten, wodurch eine Web2-ähnliche Reaktionsfähigkeit entsteht.

2. EVM-Kompatibilität: Bestehende Ethereum dApps können mit minimalen Änderungen portiert werden, wodurch Performance ohne Neuschreibungen freigeschaltet wird.

3. Kosteneffizienz: Hoher Durchsatz bedeutet niedrigere Kosten pro Transaktion für Benutzer und Anwendungen.

4. Ethereum als Sicherheitsanker: Trotz Zentralisierung auf der Ausführungsschicht bietet das Ethereum-Settlement ein Sicherheitsfundament.

Risikobetrachtungen​

1. Single Point of Failure: Der zentralisierte Sequencer schafft ein Liveness-Risiko – wenn er ausfällt, fällt auch Ihre Anwendung aus.

2. Zensur-Anfälligkeit: Anwendungen könnten einer Transaktionszensur ohne sofortige Abhilfe ausgesetzt sein.

3. Technologie im Frühstadium: Die neue Architektur von MegaETH wurde noch nicht im großen Maßstab mit echtem Wert praxiserprobt.

4. Abhängigkeit von EigenDA: Die Verwendung einer neueren Datenverfügbarkeitslösung fügt eine zusätzliche Vertrauensannahme hinzu.

Infrastruktur-Anforderungen​

Die Unterstützung des Durchsatzes von MegaETH erfordert eine robuste Infrastruktur:

• Hochleistungs-RPC-Nodes, die den Datenstrom bewältigen können
• Fortschrittliche Indizierungslösungen für Echtzeit-Datenzugriff
• Spezialisiertes Monitoring für die einzigartige Architektur
• Zuverlässiges Bridge-Monitoring für Cross-Chain-Operationen

Fazit: Revolution oder Kompromiss?​

MegaETH stellt ein kühnes Experiment in der Blockchain-Skalierung dar – eines, das bewusst Performance über Dezentralisierung priorisiert. Ob dieser Ansatz erfolgreich ist, hängt davon ab, ob der Markt Geschwindigkeit mehr schätzt als dezentrale Ausführung.

Die kommenden Monate werden entscheidend sein, wenn MegaETH vom Testnet zum Mainnet übergeht. Wenn es seine Performance-Versprechen einhält und gleichzeitig ausreichende Sicherheit gewährleistet, könnte es unsere Denkweise über Blockchain-Skalierung grundlegend verändern. Wenn es stolpert, wird es bestätigen, warum Dezentralisierung ein zentraler Blockchain-Wert bleibt.

Vorerst steht MegaETH als eine der ehrgeizigsten Ethereum-Skalierungslösungen da. Seine Bereitschaft, die Orthodoxie herauszufordern, hat bereits wichtige Gespräche darüber ausgelöst, welche Kompromisse im Streben nach Mainstream-Blockchain-Adoption akzeptabel sind.

Bei BlockEden.xyz sind wir bestrebt, Entwickler zu unterstützen, wo immer sie bauen, einschließlich Hochleistungsnetzwerken wie MegaETH. Unsere zuverlässige Node-Infrastruktur und API-Dienste sind darauf ausgelegt, Anwendungen im Multi-Chain-Ökosystem zum Erfolg zu verhelfen, unabhängig davon, welcher Skalierungsansatz sich letztendlich durchsetzt.

---

Möchten Sie auf MegaETH aufbauen oder benötigen Sie eine zuverlässige Node-Infrastruktur für Hochdurchsatzanwendungen? Kontakt-E-Mail: info@BlockEden.xyz, um zu erfahren, wie wir Ihre Entwicklung mit unserer 99,9 % Verfügbarkeitsgarantie und spezialisierten RPC-Diensten über 27+ Blockchains hinweg unterstützen können.

Das Web3-Skalierungsproblem​

Die Blockchain-Branche steht vor einer anhaltenden Herausforderung: Wie können wir skalieren, um Millionen von Nutzern zu unterstützen, ohne Sicherheit oder Dezentralisierung zu opfern?

Ethereum, die führende Smart-Contract-Plattform, verarbeitet auf ihrer Basisschicht etwa 15 Transaktionen pro Sekunde. In Zeiten hoher Nachfrage hat diese Einschränkung zu exorbitanten Gasgebühren geführt – manchmal über 100 US-Dollar pro Transaktion während NFT-Mints oder DeFi-Farming-Rauschphasen.

Dieser Skalierungsengpass stellt eine existenzielle Bedrohung für die Web3-Adoption dar. Nutzer, die an die sofortige Reaktionsfähigkeit von Web2-Anwendungen gewöhnt sind, werden es nicht tolerieren, 50 US-Dollar zu zahlen und 3 Minuten zu warten, nur um Token zu tauschen oder ein NFT zu minten.

Hier kommt die Lösung ins Spiel, die die Blockchain-Architektur schnell umgestaltet: Rollups-as-a-Service (RaaS).

Rollups-as-a-Service (RaaS) verstehen​

RaaS-Plattformen ermöglichen es Entwicklern, ihre eigenen benutzerdefinierten Blockchain-Rollups bereitzustellen, ohne die Komplexität, alles von Grund auf neu aufbauen zu müssen. Diese Dienste verwandeln das, was normalerweise ein spezialisiertes Ingenieurteam und monatelange Entwicklung erfordern würde, in einen optimierten, manchmal sogar Ein-Klick-Bereitstellungsprozess.

Warum ist das wichtig? Weil Rollups der Schlüssel zur Blockchain-Skalierung sind.

Rollups funktionieren, indem sie:

• Transaktionen außerhalb der Hauptkette (Layer 1) verarbeiten
• Diese Transaktionen bündeln
• Komprimierte Nachweise dieser Transaktionen an die Hauptkette zurücksenden

Das Ergebnis? Drastisch erhöhter Durchsatz und erheblich reduzierte Kosten, während die Sicherheit von der zugrunde liegenden Layer-1-Blockchain (wie Ethereum) geerbt wird.

„Rollups konkurrieren nicht mit Ethereum – sie erweitern es. Sie sind wie spezialisierte Expressspuren, die auf Ethereums Autobahn gebaut wurden.“

Dieser Skalierungsansatz ist so vielversprechend, dass Ethereum im Jahr 2020 offiziell eine „Rollup-zentrierte Roadmap“ verabschiedete und damit anerkannte, dass die Zukunft nicht eine einzige monolithische Kette ist, sondern ein Ökosystem aus miteinander verbundenen, zweckgebundenen Rollups.

Caldera: An der Spitze der RaaS-Revolution​

Unter den aufstrebenden RaaS-Anbietern sticht Caldera als Vorreiter hervor. Im Jahr 2023 gegründet und mit 25 Millionen US-Dollar von prominenten Investoren wie Dragonfly, Sequoia Capital und Lattice ausgestattet, hat sich Caldera schnell als führender Infrastrukturanbieter im Rollup-Bereich etabliert.

Was macht Caldera anders?​

Caldera zeichnet sich in mehreren wichtigen Punkten aus:

1. Multi-Framework-Unterstützung: Im Gegensatz zu Wettbewerbern, die sich auf ein einziges Rollup-Framework konzentrieren, unterstützt Caldera wichtige Frameworks wie Optimisms OP Stack und Arbitrums Orbit/Nitro-Technologie, was Entwicklern Flexibilität in ihrem technischen Ansatz bietet.

2. End-to-End-Infrastruktur: Wenn Sie mit Caldera bereitstellen, erhalten Sie eine komplette Suite von Komponenten: zuverlässige RPC-Knoten, Block-Explorer, Indexierungsdienste und Bridge-Schnittstellen.

3. Reichhaltiges Integrations-Ökosystem: Caldera ist vorintegriert mit über 40 Web3-Tools und -Diensten, darunter Oracles, Faucets, Wallets und Cross-Chain-Bridges (LayerZero, Axelar, Wormhole, Connext und weitere).

4. Das Metalayer-Netzwerk: Die vielleicht ambitionierteste Innovation von Caldera ist sein Metalayer – ein Netzwerk, das alle von Caldera betriebenen Rollups zu einem einheitlichen Ökosystem verbindet und es ihnen ermöglicht, Liquidität und Nachrichten nahtlos auszutauschen.

5. Multi-VM-Unterstützung: Ende 2024 wurde Caldera der erste RaaS-Anbieter, der die Solana Virtual Machine (SVM) auf Ethereum unterstützte, wodurch Solana-ähnliche Hochleistungsketten ermöglicht werden, die weiterhin auf Ethereums sichere Basisschicht abgewickelt werden.

Calderas Ansatz schafft das, was sie eine „Alles-Schicht“ für Rollups nennen – ein kohärentes Netzwerk, in dem verschiedene Rollups interoperieren können, anstatt als isolierte Inseln zu existieren.

Praktische Anwendung: Wer nutzt Caldera?​

Caldera hat erheblich an Bedeutung gewonnen, mit über 75 Rollups, die Ende 2024 in Produktion waren. Einige bemerkenswerte Projekte sind:

• Manta Pacific: Ein hoch skalierbares Netzwerk für die Bereitstellung von Zero-Knowledge-Anwendungen, das Calderas OP Stack in Kombination mit Celestia für die Datenverfügbarkeit nutzt.

• RARI Chain: Raribles NFT-fokussiertes Rollup, das Transaktionen in weniger als einer Sekunde verarbeitet und NFT-Lizenzgebühren auf Protokollebene durchsetzt.

• Kinto: Eine regulierungskonforme DeFi-Plattform mit On-Chain-KYC/AML- und Account-Abstraction-Funktionen.

• Injectives inEVM: Ein EVM-kompatibles Rollup, das die Interoperabilität von Injective erweitert und das Cosmos-Ökosystem mit Ethereum-basierten dApps verbindet.

Diese Projekte verdeutlichen, wie anwendungsspezifische Rollups Anpassungen ermöglichen, die auf allgemeinen Layer 1s nicht möglich sind. Bis Ende 2024 hatten Calderas kollektive Rollups Berichten zufolge über 300 Millionen Transaktionen für mehr als 6 Millionen einzigartige Wallets verarbeitet, mit einem Gesamt gesperrten Wert (TVL) von fast 1 Milliarde US-Dollar.

RaaS im Vergleich: Caldera vs. Wettbewerber​

Die RaaS-Landschaft wird zunehmend wettbewerbsintensiver, mit mehreren bemerkenswerten Akteuren:

Conduit​

• Konzentriert sich ausschließlich auf die Ökosysteme von Optimism und Arbitrum
• Betont ein vollständig selbstbedienbares No-Code-Erlebnis
• Betreibt etwa 20 % der Ethereum-Mainnet-Rollups, einschließlich Zora

AltLayer​

• Bietet „Flashlayers“ – temporäre, On-Demand-Rollups für kurzfristige Anforderungen
• Konzentriert sich auf elastische Skalierung für bestimmte Ereignisse oder Hochverkehrszeiten
• Zeigte beeindruckenden Durchsatz während Gaming-Events (über 180.000 tägliche Transaktionen)

Sovereign Labs​

• Entwickelt ein Rollup SDK, das sich auf Zero-Knowledge-Technologien konzentriert
• Zielt darauf ab, ZK-Rollups auf jeder Basis-Blockchain zu ermöglichen, nicht nur auf Ethereum
• Noch in Entwicklung, positioniert sich für die nächste Welle der Multi-Chain-ZK-Bereitstellung

Während diese Wettbewerber in spezifischen Nischen glänzen, hat Calderas umfassender Ansatz – die Kombination eines einheitlichen Rollup-Netzwerks, Multi-VM-Unterstützung und ein Fokus auf die Entwicklererfahrung – dazu beigetragen, es als Marktführer zu etablieren.

Die Zukunft von RaaS und Blockchain-Skalierung​

RaaS ist bereit, die Blockchain-Landschaft auf tiefgreifende Weise neu zu gestalten:

1. Die Verbreitung anwendungsspezifischer Ketten​

Branchenstudien deuten darauf hin, dass wir uns auf eine Zukunft mit potenziell Millionen von Rollups zubewegen, die jeweils spezifische Anwendungen oder Gemeinschaften bedienen. Da RaaS die Bereitstellungshürden senkt, könnte jede bedeutende dApp ihre eigene optimierte Kette haben.

2. Interoperabilität als kritische Herausforderung​

Mit der Zunahme von Rollups wird die Fähigkeit, zwischen ihnen zu kommunizieren und Werte auszutauschen, entscheidend. Calderas Metalayer stellt einen frühen Versuch dar, diese Herausforderung zu lösen – indem es eine einheitliche Erfahrung über ein Netzwerk von Rollups hinweg schafft.

3. Von isolierten Ketten zu vernetzten Ökosystemen​

Das Endziel ist ein nahtloses Multi-Chain-Erlebnis, bei dem Nutzer kaum wissen müssen, auf welcher Kette sie sich befinden. Werte und Daten würden frei durch ein miteinander verbundenes Netz spezialisierter Rollups fließen, die alle durch robuste Layer-1-Netzwerke gesichert sind.

4. Cloud-ähnliche Blockchain-Infrastruktur​

RaaS verwandelt die Blockchain-Infrastruktur effektiv in einen Cloud-ähnlichen Dienst. Calderas „Rollup Engine“ ermöglicht dynamische Upgrades und modulare Komponenten, wodurch Rollups wie konfigurierbare Cloud-Dienste behandelt werden, die bei Bedarf skaliert werden können.

Was das für Entwickler und BlockEden.xyz bedeutet​

Bei BlockEden.xyz sehen wir enormes Potenzial in der RaaS-Revolution. Als Infrastrukturanbieter, der Entwickler sicher mit Blockchain-Knoten verbindet, sind wir prädestiniert, eine entscheidende Rolle in dieser sich entwickelnden Landschaft zu spielen.

Die Verbreitung von Rollups bedeutet, dass Entwickler mehr denn je eine zuverlässige Knoten-Infrastruktur benötigen. Eine Zukunft mit Tausenden von anwendungsspezifischen Ketten erfordert robuste RPC-Dienste mit hoher Verfügbarkeit – genau das, worauf BlockEden.xyz spezialisiert ist.

Wir sind besonders begeistert von den Möglichkeiten in:

1. Spezialisierte RPC-Dienste für Rollups: Da Rollups einzigartige Funktionen und Optimierungen übernehmen, wird spezialisierte Infrastruktur entscheidend.

2. Cross-Chain-Datenindexierung: Da Werte zwischen mehreren Rollups fließen, benötigen Entwickler Tools, um Cross-Chain-Aktivitäten zu verfolgen und zu analysieren.

3. Erweiterte Entwickler-Tools: Mit der Vereinfachung der Rollup-Bereitstellung wächst der Bedarf an ausgeklügelten Überwachungs-, Debugging- und Analysetools.

4. Vereinheitlichter API-Zugang: Entwickler, die über mehrere Rollups hinweg arbeiten, benötigen einen vereinfachten, einheitlichen Zugang zu verschiedenen Blockchain-Netzwerken.

Fazit: Die modulare Blockchain-Zukunft​

Der Aufstieg von Rollups-as-a-Service stellt einen grundlegenden Wandel in unserer Denkweise über Blockchain-Skalierung dar. Anstatt alle Anwendungen auf eine einzige Kette zu zwingen, bewegen wir uns auf eine modulare Zukunft mit spezialisierten Ketten für spezifische Anwendungsfälle zu, die alle miteinander verbunden und durch robuste Layer-1-Netzwerke gesichert sind.

Calderas Ansatz – die Schaffung eines einheitlichen Netzwerks von Rollups mit geteilter Liquidität und nahtloser Nachrichtenübermittlung – bietet einen Einblick in diese Zukunft. Indem RaaS-Anbieter die Rollup-Bereitstellung so einfach wie das Starten eines Cloud-Servers gestalten, demokratisieren sie den Zugang zur Blockchain-Infrastruktur.

Bei BlockEden.xyz engagieren wir uns dafür, diese Entwicklung zu unterstützen, indem wir die zuverlässige Knoten-Infrastruktur und Entwickler-Tools bereitstellen, die für den Aufbau in dieser Multi-Chain-Zukunft benötigt werden. Wie wir oft sagen, ist die Zukunft von Web3 keine einzelne Kette – es sind Tausende von spezialisierten Ketten, die zusammenarbeiten.

---

Möchten Sie auf einem Rollup aufbauen oder benötigen Sie eine zuverlässige Knoten-Infrastruktur für Ihr Blockchain-Projekt? Kontakt-E-Mail: info@BlockEden.xyz, um zu erfahren, wie wir Ihre Entwicklung mit unserer 99,9 % Verfügbarkeitsgarantie und spezialisierten RPC-Diensten über 27+ Blockchains hinweg unterstützen können.