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

title: Programmierbare Privatsphäre in der Blockchain: Off-Chain-Berechnung mit On-Chain-Verifizierung description: Ein tiefer Einblick in FHE-VM- und ZK-Coprozessor-Architekturen, die vertrauliche Berechnungen in Web3 ermöglichen, sowie deren Anwendungsfälle in den Bereichen Finanzen, Identität und Gesundheitswesen. keywords:

• Blockchain
• Privatsphäre
• FHE
• ZK-Coprozessor
• Web3
• Kryptografie image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=Programmierbare%20Privatsph%C3%A4re%20in%20der%20Blockchain%3A%20Off-Chain-Berechnung%20mit%20On-Chain-Verifizierung%22%0Atags%3A%20%5Bblockchain%2C%20web3%5D%0A%0A%23%20Programmierbare%20Privatsph%C3%A4re%20in%20der%20Blockchain%3A%20Off-Chain-Berechnung%20mit%20On-Chain-Verifizierung%0A%0A!%5B%5D(https%3A%2F%2Fopengraph-image.blockeden.xyz%2Fapi%2Fog-blockeden-xyz%3Ftitle%3DProgrammierbare%20Privatsph%C3%A4re%20in%20der%20Blockchain%3A%20Off-Chain-Berechnung%20mit%20On-Chain-Verifizierung)

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

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

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

Architektur und Design der FHE-VM

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

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

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

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

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

Sicherstellung von Korrektheit und Privatsphäre

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

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

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

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

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

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

Zero-Knowledge-Coprozessoren (ZK-Coprocessors)

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

Architektur und Workflow

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

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

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

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

Die Hauptkomponenten eines ZK-Coprozessor-Systems sind:

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

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

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

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

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

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

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

Bekannte ZK-Coprozessor-Projekte

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

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

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

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

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

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

FHE-VM vs. ZK-Coprozessor: Vergleich

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

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

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

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

Anwendungsfälle und Auswirkungen

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

Vertrauliches DeFi und Finanzwesen

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

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

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

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

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

Digitale Identität und persönliche Daten

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

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

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

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

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

Gesundheitswesen und sensibler Datenaustausch

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

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

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

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

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

Datenmarktplätze und Zusammenarbeit

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

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

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

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

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

Dezentrales maschinelles Lernen (ZKML und FHE-ML)

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

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

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

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

Zusätzliche Bereiche

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

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

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

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

Fazit

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

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

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

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

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

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

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