Die Sui Blockchain hat sich als die technisch fortschrittlichste Plattform für Rechenlasten der nächsten Generation etabliert und erreicht 297.000 Transaktionen pro Sekunde mit 480 ms Finalität, während sie quantenresistente Kryptographie und eine speziell entwickelte Robotik-Infrastruktur integriert. Unter der Leitung des Chefkryptographen Kostas Chalkias – der über 50 akademische Publikationen vorweisen kann und kryptographische Innovationen im Diem-Projekt von Meta vorangetrieben hat – stellt Sui eine grundlegende architektonische Abkehr von traditionellen Blockchains dar, die speziell darauf ausgelegt ist, autonome KI-Agenten, Multi-Roboter-Koordination und Post-Quanten-Sicherheit zu ermöglichen.

Im Gegensatz zu Wettbewerbern, die Blockchains für fortgeschrittene Berechnungen nachrüsten, wurden Sais objektzentriertes Datenmodell, die Programmiersprache Move und das Mysticeti-Konsensprotokoll von Anfang an für parallele KI-Operationen, Echtzeit-Robotiksteuerung und kryptographische Agilität entwickelt – Fähigkeiten, die durch Live-Implementierungen validiert wurden, darunter über 50 KI-Projekte, Demonstrationen der Multi-Roboter-Zusammenarbeit und der weltweit erste abwärtskompatible quantensichere Upgrade-Pfad für Blockchain-Wallets.

Sais revolutionäre technische Grundlage ermöglicht das Unmögliche​

Sais Architektur bricht mit traditionellen kontobasierten Blockchain-Modellen durch drei synergistische Innovationen, die sie einzigartig für KI-, Robotik- und Quantenanwendungen positionieren.

Das Mysticeti-Konsensprotokoll erreicht eine beispiellose Leistung durch eine unzertifizierte DAG-Architektur, die die Konsenslatenz auf 390-650 ms reduziert (80 % schneller als sein Vorgänger) und gleichzeitig einen nachhaltigen Durchsatz von über 200.000 TPS unterstützt. Dies stellt einen grundlegenden Durchbruch dar: Traditionelle Blockchains wie Ethereum benötigen 12-15 Sekunden für die Finalität, während Sais schneller Pfad für Transaktionen mit einem einzigen Eigentümer in nur 250 ms abgeschlossen wird. Die mehreren Leader pro Runde des Protokolls und der implizite Commit-Mechanismus ermöglichen Echtzeit-KI-Entscheidungsschleifen und Robotik-Steuerungssysteme, die ein Feedback im Sub-Sekunden-Bereich erfordern – Anwendungen, die auf sequenziellen Ausführungsketten physisch unmöglich sind.

Das objektzentrierte Datenmodell behandelt jedes Asset als ein unabhängig adressierbares Objekt mit expliziter Eigentümerschaft und Versionierung, was eine statische Abhängigkeitsanalyse vor der Ausführung ermöglicht. Diese architektonische Wahl eliminiert den Overhead der retrospektiven Konflikterkennung, der optimistische Ausführungsmodelle plagt, und ermöglicht es Tausenden von KI-Agenten, gleichzeitig und ohne Konflikte Transaktionen durchzuführen. Objekte umgehen den Konsens vollständig, wenn sie von einzelnen Parteien besessen werden, was 70 % der Verarbeitungszeit für gängige Operationen einspart. Für die Robotik bedeutet dies, dass einzelne Roboter eigene Objekte für Sensordaten verwalten, während sie nur bei Bedarf über gemeinsam genutzte Objekte koordinieren – was die Architekturen autonomer Systeme in der realen Welt präzise widerspiegelt.

Die Programmiersprache Move bietet ressourcenorientierte Sicherheit, die in kontobasierten Sprachen wie Solidity unmöglich ist. Assets existieren als erstklassige Typen, die nicht kopiert oder zerstört werden können – nur zwischen Kontexten verschoben werden – wodurch ganze Klassen von Schwachstellen, einschließlich Reentrancy-Angriffen, Double-Spending und unautorisierter Asset-Manipulation, verhindert werden. Moves lineares Typsystem und die Unterstützung für formale Verifikation machen es besonders geeignet für KI-Agenten, die wertvolle Assets autonom verwalten. Programmierbare Transaktionsblöcke können bis zu 1.024 Funktionsaufrufe atomar zusammensetzen, was komplexe mehrstufige KI-Workflows mit garantierter Konsistenz ermöglicht.

Kostas Chalkias konzipiert Quantenresistenz als Wettbewerbsvorteil​

Kostas „Kryptos“ Chalkias bringt unübertroffene kryptographische Expertise in Sais Quantencomputing-Strategie ein, nachdem er den Blockchained Post-Quantum Signature (BPQS)-Algorithmus entwickelt, die Kryptographie für Metas Diem-Blockchain geleitet und über 50 von Fachleuten begutachtete Artikel veröffentlicht hat, die über 1.374 Mal zitiert wurden. Sein Forschungsdurchbruch im Juli 2025 demonstrierte den ersten abwärtskompatiblen quantensicheren Upgrade-Pfad für Blockchain-Wallets, anwendbar auf EdDSA-basierte Ketten wie Sui, Solana, Near und Cosmos.

Chalkias' Vision positioniert Quantenresistenz nicht als ferne Sorge, sondern als unmittelbares Wettbewerbsmerkmal. Er warnte im Januar 2025, dass „Regierungen sich der Risiken des Quantencomputings sehr bewusst sind. Behörden weltweit haben Mandate erlassen, dass klassische Algorithmen wie ECDSA und RSA bis 2030 oder 2035 veraltet sein müssen.“ Seine technische Erkenntnis: Selbst wenn Benutzer private Schlüssel behalten, könnten sie ohne die Offenlegung der Schlüssel gegenüber Quantenangriffen keine Post-Quanten-Eigentumsnachweise generieren. Sais Lösung nutzt Zero-Knowledge-STARK-Proofs, um das Wissen über Schlüsselgenerierungssamen zu beweisen, ohne sensible Daten preiszugeben – eine kryptographische Innovation, die auf Blockchains ohne integrierte Agilität unmöglich ist.

Das Framework für kryptographische Agilität repräsentiert Chalkias' charakteristische Designphilosophie. Sui verwendet 1-Byte-Flags, um Signaturschemata (Ed25519, ECDSA Secp256k1/r1, BLS12-381, Multisig, zkLogin) zu unterscheiden, was die Unterstützung neuer Algorithmen auf Protokollebene ohne Smart-Contract-Overhead oder Hard Forks ermöglicht. Diese Architektur erlaubt „auf Knopfdruck“ Übergänge zu NIST-standardisierten Post-Quanten-Algorithmen, einschließlich CRYSTALS-Dilithium (2.420-Byte-Signaturen) und FALCON (666-Byte-Signaturen), wenn Quantenbedrohungen auftreten. Chalkias konzipierte mehrere Migrationspfade: proaktiv (neue Konten generieren PQ-Schlüssel bei der Erstellung), adaptiv (STARK-Proofs ermöglichen die PQ-Migration von bestehenden Seeds) und hybrid (zeitlich begrenzte Multisig, die klassische und quantenresistente Schlüssel kombiniert).

Seine zkLogin-Innovation demonstriert kryptographische Kreativität, angewandt auf Benutzerfreundlichkeit. Das System ermöglicht es Benutzern, sich über Google-, Facebook- oder Twitch-Anmeldeinformationen unter Verwendung von Groth16 Zero-Knowledge-Proofs über BN254-Kurven zu authentifizieren, wobei ein benutzergesteuertes Salt die Korrelation von Web2-Web3-Identitäten verhindert. zkLogin berücksichtigt Quantenüberlegungen bereits im Design – die STARK-basierten Seed-Knowledge-Proofs bieten Post-Quanten-Sicherheit, selbst wenn zugrunde liegende JWT-Signaturen von RSA zu gitterbasierten Alternativen übergehen.

Auf dem Sui Basecamp 2025 enthüllte Chalkias native verifizierbare Zufälligkeit, zk-Tunnel für Off-Chain-Logik, Blitztransaktionen (Zero-Gas, Zero-Latenz) und Zeitkapseln für den verschlüsselten zukünftigen Datenzugriff. Diese Funktionen ermöglichen private KI-Agenten-Simulationen, Glücksspielanwendungen, die vertrauenswürdige Zufälligkeit erfordern, und Zero-Knowledge-Pokerspiele – all dies wäre ohne kryptographische Primitive auf Protokollebene unmöglich. Seine Vision: „Ein Ziel für Sui war es, die erste Blockchain zu werden, die Post-Quanten-Technologien einführt und dadurch die Sicherheit verbessert und sich auf zukünftige regulatorische Standards vorbereitet.“

KI-Agenten-Infrastruktur erreicht Produktionsreife auf Sui​

Sui beherbergt das umfassendste KI-Agenten-Ökosystem der Blockchain-Industrie mit über 50 Projekten, die Infrastruktur, Frameworks und Anwendungen umfassen – alle nutzen Sais parallele Ausführung und Sub-Sekunden-Finalität für autonome Echtzeit-Operationen.

Das Atoma Network wurde im Dezember 2024 auf dem Sui Mainnet als erste vollständig dezentrale KI-Inferenzschicht gestartet und positioniert sich als „dezentraler Hyperscaler für Open-Source-KI“. Die gesamte Verarbeitung erfolgt in Trusted Execution Environments (TEEs), die vollständige Privatsphäre und Zensurresistenz gewährleisten, während die API-Kompatibilität mit OpenAI-Endpunkten erhalten bleibt. Die Chat-Anwendung Utopia demonstriert produktionsreife, datenschutzfreundliche KI mit einer Leistung, die ChatGPT entspricht, und wickelt Zahlungen und Validierungen durch Sais Sub-Sekunden-Finalität ab. Atoma ermöglicht DeFi-Portfoliomanagement, Moderation von Social-Media-Inhalten und persönliche Assistenten-Anwendungen – Anwendungsfälle, die sowohl KI-Intelligenz als auch Blockchain-Abwicklung erfordern und auf langsameren Ketten unmöglich zu realisieren wären.

OpenGraph Labs erzielte einen technischen Durchbruch als erstes vollständig On-Chain-KI-Inferenzsystem, das speziell für KI-Agenten entwickelt wurde. Ihr TensorflowSui SDK automatisiert die Bereitstellung von Web2-ML-Modellen (TensorFlow, PyTorch) auf der Sui Blockchain, speichert Trainingsdaten im dezentralen Walrus-Speicher und führt Inferenzen mithilfe von Programmable Transaction Blocks aus. OpenGraph bietet drei flexible Inferenzansätze: PTB-Inferenz für kritische Berechnungen, die Atomizität erfordern, geteilte Transaktionen zur Kostenoptimierung und hybride Kombinationen, die pro Anwendungsfall angepasst werden. Diese Architektur eliminiert „Black-Box“-KI-Risiken durch vollständig verifizierbare, auditierbare Inferenzprozesse mit klar definierter algorithmischer Eigentümerschaft – entscheidend für regulierte Industrien, die erklärbare KI benötigen.

Das Talus Network wurde im Februar 2025 auf Sui mit dem Nexus-Framework gestartet, das Entwicklern ermöglicht, zusammensetzbare KI-Agenten zu erstellen, die Workflows direkt On-Chain ausführen. Talus' Idol.fun-Plattform demonstriert kundenorientierte KI-Agenten als tokenisierte Entitäten, die 24/7 autonom agieren und Echtzeitentscheidungen treffen, indem sie in Walrus gespeicherte Datensätze für Marktstimmung, DeFi-Statistiken und soziale Trends nutzen. Beispielanwendungen umfassen dynamisches NFT-Profilmanagement, DeFi-Liquiditätsstrategie-Agenten, die Modelle in Echtzeit laden, und Betrugserkennungsagenten, die historische Transaktionsmuster aus unveränderlichen Sui-Checkpoints analysieren.

Die im August 2025 angekündigte Alibaba Cloud-Partnerschaft integrierte KI-Codierungsassistenten in die ChainIDE-Entwicklungsplattform mit mehrsprachiger Unterstützung (Englisch, Chinesisch, Koreanisch). Zu den Funktionen gehören die Generierung von Move-Code aus natürlicher Sprache, intelligente Autovervollständigung, Echtzeit-Erkennung von Sicherheitslücken und automatisierte Dokumentationsgenerierung – was die Hürden für 60 % der nicht-englischsprachigen Entwicklerzielgruppe von Sui senkt. Diese Partnerschaft bestätigt Sais Positionierung als KI-Entwicklungsplattform, nicht nur als KI-Bereitstellungsplattform.

Sais gesponserte Transaktionen eliminieren die Reibung bei Gaszahlungen für KI-Agenten – Entwickler können Transaktionsgebühren übernehmen, sodass Agenten ohne SUI-Token operieren können. Die MIST-Denomination (1 SUI = 1 Milliarde MIST) ermöglicht Mikrozahlungen von Bruchteilen eines Cents, perfekt für Pay-per-Inference-KI-Dienste. Mit durchschnittlichen Transaktionskosten von etwa 0,0023 $ können KI-Agenten täglich Tausende von Operationen für wenige Cents ausführen, was autonome Agentenökonomien wirtschaftlich rentabel macht.

