Einleitung: Die Notwendigkeit verifizierbarer KI auf der Blockchain
Da KI-Systeme an Einfluss gewinnen, wird die Vertrauenswürdigkeit ihrer Ergebnisse entscheidend. Traditionelle Methoden verlassen sich auf institutionelle Zusicherungen (im Wesentlichen „vertrauen Sie uns einfach“), die keine kryptografischen Garantien bieten. Dies ist besonders problematisch in dezentralen Kontexten wie Blockchains, wo ein Smart Contract oder ein Benutzer einem KI-abgeleiteten Ergebnis vertrauen muss, ohne ein schweres Modell On-Chain erneut ausführen zu können. Zero-Knowledge Machine Learning (zkML) begegnet diesem Problem, indem es die kryptografische Verifizierung von ML-Berechnungen ermöglicht. Im Wesentlichen ermöglicht zkML einem Prover, einen prägnanten Beweis zu generieren, dass „die Ausgabe $Y$ aus der Ausführung des Modells $M$ mit der Eingabe $X$ resultierte“ – ohne $X$ oder die internen Details von $M$ preiszugeben. Diese Zero-Knowledge-Beweise (ZKPs) können von jedem (oder jedem Vertrag) effizient verifiziert werden, wodurch das KI-Vertrauen von „Richtlinie zu Beweis“ verlagert wird.
Die On-Chain-Verifizierbarkeit von KI bedeutet, dass eine Blockchain fortgeschrittene Berechnungen (wie neuronale Netzwerk-Inferenzen) integrieren kann, indem sie einen Beweis für die korrekte Ausführung verifiziert, anstatt die Berechnung selbst durchzuführen. Dies hat weitreichende Implikationen: Smart Contracts können Entscheidungen auf der Grundlage von KI-Vorhersagen treffen, dezentrale autonome Agenten können beweisen, dass sie ihren Algorithmen gefolgt sind, und Cross-Chain- oder Off-Chain-Berechnungsdienste können verifizierbare Ergebnisse anstelle von nicht verifizierbaren Orakeln liefern. Letztendlich bietet zkML einen Weg zu vertrauensloser und datenschutzfreundlicher KI – zum Beispiel, um zu beweisen, dass die Entscheidungen eines KI-Modells korrekt und autorisiert sind, ohne private Daten oder proprietäre Modellgewichte preiszugeben. Dies ist entscheidend für Anwendungen, die von sicherer Gesundheitsanalyse bis hin zu Blockchain-Gaming und DeFi-Orakeln reichen.
Wie zkML funktioniert: Komprimierung von ML-Inferenzen in prägnante Beweise
Im Allgemeinen kombiniert zkML kryptografische Beweissysteme mit ML-Inferenzen, sodass eine komplexe Modellbewertung in einen kleinen Beweis „komprimiert“ werden kann. Intern wird das ML-Modell (z. B. ein neuronales Netzwerk) als Schaltkreis oder Programm dargestellt, das aus vielen arithmetischen Operationen (Matrixmultiplikationen, Aktivierungsfunktionen usw.) besteht. Anstatt alle Zwischenwerte preiszugeben, führt ein Prover die vollständige Berechnung Off-Chain durch und verwendet dann ein Zero-Knowledge-Beweisprotokoll, um zu bestätigen, dass jeder Schritt korrekt ausgeführt wurde. Der Verifizierer, dem nur der Beweis und einige öffentliche Daten (wie die endgültige Ausgabe und ein Bezeichner für das Modell) vorliegen, kann kryptografisch von der Korrektheit überzeugt werden, ohne das Modell erneut auszuführen.
Um dies zu erreichen, transformieren zkML-Frameworks die Modellberechnung typischerweise in ein für ZKPs geeignetes Format:
- Schaltkreis-Kompilierung: Bei SNARK-basierten Ansätzen wird der Berechnungsgraph des Modells in einen arithmetischen Schaltkreis oder eine Menge von Polynom-Constraints kompiliert. Jede Schicht des neuronalen Netzwerks (Faltungen, Matrixmultiplikationen, nichtlineare Aktivierungen) wird zu einem Teilschaltkreis mit Constraints, die sicherstellen, dass die Ausgaben bei gegebenen Eingaben korrekt sind. Da neuronale Netze nichtlineare Operationen (ReLUs, Sigmoids usw.) beinhalten, die nicht von Natur aus für Polynome geeignet sind, werden Techniken wie Lookup-Tabellen verwendet, um diese effizient zu handhaben. Zum Beispiel kann eine ReLU (Ausgabe = max(0, Eingabe)) durch eine benutzerdefinierte Constraint oder einen Lookup erzwungen werden, der überprüft, ob die Ausgabe der Eingabe entspricht, wenn Eingabe≥0, andernfalls Null. Das Endergebnis ist eine Reihe kryptografischer Constraints, die der Prover erfüllen muss, was implizit beweist, dass das Modell korrekt ausgeführt wurde.
- Ausführungs-Trace & Virtuelle Maschinen: Eine Alternative besteht darin, die Modellinferenz als Programm-Trace zu behandeln, wie es bei zkVM-Ansätzen der Fall ist. Zum Beispiel zielt die JOLT zkVM auf den RISC-V-Befehlssatz ab; man kann das ML-Modell (oder den Code, der es berechnet) nach RISC-V kompilieren und dann beweisen, dass jeder CPU-Befehl ordnungsgemäß ausgeführt wurde. JOLT führt eine „Lookup-Singularität“-Technik ein, die teure arithmetische Constraints durch schnelle Tabellen-Lookups für jede gültige CPU-Operation ersetzt. Jede Operation (Addition, Multiplikation, Bit-Operation usw.) wird über einen Lookup in einer riesigen Tabelle von vorab berechneten gültigen Ergebnissen überprüft, wobei ein spezialisiertes Argument (Lasso/SHOUT) verwendet wird, um dies effizient zu halten. Dies reduziert die Arbeitslast des Provers drastisch: Selbst komplexe 64-Bit-Operationen werden zu einem einzigen Tabellen-Lookup im Beweis anstelle vieler arithmetischer Constraints.
- Interaktive Protokolle (GKR Sum-Check): Ein dritter Ansatz verwendet interaktive Beweise wie GKR (Goldwasser–Kalai–Rotblum), um eine geschichtete Berechnung zu verifizieren. Hier wird die Berechnung des Modells als geschichteter arithmetischer Schaltkreis betrachtet (jede neuronale Netzwerkschicht ist eine Schicht des Schaltkreisgraphen). Der Prover führt das Modell normal aus, beteiligt sich dann aber an einem Sum-Check-Protokoll, um zu beweisen, dass die Ausgaben jeder Schicht bei gegebenen Eingaben korrekt sind. Im Lagrange-Ansatz (DeepProve, als Nächstes detailliert) führen Prover und Verifizierer ein interaktives Polynomprotokoll durch (das über Fiat-Shamir nicht-interaktiv gemacht wird), das die Konsistenz der Berechnungen jeder Schicht überprüft, ohne sie erneut durchzuführen. Diese Sum-Check-Methode vermeidet die Generierung eines monolithischen statischen Schaltkreises; stattdessen verifiziert sie die Konsistenz der Berechnungen schrittweise mit minimalen kryptografischen Operationen (hauptsächlich Hashing oder Polynombewertungen).
Unabhängig vom Ansatz ist das Ergebnis ein prägnanter Beweis (typischerweise einige Kilobyte bis einige zehn Kilobyte), der die Korrektheit der gesamten Inferenz bestätigt. Der Beweis ist Zero-Knowledge, was bedeutet, dass alle geheimen Eingaben (private Daten oder Modellparameter) verborgen bleiben können – sie beeinflussen den Beweis, werden aber den Verifizierern nicht offengelegt. Nur die beabsichtigten öffentlichen Ausgaben oder Behauptungen werden offengelegt. Dies ermöglicht Szenarien wie „beweisen Sie, dass Modell $M$, angewendet auf Patientendaten $X$, die Diagnose $Y$ ergibt, ohne $X$ oder die Gewichte des Modells preiszugeben.“
On-Chain-Verifizierung ermöglichen: Sobald ein Beweis generiert wurde, kann er auf einer Blockchain veröffentlicht werden. Smart Contracts können Verifizierungslogik enthalten, um den Beweis zu überprüfen, oft unter Verwendung vorkompilierter kryptografischer Primitive. Zum Beispiel verfügt Ethereum über Precompiles für BLS12-381-Pairing-Operationen, die in vielen zk-SNARK-Verifizierern verwendet werden, was die On-Chain-Verifizierung von SNARK-Beweisen effizient macht. STARKs (Hash-basierte Beweise) sind größer, können aber dennoch On-Chain mit sorgfältiger Optimierung oder möglicherweise mit einigen Vertrauensannahmen verifiziert werden (StarkWares L2 verifiziert beispielsweise STARK-Beweise auf Ethereum durch einen On-Chain-Verifizierer-Vertrag, wenn auch mit höheren Gaskosten als SNARKs). Der Schlüssel ist, dass die Kette das ML-Modell nicht ausführen muss – sie führt nur eine Verifizierung durch, die viel billiger ist als die ursprüngliche Berechnung. Zusammenfassend lässt sich sagen, dass zkML teure KI-Inferenzen in einen kleinen Beweis komprimiert, den Blockchains (oder jeder Verifizierer) in Millisekunden bis Sekunden überprüfen können.
Lagrange DeepProve: Architektur und Leistung eines zkML-Durchbruchs
DeepProve von Lagrange Labs ist ein hochmodernes zkML-Inferenz-Framework, das sich auf Geschwindigkeit und Skalierbarkeit konzentriert. DeepProve wurde 2025 eingeführt und stellte ein neues Beweissystem vor, das dramatisch schneller ist als frühere Lösungen wie Ezkl. Sein Design konzentriert sich auf das GKR-interaktive Beweisprotokoll mit Sum-Check und spezialisierte Optimierungen für neuronale Netzwerk-Schaltkreise. So funktioniert DeepProve und erreicht seine Leistung:
-
Einmalige Vorverarbeitung: Entwickler beginnen mit einem trainierten neuronalen Netzwerk (derzeit unterstützte Typen umfassen Multilayer-Perceptrons und gängige CNN-Architekturen). Das Modell wird in das ONNX-Format exportiert, eine Standard-Graphdarstellung. Das Tool von DeepProve parst dann das ONNX-Modell und quantisiert es (konvertiert Gewichte in Festkomma-/Ganzzahlform) für effiziente Feldarithmetik. In dieser Phase generiert es auch die Proving- und Verifizierungs-Keys für das kryptografische Protokoll. Dieses Setup wird einmal pro Modell durchgeführt und muss nicht pro Inferenz wiederholt werden. DeepProve betont die einfache Integration: „Exportieren Sie Ihr Modell nach ONNX → einmaliges Setup → Beweise generieren → überall verifizieren“.
-
Beweiserstellung (Inferenz + Beweisgenerierung): Nach dem Setup nimmt ein Prover (der von einem Benutzer, einem Dienst oder dem dezentralen Prover-Netzwerk von Lagrange ausgeführt werden könnte) eine neue Eingabe $X$ und führt das Modell $M$ darauf aus, wobei er die Ausgabe $Y$ erhält. Während dieser Ausführung zeichnet DeepProve einen Ausführungs-Trace der Berechnungen jeder Schicht auf. Anstatt jede Multiplikation im Voraus in einen statischen Schaltkreis zu übersetzen (wie es SNARK-Ansätze tun), verwendet DeepProve das linearzeitliche GKR-Protokoll, um jede Schicht im laufenden Betrieb zu verifizieren. Für jede Netzwerkschicht verpflichtet sich der Prover zu den Eingaben und Ausgaben der Schicht (z. B. über kryptografische Hashes oder Polynom-Commitments) und beteiligt sich dann an einem Sum-Check-Argument, um zu beweisen, dass die Ausgaben tatsächlich aus den Eingaben gemäß der Funktion der Schicht resultieren. Das Sum-Check-Protokoll überzeugt den Verifizierer iterativ von der Korrektheit einer Summe von Auswertungen eines Polynoms, das die Berechnung der Schicht kodiert, ohne die tatsächlichen Werte preiszugeben. Nichtlineare Operationen (wie ReLU, Softmax) werden in DeepProve effizient durch Lookup-Argumente behandelt – wenn die Ausgabe einer Aktivierung berechnet wurde, kann DeepProve beweisen, dass jede Ausgabe einem gültigen Eingabe-Ausgabe-Paar aus einer vorab berechneten Tabelle für diese Funktion entspricht. Schicht für Schicht werden Beweise generiert und dann zu einem prägnanten Beweis aggregiert, der den gesamten Vorwärtslauf des Modells abdeckt. Der Großteil der Kryptografie wird minimiert – der Prover von DeepProve führt hauptsächlich normale numerische Berechnungen (die eigentliche Inferenz) sowie einige leichte kryptografische Commitments durch, anstatt ein riesiges System von Constraints zu lösen.
-
Verifizierung: Der Verifizierer verwendet den endgültigen prägnanten Beweis zusammen mit einigen öffentlichen Werten – typischerweise dem committed Identifier des Modells (ein kryptografisches Commitment zu den Gewichten von $M$), der Eingabe $X$ (falls nicht privat) und der behaupteten Ausgabe $Y$ – um die Korrektheit zu überprüfen. Die Verifizierung im DeepProve-System beinhaltet die Überprüfung des Transkripts des Sum-Check-Protokolls und der endgültigen Polynom- oder Hash-Commitments. Dies ist aufwendiger als die Verifizierung eines klassischen SNARK (der einige Pairings umfassen könnte), aber es ist wesentlich billiger als das erneute Ausführen des Modells. In den Benchmarks von Lagrange dauert die Verifizierung eines DeepProve-Beweises für ein mittleres CNN in Software etwa 0,5 Sekunden. Das sind ~0,5s, um beispielsweise zu bestätigen, dass ein Faltungsnetzwerk mit Hunderttausenden von Parametern korrekt ausgeführt wurde – über 500-mal schneller als die naive Neuberechnung dieses CNN auf einer GPU zur Verifizierung. (Tatsächlich maß DeepProve eine 521-mal schnellere Verifizierung für CNNs und 671-mal für MLPs im Vergleich zur erneuten Ausführung.) Die Beweisgröße ist klein genug, um On-Chain übertragen zu werden (Zehntausende von KB), und die Verifizierung könnte bei Bedarf in einem Smart Contract durchgeführt werden, obwohl 0,5s Rechenzeit eine sorgfältige Gasoptimierung oder Layer-2-Ausführung erfordern könnten.
Architektur und Tools: DeepProve ist in Rust implementiert und bietet ein Toolkit (die zkml-Bibliothek) für Entwickler. Es unterstützt nativ ONNX-Modellgraphen und ist somit mit Modellen von PyTorch oder TensorFlow (nach dem Export) kompatibel. Der Proving-Prozess zielt derzeit auf Modelle mit bis zu einigen Millionen Parametern ab (Tests umfassen ein dichtes Netzwerk mit 4 Millionen Parametern). DeepProve nutzt eine Kombination kryptografischer Komponenten: ein multilineares Polynom-Commitment (um sich auf Schichtausgaben festzulegen), das Sum-Check-Protokoll zur Verifizierung von Berechnungen und Lookup-Argumente für nichtlineare Operationen. Bemerkenswerterweise erkennt Lagranges Open-Source-Repository an, dass es auf früheren Arbeiten (der Sum-Check- und GKR-Implementierung aus Scrolls Ceno-Projekt) aufbaut, was eine Überschneidung von zkML mit der Zero-Knowledge-Rollup-Forschung anzeigt.
Um Echtzeit-Skalierbarkeit zu erreichen, koppelt Lagrange DeepProve mit seinem Prover Network – einem dezentralen Netzwerk spezialisierter ZK-Prover. Die aufwendige Beweisgenerierung kann an dieses Netzwerk ausgelagert werden: Wenn eine Anwendung eine Inferenz verifiziert haben muss, sendet sie den Auftrag an das Lagrange-Netzwerk, wo viele Operatoren (die auf EigenLayer für Sicherheit gestaked sind) Beweise berechnen und das Ergebnis zurückgeben. Dieses Netzwerk incentiviert die zuverlässige Beweisgenerierung wirtschaftlich (bösartige oder fehlgeschlagene Aufträge führen dazu, dass der Operator slashed wird). Durch die Verteilung der Arbeit auf mehrere Prover (und potenziell die Nutzung von GPUs oder ASICs) verbirgt das Lagrange Prover Network die Komplexität und Kosten vor den Endbenutzern. Das Ergebnis ist ein schneller, skalierbarer und dezentraler zkML-Dienst: „verifizierbare KI-Inferenzen schnell und erschwinglich“.
Leistungsmeilensteine: Die Behauptungen von DeepProve werden durch Benchmarks gegen den bisherigen Stand der Technik, Ezkl, untermauert. Für ein CNN mit ~264.000 Parametern (Modell im CIFAR-10-Maßstab) betrug die Proving-Zeit von DeepProve ~1,24 Sekunden gegenüber ~196 Sekunden für Ezkl – etwa 158-mal schneller. Für ein größeres dichtes Netzwerk mit 4 Millionen Parametern bewies DeepProve eine Inferenz in ~2,3 Sekunden gegenüber ~126,8 Sekunden für Ezkl (~54-mal schneller). Auch die Verifizierungszeiten sanken: DeepProve verifizierte den 264k CNN-Beweis in ~0,6s, während die Verifizierung des Ezkl-Beweises (Halo2-basiert) in diesem Test über 5 Minuten auf der CPU dauerte. Die Beschleunigungen resultieren aus der nahezu linearen Komplexität von DeepProve: Sein Prover skaliert ungefähr O(n) mit der Anzahl der Operationen, während schaltkreisbasierte SNARK-Prover oft einen superlinearen Overhead aufweisen (FFT- und Polynom-Commitments-Skalierung). Tatsächlich kann der Prover-Durchsatz von DeepProve innerhalb einer Größenordnung der reinen Inferenzlaufzeit liegen – neuere GKR-Systeme können <10-mal langsamer sein als die Rohausführung für große Matrixmultiplikationen, eine beeindruckende Leistung in ZK. Dies macht Echtzeit- oder On-Demand-Beweise praktikabler und ebnet den Weg für verifizierbare KI in interaktiven Anwendungen.
Anwendungsfälle: Lagrange arbeitet bereits mit Web3- und KI-Projekten zusammen, um zkML anzuwenden. Beispielhafte Anwendungsfälle sind: verifizierbare NFT-Merkmale (Nachweis, dass eine KI-generierte Evolution eines Spielcharakters oder Sammlerstücks vom autorisierten Modell berechnet wurde), Provenienz von KI-Inhalten (Nachweis, dass ein Bild oder Text von einem bestimmten Modell generiert wurde, um Deepfakes zu bekämpfen), DeFi-Risikomodelle (Nachweis der Ausgabe eines Modells, das finanzielle Risiken bewertet, ohne proprietäre Daten preiszugeben) und private KI-Inferenz im Gesundheitswesen oder Finanzbereich (wo ein Krankenhaus KI-Vorhersagen mit einem Beweis erhalten kann, der die Korrektheit gewährleistet, ohne Patientendaten preiszugeben). Indem KI-Ausgaben verifizierbar und datenschutzfreundlich gemacht werden, öffnet DeepProve die Tür zu „KI, der Sie vertrauen können“ in dezentralen Systemen – von einer Ära des „blinden Vertrauens in Black-Box-Modelle“ zu einer Ära der „objektiven Garantien“.
SNARK-basiertes zkML: Ezkl und der Halo2-Ansatz
Der traditionelle Ansatz für zkML verwendet zk-SNARKs (Succinct Non-interactive Arguments of Knowledge), um neuronale Netzwerk-Inferenzen zu beweisen. Ezkl (von ZKonduit/Modulus Labs) ist ein führendes Beispiel für diesen Ansatz. Es baut auf dem Halo2-Beweissystem auf (ein SNARK im PLONK-Stil mit Polynom-Commitments über BLS12-381). Ezkl bietet eine Toolchain, mit der ein Entwickler ein PyTorch- oder TensorFlow-Modell nehmen, es nach ONNX exportieren und Ezkl es automatisch in einen benutzerdefinierten arithmetischen Schaltkreis kompilieren lassen kann.
Funktionsweise: Jede Schicht des neuronalen Netzwerks wird in Constraints umgewandelt:
- Lineare Schichten (dicht oder Faltung) werden zu Sammlungen von Multiplikations-Additions-Constraints, die die Skalarprodukte zwischen Eingaben, Gewichten und Ausgaben erzwingen.
- Nichtlineare Schichten (wie ReLU, Sigmoid usw.) werden über Lookups oder stückweise Constraints behandelt, da solche Funktionen nicht polynomial sind. Zum Beispiel kann eine ReLU durch einen booleschen Selektor $b$ implementiert werden, mit Constraints, die sicherstellen, dass $y = x \cdot b$ und $0 \le b \le 1$ und $b=1$ wenn $x>0$ (eine Möglichkeit), oder effizienter durch eine Lookup-Tabelle, die $x \mapsto \max(0,x)$ für einen Bereich von $x$-Werten abbildet. Halo2s Lookup-Argumente ermöglichen das Mapping von 16-Bit (oder kleineren) Wertblöcken, sodass große Domänen (wie alle 32-Bit-Werte) normalerweise in mehrere kleinere Lookups „zerlegt“ werden. Dieses Zerlegen erhöht die Anzahl der Constraints.
- Große Ganzzahloperationen oder Divisionen (falls vorhanden) werden ähnlich in kleine Teile zerlegt. Das Ergebnis ist eine große Menge von R1CS/PLONK-Constraints, die auf die spezifische Modellarchitektur zugeschnitten sind.
Ezkl verwendet dann Halo2, um einen Beweis zu generieren, dass diese Constraints bei gegebenen geheimen Eingaben (Modellgewichte, private Eingaben) und öffentlichen Ausgaben gelten. Tools und Integration: Ein Vorteil des SNARK-Ansatzes ist, dass er auf bekannte Primitive zurückgreift. Halo2 wird bereits in Ethereum-Rollups (z. B. Zcash, zkEVMs) verwendet, ist also kampferprobt und verfügt über einen sofort verfügbaren On-Chain-Verifizierer. Die Beweise von Ezkl verwenden die BLS12-381-Kurve, die Ethereum über Precompiles verifizieren kann, was die Verifizierung eines Ezkl-Beweises in einem Smart Contract unkompliziert macht. Das Team hat auch benutzerfreundliche APIs bereitgestellt; zum Beispiel können Datenwissenschaftler mit ihren Modellen in Python arbeiten und Ezkls CLI verwenden, um Beweise zu erstellen, ohne tiefgehende Kenntnisse von Schaltkreisen zu haben.
Stärken: Der Ansatz von Ezkl profitiert von der Allgemeinheit und dem Ökosystem von SNARKs. Er unterstützt einigermaßen komplexe Modelle und hat bereits „praktische Integrationen (von DeFi-Risikomodellen bis hin zu Gaming-KI)“ erfahren, die reale ML-Aufgaben beweisen. Da er auf der Ebene des Berechnungsdiagramms des Modells arbeitet, kann er ML-spezifische Optimierungen anwenden: z. B. das Beschneiden unbedeutender Gewichte oder das Quantisieren von Parametern, um die Schaltkreisgröße zu reduzieren. Es bedeutet auch, dass die Modellvertraulichkeit natürlich ist – die Gewichte können als private Zeugendaten behandelt werden, sodass der Verifizierer nur sieht, dass irgendein gültiges Modell die Ausgabe erzeugt hat, oder bestenfalls ein Commitment zum Modell. Die Verifizierung von SNARK-Beweisen ist extrem schnell (typischerweise wenige Millisekunden oder weniger On-Chain), und die Beweisgrößen sind klein (einige Kilobyte), was ideal für die Blockchain-Nutzung ist.
Schwächen: Die Leistung ist die Achillesferse. Schaltkreisbasierte Beweiserstellung verursacht große Overheads, insbesondere wenn Modelle wachsen. Es wird angemerkt, dass SNARK-Schaltkreise historisch gesehen eine Million Mal mehr Arbeit für den Prover bedeuten konnten, als nur das Modell selbst auszuführen. Halo2 und Ezkl optimieren dies, aber dennoch erzeugen Operationen wie große Matrixmultiplikationen Tonnen von Constraints. Wenn ein Modell Millionen von Parametern hat, muss der Prover entsprechend Millionen von Constraints verarbeiten und dabei aufwendige FFTs und Multiexponentiationen durchführen. Dies führt zu hohen Proving-Zeiten (oft Minuten oder Stunden für nicht-triviale Modelle) und hohem Speicherverbrauch. Zum Beispiel kann die Beweiserstellung für ein relativ kleines CNN (z. B. einige Hunderttausend Parameter) mit Ezkl auf einer einzelnen Maschine Dutzende von Minuten dauern. Das Team hinter DeepProve zitierte, dass Ezkl Stunden für bestimmte Modellbeweise benötigte, die DeepProve in Minuten erledigen kann. Große Modelle passen möglicherweise nicht einmal in den Speicher oder erfordern eine Aufteilung in mehrere Beweise (die dann eine rekursive Aggregation benötigen). Obwohl Halo2 „moderat optimiert“ ist, führt jede Notwendigkeit, Lookups zu „zerlegen“ oder Operationen mit breiten Bits zu handhaben, zu zusätzlichem Overhead. Zusammenfassend lässt sich sagen, dass die Skalierbarkeit begrenzt ist – Ezkl funktioniert gut für kleine bis mittlere Modelle (und übertraf in Benchmarks tatsächlich einige frühere Alternativen wie naive Stark-basierte VMs), aber es stößt an Grenzen, wenn die Modellgröße einen bestimmten Punkt überschreitet.
Trotz dieser Herausforderungen sind Ezkl und ähnliche SNARK-basierte zkML-Bibliotheken wichtige Meilensteine. Sie bewiesen, dass verifizierte ML-Inferenz On-Chain möglich ist und aktiv genutzt wird. Insbesondere Projekte wie Modulus Labs demonstrierten die Verifizierung eines 18-Millionen-Parameter-Modells On-Chain unter Verwendung von SNARKs (mit starker Optimierung). Die Kosten waren nicht trivial, aber es zeigt die Entwicklung. Darüber hinaus verfügt das Mina Protocol über ein eigenes zkML-Toolkit, das SNARKs verwendet, um Smart Contracts auf Mina (die SNARK-basiert sind) die Verifizierung der ML-Modellausführung zu ermöglichen. Dies deutet auf eine wachsende Multi-Plattform-Unterstützung für SNARK-basierte zkML hin.
STARK-basierte Ansätze: Transparente und programmierbare ZK für ML
zk-STARKs (Scalable Transparent ARguments of Knowledge) bieten einen weiteren Weg zu zkML. STARKs verwenden Hash-basierte Kryptografie (wie FRI für Polynom-Commitments) und vermeiden jegliches Trusted Setup. Sie arbeiten oft, indem sie eine CPU oder VM simulieren und die Korrektheit des Ausführungs-Traces beweisen. Im Kontext von ML kann man entweder einen benutzerdefinierten STARK für das neuronale Netzwerk erstellen oder eine allgemeine STARK-VM verwenden, um den Modellcode auszuführen.
Allgemeine STARK-VMs (RISC Zero, Cairo): Ein unkomplizierter Ansatz ist, Inferenzcode zu schreiben und ihn in einer STARK-VM auszuführen. Zum Beispiel bietet Risc0 eine RISC-V-Umgebung, in der jeder Code (z. B. eine C++- oder Rust-Implementierung eines neuronalen Netzwerks) ausgeführt und über einen STARK bewiesen werden kann. Ähnlich kann StarkWares Cairo-Sprache beliebige Berechnungen (wie eine LSTM- oder CNN-Inferenz) ausdrücken, die dann vom StarkNet STARK-Prover bewiesen werden. Der Vorteil ist die Flexibilität – man muss keine benutzerdefinierten Schaltkreise für jedes Modell entwerfen. Frühe Benchmarks zeigten jedoch, dass naive STARK-VMs im Vergleich zu optimierten SNARK-Schaltkreisen für ML langsamer waren. In einem Test war ein Halo2-basierter Beweis (Ezkl) etwa 3-mal schneller als ein STARK-basierter Ansatz auf Cairo und sogar 66-mal schneller als eine RISC-V STARK-VM bei einem bestimmten Benchmark im Jahr 2024. Diese Lücke ist auf den Overhead der Simulation jeder Low-Level-Anweisung in einem STARK und die größeren Konstanten in STARK-Beweisen zurückzuführen (Hashing ist schnell, aber man braucht viel davon; STARK-Beweisgrößen sind größer usw.). STARK-VMs verbessern sich jedoch und bieten den Vorteil eines transparenten Setups (kein Trusted Setup) und Post-Quanten-Sicherheit. Mit fortschreitender STARK-freundlicher Hardware und Protokollen werden sich die Proving-Geschwindigkeiten verbessern.
DeepProves Ansatz vs. STARK: Interessanterweise liefert DeepProves Verwendung von GKR und Sum-Check einen Beweis, der im Geiste eher einem STARK ähnelt – es ist ein interaktiver, Hash-basierter Beweis, der keine strukturierte Referenzzeichenfolge benötigt. Der Kompromiss ist, dass seine Beweise größer und die Verifizierung aufwendiger ist als bei einem SNARK. Dennoch zeigt DeepProve, dass ein sorgfältiges Protokolldesign (spezialisiert auf die geschichtete Struktur von ML) sowohl generische STARK-VMs als auch SNARK-Schaltkreise in der Proving-Zeit deutlich übertreffen kann. Wir können DeepProve als einen maßgeschneiderten STARK-ähnlichen zkML-Prover betrachten (obwohl sie den Begriff zkSNARK für Prägnanz verwenden, hat er nicht die kleine konstante Verifizierungsgröße eines traditionellen SNARK, da 0,5s Verifizierung größer ist als die typische SNARK-Verifizierung). Traditionelle STARK-Beweise (wie die von StarkNet) erfordern oft Zehntausende von Feldoperationen zur Verifizierung, während SNARKs vielleicht nur wenige Dutzend verifizieren. Somit ist ein Kompromiss offensichtlich: SNARKs liefern kleinere Beweise und schnellere Verifizierer, während STARKs (oder GKR) eine einfachere Skalierung und kein Trusted Setup auf Kosten der Beweisgröße und Verifizierungsgeschwindigkeit bieten.
Aufkommende Verbesserungen: Die JOLT zkVM (zuvor unter JOLTx besprochen) gibt tatsächlich SNARKs aus (unter Verwendung von PLONKish-Commitments), verkörpert aber Ideen, die auch im STARK-Kontext angewendet werden könnten (Lasso-Lookups könnten theoretisch mit FRI-Commitments verwendet werden). StarkWare und andere erforschen Wege, die Beweiserstellung gängiger Operationen zu beschleunigen (z. B. die Verwendung von Custom Gates oder Hints in Cairo für Big-Int-Operationen usw.). Es gibt auch Circomlib-ML von Privacy&Scaling Explorations (PSE), das Circom-Templates für CNN-Schichten usw. bereitstellt – das ist SNARK-orientiert, aber konzeptionell ähnliche Templates könnten für STARK-Sprachen erstellt werden.
In der Praxis umfassen Nicht-Ethereum-Ökosysteme, die STARKs nutzen, StarkNet (das eine On-Chain-Verifizierung von ML ermöglichen könnte, wenn jemand einen Verifizierer schreibt, obwohl die Kosten hoch sind) und den Bonsai-Dienst von Risc0 (ein Off-Chain-Proving-Dienst, der STARK-Beweise ausgibt, die auf verschiedenen Chains verifiziert werden können). Ab 2025 haben die meisten zkML-Demos auf der Blockchain SNARKs bevorzugt (aufgrund der Verifizierereffizienz), aber STARK-Ansätze bleiben attraktiv wegen ihrer Transparenz und ihres Potenzials in Hochsicherheits- oder quantenresistenten Umgebungen. Zum Beispiel könnte ein dezentrales Computernetzwerk STARKs verwenden, um jedem die Verifizierung der Arbeit ohne Trusted Setup zu ermöglichen, was für die Langlebigkeit nützlich ist. Auch könnten einige spezialisierte ML-Aufgaben STARK-freundliche Strukturen nutzen: z. B. Berechnungen, die stark XOR-/Bit-Operationen verwenden, könnten in STARKs (da diese in der Booleschen Algebra und beim Hashing günstig sind) schneller sein als in der SNARK-Feldarithmetik.
Zusammenfassung von SNARK vs. STARK für ML:
- Leistung: SNARKs (wie Halo2) haben einen enormen Prover-Overhead pro Gate, profitieren aber von leistungsstarken Optimierungen und kleinen Konstanten für die Verifizierung; STARKs (generisch) haben einen größeren konstanten Overhead, skalieren aber linearer und vermeiden teure Kryptografie wie Pairings. DeepProve zeigt, dass die Anpassung des Ansatzes (Sum-Check) eine nahezu lineare Proving-Zeit (schnell) mit einem STARK-ähnlichen Beweis ergibt. JOLT zeigt, dass selbst eine allgemeine VM durch intensive Nutzung von Lookups schneller gemacht werden kann. Empirisch gesehen, für Modelle bis zu Millionen von Operationen: Ein gut optimierter SNARK (Ezkl) kann dies bewältigen, benötigt aber möglicherweise Dutzende von Minuten, während DeepProve (GKR) dies in Sekunden erledigen kann. STARK-VMs waren 2024 wahrscheinlich dazwischen oder schlechter als SNARKs, es sei denn, sie waren spezialisiert (Risc0 war in Tests langsamer, Cairo war ohne benutzerdefinierte Hints langsamer).
- Verifizierung: SNARK-Beweise verifizieren am schnellsten (Millisekunden, und minimale Daten On-Chain ~ einige Hundert Byte bis wenige KB). STARK-Beweise sind größer (Dutzende von KB) und benötigen aufgrund vieler Hashing-Schritte länger (Zehntausende von ms bis Sekunden) zur Verifizierung. In Blockchain-Begriffen könnte eine SNARK-Verifizierung z. B. ~200k Gas kosten, während eine STARK-Verifizierung Millionen von Gas kosten könnte – oft zu hoch für L1, akzeptabel auf L2 oder mit prägnanten Verifizierungsschemata.
- Setup und Sicherheit: SNARKs wie Groth16 erfordern ein Trusted Setup pro Schaltkreis (unfreundlich für beliebige Modelle), aber universelle SNARKs (PLONK, Halo2) haben ein einmaliges Setup, das für jeden Schaltkreis bis zu einer bestimmten Größe wiederverwendet werden kann. STARKs benötigen kein Setup und verwenden nur Hash-Annahmen (plus klassische Polynomkomplexitätsannahmen) und sind post-quantensicher. Dies macht STARKs attraktiv für die Langlebigkeit – Beweise bleiben sicher, selbst wenn Quantencomputer auftauchen, während aktuelle SNARKs (BLS12-381-basiert) durch Quantenangriffe gebrochen würden.
Wir werden diese Unterschiede in Kürze in einer Vergleichstabelle zusammenfassen.
FHE für ML (FHE-o-ML): Private Berechnung vs. verifizierbare Berechnung
Vollständig Homomorphe Verschlüsselung (FHE) ist eine kryptografische Technik, die es ermöglicht, Berechnungen direkt auf verschlüsselten Daten durchzuführen. Im Kontext von ML kann FHE eine Form der datenschutzfreundlichen Inferenz ermöglichen: Zum Beispiel kann ein Client verschlüsselte Eingaben an einen Modell-Host senden, der Host führt das neuronale Netzwerk auf dem Chiffretext aus, ohne ihn zu entschlüsseln, und sendet ein verschlüsseltes Ergebnis zurück, das der Client entschlüsseln kann. Dies gewährleistet die Datenvertraulichkeit – der Modelleigentümer erfährt nichts über die Eingabe (und potenziell erfährt der Client nur die Ausgabe, nicht die internen Details des Modells, wenn er nur die Ausgabe erhält). FHE allein erzeugt jedoch keinen Korrektheitsbeweis auf die gleiche Weise wie ZKPs. Der Client muss darauf vertrauen, dass der Modelleigentümer die Berechnung tatsächlich ehrlich durchgeführt hat (der Chiffretext könnte manipuliert worden sein). Normalerweise, wenn der Client das Modell hat oder eine bestimmte Verteilung der Ausgaben erwartet, kann offensichtlicher Betrug erkannt werden, aber subtile Fehler oder die Verwendung einer falschen Modellversion wären allein aus der verschlüsselten Ausgabe nicht ersichtlich.
Kompromisse bei der Leistung: FHE ist bekanntermaßen rechenintensiv. Die Ausführung von Deep-Learning-Inferenzen unter FHE führt zu Verlangsamungen um Größenordnungen. Frühe Experimente (z. B. CryptoNets im Jahr 2016) benötigten Dutzende von Sekunden, um ein winziges CNN auf verschlüsselten Daten zu evaluieren. Bis 2024 haben Verbesserungen wie CKKS (für ungefähre Arithmetik) und bessere Bibliotheken (Microsoft SEAL, Zamas Concrete) diesen Overhead reduziert, er bleibt jedoch groß. Zum Beispiel berichtete ein Benutzer, dass die Verwendung von Zamas Concrete-ML zur Ausführung eines CIFAR-10-Klassifikators 25–30 Minuten pro Inferenz auf seiner Hardware dauerte. Nach Optimierungen erreichte Zamas Team ~40 Sekunden für diese Inferenz auf einem 192-Core-Server. Selbst 40s sind extrem langsam im Vergleich zu einer Klartext-Inferenz (die vielleicht 0,01s dauert), was einen Overhead von ~$10^3$–$10^4\times$ zeigt. Größere Modelle oder höhere Präzision erhöhen die Kosten weiter. Zusätzlich verbrauchen FHE-Operationen viel Speicher und erfordern gelegentliches Bootstrapping (einen Rauschunterdrückungsschritt), was rechenintensiv ist. Zusammenfassend lässt sich sagen, dass Skalierbarkeit ein großes Problem ist – modernste FHE könnte ein kleines CNN oder eine einfache logistische Regression bewältigen, aber die Skalierung auf große CNNs oder Transformer liegt jenseits der aktuellen praktischen Grenzen.
Datenschutzvorteile: Der große Reiz von FHE ist der Datenschutz. Die Eingabe kann während des gesamten Prozesses vollständig verschlüsselt bleiben. Das bedeutet, dass ein nicht vertrauenswürdiger Server auf den privaten Daten eines Clients rechnen kann, ohne etwas darüber zu erfahren. Umgekehrt könnte man, wenn das Modell sensibel (proprietär) ist, die Modellparameter verschlüsseln und den Client die FHE-Inferenz auf seiner Seite durchführen lassen – dies ist jedoch weniger verbreitet, da der Client, wenn er die aufwendige FHE-Berechnung durchführen muss, die Idee der Auslagerung an einen leistungsstarken Server zunichtemacht. Typischerweise ist das Modell öffentlich oder wird vom Server im Klartext gehalten, und die Daten werden mit dem Schlüssel des Clients verschlüsselt. Der Modellschutz ist in diesem Szenario standardmäßig nicht gegeben (der Server kennt das Modell; der Client erfährt Ausgaben, aber nicht die Gewichte). Es gibt exotischere Setups (wie sichere Zwei-Parteien-Berechnung oder Multi-Key-FHE), bei denen sowohl Modell als auch Daten voneinander privat gehalten werden können, aber diese verursachen noch mehr Komplexität. Im Gegensatz dazu kann zkML über ZKPs Modellschutz und Datenschutz gleichzeitig gewährleisten – der Prover kann sowohl das Modell als auch die Daten als geheime Zeugen haben und dem Verifizierer nur das Notwendige offenbaren.
Keine On-Chain-Verifizierung erforderlich (und keine möglich): Bei FHE wird das Ergebnis verschlüsselt an den Client übermittelt. Der Client entschlüsselt es dann, um die tatsächliche Vorhersage zu erhalten. Wenn wir dieses Ergebnis On-Chain verwenden wollen, müsste der Client (oder wer auch immer den Entschlüsselungsschlüssel besitzt) das Klartext-Ergebnis veröffentlichen und andere davon überzeugen, dass es korrekt ist. Aber an diesem Punkt ist Vertrauen wieder im Spiel – es sei denn, es wird mit einem ZKP kombiniert. Im Prinzip könnte man FHE und ZKP kombinieren: z. B. FHE verwenden, um Daten während der Berechnung privat zu halten, und dann einen ZK-Beweis generieren, dass das Klartext-Ergebnis einer korrekten Berechnung entspricht. Die Kombination beider bedeutet jedoch, dass man die Leistungsstrafe von FHE und ZKP zahlt – extrem unpraktisch mit der heutigen Technologie. In der Praxis dienen FHE-of-ML und zkML also unterschiedlichen Anwendungsfällen:
- FHE-of-ML: Ideal, wenn das Ziel die Vertraulichkeit zwischen zwei Parteien (Client und Server) ist. Zum Beispiel kann ein Cloud-Dienst ein ML-Modell hosten, und Benutzer können es mit ihren sensiblen Daten abfragen, ohne die Daten der Cloud preiszugeben (und wenn das Modell sensibel ist, es vielleicht über FHE-freundliche Kodierungen bereitstellen). Dies ist großartig für datenschutzfreundliche ML-Dienste (medizinische Vorhersagen usw.). Der Benutzer muss dem Dienst immer noch vertrauen, dass er das Modell getreu ausführt (da kein Beweis vorliegt), aber zumindest wird jegliches Datenleck verhindert. Einige Projekte wie Zama erforschen sogar eine „FHE-fähige EVM (fhEVM)“, bei der Smart Contracts auf verschlüsselten Eingaben operieren könnten, aber die Verifizierung dieser Berechnungen On-Chain würde erfordern, dass der Vertrag die korrekte Berechnung irgendwie durchsetzt – eine offene Herausforderung, die wahrscheinlich ZK-Beweise oder spezialisierte sichere Hardware erfordert.
- zkML (ZKPs): Ideal, wenn das Ziel Verifizierbarkeit und öffentliche Auditierbarkeit ist. Wenn Sie sicherstellen möchten, dass „Modell $M$ korrekt auf $X$ evaluiert wurde und $Y$ erzeugte“, sind ZKPs die Lösung. Sie bieten auch Datenschutz als Bonus (Sie können $X$ oder $Y$ oder $M$ bei Bedarf verbergen, indem Sie sie als private Eingaben für den Beweis behandeln), aber ihr Hauptmerkmal ist der Beweis der korrekten Ausführung.
Eine komplementäre Beziehung: Es ist erwähnenswert, dass ZKPs den Verifizierer schützen (sie erfahren nichts über Geheimnisse, nur dass die Berechnung korrekt durchgeführt wurde), während FHE die Daten des Provers vor der rechnenden Partei schützt. In einigen Szenarien könnten diese kombiniert werden – zum Beispiel könnte ein Netzwerk nicht vertrauenswürdiger Knoten FHE verwenden, um auf den privaten Daten der Benutzer zu rechnen und dann ZK-Beweise an die Benutzer (oder Blockchain) liefern, dass die Berechnungen gemäß dem Protokoll durchgeführt wurden. Dies würde sowohl Datenschutz als auch Korrektheit abdecken, aber die Leistungskosten sind mit den heutigen Algorithmen enorm. Kurzfristig praktikabler sind Hybride wie Trusted Execution Environments (TEE) plus ZKP oder Funktionale Verschlüsselung plus ZKP – diese liegen außerhalb unseres Rahmens, zielen aber darauf ab, etwas Ähnliches zu bieten (TEEs halten Daten/Modell während der Berechnung geheim, dann kann ein ZKP bestätigen, dass das TEE das Richtige getan hat).
Zusammenfassend lässt sich sagen, dass FHE-of-ML die Vertraulichkeit von Eingaben/Ausgaben priorisiert, während zkML die verifizierbare Korrektheit (mit möglicher Privatsphäre) priorisiert. Tabelle 1 unten vergleicht die wichtigsten Eigenschaften:
| Ansatz | Prover-Leistung (Inferenz & Beweis) | Beweisgröße & Verifizierung | Datenschutzmerkmale | Trusted Setup? | Post-Quanten-sicher? |
|---|
| zk-SNARK (Halo2, Groth16, PLONK, etc) | Hoher Prover-Overhead (bis zu 10^6-fach der normalen Laufzeit ohne Optimierungen; in der Praxis 10^3–10^5-fach). Optimiert für spezifische Modelle/Schaltkreise; Proving-Zeit in Minuten für mittlere Modelle, Stunden für große. Neuere zkML-SNARKs (DeepProve mit GKR) verbessern dies erheblich (nahezu linearer Overhead, z. B. Sekunden statt Minuten für Modelle mit Millionen von Parametern). | Sehr kleine Beweise (oft < 100 KB, manchmal ~einige KB). Verifizierung ist schnell: wenige Pairings oder Polynom-Evaluierungen (typischerweise < 50 ms On-Chain). DeepProves GKR-basierte Beweise sind größer (Zehntausende–Hunderte von KB) und verifizieren in ~0,5 s (immer noch viel schneller als das erneute Ausführen des Modells). | Datenvertraulichkeit: Ja – Eingaben können im Beweis privat sein (nicht offengelegt). Modellschutz: Ja – Prover kann sich zu Modellgewichten committen und diese nicht offenlegen. Ausgabeverbergen: Optional – Beweis kann eine Aussage sein, ohne die Ausgabe preiszugeben (z. B. „Ausgabe hat Eigenschaft P“). Wenn die Ausgabe selbst jedoch On-Chain benötigt wird, wird sie typischerweise öffentlich. Insgesamt bieten SNARKs volle Zero-Knowledge-Flexibilität (verbergen Sie, welche Teile Sie möchten). | Abhängig vom Schema. Groth16/EZKL erfordern ein Trusted Setup pro Schaltkreis; PLONK/Halo2 verwenden ein universelles Setup (einmalig). DeepProves Sum-Check GKR ist transparent (kein Setup) – ein Bonus dieses Designs. | Klassische SNARKs (BLS12-381-Kurven) sind nicht PQ-sicher (anfällig für Quantenangriffe auf den elliptischen Kurven-Diskreten Logarithmus). Einige neuere SNARKs verwenden PQ-sichere Commitments, aber Halo2/PLONK, wie in Ezkl verwendet, sind nicht PQ-sicher. GKR (DeepProve) verwendet Hash-Commitments (z. B. Poseidon/Merkle), die als PQ-sicher vermutet werden (basierend auf der Hash-Preimage-Resistenz). |
| zk-STARK (FRI, Hash-basierter Beweis) | Prover-Overhead ist hoch, aber die Skalierung ist linearer. Typischerweise 10^2–10^4-mal langsamer als nativ für große Aufgaben, mit Raum zur Parallelisierung. Allgemeine STARK-VMs (Risc0, Cairo) zeigten 2024 eine langsamere Leistung im Vergleich zu SNARK für ML (z. B. 3- bis 66-mal langsamer als Halo2 in einigen Fällen). Spezialisierte STARKs (oder GKR) können einen linearen Overhead erreichen und SNARKs für große Schaltkreise übertreffen. | Beweise sind größer: oft Zehntausende von KB (wachsend mit Schaltkreisgröße/log(n)). Verifizierer muss mehrere Hash- und FFT-Prüfungen durchführen – Verifizierungszeit ~O(n^ε) für kleines ε (z. B. ~50 ms bis 500 ms je nach Beweisgröße). On-Chain ist dies kostspieliger (StarkWares L1-Verifizierer kann Millionen von Gas pro Beweis verbrauchen). Einige STARKs unterstützen rekursive Beweise zur Komprimierung der Größe, auf Kosten der Prover-Zeit. | Daten- & Modellschutz: Ein STARK kann Zero-Knowledge gemacht werden, indem Trace-Daten randomisiert werden (Hinzufügen von Blinding zu Polynom-Evaluierungen), sodass er private Eingaben ähnlich wie SNARK verbergen kann. Viele STARK-Implementierungen konzentrieren sich auf Integrität, aber zk-STARK-Varianten ermöglichen Datenschutz. Ja, sie können Eingaben/Modelle wie SNARKs verbergen. Ausgabeverbergen: theoretisch ebenfalls möglich (Prover deklariert die Ausgabe nicht als öffentlich), aber selten verwendet, da die Ausgabe normalerweise das ist, was wir offenlegen/verifizieren wollen. | Kein Trusted Setup. Transparenz ist ein Kennzeichen von STARKs – erfordert nur eine gemeinsame Zufallszeichenfolge (die Fiat-Shamir ableiten kann). Dies macht sie attraktiv für den offenen Einsatz (jedes Modell, jederzeit, keine Zeremonie pro Modell). | Ja, STARKs basieren auf Hash- und informationstheoretischen Sicherheitsannahmen (wie Random Oracle und der Schwierigkeit bestimmter Codewort-Dekodierungen in FRI). Diese gelten als sicher gegen Quantengegner. STARK-Beweise sind somit PQ-resistent, ein Vorteil für die Zukunftssicherheit verifizierbarer KI. |
| FHE für ML (Vollständig Homomorphe Verschlüsselung angewendet auf Inferenz) | Prover = Partei, die Berechnungen auf verschlüsselten Daten durchführt. Die Berechnungszeit ist extrem hoch: 10^3–10^5-mal langsamer als Klartext-Inferenz ist üblich. High-End-Hardware (Multi-Core-Server, FPGA usw.) kann dies mildern. Einige Optimierungen (Inferenz mit geringer Präzision, gestufte FHE-Parameter) können den Overhead reduzieren, aber es gibt einen grundlegenden Leistungseinbruch. FHE ist derzeit praktisch für kleine Modelle oder einfache lineare Modelle; tiefe Netzwerke bleiben über Spielzeuggrößen hinaus eine Herausforderung. | Kein Beweis generiert. Das Ergebnis ist eine verschlüsselte Ausgabe. Verifizierung im Sinne der Korrektheitsprüfung wird von FHE allein nicht bereitgestellt – man vertraut der rechnenden Partei, nicht zu betrügen. (Wenn mit sicherer Hardware kombiniert, könnte man eine Bestätigung erhalten; andernfalls könnte ein bösartiger Server ein falsches verschlüsseltes Ergebnis zurückgeben, das der Client zu einer falschen Ausgabe entschlüsseln würde, ohne den Unterschied zu kennen). | Datenvertraulichkeit: Ja – die Eingabe ist verschlüsselt, sodass die rechnende Partei nichts darüber erfährt. Modellschutz: Wenn der Modelleigentümer die Berechnung auf verschlüsselten Eingaben durchführt, ist das Modell auf seiner Seite im Klartext (nicht geschützt). Wenn die Rollen vertauscht sind (Client hält Modell verschlüsselt und Server rechnet), könnte das Modell verschlüsselt bleiben, aber dieses Szenario ist weniger verbreitet. Es gibt Techniken wie sicheres Zwei-Parteien-ML, die FHE/MPC kombinieren, um beides zu schützen, aber diese gehen über reines FHE hinaus. Ausgabeverbergen: Standardmäßig ist die Ausgabe der Berechnung verschlüsselt (nur entschlüsselbar durch die Partei mit dem geheimen Schlüssel, normalerweise den Eingabeinhaber). Die Ausgabe ist also vor dem rechnenden Server verborgen. Wenn wir die Ausgabe öffentlich machen wollen, kann der Client sie entschlüsseln und offenlegen. | Kein Setup erforderlich. Jeder Benutzer generiert sein eigenes Schlüsselpaar für die Verschlüsselung. Vertrauen basiert darauf, dass die Schlüssel geheim bleiben. | Die Sicherheit von FHE-Schemata (z. B. BFV, CKKS, TFHE) basiert auf Gitterproblemen (Learning With Errors), die als resistent gegen Quantenangriffe gelten (zumindest ist kein effizienter Quantenalgorithmus bekannt). FHE wird daher im Allgemeinen als post-quantensicher angesehen. |
Tabelle 1: Vergleich von zk-SNARK-, zk-STARK- und FHE-Ansätzen für maschinelles Lernen (Leistungs- und Datenschutzkompromisse).
Anwendungsfälle und Implikationen für Web3-Anwendungen
Die Konvergenz von KI und Blockchain über zkML erschließt leistungsstarke neue Anwendungsmuster in Web3:
-
Dezentrale autonome Agenten & On-Chain-Entscheidungsfindung: Smart Contracts oder DAOs können KI-gesteuerte Entscheidungen mit Korrektheitsgarantien integrieren. Stellen Sie sich zum Beispiel eine DAO vor, die ein neuronales Netzwerk verwendet, um Marktbedingungen zu analysieren, bevor sie Trades ausführt. Mit zkML kann der Smart Contract der DAO einen zkSNARK-Beweis verlangen, dass das autorisierte ML-Modell (mit einem bekannten Hash-Commitment) auf den neuesten Daten ausgeführt wurde und die empfohlene Aktion erzeugte, bevor die Aktion akzeptiert wird. Dies verhindert, dass böswillige Akteure eine gefälschte Vorhersage einschleusen – die Kette verifiziert die KI-Berechnung. Im Laufe der Zeit könnten sogar vollständig On-Chain autonome Agenten (Contracts, die Off-Chain-KI abfragen oder vereinfachte Modelle enthalten) Entscheidungen in DeFi oder Spielen treffen, wobei alle ihre Schritte über zk-Beweise als korrekt und richtlinienkonform nachgewiesen werden. Dies erhöht das Vertrauen in autonome Agenten, da ihr „Denken“ transparent und verifizierbar ist und nicht als Black-Box fungiert.
-
Verifizierbare Computemärkte: Projekte wie Lagrange schaffen effektiv verifizierbare Berechnungsmarktplätze – Entwickler können aufwendige ML-Inferenzen an ein Netzwerk von Provern auslagern und erhalten einen Beweis mit dem Ergebnis zurück. Dies ist vergleichbar mit dezentralem Cloud Computing, aber mit integriertem Vertrauen: Sie müssen dem Server nicht vertrauen, nur dem Beweis. Es ist ein Paradigmenwechsel für Orakel und Off-Chain-Berechnungen. Protokolle wie Ethereums kommender DSC (dezentraler Sequencing Layer) oder Orakelnetzwerke könnten dies nutzen, um Daten-Feeds oder Analyse-Feeds mit kryptografischen Garantien bereitzustellen. Zum Beispiel könnte ein Orakel „das Ergebnis von Modell X auf Eingabe Y“ liefern, und jeder kann den beigefügten Beweis On-Chain verifizieren, anstatt dem Wort des Orakels zu vertrauen. Dies könnte verifizierbare KI-as-a-Service auf der Blockchain ermöglichen: Jeder Vertrag kann eine Berechnung anfordern (wie „bewerten Sie diese Kreditrisiken mit meinem privaten Modell“) und die Antwort nur mit einem gültigen Beweis akzeptieren. Projekte wie Gensyn erforschen dezentrale Trainings- und Inferenzmarktplätze unter Verwendung dieser Verifizierungstechniken.
-
NFTs und Gaming – Provenienz und Evolution: In Blockchain-Spielen oder NFT-Sammlerstücken kann zkML beweisen, dass Merkmale oder Spielzüge von legitimen KI-Modellen generiert wurden. Zum Beispiel könnte ein Spiel einer KI erlauben, die Attribute eines NFT-Haustiers zu entwickeln. Ohne ZK könnte ein cleverer Benutzer die KI oder das Ergebnis manipulieren, um ein überlegenes Haustier zu erhalten. Mit zkML kann das Spiel einen Beweis verlangen, dass „die neuen Werte des Haustiers vom offiziellen Evolutionsmodell auf den alten Werten des Haustiers berechnet wurden“, wodurch Betrug verhindert wird. Ähnlich bei generativen Kunst-NFTs: Ein Künstler könnte ein generatives Modell als Commitment veröffentlichen; später, beim Minten von NFTs, beweisen, dass jedes Bild von diesem Modell mit einem bestimmten Seed erzeugt wurde, wodurch die Authentizität garantiert wird (und dies sogar, ohne das genaue Modell der Öffentlichkeit preiszugeben, wodurch das geistige Eigentum des Künstlers geschützt wird). Diese Provenienzverifizierung gewährleistet Authentizität auf eine Weise, die der verifizierbaren Zufälligkeit ähnelt – nur hier ist es verifizierbare Kreativität.
-
Datenschutzfreundliche KI in sensiblen Bereichen: zkML ermöglicht die Bestätigung von Ergebnissen, ohne Eingaben preiszugeben. Im Gesundheitswesen könnten Patientendaten von einem Cloud-Anbieter durch ein KI-Diagnosemodell laufen; das Krankenhaus erhält eine Diagnose und einen Beweis, dass das Modell (das privat von einem Pharmaunternehmen gehalten werden könnte) korrekt auf den Patientendaten ausgeführt wurde. Die Patientendaten bleiben privat (nur eine verschlüsselte oder committed Form wurde im Beweis verwendet), und die Modellgewichte bleiben proprietär – dennoch ist das Ergebnis vertrauenswürdig. Regulierungsbehörden oder Versicherungen könnten auch überprüfen, dass nur genehmigte Modelle verwendet wurden. Im Finanzwesen könnte ein Unternehmen einem Auditor oder einer Regulierungsbehörde beweisen, dass sein Risikomodell auf seine internen Daten angewendet wurde und bestimmte Metriken erzeugte, ohne die zugrunde liegenden sensiblen Finanzdaten preiszugeben. Dies ermöglicht Compliance und Aufsicht mit kryptografischen Zusicherungen anstelle von manuellem Vertrauen.
-
Cross-Chain- und Off-Chain-Interoperabilität: Da Zero-Knowledge-Beweise grundsätzlich portabel sind, kann zkML Cross-Chain-KI-Ergebnisse erleichtern. Eine Kette könnte eine KI-intensive Anwendung Off-Chain ausführen; sie kann einen Beweis des Ergebnisses an eine andere Blockchain senden, die ihn vertrauenslos akzeptiert. Betrachten Sie zum Beispiel eine Multi-Chain-DAO, die eine KI verwendet, um Stimmungen in sozialen Medien zu aggregieren (Off-Chain-Daten). Die KI-Analyse (komplexes NLP auf großen Datenmengen) wird Off-Chain von einem Dienst durchgeführt, der dann einen Beweis an eine kleine Blockchain (oder mehrere Chains) sendet, dass „die Analyse korrekt durchgeführt wurde und der Stimmungs-Score = 0,85 ergab“. Alle Chains können dieses Ergebnis in ihrer Governance-Logik verifizieren und verwenden, ohne dass jede die Analyse erneut durchführen muss. Diese Art der interoperablen verifizierbaren Berechnung ist das, was Lagranges Netzwerk unterstützen will, indem es mehrere Rollups oder L1s gleichzeitig bedient. Es beseitigt die Notwendigkeit von Trusted Bridges oder Orakel-Annahmen beim Verschieben von Ergebnissen zwischen Chains.
-
KI-Ausrichtung und Governance: Aus einer zukunftsorientierteren Perspektive wurde zkML als Werkzeug für KI-Governance und -Sicherheit hervorgehoben. Lagranges Vision Statements argumentieren beispielsweise, dass mit zunehmender Leistungsfähigkeit von KI-Systemen (sogar superintelligenten) kryptografische Verifizierung unerlässlich sein wird, um sicherzustellen, dass sie vereinbarten Regeln folgen. Indem KI-Modelle Beweise für ihre Argumentation oder Constraints erbringen müssen, behalten Menschen ein gewisses Maß an Kontrolle – „man kann nicht vertrauen, was man nicht verifizieren kann“. Obwohl dies spekulativ ist und sowohl soziale als auch technische Aspekte umfasst, könnte die Technologie durchsetzen, dass ein autonom agierender KI-Agent immer noch beweist, dass er ein genehmigtes Modell verwendet und nicht manipuliert wurde. Dezentrale KI-Netzwerke könnten On-Chain-Beweise verwenden, um Beiträge zu verifizieren (z. B. kann ein Netzwerk von Knoten, die gemeinsam ein Modell trainieren, beweisen, dass jedes Update getreu berechnet wurde). Somit könnte zkML eine Rolle dabei spielen, sicherzustellen, dass KI-Systeme gegenüber menschlich definierten Protokollen rechenschaftspflichtig bleiben, selbst in dezentralen oder unkontrollierten Umgebungen.
Zusammenfassend lässt sich sagen, dass zkML und verifizierbare On-Chain-KI eine Konvergenz von fortschrittlicher Kryptografie und maschinellem Lernen darstellen, die das Vertrauen, die Transparenz und den Datenschutz in KI-Anwendungen verbessern wird. Durch den Vergleich der wichtigsten Ansätze – zk-SNARKs, zk-STARKs und FHE – sehen wir ein Spektrum von Kompromissen zwischen Leistung und Datenschutz, die jeweils für unterschiedliche Szenarien geeignet sind. SNARK-basierte Frameworks wie Ezkl und Innovationen wie Lagranges DeepProve haben es ermöglicht, substanzielle neuronale Netzwerk-Inferenzen mit praktischem Aufwand zu beweisen, was die Tür für reale Implementierungen verifizierbarer KI öffnet. STARK-basierte und VM-basierte Ansätze versprechen größere Flexibilität und Post-Quanten-Sicherheit, was mit der Reifung des Feldes wichtig werden wird. FHE, obwohl keine Lösung für die Verifizierbarkeit, adressiert den komplementären Bedarf an vertraulicher ML-Berechnung und kann in Kombination mit ZKPs oder in spezifischen privaten Kontexten Benutzer befähigen, KI zu nutzen, ohne den Datenschutz zu opfern.
Die Implikationen für Web3 sind erheblich: Wir können Smart Contracts erwarten, die auf KI-Vorhersagen reagieren, wissend, dass diese korrekt sind; Märkte für Berechnungen, auf denen Ergebnisse vertrauenslos verkauft werden; digitale Identitäten (wie Worldcoins Proof-of-Personhood über Iris-KI), die durch zkML geschützt sind, um zu bestätigen, dass jemand ein Mensch ist, ohne sein biometrisches Bild preiszugeben; und generell eine neue Klasse von „nachweisbarer Intelligenz“, die Blockchain-Anwendungen bereichert. Viele Herausforderungen bleiben bestehen – Leistung für sehr große Modelle, Entwicklerergonomie und der Bedarf an spezialisierter Hardware –, aber die Richtung ist klar. Wie ein Bericht feststellte, „können die heutigen ZKPs kleine Modelle unterstützen, aber mittlere bis große Modelle sprengen das Paradigma“; jedoch verschieben schnelle Fortschritte (50- bis 150-fache Beschleunigungen mit DeepProve gegenüber dem Stand der Technik) diese Grenze nach außen. Mit fortlaufender Forschung (z. B. zur Hardwarebeschleunigung und verteilten Beweiserstellung) können wir erwarten, dass zunehmend größere und komplexere KI-Modelle beweisbar werden. zkML könnte sich bald von Nischen-Demos zu einer wesentlichen Komponente vertrauenswürdiger KI-Infrastruktur entwickeln und sicherstellen, dass KI, wenn sie allgegenwärtig wird, dies auf eine Weise tut, die prüfbar, dezentralisiert und auf den Datenschutz und die Sicherheit der Benutzer ausgerichtet ist.
