Direkt zum Hauptinhalt

38 Beiträge getaggt mit „Kryptographie“

Kryptographische Protokolle und Techniken

Alle Tags anzeigen

Sui-gestütztes MPC-Netzwerk Ika – Umfassende technische und Investitionsbewertung

· 40 Min. Lesezeit

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.

Ika Network

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/3X/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):

AspektIka (Paralleles MPC-Netzwerk)Lit Protocol (PKI & Compute)Threshold Network (tBTC & TSS)Zama (FHE-Netzwerk)
Start & StatusGegrü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/AnwendungsfallCross-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.
ArchitekturFork 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.
Sicherheitsmodell2PC-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.
LeistungLatenz 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.
DezentralisierungHoch – 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ützerSui 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.

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

· 48 Min. Lesezeit
Dora Noda
Software Engineer

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

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

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

Architektur und Design der FHE-VM

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

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

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

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

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

Sicherstellung von Korrektheit und Privatsphäre

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

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

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

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

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

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

Zero-Knowledge-Coprozessoren (ZK-Coprocessors)

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

Architektur und Workflow

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

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

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

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

Die Hauptkomponenten eines ZK-Coprozessor-Systems sind:

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

    • Einige Projekte verwenden handgefertigte Schaltungen (handcrafted circuits) für jede unterstützte Abfrage oder Funktion (um die Effizienz für diese Funktion zu maximieren).
    • Andere bieten eine domänenspezifische Sprache (DSL) oder eine eingebettete DSL an, die Entwickler verwenden, um ihre Off-Chain-Logik zu schreiben, welche dann in Schaltungen kompiliert wird (ein Kompromiss zwischen Benutzerfreundlichkeit und Leistung).
    • Der flexibelste Ansatz ist eine ZKVM: eine virtuelle Maschine (oft basierend auf RISC-Architekturen), auf der Programme in Standardsprachen (Rust, C usw.) geschrieben und automatisch bewiesen werden können. Dies opfert Leistung (die Simulation einer CPU in einer Schaltung verursacht Overhead) für eine maximale Entwicklererfahrung.
  • Datenzugriff und Integrität (Data Access and Integrity): Eine besondere Herausforderung besteht darin, die Off-Chain-Berechnung mit den richtigen Daten zu versorgen, insbesondere wenn diese Daten auf der Blockchain liegen (vergangene Blöcke, Contract-Zustände usw.). Eine naive Lösung wäre, dass der Prover von einem Archivknoten liest und ihm vertraut – aber das führt Vertrauensannahmen ein. ZK-Coprozessoren beweisen stattdessen in der Regel, dass alle verwendeten On-Chain-Daten tatsächlich authentisch waren, indem sie eine Verknüpfung zu Merkle-Beweisen oder State-Commitments herstellen. Zum Beispiel könnte das Abfrageprogramm eine Blocknummer und einen Merkle-Beweis eines Speicherplatzes oder einer Transaktion entgegennehmen, und die Schaltung verifiziert diesen Beweis gegen einen bekannten Block-Header-Hash. Es existieren drei Muster:

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

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

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

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

Bekannte ZK-Coprozessor-Projekte

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

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

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

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

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

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

FHE-VM vs. ZK-Coprozessor: Vergleich

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