Multi-Roboter-Zusammenarbeit beweist Sais Echtzeit-Koordinationsvorteil​

Sui demonstrierte das erste Multi-Roboter-Kollaborationssystem der Blockchain-Industrie unter Verwendung des Mysticeti-Konsenses, validiert durch die umfassende Analyse von Tiger Research aus dem Jahr 2025. Das System ermöglicht es Robotern, einen konsistenten Zustand in verteilten Umgebungen zu teilen, während die Byzantinische Fehlertoleranz aufrechterhalten wird – was den Konsens auch dann sicherstellt, wenn Roboter Fehlfunktionen aufweisen oder von Gegnern kompromittiert werden.

Die technische Architektur nutzt Sais Objektmodell, in dem Roboter als programmierbare Objekte mit Metadaten, Eigentümerschaft und Fähigkeiten existieren. Aufgaben werden spezifischen Roboterobjekten zugewiesen, wobei Smart Contracts die Sequenzierung und Ressourcenallokationsregeln automatisieren. Das System gewährleistet Zuverlässigkeit ohne zentrale Server, wobei parallele Blockvorschläge von mehreren Validatoren einzelne Fehlerquellen verhindern. Die Sub-Sekunden-Transaktionsfinalität ermöglicht Echtzeit-Anpassungsschleifen – Roboter erhalten Aufgabenbestätigungen und Statusaktualisierungen in unter 400 ms, was den Anforderungen von Steuerungssystemen für einen reaktionsschnellen autonomen Betrieb entspricht.

Physische Tests mit hundeähnlichen Robotern haben bereits die Machbarkeit demonstriert, wobei Teams mit Hintergründen bei NASA, Meta und Uber Sui-basierte Robotik-Anwendungen entwickeln. Sais einzigartige „Internetlos-Modus“-Fähigkeit – der Betrieb über Funkwellen ohne stabile Internetverbindung – bietet revolutionäre Vorteile für ländliche Einsätze in Afrika, ländlichen Gebieten Asiens und in Notfallszenarien. Diese Offline-Fähigkeit existiert unter den großen Blockchains ausschließlich auf Sui, validiert durch Tests während Stromausfällen in Spanien/Portugal.

Die im September 2024 angekündigte 3DOS-Partnerschaft bestätigt Sais Fähigkeiten im Bereich der Fertigungsrobotik in großem Maßstab. 3DOS integrierte über 79.909 3D-Drucker in über 120 Ländern als exklusiver Blockchain-Partner von Sui und schuf ein „Uber für den 3D-Druck“-Netzwerk, das Peer-to-Peer-Fertigung ermöglicht. Zu den namhaften Kunden gehören John Deere, Google, MIT, Harvard, Bosch, die British Army, die US Navy, die US Air Force und die NASA – was das Vertrauen auf Unternehmensebene in Sais Infrastruktur demonstriert. Das System ermöglicht es Robotern, Ersatzteile autonom über Smart-Contract-Automatisierung zu bestellen und zu drucken, wodurch die Selbstreparatur von Robotern mit nahezu null menschlichem Eingriff erleichtert wird. Dies adressiert den globalen Fertigungsmarkt von 15,6 Billionen US-Dollar durch On-Demand-Produktion, die Lagerbestände, Abfall und internationalen Versand eliminiert.

Sais Byzantinische Fehlertoleranz erweist sich als entscheidend für sicherheitskritische Robotik-Anwendungen. Der Konsensmechanismus toleriert bis zu f fehlerhafte/bösartige Roboter in einem 3f+1-System und stellt sicher, dass autonome Fahrzeugflotten, Lagerroboter und Fertigungssysteme die Koordination trotz individueller Ausfälle aufrechterhalten. Smart Contracts erzwingen Sicherheitsbeschränkungen und Betriebsgrenzen, wobei unveränderliche Audit-Trails die Rechenschaftspflicht für autonome Entscheidungen gewährleisten – Anforderungen, die mit zentralisierten Koordinationsservern, die anfällig für einzelne Fehlerquellen sind, unmöglich zu erfüllen wären.

Roadmap zur Quantenresistenz liefert kryptographische Überlegenheit​

Sais Quantencomputing-Strategie stellt den einzigen umfassenden, proaktiven Ansatz der Blockchain-Industrie dar, der mit den NIST-Mandaten übereinstimmt, die die Abschaffung klassischer Algorithmen bis 2030 und eine vollständige quantenresistente Standardisierung bis 2035 vorschreiben.

Chalkias' bahnbrechende Forschung vom Juli 2025 zeigte, dass EdDSA-basierte Ketten, einschließlich Sui, quantensichere Wallet-Upgrades ohne Hard Forks, Adressänderungen oder Kontosperrungen durch Zero-Knowledge-Proofs, die das Wissen über den Seed beweisen, implementieren können. Dies ermöglicht eine sichere Migration auch für ruhende Konten – und löst die existenzielle Bedrohung für Blockchains, bei der Millionen von Wallets „sofort geleert werden könnten“, sobald Quantencomputer verfügbar sind. Die technische Innovation verwendet STARK-Proofs (quantenresistente hash-basierte Sicherheit), um das Wissen über EdDSA-Schlüsselgenerierungssamen zu beweisen, ohne sensible Daten preiszugeben, wodurch Benutzer die PQ-Schlüsseleigentümerschaft an bestehende Adressen binden können.

Sais Architektur für kryptographische Agilität ermöglicht mehrere Übergangsstrategien: proaktiv (PQ-Schlüssel signieren PreQ-Public-Keys bei der Erstellung), adaptiv (STARK-Proofs migrieren bestehende Adressen) und hybrid (zeitlich begrenzte Multisig, die klassische und quantenresistente Schlüssel kombiniert). Das Protokoll unterstützt die sofortige Bereitstellung von NIST-standardisierten Algorithmen, einschließlich CRYSTALS-Dilithium (ML-DSA), FALCON (FN-DSA) und SPHINCS+ (SLH-DSA) für gitterbasierte und hash-basierte Post-Quanten-Sicherheit. Validator-BLS-Signaturen wechseln zu gitterbasierten Alternativen, Hash-Funktionen werden von 256-Bit- auf 384-Bit-Ausgaben für quantenresistente Kollisionsresistenz aktualisiert, und zkLogin-Schaltungen migrieren von Groth16 zu STARK-basierten Zero-Knowledge-Proofs.

Das im Juni 2025 gestartete Nautilus-Framework bietet sichere Off-Chain-Berechnungen unter Verwendung selbstverwalteter TEEs (Trusted Execution Environments), die derzeit AWS Nitro Enclaves unterstützen, mit zukünftiger Intel TDX- und AMD SEV-Kompatibilität. Für KI-Anwendungen ermöglicht Nautilus private KI-Inferenz mit kryptographischen Attestierungen, die On-Chain verifiziert werden, wodurch die Spannung zwischen Recheneffizienz und Verifizierbarkeit gelöst wird. Startpartner wie Bluefin (TEE-basiertes Order-Matching bei <1 ms), TensorBlock (KI-Agenten-Infrastruktur) und OpenGradient demonstrieren die Produktionsreife für datenschutzfreundliche, quantenresistente Berechnungen.

Vergleichende Analysen zeigen Sais Quantenvorteil: Ethereum befindet sich noch in der Planungsphase, wobei Vitalik Buterin erklärt, dass Quantenresistenz „mindestens ein Jahrzehnt entfernt“ sei und Hard Forks sowie einen Community-Konsens erfordere. Solana führte im Januar 2025 Winternitz Vault als optionales hash-basiertes Signaturmerkmal ein, das eine Benutzerzustimmung erfordert und keine protokollweite Implementierung darstellt. Andere große Blockchains (Aptos, Avalanche, Polkadot) verbleiben in der Forschungsphase ohne konkrete Implementierungszeitpläne. Nur Sui hat kryptographische Agilität als grundlegendes Prinzip konzipiert, das schnelle Algorithmusübergänge ohne Governance-Kämpfe oder Netzwerkspaltungen ermöglicht.

Synthese der technischen Architektur schafft emergente Fähigkeiten​

Sais architektonische Komponenten interagieren synergistisch, um Fähigkeiten zu schaffen, die die Summe der einzelnen Merkmale übertreffen – ein Merkmal, das wirklich innovative Plattformen von inkrementellen Verbesserungen unterscheidet.

Das Ressourcenmodell der Move-Sprache kombiniert mit paralleler Objektausführung ermöglicht einen beispiellosen Durchsatz für KI-Agenten-Schwärme. Traditionelle Blockchains, die kontobasierte Modelle verwenden, erfordern eine sequentielle Ausführung, um Race Conditions zu verhindern, was die Koordination von KI-Agenten auf Single-Thread-Engpässe beschränkt. Sais explizite Abhängigkeitsdeklaration durch Objektverweise ermöglicht es Validatoren, unabhängige Operationen vor der Ausführung zu identifizieren und Tausende von KI-Agenten-Transaktionen gleichzeitig über CPU-Kerne zu planen. Diese Parallelisierung des State-Zugriffs (im Gegensatz zur optimistischen Ausführung, die Konflikterkennung erfordert) bietet eine vorhersehbare Leistung ohne nachträgliche Transaktionsfehler – entscheidend für KI-Systeme, die Zuverlässigkeitsgarantien benötigen.

Programmierbare Transaktionsblöcke verstärken Moves Komponierbarkeit, indem sie bis zu 1.024 heterogene Funktionsaufrufe in atomaren Transaktionen ermöglichen. KI-Agenten können komplexe Workflows ausführen – Token tauschen, Orakeldaten aktualisieren, Machine-Learning-Inferenz auslösen, NFTs prägen, Benachrichtigungen senden – alles mit der Garantie, dass sie gemeinsam erfolgreich sind oder fehlschlagen. Diese heterogene Komposition verlagert die Logik von Smart Contracts auf die Transaktionsebene, wodurch die Gaskosten drastisch gesenkt und die Flexibilität erhöht werden. Für die Robotik ermöglichen PTBs atomare mehrstufige Operationen wie „Inventar prüfen, Teile bestellen, Zahlung autorisieren, Status aktualisieren“ mit kryptographischen Konsistenzgarantien.

Der Konsens-Bypass-Schnellpfad für Objekte mit einem einzigen Eigentümer schafft ein zweistufiges Leistungsmodell, das perfekt zu den Zugriffsmodellen von KI/Robotik passt. Einzelne Roboter verwalten private Zustände (Sensorwerte, Betriebsparameter) als eigene Objekte, die in 250 ms ohne Validator-Konsens verarbeitet werden. Koordinationspunkte (Aufgabenwarteschlangen, Ressourcenpools) existieren als gemeinsam genutzte Objekte, die einen 390 ms Konsens erfordern. Diese Architektur spiegelt autonome Systeme der realen Welt wider, bei denen Agenten lokale Zustände verwalten, aber über gemeinsam genutzte Ressourcen koordinieren – Sais Objektmodell bietet Blockchain-native Primitive, die diese Muster auf natürliche Weise abbilden.

zkLogin löst die Onboarding-Reibung, die die Mainstream-Adoption von KI-Agenten verhindert. Traditionelle Blockchains erfordern von Benutzern die Verwaltung von Seed-Phrasen und privaten Schlüsseln – kognitiv anspruchsvoll und fehleranfällig. zkLogin ermöglicht die Authentifizierung über vertraute OAuth-Anmeldeinformationen (Google, Facebook, Twitch) mit einem benutzergesteuerten Salt, das die Korrelation von Web2-Web3-Identitäten verhindert. KI-Agenten können unter Web2-Authentifizierung operieren, während die Blockchain-Sicherheit erhalten bleibt, was die Hürden für Verbraucheranwendungen drastisch senkt. Die über 10 dApps, die zkLogin bereits integrieren, demonstrieren die praktische Umsetzbarkeit für nicht-krypto-native Zielgruppen.

Wettbewerbspositionierung offenbart technische Führung und Ökosystemwachstum​

Vergleichende Analysen über große Blockchains (Solana, Ethereum, Aptos, Avalanche, Polkadot) zeigen Sais technische Überlegenheit für fortgeschrittene Rechenlasten, abgewogen gegen Ethereums Ökosystemreife und Solanas aktuelle DePIN-Adoption.

Leistungsmetriken etablieren Sui als Durchsatzführer mit 297.000 TPS, getestet auf 100 Validatoren, die eine Finalität von 480 ms aufrechterhalten, gegenüber Solanas theoretischen 65.000-107.000 TPS (3.000-4.000 nachhaltig) und Ethereums 15-30 TPS Basisschicht. Aptos erreicht theoretisch 160.000 TPS mit ähnlicher Move-basierter Architektur, aber unterschiedlichen Ausführungsmodellen. Für KI-Workloads, die Echtzeitentscheidungen erfordern, ermöglicht Sais 480 ms Finalität sofortige Antwortschleifen, die auf Ethereums 12-15 Minuten Finalität oder sogar Solanas gelegentlicher Netzwerküberlastung (75 % Transaktionsfehler im April 2024 bei Spitzenlast) unmöglich sind.

Die Analyse der Quantenresistenz zeigt Sui als die einzige Blockchain mit quantenresistenter Kryptographie, die von Anfang an in die Kernarchitektur integriert wurde. Ethereum adressiert Quanten in der Roadmap-Phase „The Splurge“, aber Vitalik Buterin schätzt eine 20%ige Wahrscheinlichkeit, dass Quanten Krypto bis 2030 brechen, und verlässt sich auf Notfall-„Recovery-Fork“-Pläne, die reaktiv statt proaktiv sind. Solanas Winternitz Vault bietet optionalen Quantenschutz, der eine Benutzerzustimmung erfordert, keine automatische netzwerkweite Sicherheit. Aptos, Avalanche und Polkadot verbleiben in der Forschungsphase ohne konkrete Zeitpläne. Sais kryptographische Agilität mit mehreren Migrationspfaden, STARK-basiertem zkLogin und einer NIST-konformen Roadmap positioniert sie als die einzige Blockchain, die für die vorgeschriebenen Post-Quanten-Übergänge 2030/2035 bereit ist.

KI-Agenten-Ökosysteme zeigen, dass Solana derzeit die Adoption mit ausgereiften Tools (SendAI Agent Kit, ElizaOS) und der größten Entwicklergemeinschaft anführt, aber Sui demonstriert überlegene technische Fähigkeiten durch eine Kapazität von 300.000 TPS, Sub-Sekunden-Latenz und über 50 Projekten, einschließlich Produktionsplattformen (Atoma Mainnet, Talus Nexus, OpenGraph On-Chain-Inferenz). Ethereum konzentriert sich auf institutionelle KI-Standards (ERC-8004 für KI-Identität/Vertrauen), aber die 15-30 TPS Basisschicht begrenzt Echtzeit-KI-Anwendungen auf Layer-2-Lösungen. Die Alibaba Cloud-Partnerschaft, die Sui als KI-Entwicklungsplattform (nicht nur Bereitstellungsplattform) positioniert, signalisiert eine strategische Differenzierung von reinen Finanz-Blockchains.

Robotik-Fähigkeiten existieren unter den großen Blockchains ausschließlich auf Sui. Kein Wettbewerber demonstriert Multi-Roboter-Kollaborationsinfrastruktur, Byzantinisch Fehlertolerante Koordination oder „Internetlos-Modus“-Offline-Betrieb. Die Analyse von Tiger Research kommt zu dem Schluss, dass „Blockchain möglicherweise eine geeignetere Infrastruktur für Roboter als für Menschen ist“, angesichts der Fähigkeit von Robotern, dezentrale Koordination ohne zentrales Vertrauen zu nutzen. Da Morgan Stanley bis 2050 1 Milliarde humanoider Roboter prognostiziert, schafft Sais speziell entwickelte Robotik-Infrastruktur einen First-Mover-Vorteil in der aufkommenden Roboterökonomie, in der autonome Systeme Identität, Zahlungen, Verträge und Koordination benötigen – Primitive, die Sui nativ bereitstellt.

Die Vorteile der Programmiersprache Move positionieren sowohl Sui als auch Aptos über Solidity-basierten Ketten für komplexe Anwendungen, die Sicherheit erfordern. Moves ressourcenorientiertes Modell verhindert Schwachstellenklassen, die in Solidity unmöglich zu beheben sind, wie der Verlust von über 1,1 Milliarden US-Dollar durch Exploits im Jahr 2024 auf Ethereum belegt. Die Unterstützung für formale Verifikation, das lineare Typsystem und erstklassige Asset-Abstraktionen machen Move besonders geeignet für KI-Agenten, die wertvolle Assets autonom verwalten. Sais objektzentrierte Move-Variante (im Gegensatz zu kontobasiertem Diem Move) ermöglicht Vorteile bei der parallelen Ausführung, die auf Aptos trotz gemeinsamer Sprachherkunft nicht verfügbar sind.

Praktische Implementierungen bestätigen technische Fähigkeiten​

Sais Produktionsimplementierungen demonstrieren den Übergang der Plattform vom technischen Potenzial zum praktischen Nutzen in den Bereichen KI, Robotik und Quanten.

Die Reife der KI-Infrastruktur zeigt eine klare Dynamik mit dem Mainnet-Start des Atoma Network im Dezember 2024, das Produktions-KI-Inferenz bedient, der Bereitstellung des Talus Nexus-Frameworks im Februar 2025, das zusammensetzbare Agenten-Workflows ermöglicht, und der 13-Millionen-Dollar-Finanzierungsrunde des Swarm Network, unterstützt von Kostas Chalkias, der über 10.000 KI-Agenten-Lizenzen auf Sui verkauft. Die Alibaba Cloud-Partnerschaft bietet eine Validierung auf Unternehmensebene mit in Entwicklertools integrierten KI-Codierungsassistenten, was ein strategisches Engagement über spekulative Anwendungen hinaus demonstriert. OpenGraph Labs, das den ersten Platz beim Sui AI Typhoon Hackathon mit On-Chain-ML-Inferenz gewann, signalisiert technische Innovation, die von Expertenjuroren anerkannt wird.

Fertigungsrobotik erreichte kommerziellen Maßstab durch das 79.909-Drucker-Netzwerk von 3DOS in über 120 Ländern, das NASA, US Navy, US Air Force, John Deere und Google bedient. Dies stellt das weltweit größte Blockchain-integrierte Fertigungsnetzwerk dar, das über 4,2 Millionen Teile mit über 500.000 Benutzern verarbeitet. Das Peer-to-Peer-Modell, das es Robotern ermöglicht, Ersatzteile autonom zu bestellen, demonstriert die Smart-Contract-Automatisierung, die den Koordinationsaufwand im industriellen Maßstab eliminiert – ein Proof of Concept, der von anspruchsvollen Regierungs- und Luftfahrtkunden, die Zuverlässigkeit und Sicherheit erfordern, validiert wurde.

Finanzkennzahlen zeigen eine wachsende Akzeptanz mit 538 Millionen US-Dollar TVL, 17,6 Millionen monatlich aktiven Wallets (Höhepunkt im Februar 2025) und einer SUI-Token-Marktkapitalisierung von über 16 Milliarden US-Dollar. Mysten Labs erreichte eine Bewertung von über 3 Milliarden US-Dollar, unterstützt von a16z, Binance Labs, Coinbase Ventures und Jump Crypto – eine institutionelle Validierung des technischen Potenzials. Schweizer Banken (Sygnum, Amina Bank), die Sui-Verwahrung und -Handel anbieten, bieten traditionelle Finanzzugänge, während institutionelle Produkte von Grayscale, Franklin Templeton und VanEck die Mainstream-Anerkennung signalisieren.

Wachstum des Entwickler-Ökosystems demonstriert Nachhaltigkeit mit umfassenden Tools (TypeScript, Rust, Python, Swift, Dart, Golang SDKs), KI-Codierungsassistenten in ChainIDE und aktiven Hackathon-Programmen, bei denen 50 % der Gewinner sich auf KI-Anwendungen konzentrierten. Die 122 aktiven Validatoren im Mainnet bieten eine ausreichende Dezentralisierung bei gleichzeitiger Aufrechterhaltung der Leistung, wodurch Sicherheit und Durchsatz besser ausbalanciert werden als bei stark zentralisierten Alternativen.

Strategische Vision positioniert Sui für die Konvergenz-Ära​

Kostas Chalkias und die Führung von Mysten Labs formulieren eine kohärente langfristige Vision, die Sui von Wettbewerbern unterscheidet, die sich auf enge Anwendungsfälle oder inkrementelle Verbesserungen konzentrieren.

Chalkias' kühne Vorhersage, dass „Blockchain irgendwann sogar Visa in der Transaktionsgeschwindigkeit übertreffen wird. Es wird die Norm sein. Ich sehe nicht, wie wir dem entkommen können“, signalisiert Vertrauen in die technische Entwicklung, gestützt durch architektonische Entscheidungen, die diese Zukunft ermöglichen. Seine Aussage, dass Mysten Labs „das übertreffen könnte, was Apple heute ist“, spiegelt den Ehrgeiz wider, grundlegende Infrastruktur für das Computing der nächsten Generation aufzubauen, anstatt inkrementelle DeFi-Anwendungen zu entwickeln. Die Entscheidung, seinen Sohn „Kryptos“ (griechisch für „geheim/verborgen“) zu nennen, symbolisiert das persönliche Engagement für kryptographische Innovation als zivilisatorische Infrastruktur.

Die Drei-Säulen-Strategie, die KI, Robotik und Quantencomputing integriert, schafft sich gegenseitig verstärkende Vorteile. Quantenresistente Kryptographie ermöglicht langfristige Asset-Sicherheit für autonom operierende KI-Agenten. Sub-Sekunden-Finalität unterstützt Echtzeit-Robotik-Regelkreise. Parallele Ausführung ermöglicht Tausenden von KI-Agenten die gleichzeitige Koordination. Das Objektmodell bietet eine natürliche Abstraktion sowohl für den Zustand von KI-Agenten als auch für die Darstellung von Robotergeräten. Diese architektonische Kohärenz unterscheidet ein zielgerichtetes Plattformdesign von nachträglich hinzugefügten Funktionen.

Sui Basecamp 2025 Technologie-Enthüllungen demonstrieren kontinuierliche Innovation mit nativer verifizierbarer Zufälligkeit (eliminiert Orakelabhängigkeiten für KI-Inferenz), zk-Tunneln, die private Videoanrufe direkt auf Sui ermöglichen, Blitztransaktionen für Zero-Gas-Operationen in Notfällen und Zeitkapseln für verschlüsselten zukünftigen Datenzugriff. Diese Funktionen adressieren reale Benutzerprobleme (Datenschutz, Zuverlässigkeit, Zugänglichkeit) statt akademischer Übungen, mit klaren Anwendungen für KI-Agenten, die vertrauenswürdige Zufälligkeit benötigen, Robotiksysteme, die Offline-Betrieb erfordern, und quantenresistente Verschlüsselung für sensible Daten.

Die Positionierung als „Koordinationsschicht für eine breite Palette von Anwendungen“ von der Verwaltung von Gesundheitsdaten über die persönliche Datenhoheit bis hin zur Robotik spiegelt die Plattformambitionen jenseits finanzieller Spekulationen wider. Chalkias' Identifizierung der Ineffizienz von Gesundheitsdaten als Problem, das eine gemeinsame Datenbank erfordert, zeigt ein Denken über gesellschaftliche Infrastruktur statt enger Blockchain-Enthusiasten-Nischen. Diese Vision zieht Forschungslabore, Hardware-Startups und Regierungen an – Zielgruppen, die zuverlässige Infrastruktur für langfristige Projekte suchen, nicht spekulatives Yield Farming.

Technische Roadmap liefert umsetzbaren Zeitplan​

Sais Entwicklungs-Roadmap bietet konkrete Meilensteine, die den Fortschritt von der Vision zur Implementierung in allen drei Fokusbereichen demonstrieren.

Der Zeitplan für Quantenresistenz stimmt mit den NIST-Mandaten überein: 2025-2027 wird die Infrastruktur und das Testen der kryptographischen Agilität abgeschlossen, 2028-2030 werden Protokoll-Upgrades für Dilithium/FALCON-Signaturen mit hybrider PreQ-PQ-Operation eingeführt, 2030-2035 wird der vollständige Post-Quanten-Übergang mit der Abschaffung klassischer Algorithmen erreicht. Die mehreren Migrationspfade (proaktiv, adaptiv, hybrid) bieten Flexibilität für verschiedene Benutzersegmente, ohne eine einzige Adoptionsstrategie zu erzwingen. Hash-Funktions-Upgrades auf 384-Bit-Ausgaben und die zkLogin PQ-zkSNARK-Forschung verlaufen parallel, um eine umfassende Quantenbereitschaft statt stückweiser Patches zu gewährleisten.

Erweiterung der KI-Infrastruktur zeigt klare Meilensteine mit dem Walrus Mainnet-Start (Q1 2025), der dezentralen Speicher für KI-Modelle bereitstellt, dem Talus Nexus-Framework, das zusammensetzbare Agenten-Workflows ermöglicht (Bereitstellung im Februar 2025), und dem Nautilus TEE-Framework, das über die aktuelle AWS Nitro Enclaves-Unterstützung hinaus auf Intel TDX und AMD SEV erweitert wird. Die Roadmap der Alibaba Cloud-Partnerschaft umfasst erweiterte Sprachunterstützung, tiefere ChainIDE-Integration und Demo-Tage in Hongkong, Singapur und Dubai, die auf Entwicklergemeinschaften abzielen. OpenGraphs On-Chain-Inferenz-Explorer und die Reifung des TensorflowSui SDK bieten praktische Tools für KI-Entwickler jenseits theoretischer Frameworks.