AspektFHE-VM (Verschlüsselte On-Chain-Ausführung)ZK-Coprozessor (Off-Chain-Beweisführung)
Wo die Berechnung stattfindetDirekt On-Chain (alle Knoten führen homomorphe Operationen auf Chiffretexten aus).Off-Chain (ein Prover oder ein Netzwerk führt das Programm aus; nur ein Beweis wird On-Chain verifiziert).
DatenvertraulichkeitVollständige Verschlüsselung: Daten bleiben On-Chain jederzeit verschlüsselt; Validatoren sehen niemals den Klartext. Nur Inhaber von Entschlüsselungsschlüsseln können Ergebnisse entschlüsseln.Zero-Knowledge: Die privaten Eingaben des Provers werden On-Chain niemals offengelegt; der Beweis enthüllt keine Geheimnisse außer dem, was in den öffentlichen Ausgaben steht. Alle Daten, die sich auf den On-Chain-Status auswirken müssen, müssen jedoch im Output oder Commitment kodiert sein. Geheimnisse bleiben standardmäßig Off-Chain.
VertrauensmodellVertrauen in Konsens-Ausführung und Kryptografie: Wenn die Mehrheit der Validatoren dem Protokoll folgt, ist die verschlüsselte Ausführung deterministisch und korrekt. Kein externes Vertrauen für die Korrektheit der Berechnung nötig (alle Knoten berechnen sie neu). Für den Datenschutz muss der Sicherheit des FHE-Schemas vertraut werden (meist basierend auf Lattice-Hardness). In einigen Designs auch Vertrauen darauf, dass keine Kollusion von ausreichend Validatoren stattfindet, um Threshold-Keys zu missbrauchen.Vertrauen in die Sicherheit des Beweissystems (Soundness von SNARK/STARK). Wenn der Beweis verifiziert wird, ist das Ergebnis mit kryptografischer Sicherheit korrekt. Off-Chain-Prover können die Mathematik nicht austricksen. Es gibt eine Lebendigkeitsannahme für Prover, die Arbeit tatsächlich zu erledigen. Bei Verwendung eines Trusted Setups (z. B. SNARK SRS) muss darauf vertraut werden, dass dieses ehrlich erstellt wurde, oder es müssen transparente/setup-lose Systeme verwendet werden.
On-Chain-Kosten und SkalierbarkeitHohe Kosten pro Transaktion: Homomorphe Operationen sind extrem rechenintensiv und jeder Knoten muss sie ausführen. Die Gas-Kosten sind hoch (z. B. 100k+ Gas für eine einfache 8-Bit-Addition). Komplexe Contracts sind dadurch begrenzt, was jeder Validator in einem Block berechnen kann. Der Durchsatz ist viel geringer als bei normalen Smart Contracts, sofern keine spezialisierte Hardware eingesetzt wird. Skalierbarkeit wird durch schnellere Kryptografie und Hardwarebeschleunigung verbessert, aber grundsätzlich erhöht jede Operation die Last der Chain.Geringe Verifizierungskosten: Das Verifizieren eines prägnanten Beweises ist effizient und hat eine konstante Größe, sodass das On-Chain-Gas moderat ist (einige hunderttausend Gas für Berechnungen beliebiger Größe). Dies entkoppelt die Komplexität von On-Chain-Ressourcenlimits – große Berechnungen verursachen keine zusätzlichen On-Chain-Kosten. Somit skaliert es in Bezug auf die On-Chain-Last. Off-Chain kann die Beweiszeit erheblich sein (Minuten oder mehr für riesige Aufgaben) und leistungsstarke Maschinen erfordern, aber dies verlangsamt die Blockchain nicht direkt. Der Gesamtdurchsatz kann hoch sein, solange Beweise rechtzeitig generiert werden können (potenzielle parallele Prover-Netzwerke).
LatenzErgebnisse sind sofort in derselben Transaktion/demselben Block verfügbar, da die Berechnung während der Ausführung erfolgt. 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 Anfrage und eine spätere Transaktion (oder einen Callback), um den Beweis/das Ergebnis zu liefern. Dies führt zu Verzögerungen (je nach Beweiskomplexität und Hardware möglicherweise Sekunden bis Stunden). Nicht geeignet für sofortige Finalität einer einzelnen Transaktion – eher wie ein asynchrones Job-Modell.
DatenschutzgarantienStark: Alles (Eingaben, Ausgaben, Zwischenzustände) kann On-Chain verschlüsselt bleiben. Man kann einen langlebigen verschlüsselten Zustand haben, den mehrere Transaktionen aktualisieren, ohne ihn jemals offenzulegen. Nur autorisierte Entschlüsselungsaktionen (falls vorhanden) geben Ergebnisse preis, und diese können über Schlüssel/ACLs gesteuert werden. Seitenkanal-Aspekte wie Gasverbrauch oder Event-Logs müssen jedoch so verwaltet werden, dass sie keine Muster verraten (fhEVM-Designs streben eine datenunabhängige Ausführung mit konstantem Gas für Operationen an, um Leaks zu vermeiden).Selektiv: Der Beweis offenbart alles, was in den öffentlichen Ausgaben steht oder zur Verifizierung notwendig ist (z. B. ein Commitment zum Anfangszustand). Designer können sicherstellen, dass nur das beabsichtigte Ergebnis preisgegeben wird und alle anderen Eingaben Zero-Knowledge-verborgen bleiben. Aber im Gegensatz zu FHE speichert die Blockchain normalerweise nicht den verborgenen Zustand – Datenschutz wird dadurch erreicht, dass Daten vollständig Off-Chain gehalten werden. Wenn ein persistenter privater Zustand benötigt wird, kann der Contract ein kryptografisches Commitment dazu speichern (Zustandsaktualisierungen offenbaren dann jedes Mal ein neues Commitment). Der Datenschutz ist darauf begrenzt, was man zu beweisen wählt; man hat die Flexibilität, z. B. zu beweisen, dass ein Schwellenwert erreicht wurde, ohne exakte Werte offenzulegen.

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

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

Anwendungsfälle und Auswirkungen

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

Vertrauliches DeFi und Finanzwesen

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

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

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

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

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

Digitale Identität und persönliche Daten

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

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

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

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

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

Gesundheitswesen und sensibler Datenaustausch

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

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

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

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

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

Datenmarktplätze und Zusammenarbeit

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

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

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

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

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

Dezentrales maschinelles Lernen (ZKML und FHE-ML)

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

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

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

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

Zusätzliche Bereiche

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

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

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

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

Fazit

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

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

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

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

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

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

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