Fortschritt der Robotik-Fähigkeiten schreitet von Multi-Roboter-Kollaborationsdemos zu Produktionsimplementierungen mit der 3DOS-Netzwerkerweiterung, „Internetlos-Modus“-Funkwellen-Transaktionsfähigkeiten und zkTunneln, die Zero-Gas-Roboterbefehle ermöglichen. Die technische Architektur, die Byzantinische Fehlertoleranz, Sub-Sekunden-Koordinationsschleifen und autonome M2M-Zahlungen unterstützt, existiert heute – Adoptionsbarrieren sind eher pädagogischer Natur und Ökosystem-Aufbau als technische Einschränkungen. Die Beteiligung von NASA-, Meta- und Uber-Alumni signalisiert ernsthaftes Ingenieurstalent, das reale Robotik-Herausforderungen angeht, im Gegensatz zu akademischen Forschungsprojekten.

Protokollverbesserungen umfassen Verfeinerungen des Mysticeti-Konsenses, die einen 80%igen Latenzreduktionsvorteil beibehalten, horizontale Skalierung durch Pilotfish-Multi-Maschinen-Ausführung und Speicheroptimierung für wachsenden Zustand. Das Checkpoint-System (alle ~3 Sekunden) bietet verifizierbare Snapshots für KI-Trainingsdaten und Robotik-Audit-Trails. Die Reduzierung der Transaktionsgröße auf ein-Byte-Voreinstellungsformate reduziert die Bandbreitenanforderungen für IoT-Geräte. Die Erweiterung gesponserter Transaktionen eliminiert Gas-Reibung für Verbraucheranwendungen, die eine nahtlose Web2-ähnliche UX erfordern.

Technische Exzellenz positioniert Sui für die Dominanz im Bereich des fortgeschrittenen Computings​

Eine umfassende Analyse der technischen Architektur, der Führungsvision, der realen Implementierungen und der Wettbewerbspositionierung zeigt Sui als die Blockchain-Plattform, die einzigartig auf die Konvergenz von KI, Robotik und Quantencomputing vorbereitet ist.

Sui erreicht technische Überlegenheit durch gemessene Leistungsmetriken: 297.000 TPS mit 480 ms Finalität übertrifft alle großen Wettbewerber und ermöglicht Echtzeit-KI-Agenten-Koordination und Robotik-Steuerung, die auf langsameren Ketten unmöglich sind. Das objektzentrierte Datenmodell kombiniert mit der Sicherheit der Move-Sprache bietet Vorteile im Programmiermodell, die Schwachstellenklassen verhindern, die kontobasierte Architekturen plagen. Kryptographische Agilität, von Anfang an konzipiert – nicht nachgerüstet – ermöglicht quantenresistente Übergänge ohne Hard Forks oder Governance-Kämpfe. Diese Fähigkeiten existieren heute in Produktion auf dem Mainnet mit 122 Validatoren, nicht als theoretische Whitepapers oder ferne Roadmaps.

Visionäre Führung durch Kostas Chalkias' über 50 Publikationen, 8 US-Patente und kryptographische Innovationen (zkLogin, BPQS, Winterfell STARK, HashWires) bietet eine intellektuelle Grundlage, die Sui von technisch kompetenten, aber fantasielosen Wettbewerbern unterscheidet. Seine bahnbrechende Forschung im Quantencomputing (Juli 2025), die Unterstützung der KI-Infrastruktur (Swarm Network-Unterstützung) und die öffentliche Kommunikation (Token 2049, Korea Blockchain Week, London Real) etablieren Vordenkerrolle, die Top-Entwickler und institutionelle Partner anzieht. Die Bereitschaft, für Zeiträume über 2030 hinaus zu planen, anstatt sich auf vierteljährliche Metriken zu konzentrieren, demonstriert das langfristige strategische Denken, das für die Plattforminfrastruktur erforderlich ist.

Ökosystem-Validierung durch Produktionsimplementierungen (Atoma Mainnet KI-Inferenz, 3DOS 79.909-Drucker-Netzwerk, Talus Agenten-Frameworks) beweist, dass technische Fähigkeiten in realen Nutzen umgesetzt werden können. Institutionelle Partnerschaften (Alibaba Cloud, Schweizer Bankverwahrung, Grayscale/Franklin Templeton Produkte) signalisieren Mainstream-Anerkennung jenseits von Blockchain-nativen Enthusiasten. Entwicklerwachstumsmetriken (50 % der Hackathon-Gewinner im Bereich KI, umfassende SDK-Abdeckung, KI-Codierungsassistenten) demonstrieren eine nachhaltige Ökosystemerweiterung, die die langfristige Akzeptanz unterstützt.

Die strategische Positionierung als Blockchain-Infrastruktur für die Roboterökonomie, quantenresistente Finanzsysteme und autonome KI-Agenten-Koordination schafft ein differenziertes Wertversprechen gegenüber Wettbewerbern, die sich auf inkrementelle Verbesserungen bestehender Blockchain-Anwendungsfälle konzentrieren. Da Morgan Stanley bis 2050 1 Milliarde humanoider Roboter prognostiziert, NIST quantenresistente Algorithmen bis 2030 vorschreibt und McKinsey 40 % Produktivitätssteigerungen durch agentische KI prognostiziert – stimmen Sais technische Fähigkeiten genau mit den makrotechnologischen Trends überein, die dezentrale Infrastruktur erfordern.

Für Organisationen, die fortschrittliche Computing-Anwendungen auf der Blockchain entwickeln, bietet Sui unübertroffene technische Fähigkeiten (297K TPS, 480 ms Finalität), eine zukunftssichere quantenresistente Architektur (die einzige Blockchain, die von Anfang an für Quanten konzipiert wurde), eine bewährte Robotik-Infrastruktur (die einzige, die Multi-Roboter-Kollaboration demonstriert hat), ein überlegenes Programmiermodell (Sicherheit und Ausdrucksstärke der Move-Sprache) und Echtzeit-Leistung, die KI-/Robotik-Anwendungen ermöglicht, die auf sequenziellen Ausführungsketten physisch unmöglich wären. Die Plattform stellt keine inkrementelle Verbesserung dar, sondern ein fundamentales architektonisches Umdenken für das nächste Jahrzehnt der Blockchain.

Die Sui Blockchain hebt sich von ihren Konkurrenten durch ihre grundlegende kryptographische Agilität und objektzentrierte Architektur ab und positioniert sich als die einzige große Layer-1-Blockchain, die gleichzeitig die KI-Integration, die Robotik-Koordination und die quantenresistente Sicherheit vorantreibt. Dies ist keine Marketingpositionierung – es ist architektonische Realität. Mitbegründer und Chief Cryptographer Kostas „Kryptos“ Chalkias hat diese Fähigkeiten seit der Gründung systematisch in Suis Kerndesign integriert und damit eine Infrastruktur geschaffen, die seiner Beschreibung nach „sogar Visa in puncto Geschwindigkeit übertreffen“ wird, während sie gleichzeitig sicher gegen Quantenbedrohungen bleibt, die „die gesamte moderne Kryptographie“ innerhalb eines Jahrzehnts „zerstören“ könnten.

Die technische Grundlage ist bereits produktionsreif: Eine Konsensfinalität von 390 Millisekunden ermöglicht die Echtzeit-Koordination von KI-Agenten, die parallele Ausführung verarbeitet Spitzenwerte von 297.000 Transaktionen pro Sekunde, und EdDSA-Signaturschemata bieten einen bewährten Migrationspfad zur Post-Quanten-Kryptographie, ohne Hard Forks zu erfordern. Unterdessen stehen Bitcoin und Ethereum vor existenziellen Bedrohungen durch Quantencomputing, ohne einen abwärtskompatiblen Upgrade-Pfad zu besitzen. Chalkias' Vision konzentriert sich auf drei konvergierende Säulen – KI als Koordinationsschicht, autonome Robotersysteme, die eine Finalität im Sub-Sekunden-Bereich erfordern, und kryptographische Frameworks, die bis 2035 und darüber hinaus sicher bleiben. Seine Aussagen auf Konferenzen, in Forschungsarbeiten und technischen Implementierungen zeigen keine spekulativen Versprechen, sondern die systematische Umsetzung einer Roadmap, die bei der Gründung von Mysten Labs im Jahr 2022 festgelegt wurde.

Dies ist über den Blockchain-Tribalismus hinaus von Bedeutung. Bis 2030 erfordern NIST-Vorgaben die Abschaffung aktueller Verschlüsselungsstandards. Autonome Systeme, von Fertigungsrobotern bis hin zu KI-Agenten, werden eine vertrauenslose Koordination in großem Maßstab erfordern. Suis Architektur begegnet beiden Unvermeidlichkeiten gleichzeitig, während Konkurrenten darum kämpfen, Lösungen nachzurüsten. Die Frage ist nicht, ob diese Technologien konvergieren, sondern welche Plattformen die Konvergenz unbeschadet überstehen.

Der Kryptograph, der seinen Sohn Kryptos nannte​

Kostas Chalkias bringt eine außergewöhnliche Glaubwürdigkeit an die Schnittstelle von Blockchain und neuen Technologien. Bevor er Mysten Labs mitbegründete, war er Lead Cryptographer für Metas Diem-Projekt und Novi Wallet, arbeitete mit Mike Hearn (einem der ersten Bitcoin-Entwickler, der mit Satoshi Nakamoto in Verbindung gebracht wird) an der Corda-Blockchain von R3 und besitzt einen Doktortitel in identitätsbasierter Kryptographie mit über 50 wissenschaftlichen Publikationen, 8 US-Patenten und 1.374 akademischen Zitaten. Seine Hingabe an das Fachgebiet geht so weit, dass er seinen Sohn Kryptos nannte – „Ich bin so tief in der Technologie der Blockchain und Kryptographie verwurzelt, dass ich meine Frau tatsächlich davon überzeugt habe, ein Kind zu bekommen, das Kryptos heißt“, erklärte er in einem Sui-Blog-Interview.

Sein Karriereweg zeigt eine konsequente Konzentration auf praktische Kryptographie für massive Skalierung. Bei Facebook baute er die Sicherheitsinfrastruktur für WhatsApp und Authentifizierungssysteme für Milliarden von Nutzern auf. Bei R3 leistete er Pionierarbeit bei Zero-Knowledge Proofs und Post-Quanten-Signaturen für Enterprise-Blockchain. Zu seiner frühen Karriere gehörte die Gründung von Betmanager, einer KI-gestützten Plattform, die Fußballergebnisse mithilfe von Börsentechniken vorhersagte – eine Erfahrung, die seine aktuelle Perspektive auf die Blockchain-KI-Integration prägt. Diese Mischung aus KI-Erfahrung, Produktionskryptographie und Blockchain-Infrastruktur positioniert ihn einzigartig, um Systeme zu entwerfen, die diese Bereiche miteinander verbinden.

Chalkias' technische Philosophie betont „kryptographische Agilität“ – die Integration von Flexibilität in grundlegende Protokolle, anstatt von Permanenz auszugehen. Auf der Emergence Conference in Prag (Dezember 2024) formulierte er diese Weltanschauung: „Irgendwann wird die Blockchain sogar Visa in puncto Transaktionsgeschwindigkeit übertreffen. Es wird die Norm sein. Ich sehe nicht, wie wir dem entkommen können.“ Aber Geschwindigkeit allein genügt nicht. Seine Arbeit verbindet konsequent Leistung mit zukunftsorientierter Sicherheit und erkennt an, dass Quantencomputer Bedrohungen darstellen, die heute Handeln erfordern, nicht erst, wenn die Gefahr real wird. Dieser doppelte Fokus – aktuelle Leistung und zukünftige Resilienz – prägt Suis architektonische Entscheidungen in den Bereichen KI, Robotik und Quantenresistenz.

Architektur für intelligente Agenten​

Suis technische Grundlage unterscheidet sich grundlegend von konto-basierten Blockchains wie Ethereum und Solana. Jede Entität existiert als Objekt mit einer global eindeutigen 32-Byte-ID, Versionsnummer, einem Eigentumsfeld und typisierten Inhalten. Dieses objektzentrierte Modell ist keine ästhetische Präferenz, sondern ermöglicht die parallele Ausführung in großem Maßstab. Wenn KI-Agenten als eigene Objekte agieren, umgehen sie den Konsens für Single-Writer-Operationen vollständig und erreichen eine Finalität von ~400 ms. Wenn mehrere Agenten über gemeinsame Objekte koordinieren, liefert Suis Mysticeti-Konsens eine Latenz von 390 ms – immer noch im Sub-Sekunden-Bereich, aber durch byzantinisch fehlertolerante Einigung.

Die Programmiersprache Move, ursprünglich bei Meta für Diem entwickelt und für Sui erweitert, erzwingt Ressourcensicherheit auf der Ebene des Typsystems. Assets können nicht versehentlich kopiert, zerstört oder ohne Erlaubnis erstellt werden. Für KI-Anwendungen, die wertvolle Daten oder Modellgewichte verwalten, verhindert dies ganze Klassen von Schwachstellen, die Solidity-Smart Contracts plagen. Chalkias betonte dies während des Sui Basecamp 2025 in Dubai: „Wir haben Zero-Knowledge Proofs, datenschutzfreundliche Technologien, von Anfang an in Sui integriert. So kann jemand jetzt ein KYC-System mit so viel Privatsphäre erstellen, wie er möchte.“

Die parallele Transaktionsausführung erreicht theoretische Grenzen durch explizite Abhängigkeitsdeklaration. Im Gegensatz zur optimistischen Ausführung, die eine nachträgliche Verifizierung erfordert, identifiziert Suis Scheduler nicht überlappende Transaktionen im Voraus über eindeutige Objekt-IDs. Unabhängige Operationen werden gleichzeitig über Validatoren-Kerne hinweg ohne Beeinträchtigung ausgeführt. Diese Architektur zeigte im Test einen Spitzendurchsatz von 297.000 TPS – keine theoretischen Maxima, sondern gemessene Leistung auf Produktionshardware. Für KI-Anwendungen bedeutet dies, dass Tausende von Inferenzanfragen gleichzeitig verarbeitet werden, mehrere autonome Agenten ohne Blockierung koordinieren und Echtzeit-Entscheidungen mit für Menschen wahrnehmbaren Geschwindigkeiten ablaufen.

Das 2024 eingeführte Mysticeti-Konsensprotokoll erreicht, was Chalkias und Co-Autoren mathematisch als optimal erwiesen haben: drei Nachrichtenrunden für das Commitment. Durch die Eliminierung expliziter Blockzertifizierung und die Implementierung unzertifizierter DAG-Strukturen reduzierte Mysticeti die Latenz um 80 % gegenüber dem früheren Narwhal-Bullshark-Konsens. Das Protokoll committet Blöcke in jeder Runde statt in jeder zweiten Runde, wobei direkte und indirekte Entscheidungsregeln verwendet werden, die aus DAG-Mustern abgeleitet sind. Für Robotik-Anwendungen, die Echtzeit-Steuerungsfeedback erfordern, wird diese Sub-Sekunden-Finalität nicht verhandelbar. Während der Korea Blockchain Week 2025 positionierte Chalkias Sui als „eine Koordinationsschicht für Anwendungen und KI“ und betonte, wie Partner in den Bereichen Zahlungen, Gaming und KI diese Leistungsbasis nutzen.

Walrus: Lösung des Datenproblems der KI​

KI-Workloads erfordern Speicherkapazitäten in einem Umfang, der mit der traditionellen Blockchain-Ökonomie unvereinbar ist. Trainingsdatensätze umfassen Terabytes, Modellgewichte benötigen Gigabytes, und Inferenzprotokolle sammeln sich schnell an. Sui begegnet diesem Problem durch Walrus, ein dezentrales Speicherprotokoll, das Erasure Coding verwendet, um eine 4-5-fache Replikation zu erreichen, anstelle der 100-fachen Replikation, die für On-Chain-Speicher typisch ist. Der „Red Stuff“-Algorithmus teilt Daten in Fragmente auf, die über Speicherknoten verteilt werden und auch dann wiederherstellbar bleiben, wenn 2/3 der Knoten nicht verfügbar sind. Metadaten und Verfügbarkeitsnachweise leben auf Suis Blockchain, während die eigentlichen Daten in Walrus liegen, wodurch kryptographisch verifizierbarer Speicher im Exabyte-Maßstab entsteht.

Im ersten Monat des Walrus-Testnetzes speicherte das Netzwerk über 4.343 GB auf mehr als 25 Community-Knoten, was die Machbarkeit der Architektur bestätigte. Projekte wie TradePort, Tusky und Decrypt Media integrierten Walrus für die Speicherung und den Abruf von Medien. Für KI-Anwendungen ermöglicht dies praktische Szenarien: Trainingsdatensätze, die als programmierbare Assets mit in Smart Contracts kodierten Lizenzbedingungen tokenisiert werden, Modellgewichte, die mit Versionskontrolle persistent gespeichert werden, Inferenz-Ergebnisse, die unveränderlich für Audit-Trails protokolliert werden, und KI-generierte Inhalte, die kostengünstig gespeichert werden. Die KI-Inferenzschicht von Atoma Network, die als Suis erster Blockchain-Integrationspartner angekündigt wurde, nutzt diese Speicherbasis für die automatisierte Codegenerierung, Workflow-Automatisierung und DeFi-Risikoanalyse.

Die Integration erstreckt sich über den Speicher hinaus auf die Orchestrierung von Berechnungen. Suis Programmierbare Transaktionsblöcke (PTBs) bündeln bis zu 1.024 heterogene Operationen atomar und führen sie nach dem Alles-oder-Nichts-Prinzip aus. Ein KI-Workflow könnte Trainingsdaten von Walrus abrufen, Modellgewichte in einem Smart Contract aktualisieren, Inferenz-Ergebnisse On-Chain aufzeichnen und Belohnungen an Datenbeitragende verteilen – alles in einer einzigen atomaren Transaktion. Diese Komponierbarkeit, kombiniert mit der Typsicherheit von Move, schafft Bausteine für komplexe KI-Systeme ohne die Anfälligkeit von Cross-Contract-Aufrufen in anderen Umgebungen.

Chalkias betonte während des Podcasts „Just The Metrics“ (Juli 2025) die Leistungsfähigkeit gegenüber dem Marketing und verwies auf „Ineffizienzen im Gesundheitsdatenmanagement“ als praktische Anwendungsbereiche. KI im Gesundheitswesen erfordert Koordination zwischen Institutionen, den Schutz der Privatsphäre sensibler Daten und verifizierbare Berechnungen für die Einhaltung gesetzlicher Vorschriften. Suis Architektur – die On-Chain-Koordination, Walrus-Speicher und Zero-Knowledge-Privatsphäre kombiniert – erfüllt diese Anforderungen technisch und nicht nur konzeptionell. Die 2024 angekündigte Partnerschaft mit Google Cloud verstärkte diese Richtung, indem Sui-Daten für Analysen in BigQuery integriert und Googles Vertex AI-Plattform in der Move-Sprache für KI-gestützte Entwicklung trainiert wurde.

Wenn Roboter eine Abwicklung im Sub-Sekunden-Bereich benötigen​

Die Robotik-Vision materialisiert sich konkreter durch technische Fähigkeiten als durch angekündigte Partnerschaften. Suis Objektmodell stellt Roboter, Werkzeuge und Aufgaben als erstklassige On-Chain-Bürger mit granularer Zugriffskontrolle dar. Im Gegensatz zu konto-basierten Systemen, bei denen Roboter über Berechtigungen auf Kontoebene interagieren, ermöglichen Suis Objekte mehrstufige Berechtigungssysteme von der grundlegenden Bedienung bis zur vollständigen Kontrolle mit Multi-Signatur-Anforderungen. Die Integration von PassKeys und FaceID unterstützt Mensch-in-der-Schleife-Szenarien, während zkTunnels eine gasfreie Befehlsübertragung für den Echtzeit-Fernbetrieb ermöglichen.

Während Diskussionen in sozialen Medien enthüllte Chalkias (unter dem Namen „Kostas Kryptos“), dass Sui-Ingenieure mit Hintergründen bei NASA, Meta und Uber hundeähnliche vierbeinige Roboter im Netzwerk testen. Die objektbasierte Architektur eignet sich für die Robotik-Koordination: Jeder Roboter besitzt Objekte, die seinen Zustand und seine Fähigkeiten repräsentieren, Aufgaben existieren als übertragbare Objekte mit Ausführungsparametern, und die Ressourcenzuweisung erfolgt durch Objektkomposition statt durch zentrale Koordination. Eine Fertigungsanlage könnte Roboterflotten einsetzen, bei denen jede Einheit autonom Aufgaben annimmt, sich mit anderen über gemeinsame Objekte koordiniert, Operationen mit kryptographischer Verifizierung ausführt und Mikrozahlungen für erbrachte Dienstleistungen abwickelt – alles ohne zentrale Autorität oder menschliches Eingreifen.

Der „internetlose“ Transaktionsmodus, der während des Sui Basecamp 2025 und im London Real Podcast (April 2025) diskutiert wurde, adressiert die realen Einschränkungen der Robotik. Chalkias beschrieb, wie das System während Stromausfällen in Spanien und Portugal die Funktionalität aufrechterhielt, wobei die Transaktionsgrößen mithilfe voreingestellter Formate auf einzelne Bytes optimiert wurden. Für autonome Systeme, die in Katastrophengebieten, ländlichen Gebieten oder Umgebungen mit unzuverlässiger Konnektivität betrieben werden, wird diese Resilienz entscheidend. Roboter können Peer-to-Peer-Transaktionen für sofortige Koordination durchführen und sich mit dem breiteren Netzwerk synchronisieren, wenn die Konnektivität wiederhergestellt ist.

Das 3DOS-Projekt veranschaulicht diese Vision praktisch: ein Blockchain-basiertes 3D-Drucknetzwerk, das die On-Demand-Fertigung ermöglicht, bei der Maschinen autonom Teile drucken. Zukünftige Iterationen sehen sich selbst reparierende Roboter vor, die Komponentenausfälle erkennen, Ersatzteile über Smart Contracts bestellen, nahegelegene 3D-Drucker über On-Chain-Discovery identifizieren, Druck und Lieferung koordinieren und Komponenten installieren – alles autonom. Dies ist keine Science-Fiction, sondern eine logische Erweiterung bestehender Fähigkeiten: Die Integration von ESP32- und Arduino-Mikrocontrollern unterstützt bereits grundlegende IoT-Geräte, BugDar bietet Sicherheitsaudits für Robotik-Smart Contracts, und Multi-Signatur-Genehmigungen ermöglichen eine abgestufte Autonomie mit menschlicher Aufsicht für kritische Operationen.

Die Quantenuhr tickt​

Kostas Chalkias' Ton wechselt von philosophisch zu dringend, wenn er über Quantencomputing spricht. In einem Forschungsbericht vom Juli 2025 warnte er unverblümt: „Regierungen sind sich der Risiken des Quantencomputings sehr bewusst. Behörden weltweit haben Mandate erlassen, dass klassische Algorithmen wie ECDSA und RSA bis 2030 oder 2035 abgeschafft werden müssen.“ Seine Ankündigung auf Twitter begleitete die bahnbrechende Forschung von Mysten Labs, die im IACR ePrint Archive veröffentlicht wurde und zeigt, wie EdDSA-basierte Blockchains wie Sui, Solana, Near und Cosmos strukturelle Vorteile für den Quantenübergang besitzen, die Bitcoin und Ethereum nicht zur Verfügung stehen.

Die Bedrohung geht von Quantencomputern aus, die Shors Algorithmus ausführen, der große Zahlen effizient faktorisiert – die mathematische Härte, die der RSA-, ECDSA- und BLS-Kryptographie zugrunde liegt. Googles Willow-Quantenprozessor mit 105 Qubits signalisiert einen beschleunigten Fortschritt hin zu Maschinen, die klassische Verschlüsselung brechen können. Der „Jetzt speichern, später entschlüsseln“-Angriff verstärkt die Dringlichkeit: Angreifer sammeln heute verschlüsselte Daten und warten darauf, dass Quantencomputer sie rückwirkend entschlüsseln. Für Blockchain-Assets erklärte Chalkias gegenüber dem Decrypt Magazine: „Selbst wenn jemand seinen Bitcoin- oder Ethereum-Privatschlüssel noch besitzt, ist er möglicherweise nicht in der Lage, einen post-quantensicheren Eigentumsnachweis zu generieren, und dies hängt davon ab, wie dieser Schlüssel ursprünglich generiert wurde und wie viele seiner zugehörigen Daten im Laufe der Zeit exponiert wurden.“

Bitcoins besondere Anfälligkeit rührt von „schlafenden“ Wallets mit exponierten öffentlichen Schlüsseln her. Satoshi Nakamotos geschätzte 1 Million BTC befinden sich in frühen Adressen, die das Pay-to-Public-Key-Format verwenden – der öffentliche Schlüssel ist On-Chain sichtbar, anstatt hinter gehashten Adressen versteckt zu sein. Sobald Quantencomputer ausreichend skaliert sind, können diese Wallets sofort geleert werden. Chalkias' Einschätzung: „Sobald Quantencomputer verfügbar sind, könnten Millionen von Wallets, einschließlich der von Satoshi, sofort geleert werden. Wenn Ihr öffentlicher Schlüssel sichtbar ist, wird er irgendwann geknackt werden.“ Ethereum steht vor ähnlichen Herausforderungen, obwohl weniger exponierte öffentliche Schlüssel das unmittelbare Risiko mindern. Beide Chains erfordern gemeinschaftsweite Hard Forks mit beispielloser Koordination zur Migration – vorausgesetzt, es bildet sich ein Konsens um Post-Quanten-Algorithmen.

Suis EdDSA-Grundlage bietet einen eleganten Ausweg. Im Gegensatz zu den zufälligen privaten Schlüsseln von ECDSA leitet EdDSA Schlüssel deterministisch aus einem Seed unter Verwendung von Hash-Funktionen gemäß RFC 8032 ab. Dieser strukturelle Unterschied ermöglicht Zero-Knowledge Proofs über zk-STARKs (die post-quantensicher sind), die das Wissen über den zugrunde liegenden Seed beweisen, ohne elliptische Kurvendaten preiszugeben. Benutzer konstruieren Post-Quanten-Schlüsselpaare aus derselben Seed-Zufälligkeit, reichen ZK-Proofs ein, die identisches Eigentum demonstrieren, und wechseln zu quantensicheren Schemata, während die Adressen erhalten bleiben – keine Hard Fork erforderlich. Chalkias erläuterte dies während des Sui AMA im Juni 2022: „Wenn Sie deterministische Algorithmen wie EdDSA verwenden, gibt es eine Möglichkeit mit Stark Proofs, das Wissen über die Pyramiden Ihres privaten Schlüssels bei einer EdDSA-Schlüsselgenerierung zu beweisen, da intern eine Hash-Funktion verwendet wird.“

Kryptographische Agilität als strategischer Graben​

Sui unterstützt mehrere Signaturschemata gleichzeitig durch vereinheitlichte Typ-Aliase im gesamten Code – EdDSA (Ed25519), ECDSA (für Ethereum-Kompatibilität) und geplante Post-Quanten-Algorithmen. Chalkias entwarf diese „kryptographische Agilität“ in der Erkenntnis, dass Permanenz in der Kryptographie eine Fantasie ist. Die Architektur ähnelt dem „Wechsel eines Schließzylinders“ statt dem Neuaufbau des gesamten Sicherheitssystems. Wenn von NIST empfohlene Post-Quanten-Algorithmen eingesetzt werden – CRYSTALS-Dilithium für Signaturen, FALCON für kompakte Alternativen, SPHINCS+ für Hash-basierte Schemata – integriert Sui diese durch unkomplizierte Updates statt grundlegender Protokoll-Umschreibungen.

Die Übergangsstrategien balancieren proaktive und adaptive Ansätze aus. Für neue Adressen können Benutzer PQ-signs-PreQ-Konfigurationen generieren, bei denen Post-Quanten-Schlüssel zum Zeitpunkt der Erstellung prä-quanten-öffentliche Schlüssel signieren, was eine reibungslose zukünftige Migration ermöglicht. Für bestehende Adressen bewahrt die zk-STARK-Proof-Methode Adressen, während sie quantensicheres Eigentum beweist. Die geschichtete Verteidigung priorisiert hochwertige Daten – private Wallet-Schlüssel erhalten sofortigen PQ-Schutz, während transiente private Daten langsameren Upgrade-Pfaden folgen. Hash-Funktionsausgaben werden von 256 Bit auf 384 Bit erweitert, um Kollisionsresistenz gegen Grovers Algorithmus zu gewährleisten, und symmetrische Verschlüsselungsschlüssellängen verdoppeln sich (AES bleibt mit größeren Schlüsseln quantenresistent).

Zero-Knowledge-Proof-Systeme erfordern sorgfältige Überlegung. Lineare PCPs wie Groth16 (die derzeit zkLogin antreiben) basieren auf paarungsfreundlichen elliptischen Kurven, die anfällig für Quantenangriffe sind. Suis Übergangs-Roadmap bewegt sich in Richtung Hash-basierter STARK-Systeme – Winterfell, mitentwickelt von Mysten Labs, verwendet nur Hash-Funktionen und bleibt plausibel post-quantensicher. Die zkLogin-Migration behält dieselben Adressen bei, während interne Schaltkreise aktualisiert werden, was eine Koordination mit OpenID-Anbietern erfordert, wenn diese PQ-JWT-Tokens übernehmen. Zufalls-Beacons und verteilte Schlüsselgenerierungsprotokolle wechseln von Schwellenwert-BLS-Signaturen zu gitterbasierten Alternativen wie HashRand- oder HERB-Schemata – interne Protokolländerungen, die für On-Chain-APIs unsichtbar sind.

Chalkias' Expertise erweist sich hier als entscheidend. Als Autor von BPQS (Blockchain Post-Quantum Signature), einer Variante des Hash-basierten XMSS-Schemas, bringt er Implementierungserfahrung über theoretisches Wissen hinaus mit. Sein Engagement vom Juni 2022 erwies sich als vorausschauend: „Wir werden unsere Chain so aufbauen, dass Menschen mit einem Knopfdruck tatsächlich zu Post-Quanten-Schlüsseln wechseln können.“ Die NIST-Fristen – 2030 für die Abschaffung klassischer Algorithmen, 2035 für die vollständige PQ-Einführung – verkürzen die Zeitpläne dramatisch. Suis Vorsprung positioniert es günstig, aber Chalkias betont die Dringlichkeit: „Wenn Ihre Blockchain souveräne Assets, nationale Krypto-Schatzkammern, ETFs oder CBDCs unterstützt, wird sie bald verpflichtet sein, Post-Quanten-Kryptographie-Standards zu übernehmen, wenn Ihre Community Wert auf langfristige Glaubwürdigkeit und Massenadoption legt.“

KI-Agenten generieren bereits 1,8 Milliarden US-Dollar an Wert​

Das Ökosystem bewegt sich über die Infrastruktur hinaus in Produktionsanwendungen. Dolphin Agent (DOLA), spezialisiert auf Blockchain-Datenverfolgung und -analyse, erreichte eine Marktkapitalisierung von über 1,8 Milliarden US-Dollar – was die Nachfrage nach KI-gestützten Blockchain-Tools bestätigt. SUI Agents bietet die Bereitstellung von KI-Agenten mit einem Klick, einschließlich der Erstellung von Twitter-Personas, Tokenisierung und Handel innerhalb dezentraler Ökosysteme. Sentient AI sammelte 1,5 Millionen US-Dollar für konversationelle Chatbots, die Suis Sicherheit und Skalierbarkeit nutzen. DeSci Agents fördert wissenschaftliche Verbindungen wie Epitalon und Rapamycin durch rund um die Uhr KI-gesteuertes Engagement und überbrückt Forschung und Investitionen durch Token-Kopplung.

Die Integration von Atoma Network als Suis erstem Blockchain-KI-Inferenzpartner ermöglicht Funktionen, die von automatisierter Codegenerierung und -prüfung, Workflow-Automatisierung, DeFi-Risikoanalyse, Gaming-Asset-Generierung, Social-Media-Inhaltsklassifizierung bis hin zum DAO-Management reichen. Die Auswahl der Partnerschaft spiegelte technische Anforderungen wider: Atoma benötigte niedrige Latenz für interaktive KI, hohen Durchsatz für Skalierung, sicheres Eigentum für KI-Assets, verifizierbare Berechnungen, kostengünstigen Speicher und datenschutzfreundliche Optionen. Sui lieferte alle sechs. Während des Sui Basecamp 2025 hob Chalkias Projekte wie Aeon, Atomas KI-Agenten und Nautilus' Arbeit an verifizierbaren Off-Chain-Berechnungen als Beispiele dafür hervor, „wie Sui als Grundlage für die nächste Welle intelligenter, dezentraler Systeme dienen könnte“.

Die Google Cloud-Partnerschaft vertieft die Integration durch BigQuery-Zugriff auf Sui-Blockchain-Daten für Analysen, Vertex AI-Training in der Move-Programmiersprache für KI-gestützte Entwicklung, zkLogin-Unterstützung unter Verwendung von OAuth-Anmeldeinformationen (Google) für vereinfachten Zugriff und Infrastruktur zur Unterstützung der Netzwerkleistung und Skalierbarkeit. Die ChainIDE-Integration von Alibaba Cloud ermöglicht natürliche Sprachprompts für die Move-Codegenerierung – Entwickler schreiben „create a staking contract with 10% APY“ auf Englisch, Chinesisch oder Koreanisch und erhalten syntaktisch korrekten, dokumentierten Move-Code mit Sicherheitsprüfungen. Diese KI-gestützte Entwicklung demokratisiert den Blockchain-Aufbau und bewahrt gleichzeitig Moves Sicherheitsgarantien.

Die technischen Vorteile potenzieren sich für KI-Anwendungen. Objekteigentumsmodelle eignen sich für autonom agierende Agenten. Die parallele Ausführung ermöglicht Tausende gleichzeitiger KI-Operationen ohne Beeinträchtigung. Sub-Sekunden-Finalität unterstützt interaktive Benutzererlebnisse. Walrus-Speicher verarbeitet Trainingsdatensätze wirtschaftlich. Gesponserte Transaktionen eliminieren Gas-Reibung für Benutzer. zkLogin eliminiert Seed-Phrase-Barrieren. Programmierbare Transaktionsblöcke orchestrieren komplexe Workflows atomar. Formale Verifizierungsoptionen beweisen die Korrektheit von KI-Agenten mathematisch. Dies sind keine isolierten Funktionen, sondern integrierte Fähigkeiten, die eine kohärente Entwicklungsumgebung bilden.

Vergleich der Konkurrenten​

Suis Spitzenwert von 297.000 TPS und 390 ms Konsenslatenz übertreffen Ethereums durchschnittliche 11,3 TPS und 12-13 Minuten Finalität um Größenordnungen. Gegenüber Solana – seinem engsten Leistungs-Konkurrenten – erreicht Sui eine 32-fach schnellere Finalität (0,4 Sekunden gegenüber 12,8 Sekunden), obwohl Solana 400 ms Slot-Zeiten hat, da Solana mehrere Bestätigungen für die wirtschaftliche Finalität benötigt. Eine reale Messung aus dem Bericht der Phoenix Group vom August 2025 zeigte, dass Sui 3.900 TPS verarbeitete gegenüber Solanas 92,1 TPS, was die operative und nicht die theoretische Leistung widerspiegelt. Die Transaktionskosten bleiben auf Sui vorhersehbar niedrig (durchschnittlich ~0,0087 $, unter einem Cent) ohne Solanas historische Überlastungs- und Ausfallprobleme.

Architektonische Unterschiede erklären Leistungsunterschiede. Suis objektzentriertes Modell ermöglicht eine inhärente Parallelisierung – 300.000 einfache Übertragungen pro Sekunde erfordern keine Konsenskoordination. Ethereum und Bitcoin verarbeiten jede Transaktion sequenziell durch vollständigen Konsens. Solana parallelisiert durch Sealevel, verwendet aber eine optimistische Ausführung, die eine nachträgliche Verifizierung erfordert. Aptos, ebenfalls die Move-Sprache nutzend, implementiert Block-STM optimistische Ausführung anstelle von Suis Zustandszugriffsmethode. Für KI- und Robotik-Anwendungen, die eine vorhersehbare niedrige Latenz erfordern, bietet Suis explizite Abhängigkeitsdeklaration Determinismus, den optimistische Ansätze nicht garantieren können.

Die Quantenpositionierung weicht noch stärker ab. Bitcoin und Ethereum verwenden secp256k1 ECDSA-Signaturen ohne abwärtskompatiblen Upgrade-Pfad – der Quantenübergang erfordert Hard Forks, Adressänderungen, Asset-Migrationen und eine Community-Governance, die wahrscheinlich zu Chain-Splits führen wird. Solana teilt Suis EdDSA-Vorteil, ermöglicht ähnliche zk-STARK-Übergangsstrategien und führt Winternitz Vault Hash-basierte Einmal-Signaturen ein. Near und Cosmos profitieren ebenfalls von EdDSA. Aptos verwendet Ed25519, hat aber eine weniger entwickelte Roadmap für die Quantenbereitschaft. Chalkias' Forschungsarbeit vom Juli 2025 stellte explizit fest, dass die Ergebnisse „für Sui, Solana, Near, Cosmos und andere EdDSA-basierte Chains funktionieren, aber nicht für Bitcoin und Ethereum.“

Die Ökosystemreife begünstigt Konkurrenten vorübergehend. Solana startete 2020 mit etablierten DeFi-Protokollen, NFT-Marktplätzen und Entwicklergemeinschaften. Ethereums Start im Jahr 2015 verschaffte Vorteile als Erstanbieter bei Smart Contracts, institutioneller Akzeptanz und Netzwerkeffekten. Sui startete im Mai 2023 – kaum zweieinhalb Jahre alt – mit über 2 Milliarden US-Dollar TVL und 65.900 aktiven Adressen, die schnell wachsen, aber weit unter Solanas 16,1 Millionen liegen. Die technische Überlegenheit schafft Chancen: Entwickler, die heute auf Sui aufbauen, positionieren sich für das Ökosystemwachstum, anstatt sich etablierten, überfüllten Plattformen anzuschließen. Chalkias' Interview bei London Real spiegelte dieses Vertrauen wider: „Ehrlich gesagt, wäre ich überhaupt nicht überrascht, wenn Mysten Labs und alles, was es berührt, das übertrifft, was Apple heute ist.“

Synergien zwischen scheinbar unterschiedlichen Visionen​

Die Erzählungen über KI, Robotik und Quantenresistenz erscheinen zunächst unzusammenhängend, bis man ihre technischen Interdependenzen erkennt. KI-Agenten benötigen niedrige Latenz und hohen Durchsatz – Sui bietet beides. Robotische Koordination erfordert Echtzeit-Operationen ohne zentrale Autorität – Suis Objektmodell und Sub-Sekunden-Finalität liefern dies. Post-Quanten-Sicherheit erfordert kryptographische Flexibilität und eine zukunftsorientierte Architektur – Sui hat dies von Anfang an aufgebaut. Dies sind keine separaten Produktlinien, sondern vereinheitlichte technische Anforderungen für die Technologielandschaft von 2030-2035.

Betrachten Sie die autonome Fertigung: KI-Systeme analysieren Nachfrageprognosen und Materialverfügbarkeit und bestimmen optimale Produktionspläne. Robotische Agenten erhalten verifizierte Anweisungen durch Blockchain-Koordination, wodurch Authentizität ohne zentrale Kontrolle gewährleistet wird. Jeder Roboter agiert als eigenes Objekt, das Aufgaben parallel verarbeitet und bei Bedarf über gemeinsame Objekte koordiniert. Mikrozahlungen werden sofort für erbrachte Dienstleistungen abgewickelt – Roboter A liefert Materialien an Roboter B, Roboter B verarbeitet Komponenten für Roboter C. Das System funktioniert bei Konnektivitätsstörungen internetlos und synchronisiert sich, wenn die Netzwerke wiederhergestellt sind. Und entscheidend ist, dass alle Kommunikationen durch post-quanten-kryptographische Schemata sicher gegen Quantengegner bleiben, wodurch geistiges Eigentum und Betriebsdaten vor „Jetzt speichern, später entschlüsseln“-Angriffen geschützt werden.

Das Gesundheitsdatenmanagement ist ein weiteres Beispiel für Konvergenz. KI-Modelle trainieren auf medizinischen Datensätzen, die in Walrus mit kryptographischen Verfügbarkeitsnachweisen gespeichert sind. Zero-Knowledge Proofs wahren die Privatsphäre der Patienten und ermöglichen gleichzeitig Forschung. Robotische Chirurgiesysteme koordinieren über Blockchain für Audit-Trails und Haftungsdokumentation. Post-Quanten-Verschlüsselung schützt sensible medizinische Aufzeichnungen vor langfristigen Bedrohungen. Die Koordinationsschicht (Suis Blockchain) ermöglicht institutionellen Datenaustausch ohne Vertrauen, KI-Berechnungen ohne Kompromittierung der Privatsphäre und zukunftssichere Sicherheit ohne periodischen Infrastrukturwechsel.

Chalkias' Vision auf dem Sui Basecamp 2025 fasst diese Synthese zusammen: Sui als „Grundlage für die nächste Welle intelligenter, dezentraler Systeme“ mit „wachsender Kapazität zur Unterstützung von KI-nativen und rechenintensiven Anwendungen“ zu positionieren. Die modulare Architektur – Sui für Berechnungen, Walrus für Speicher, Scion für Konnektivität, zkLogin für Identität – schafft das, was Teammitglieder als „Blockchain-Betriebssystem“ und nicht als eng gefasstes Finanzbuch bezeichnen. Der internetlose Modus, quantensichere Kryptographie und Sub-Sekunden-Finalität sind keine Feature-Checklisten, sondern Voraussetzungen für autonome Systeme, die in feindlichen Umgebungen mit unzuverlässiger Infrastruktur operieren.

Die Innovationsmethodik hinter technischer Führung​

Das Verständnis des Ansatzes von Mysten Labs erklärt die Konsistenz der Ausführung. Chalkias formulierte die Philosophie in seinem Blogbeitrag „Build Beyond“: „Mysten Labs ist wirklich gut darin, neue Theorien in diesem Bereich zu finden, die noch niemand implementiert hat, bei denen einige der Annahmen möglicherweise nicht zutreffen. Aber wir verbinden sie mit der bestehenden Technologie, die wir haben, und letztendlich treibt uns das dazu an, ein neuartiges Produkt zu schaffen.“ Dies beschreibt einen systematischen Prozess: akademische Forschung mit praktischem Potenzial identifizieren, ungetestete Annahmen durch technische Strenge hinterfragen, in Produktionssysteme integrieren und durch Bereitstellung validieren.

Das Mysticeti-Konsensprotokoll veranschaulicht dies. Akademische Forschung etablierte drei Nachrichtenrunden als theoretisches Minimum für das Byzantine-Konsens-Commitment. Frühere Implementierungen erforderten 1,5 Roundtrips mit Quorum-Signaturen pro Block. Mysten Labs entwickelte unzertifizierte DAG-Strukturen, die eine explizite Zertifizierung eliminieren, implementierte optimale Commit-Regeln über DAG-Muster anstelle von Abstimmungsmechanismen und demonstrierte eine 80%ige Latenzreduzierung gegenüber dem früheren Narwhal-Bullshark-Konsens. Das Ergebnis: ein Peer-Review-Papier mit formalen Beweisen, begleitet von einer Produktionsimplementierung, die Milliarden von Transaktionen verarbeitet.

Eine ähnliche Methodik gilt für die Kryptographie. BPQS (Chalkias' Blockchain Post-Quanten-Signaturschema) adaptiert Hash-basierte XMSS-Signaturen für Blockchain-Einschränkungen. Winterfell implementiert den ersten Open-Source-STARK-Prover, der nur Hash-Funktionen für Post-Quanten-Sicherheit verwendet. zkLogin kombiniert OAuth-Authentifizierung mit Zero-Knowledge Proofs, wodurch zusätzliche vertrauenswürdige Parteien eliminiert und gleichzeitig die Privatsphäre gewahrt werden. Jede Innovation adressiert eine praktische Barriere (Post-Quanten-Sicherheit, ZK-Proof-Zugänglichkeit, Benutzer-Onboarding-Reibung) durch neuartige kryptographische Konstruktion, gestützt durch formale Analyse.

Die Teamzusammensetzung verstärkt diese Fähigkeit. Ingenieure von Meta bauten Authentifizierung für Milliarden, von der NASA entwickelten sicherheitskritische verteilte Systeme, von Uber skalierten Echtzeit-Koordination global. Chalkias bringt kryptographische Expertise von Facebook/Diem, R3/Corda und aus der akademischen Forschung mit. Dies ist kein traditionelles Startup-Team, das unterwegs lernt, sondern Veteranen, die Systeme ausführen, die sie zuvor gebaut haben, jetzt ungebunden von Unternehmensprioritäten. Die Finanzierung von 336 Millionen US-Dollar von a16z, Coinbase Ventures und Binance Labs spiegelt das Vertrauen der Investoren in die Ausführungsfähigkeit gegenüber spekulativer Technologie wider.

Herausforderungen und Überlegungen jenseits des Hypes​

Technische Überlegenheit garantiert keine Marktakzeptanz – eine Lektion, die in der Technologiegeschichte immer wieder gelernt wurde. Suis 65.900 aktive Adressen verblassen gegenüber Solanas 16,1 Millionen, trotz der wohl besseren Technologie. Netzwerkeffekte verstärken sich: Entwickler bauen dort, wo Benutzer sich versammeln, Benutzer kommen dorthin, wo Anwendungen existieren, wodurch Lock-in-Vorteile für etablierte Plattformen entstehen. Ethereums „langsamere und teurere“ Blockchain beansprucht durch bloße Amtsinhaberschaft um Größenordnungen mehr Entwickler-Mindshare als technisch überlegene Alternativen.

Die Positionierung als „Blockchain-Betriebssystem“ birgt das Risiko der Verwässerung – der Versuch, gleichzeitig in den Bereichen Finanzen, soziale Anwendungen, Gaming, KI, Robotik, IoT und dezentraler Speicher zu glänzen, kann zu Mittelmäßigkeit in allen Bereichen statt zu Exzellenz in einem führen. Kritiker, die diese Bedenken äußern, verweisen auf eine begrenzte Robotik-Bereitstellung jenseits von Proof-of-Concepts, KI-Projekte, die sich hauptsächlich in der Spekulationsphase statt in der Produktionsnutzung befinden, und die Vorbereitung auf Quantensicherheit für Bedrohungen, die fünf bis zehn Jahre entfernt liegen. Das Gegenargument besagt, dass modulare Komponenten eine fokussierte Entwicklung ermöglichen – Teams, die KI-Anwendungen entwickeln, nutzen Atoma-Inferenz und Walrus-Speicher, ohne sich um die Robotik-Integration kümmern zu müssen.

Post-Quanten-Kryptographie führt nicht-triviale Overheads ein. CRYSTALS-Dilithium-Signaturen messen bei Sicherheitsstufe 2 3.293 Bytes gegenüber Ed25519s 64 Bytes – über 50-mal größer. Netzwerkbandbreite, Speicherkosten und Verarbeitungszeit steigen proportional an. Verbesserungen bei der Batch-Verifizierung bleiben begrenzt (20-50 % Beschleunigung gegenüber unabhängiger Verifizierung) im Vergleich zur effizienten Batch-Verarbeitung klassischer Schemata. Migrationsrisiken umfassen Benutzerfehler während des Übergangs, Koordination zwischen Ökosystemteilnehmern (Wallets, dApps, Börsen), Anforderungen an die Abwärtskompatibilität und Schwierigkeiten beim Testen in großem Maßstab ohne echte Quantencomputer. Die Unsicherheit des Zeitplans erschwert die Planungsherausforderungen – der Fortschritt des Quantencomputings bleibt unvorhersehbar, NIST-Standards entwickeln sich ständig weiter, und neue kryptanalytische Angriffe könnten gegen PQ-Schemata entstehen.

Das Markttiming stellt vielleicht das größte Risiko dar. Suis Vorteile manifestieren sich am dramatischsten im Zeitraum 2030-2035: wenn Quantencomputer die klassische Kryptographie bedrohen, wenn autonome Systeme sich verbreiten und vertrauenslose Koordination erfordern, wenn KI-Agenten signifikanten wirtschaftlichen Wert verwalten und sichere Infrastruktur benötigen. Wenn die Blockchain-Adoption vor dieser Konvergenz stagniert, wird technische Führung irrelevant. Umgekehrt, wenn die Adoption früher explodiert, könnte Suis neueres Ökosystem trotz überlegener Leistung an Anwendungen und Liquidität mangeln, um Benutzer anzuziehen. Die Investitionsthese erfordert nicht nur den Glauben an Suis Technologie, sondern auch an die zeitliche Abstimmung zwischen der Reifung der Blockchain und der Einführung neuer Technologien.

Die jahrzehntelange Wette auf erste Prinzipien​

Kostas Chalkias' Namensgebung seines Sohnes Kryptos ist keine charmante Anekdote, sondern ein Signal für die Tiefe seines Engagements. Sein Karriereweg – von der KI-Forschung zur Kryptographie, von akademischen Publikationen zu Produktionssystemen bei Meta, von der Enterprise-Blockchain bei R3 zur Layer-1-Architektur bei Mysten Labs – zeigt eine konsequente Konzentration auf grundlegende Technologien in großem Maßstab. Die Arbeit an der Quantenresistenz begann vor Googles Willow-Ankündigung, als Post-Quanten-Kryptographie noch eine theoretische Sorge schien. Die Robotik-Integration begann, bevor KI-Agenten Milliarden-Dollar-Bewertungen erreichten. Die architektonischen Entscheidungen, die diese Fähigkeiten ermöglichen, gehen der Marktanerkennung ihrer Bedeutung voraus.

Diese vorausschauende Ausrichtung steht im Gegensatz zur reaktiven Entwicklung, die im Krypto-Bereich üblich ist. Ethereum führt Layer-2-Rollups ein, um Skalierungsengpässe zu beheben, die nach der Bereitstellung auftreten. Solana implementiert QUIC-Kommunikation und Stake-gewichtetes QoS als Reaktion auf Netzwerkausfälle und Überlastung. Bitcoin debattiert über Blockgrößen-Erhöhungen und die Einführung des Lightning Network, wenn die Transaktionsgebühren in die Höhe schnellen. Sui entwarf parallele Ausführung, objektzentrierte Datenmodelle und kryptographische Agilität vor dem Start des Mainnets – um erwartete Anforderungen statt entdeckter Probleme zu adressieren.

Die Forschungskultur verstärkt diesen Ansatz. Mysten Labs veröffentlicht akademische Arbeiten mit formalen Beweisen, bevor es Fähigkeiten beansprucht. Das Mysticeti-Konsenspapier erschien in Peer-Review-Publikationen mit Korrektheitsbeweisen und Leistungsbenchmarks. Die Forschung zum Quantenübergang, die im IACR ePrint Archive eingereicht wurde, demonstriert EdDSA-Vorteile durch mathematische Konstruktion, nicht durch Marketingaussagen. Das zkLogin-Papier (arXiv 2401.11735) beschreibt die Zero-Knowledge-Authentifizierung vor der Bereitstellung. Chalkias pflegt aktive GitHub-Beiträge (kchalkias), veröffentlicht technische Einblicke auf LinkedIn und Twitter, präsentiert auf PQCSA-Workshops zu Quantenbedrohungen und engagiert sich substanziell in der Kryptographie-Community, anstatt ausschließlich Sui zu bewerben.

Die ultimative Validierung erfolgt in 5-10 Jahren, wenn Quantencomputer reifen, autonome Systeme sich verbreiten und KI-Agenten Billionen-Dollar-Ökonomien verwalten. Wenn Sui seine Roadmap konsequent umsetzt – Post-Quanten-Signaturen vor der NIST-Frist 2030 bereitstellt, Robotik-Koordination in großem Maßstab demonstriert und KI-Inferenzschichten unterstützt, die Millionen von Anfragen verarbeiten – wird es zur Infrastrukturschicht für Technologien, die die Zivilisation neu gestalten. Wenn Quantencomputer später als vorhergesagt eintreffen, die autonome Adoption stagniert oder Konkurrenten erfolgreich Lösungen nachrüsten, könnten Suis frühe Investitionen sich als verfrüht erweisen. Die Wette konzentriert sich nicht auf die technologische Leistungsfähigkeit – Sui liefert nachweislich die versprochene Leistung – sondern auf das Markttiming und die Dringlichkeit des Problems.

Chalkias' Perspektive während der Emergence Conference fasst dies prägnant zusammen: „Irgendwann wird die Blockchain sogar Visa in puncto Transaktionsgeschwindigkeit übertreffen. Es wird die Norm sein. Ich sehe nicht, wie wir dem entkommen können.“ Die Behauptung der Unvermeidlichkeit setzt die richtige technische Richtung, ausreichende Ausführungsqualität und eine abgestimmte Zeitplanung voraus. Sui positioniert sich, um zu profitieren, wenn diese Annahmen zutreffen. Die objektzentrierte Architektur, kryptographische Agilität, Sub-Sekunden-Finalität und systematische Forschungsmethodik sind keine Nachrüstungen, sondern grundlegende Entscheidungen, die für die Technologielandschaft des nächsten Jahrzehnts konzipiert wurden. Ob Sui die Marktführerschaft erringt oder diese Fähigkeiten zum Standard über alle Blockchains hinweg werden, Kostas Chalkias und Mysten Labs entwerfen die Infrastruktur für die autonome Intelligenz des Quantenzeitalters – ein kryptographisches Primitiv, eine Millisekunde Latenzreduzierung, ein Proof-of-Concept-Roboter nach dem anderen.

Einleitung​

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

Technische Architektur und Funktionen (Gründerperspektive)​

Architektur und kryptographische Primitive​

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

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

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

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

Leistung und Skalierbarkeit​

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

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

Entwickler-Tools und Integration​

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

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

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

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

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

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

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

Sicherheit, Dezentralisierung und Fehlertoleranz​

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

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

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

Kompatibilität und Ökosystem-Interoperabilität​

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

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

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

Geschäfts- und Investitionsperspektive​

Gründerteam und Hintergrund​

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

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

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

Finanzierungsrunden und wichtige Unterstützer​

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

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

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

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

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

Tokenomics und Wirtschaftsmodell​

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ökosystem-Adoption, Partnerschaften und Roadmap​

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

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

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

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

• Roadmap: Ab 2025 umfasste Ikas Roadmap:

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

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

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

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

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

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

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

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

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

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

Fully Homomorphic Encryption Virtual Machine (FHE-VM)​

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

Architektur und Design von FHE-VM​

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

Verschlüsselter Statusspeicher wird unterstützt, sodass Vertragsvariablen im Blockchain-Status verschlüsselt bleiben. Der Ausführungsfluss ist typischerweise:

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

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

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

Gewährleistung von Korrektheit und Privatsphäre​

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

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

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

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

Aktuelle FHE-VM-Projekte​

Mehrere Projekte sind Pioniere in diesem Bereich. Zama (ein Pariser FHE-Startup) entwickelte das Kernkonzept und die Bibliotheken der FHEVM (TFHE-rs und eine fhevm-solidity-Bibliothek). Sie beabsichtigen nicht, eine eigene Kette zu starten, sondern Infrastruktur für andere bereitzustellen. Inco ist eine L1-Blockchain (aufgebaut auf Cosmos SDK mit Evmos), die Zamas FHEVM integriert hat, um eine modulare vertrauliche Kette zu schaffen. Ihre Testnetze (Gentry und Paillier genannt) zeigen verschlüsselte ERC-20-Transfers und andere private DeFi-Primitive. Fhenix ist ein Ethereum Layer-2 Optimistic Rollup, das FHE für die Privatsphäre verwendet. Es entschied sich für einen optimistischen (Betrugsbeweis-)Ansatz anstelle eines ZK-Rollups aufgrund der hohen Kosten, FHE und ZK für jeden Block zusammen zu verwenden. Fhenix verwendet dieselbe TFHE-rs-Bibliothek (mit einigen Modifikationen) und führt ein Threshold Service Network zur dezentralen Handhabung von Entschlüsselungen ein. Es gibt auch unabhängige Teams wie Fhenix (jetzt umbenannt) und Startups, die MPC + FHE-Hybride erforschen. Darüber hinaus baut Cypher (von Z1 Labs) ein Layer-3-Netzwerk auf, das sich auf KI und Privatsphäre konzentriert und eine fhEVM mit Funktionen wie geheimen Speichern und Unterstützung für föderiertes Lernen verwendet. Das Ökosystem ist noch jung, wächst aber schnell, angetrieben durch erhebliche Finanzierungen – z. B. wurde Zama bis 2025 mit über 130 Millionen US-Dollar zu einem „Einhorn“, um die FHE-Technologie voranzutreiben.

Zusammenfassend ermöglicht eine FHE-VM datenschutzfreundliche Smart Contracts, indem sie die gesamte Logik auf verschlüsselten Daten On-Chain ausführt. Dieses Paradigma gewährleistet maximale Vertraulichkeit – nichts Sensibles wird jemals in Transaktionen oder im Status offengelegt – während der bestehende Blockchain-Konsens für die Integrität genutzt wird. Die Kosten sind eine erhöhte Rechenlast für Validatoren und Komplexität im Schlüsselmanagement und der Beweisintegration. Als Nächstes untersuchen wir ein alternatives Paradigma, das die Berechnung vollständig Off-Chain auslagert und die Kette nur zur Verifizierung verwendet: den Zero-Knowledge-Koprozessor.

Zero-Knowledge-Koprozessoren (ZK-Koprozessoren)​

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

Architektur und Workflow​

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

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

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

Die Hauptkomponenten eines ZK-Koprozessor-Systems sind:

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

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

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

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

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

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

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

Bemerkenswerte ZK-Koprozessor-Projekte​

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

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

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

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

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

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

FHE-VM vs. ZK-Koprozessor: Vergleich​

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

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

---

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

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

Fully Homomorphic Encryption Virtual Machine (FHE-VM)​

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

Architecture and Design of FHE-VM​

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

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

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

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

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

Ensuring Correctness and Privacy​

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

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

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

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

Aktuelle FHE-VM-Projekte​

Mehrere Projekte sind Pioniere in diesem Bereich. Zama (ein Pariser FHE-Startup) entwickelte das Kernkonzept und die Bibliotheken der FHEVM (TFHE-rs und eine fhevm-solidity-Bibliothek). Sie beabsichtigen nicht, eine eigene Kette zu starten, sondern Infrastruktur für andere bereitzustellen. Inco ist eine L1-Blockchain (aufgebaut auf Cosmos SDK mit Evmos), die Zamas FHEVM integriert hat, um eine modulare vertrauliche Kette zu schaffen. Ihre Testnetze (Gentry und Paillier genannt) zeigen verschlüsselte ERC-20-Transfers und andere private DeFi-Primitive. Fhenix ist ein Ethereum Layer-2 Optimistic Rollup, das FHE für die Privatsphäre verwendet. Es entschied sich für einen optimistischen (Betrugsbeweis-)Ansatz anstelle eines ZK-Rollups aufgrund der hohen Kosten, FHE und ZK für jeden Block zusammen zu verwenden. Fhenix verwendet dieselbe TFHE-rs-Bibliothek (mit einigen Modifikationen) und führt ein Threshold Service Network zur dezentralen Handhabung von Entschlüsselungen ein. Es gibt auch unabhängige Teams wie Fhenix (jetzt umbenannt) und Startups, die MPC + FHE-Hybride erforschen. Darüber hinaus baut Cypher (von Z1 Labs) ein Layer-3-Netzwerk auf, das sich auf KI und Privatsphäre konzentriert und eine fhEVM mit Funktionen wie geheimen Speichern und Unterstützung für föderiertes Lernen verwendet. Das Ökosystem ist noch jung, wächst aber schnell, angetrieben durch erhebliche Finanzierungen – z. B. wurde Zama bis 2025 mit über 130 Millionen US-Dollar zu einem „Einhorn“, um die FHE-Technologie voranzutreiben.

Zusammenfassend ermöglicht eine FHE-VM datenschutzfreundliche Smart Contracts, indem sie die gesamte Logik auf verschlüsselten Daten On-Chain ausführt. Dieses Paradigma gewährleistet maximale Vertraulichkeit – nichts Sensibles wird jemals in Transaktionen oder im Status offengelegt – während der bestehende Blockchain-Konsens für die Integrität genutzt wird. Die Kosten sind eine erhöhte Rechenlast für Validatoren und Komplexität im Schlüsselmanagement und der Beweisintegration. Als Nächstes untersuchen wir ein alternatives Paradigma, das die Berechnung vollständig Off-Chain auslagert und die Kette nur zur Verifizierung verwendet: den Zero-Knowledge-Koprozessor.

Zero-Knowledge-Koprozessoren (ZK-Koprozessoren)​

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

Architektur und Workflow​

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

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

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

Die Hauptkomponenten eines ZK-Koprozessor-Systems sind:

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

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

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

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

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

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

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

Bemerkenswerte ZK-Koprozessor-Projekte​

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

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

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

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

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

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

FHE-VM vs. ZK-Koprozessor: Vergleich​

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

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

---

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

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

Fully Homomorphic Encryption Virtual Machine (FHE-VM)​

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

Architektur und Design von FHE-VM​

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

Verschlüsselter Statusspeicher wird unterstützt, sodass Vertragsvariablen im Blockchain-Status verschlüsselt bleiben. Der Ausführungsfluss ist typischerweise:

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

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

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

Gewährleistung von Korrektheit und Privatsphäre​

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

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

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

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

Aktuelle FHE-VM-Projekte​

Mehrere Projekte sind Pioniere in diesem Bereich. Zama (ein Pariser FHE-Startup) entwickelte das Kernkonzept und die Bibliotheken der FHEVM (TFHE-rs und eine fhevm-solidity-Bibliothek). Sie beabsichtigen nicht, eine eigene Kette zu starten, sondern Infrastruktur für andere bereitzustellen. Inco ist eine L1-Blockchain (aufgebaut auf Cosmos SDK mit Evmos), die Zamas FHEVM integriert hat, um eine modulare vertrauliche Kette zu schaffen. Ihre Testnetze (Gentry und Paillier genannt) zeigen verschlüsselte ERC-20-Transfers und andere private DeFi-Primitive. Fhenix ist ein Ethereum Layer-2 Optimistic Rollup, das FHE für die Privatsphäre verwendet. Es entschied sich für einen optimistischen (Betrugsbeweis-)Ansatz anstelle eines ZK-Rollups aufgrund der hohen Kosten, FHE und ZK für jeden Block zusammen zu verwenden. Fhenix verwendet dieselbe TFHE-rs-Bibliothek (mit einigen Modifikationen) und führt ein Threshold Service Network zur dezentralen Handhabung von Entschlüsselungen ein. Es gibt auch unabhängige Teams wie Fhenix (jetzt umbenannt) und Startups, die MPC + FHE-Hybride erforschen. Darüber hinaus baut Cypher (von Z1 Labs) ein Layer-3-Netzwerk auf, das sich auf KI und Privatsphäre konzentriert und eine fhEVM mit Funktionen wie geheimen Speichern und Unterstützung für föderiertes Lernen verwendet. Das Ökosystem ist noch jung, wächst aber schnell, angetrieben durch erhebliche Finanzierungen – z. B. wurde Zama bis 2025 mit über 130 Millionen US-Dollar zu einem „Einhorn“, um die FHE-Technologie voranzutreiben.

Zusammenfassend ermöglicht eine FHE-VM datenschutzfreundliche Smart Contracts, indem sie die gesamte Logik auf verschlüsselten Daten On-Chain ausführt. Dieses Paradigma gewährleistet maximale Vertraulichkeit – nichts Sensibles wird jemals in Transaktionen oder im Status offengelegt – während der bestehende Blockchain-Konsens für die Integrität genutzt wird. Die Kosten sind eine erhöhte Rechenlast für Validatoren und Komplexität im Schlüsselmanagement und der Beweisintegration. Als Nächstes untersuchen wir ein alternatives Paradigma, das die Berechnung vollständig Off-Chain auslagert und die Kette nur zur Verifizierung verwendet: den Zero-Knowledge-Koprozessor.

Zero-Knowledge-Koprozessoren (ZK-Koprozessoren)​

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

Architektur und Workflow​

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

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

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

Die Hauptkomponenten eines ZK-Koprozessor-Systems sind:

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

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

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

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

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

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

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

Bemerkenswerte ZK-Koprozessor-Projekte​

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

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

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

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

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

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

FHE-VM vs. ZK-Koprozessor: Vergleich​

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

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