3 Beiträge getaggt mit „cryptographic proofs“

Jedes Mal, wenn Sie ChatGPT, Claude oder Gemini abfragen, vertrauen Sie einer unsichtbaren Blackbox. Die Modellversion? Unbekannt. Die genauen Gewichte? Proprietär. Ob die Ausgabe von dem Modell generiert wurde, von dem Sie glauben, dass Sie es verwenden, oder von einer im Stillen aktualisierten Variante? Unmöglich zu verifizieren. Für Gelegenheitsnutzer, die nach Rezepten oder Trivia fragen, ist diese Intransparenz lediglich ärgerlich. Für kritische KI-Entscheidungen – wie Finanzhandelsalgorithmen, medizinische Diagnosen oder rechtliche Vertragsanalysen – ist sie eine fundamentale Vertrauenskrise.

Gensyn's Judge, der Ende 2025 eingeführt wurde und 2026 in die Produktion geht, bietet eine radikale Alternative: kryptografisch verifizierbare KI-Evaluierung, bei der jede Inferenz bis auf das Bit genau reproduzierbar ist. Anstatt OpenAI oder Anthropic zu vertrauen, das korrekte Modell bereitzustellen, ermöglicht Judge es jedem zu verifizieren, dass ein spezifisches, zuvor vereinbartes KI-Modell deterministisch mit realen Eingabedaten ausgeführt wurde – wobei kryptografische Beweise sicherstellen, dass die Ergebnisse nicht gefälscht werden können.

Der technische Durchbruch ist Verde, das Verifizierungssystem von Gensyn, das den Fließkomma-Nondeterminismus eliminiert – den Fluch der KI-Reproduzierbarkeit. Durch die Durchsetzung bitgenauer Berechnungen über verschiedene Geräte hinweg stellt Verde sicher, dass die Ausführung desselben Modells auf einer NVIDIA A100 in London und einer AMD MI250 in Tokio identische Ergebnisse liefert, die on-chain nachweisbar sind. Dies erschließt verifizierbare KI für dezentrale Finanzen, autonome Agenten und jede Anwendung, bei der Transparenz nicht optional, sondern existenziell ist.

Das Problem undurchsichtiger APIs: Vertrauen ohne Verifizierung​

Die KI-Branche basiert auf APIs. Entwickler integrieren GPT-4 von OpenAI, Claude von Anthropic oder Gemini von Google über REST-Endpunkte, senden Prompts und erhalten Antworten. Aber diese APIs sind von Grund auf undurchsichtig:

Versionsunsicherheit: Wenn Sie gpt-4 aufrufen, welche genaue Version erhalte ich? GPT-4-0314? GPT-4-0613? Eine im Stillen aktualisierte Variante? Anbieter spielen häufig Patches ohne öffentliche Ankündigung ein und ändern so das Modellverhalten über Nacht.

Kein Audit-Trail: API-Antworten enthalten keinen kryptografischen Beweis dafür, welches Modell sie generiert hat. Wenn OpenAI eine zensierte oder voreingenommene Variante für bestimmte Regionen oder Kunden bereitstellt, haben die Nutzer keine Möglichkeit, dies zu erkennen.

Stille Degradierung: Anbieter können Modelle „lobotomieren“, um Kosten zu senken – also die Inferenzqualität verringern, während der gleiche API-Vertrag beibehalten wird. Nutzer berichten, dass GPT-4 mit der Zeit „dümmere“ Antworten gibt, aber ohne transparente Versionierung bleiben solche Behauptungen rein anekdotisch.

Nondeterministische Ausgaben: Sogar die zweimalige Abfrage desselben Modells mit identischen Eingaben kann aufgrund von Temperatureinstellungen, Batching oder Fließkomma-Rundungsfehlern auf Hardwareebene unterschiedliche Ergebnisse liefern. Dies macht Audits unmöglich – wie verifiziert man die Korrektheit, wenn die Ausgaben nicht reproduzierbar sind?

Für alltägliche Anwendungen sind diese Probleme Unannehmlichkeiten. Für kritische Entscheidungen sind sie Hindernisse. Betrachten Sie:

Algorithmischer Handel: Ein Hedgefonds setzt einen KI-Agenten ein, der DeFi-Positionen im Wert von 50 Millionen $ verwaltet. Der Agent verlässt sich auf GPT-4, um die Marktstimmung aus X-Posts zu analysieren. Wenn das Modell während einer Handelssitzung im Stillen aktualisiert wird, verschieben sich die Sentiment-Scores unvorhersehbar – was unbeabsichtigte Liquidationen auslöst. Der Fonds hat keinen Beweis dafür, dass sich das Modell falsch verhalten hat; die Protokolle von OpenAI sind nicht öffentlich prüfbar.

Medizinische Diagnostik: Ein Krankenhaus nutzt ein KI-Modell, um Krebsbehandlungen zu empfehlen. Vorschriften verlangen, dass Ärzte die Entscheidungsprozesse dokumentieren. Wenn die Version des KI-Modells jedoch nicht verifiziert werden kann, ist der Audit-Trail unvollständig. Ein Kunstfehlerprozess könnte davon abhängen, zu beweisen, welches Modell die Empfehlung generiert hat – was mit undurchsichtigen APIs unmöglich ist.

DAO-Governance: Eine dezentrale Organisation nutzt einen KI-Agenten, um über Schatzkammer-Vorschläge abzustimmen. Community-Mitglieder fordern den Beweis, dass der Agent das genehmigte Modell verwendet hat – und nicht eine manipulierte Variante, die bestimmte Ergebnisse begünstigt. Ohne kryptografische Verifizierung fehlt der Abstimmung die Legitimität.

Dies ist die Vertrauenslücke, die Gensyn adressiert: Da KI zunehmend in kritische Entscheidungsprozesse eingebettet wird, wird die Unfähigkeit, die Authentizität und das Verhalten von Modellen zu verifizieren, zu einem „fundamentalen Hindernis für den Einsatz agiler KI in risikoreichen Umgebungen“.

Judge: Das Protokoll für verifizierbare KI-Evaluierung​

Judge löst das Transparenzproblem, indem es zuvor vereinbarte, deterministische KI-Modelle mit realen Eingabedaten ausführt und die Ergebnisse auf einer Blockchain festschreibt, wo jeder sie anfechten kann. So funktioniert das Protokoll:

1. Modell-Commitment: Die Teilnehmer einigen sich auf ein KI-Modell – seine Architektur, Gewichte und Inferenzkonfiguration. Dieses Modell wird gehasht und on-chain hinterlegt. Der Hash dient als kryptografischer Fingerabdruck: Jede Abweichung vom vereinbarten Modell erzeugt einen anderen Hash.

2. Deterministische Ausführung: Judge führt das Modell mit der Gensyn Reproducible Runtime aus, die eine bitgenaue Reproduzierbarkeit über verschiedene Geräte hinweg garantiert. Dies eliminiert den Fließkomma-Nondeterminismus – eine entscheidende Innovation, die wir gleich näher beleuchten.

3. Öffentliches Commitment: Nach der Inferenz postet Judge das Ergebnis (oder einen Hash davon) on-chain. Dies schafft einen dauerhaften, prüfbaren Datensatz darüber, was das Modell für eine bestimmte Eingabe produziert hat.

4. Challenge-Phase: Jeder kann das Ergebnis anfechten, indem er das Modell unabhängig erneut ausführt. Wenn das Ergebnis abweicht, reicht er einen Betrugsbeweis (Fraud Proof) ein. Der Refereed Delegation Mechanism von Verde lokalisiert den exakten Operator im Berechnungsgraphen, an dem die Ergebnisse divergieren.

5. Slashing bei Betrug: Wenn ein Challenger beweist, dass Judge falsche Ergebnisse geliefert hat, wird der ursprüngliche Ausführer bestraft (Slashing der gestakten Token). Dies gleicht die wirtschaftlichen Anreize an: Die Ausführer maximieren ihren Gewinn, indem sie die Modelle korrekt ausführen.

Judge transformiert die KI-Evaluierung von „Vertrauen in den API-Anbieter“ hin zu „Verifizierung des kryptografischen Beweises“. Das Verhalten des Modells ist öffentlich, prüfbar und durchsetzbar – nicht länger verborgen hinter proprietären Endpunkten.

Verde: Eliminierung des Gleitkomma-Nondeterminismus​

Die zentrale technische Herausforderung bei verifizierbarer KI ist der Determinismus. Neuronale Netze führen während der Inferenz Milliarden von Gleitkommaoperationen durch. Auf modernen GPUs sind diese Operationen nicht perfekt reproduzierbar:

Nicht-Assoziativität: Die Gleitkomma-Addition ist nicht assoziativ. ( a + b ) + c könnte aufgrund von Rundungsfehlern ein anderes Ergebnis liefern als a + ( b + c ). GPUs parallelisieren Summen über Tausende von Kernen, und die Reihenfolge, in der Teilsummen akkumuliert werden, variiert je nach Hardware und Treiberversion.

Variabilität beim Kernel-Scheduling: GPU-Kernel (wie Matrixmultiplikation oder Attention) können je nach Arbeitslast, Treiberoptimierungen oder Hardwarearchitektur in unterschiedlichen Reihenfolgen ausgeführt werden. Selbst wenn man dasselbe Modell zweimal auf derselben GPU ausführt, kann dies zu unterschiedlichen Ergebnissen führen, wenn das Kernel-Scheduling variiert.

Batch-Größen-Abhängigkeit: Untersuchungen haben ergeben, dass LLM-Inferenz auf Systemebene nondeterministisch ist, da die Ausgabe von der Batch-Größe abhängt. Viele Kernel (Matmul, RMSNorm, Attention) ändern die numerische Ausgabe basierend darauf, wie viele Samples zusammen verarbeitet werden – eine Inferenz mit Batch-Größe 1 liefert andere Werte als dieselbe Eingabe in einem Batch von 8.

Diese Probleme machen Standard-KI-Modelle für die Blockchain-Verifizierung ungeeignet. Wenn zwei Validatoren dieselbe Inferenz erneut ausführen und leicht unterschiedliche Ergebnisse erhalten, wer hat dann recht? Ohne Determinismus ist ein Konsens unmöglich.

Verde löst dies mit RepOps (Reproducible Operators) – einer Bibliothek, die Hardware-Nondeterminismus eliminiert, indem sie die Reihenfolge der Gleitkommaoperationen auf allen Geräten kontrolliert. So funktioniert es:

Kanonische Reduktionsreihenfolgen: RepOps erzwingt eine deterministische Reihenfolge für das Summieren von Teilergebnissen in Operationen wie der Matrixmultiplikation. Anstatt den GPU-Scheduler entscheiden zu lassen, legt RepOps explizit fest: „Summiere Spalte 0, dann Spalte 1, dann Spalte 2...“ über alle Hardware hinweg. Dies stellt sicher, dass ( a + b ) + c immer in derselben Sequenz berechnet wird.

Benutzerdefinierte CUDA-Kernel: Gensyn hat optimierte Kernel entwickelt, die Reproduzierbarkeit vor reine Geschwindigkeit stellen. RepOps-Matrixmultiplikationen verursachen weniger als 30 % Overhead im Vergleich zum Standard-cuBLAS – ein akzeptabler Kompromiss für Determinismus.

Treiber- und Versions-Pinning: Verde verwendet versionsgebundene GPU-Treiber und kanonische Konfigurationen, um sicherzustellen, dass dasselbe Modell auf unterschiedlicher Hardware identische bitweise Ausgaben liefert. Ein Modell, das auf einer NVIDIA A100 in einem Rechenzentrum läuft, entspricht Bit für Bit der Ausgabe einer AMD MI250 in einem anderen.

Dies ist der Durchbruch, der die Verifizierung durch Judge ermöglicht: Bitgenaue Reproduzierbarkeit bedeutet, dass Validatoren Ergebnisse unabhängig bestätigen können, ohne den Executoren vertrauen zu müssen. Wenn der Hash übereinstimmt, ist die Inferenz korrekt – mathematisch beweisbar.

Refereed Delegation: Effiziente Verifizierung ohne vollständige Neuberechnung​

Selbst bei deterministischer Ausführung ist die naive Verifizierung von KI-Inferenzen teuer. Ein Modell mit 70 Milliarden Parametern, das 1.000 Token generiert, könnte 10 GPU-Stunden erfordern. Wenn Validatoren jede Inferenz erneut ausführen müssen, um die Korrektheit zu prüfen, entsprechen die Verifizierungskosten den Ausführungskosten – was den Zweck der Dezentralisierung zunichtemacht.

Verdes Refereed-Delegation-Mechanismus macht die Verifizierung exponentiell günstiger:

Mehrere nicht vertrauenswürdige Executoren: Anstelle eines Executors weist Judge Aufgaben mehreren unabhängigen Anbietern zu. Jeder führt dieselbe Inferenz aus und reicht die Ergebnisse ein.

Unstimmigkeiten lösen Untersuchungen aus: Wenn sich alle Executoren einig sind, wird das Ergebnis akzeptiert – keine weitere Verifizierung erforderlich. Wenn die Ergebnisse voneinander abweichen, leitet Verde ein Challenge-Game ein.

Binäre Suche über den Berechnungsgraphen: Verde führt nicht die gesamte Inferenz erneut aus. Stattdessen wird eine binäre Suche über den Berechnungsgraphen des Modells durchgeführt, um den ersten Operator zu finden, bei dem die Ergebnisse divergieren. Dies lokalisiert genau die Ebene (z. B. „Attention Layer 47, Head 8“), die die Diskrepanz verursacht.

Minimale Referee-Berechnung: Ein Referee (der ein Smart Contract oder ein Validator mit begrenzter Rechenleistung sein kann) prüft nur den umstrittenen Operator – nicht den gesamten Forward-Pass. Für ein Modell mit 70 Mrd. Parametern und 80 Layern reduziert dies die Verifizierung im schlimmsten Fall auf die Prüfung von etwa 7 Layern ( log₂ 80 ).

Dieser Ansatz ist über 1.350 % effizienter als die naive Replikation (bei der jeder Validator alles erneut ausführt). Gensyn kombiniert kryptografische Beweise, Spieltheorie und optimierte Prozesse, um eine korrekte Ausführung ohne redundante Berechnungen zu garantieren.

Das Ergebnis: Judge kann KI-Workloads in großem Maßstab verifizieren und ermöglicht dezentrale Inferenznetzwerke, in denen Tausende von nicht vertrauenswürdigen Knoten Rechenleistung beisteuern – und unehrliche Executoren entlarvt und bestraft werden.

KI-Entscheidungsfindung mit hohem Einsatz: Warum Transparenz wichtig ist​

Der Zielmarkt von Judge sind keine Gelegenheits-Chatbots – es sind Anwendungen, bei denen Verifizierbarkeit nicht nur ein nettes Feature, sondern eine regulatorische oder wirtschaftliche Anforderung ist. Hier sind Szenarien, in denen undurchsichtige APIs katastrophal scheitern:

Dezentrales Finanzwesen (DeFi): Autonome Trading-Agenten verwalten Milliarden an Vermögenswerten. Wenn ein Agent ein KI-Modell nutzt, um über die Neuausrichtung von Portfolios zu entscheiden, benötigen Nutzer den Beweis, dass das Modell nicht manipuliert wurde. Judge ermöglicht die On-Chain-Verifizierung: Der Agent legt sich auf einen spezifischen Modell-Hash fest, führt Trades basierend auf dessen Ausgaben aus, und jeder kann die Entscheidungslogik anfechten. Diese Transparenz verhindert Rug Pulls, bei denen böswillige Agenten ohne Beweise behaupten, „die KI habe mir gesagt, ich solle liquidieren“.

Einhaltung regulatorischer Vorschriften (Compliance): Finanzinstitute, die KI für Kredit-Scoring, Betrugserkennung oder Geldwäscheprävention (AML) einsetzen, müssen Audits durchlaufen. Regulatoren verlangen Erklärungen: „Warum hat das Modell diese Transaktion markiert?“ Undurchsichtige APIs bieten keinen Audit-Trail. Judge erstellt eine unveränderliche Aufzeichnung von Modellversion, Eingaben und Ausgaben – und erfüllt so die Compliance-Anforderungen.

Algorithmische Governance: Dezentrale Autonome Organisationen (DAOs) nutzen KI-Agenten, um Governance-Entscheidungen vorzuschlagen oder darüber abzustimmen. Community-Mitglieder müssen verifizieren können, dass der Agent das genehmigte Modell verwendet hat – und keine manipulierte Variante. Mit Judge kodiert die DAO den Modell-Hash in ihrem Smart Contract, und jede Entscheidung enthält einen kryptografischen Korrektheitsbeweis.

Medizinische und rechtliche KI: Gesundheits- und Rechtssysteme erfordern Rechenschaftspflicht. Ein Arzt, der Krebs mithilfe von KI diagnostiziert, muss die exakte verwendete Modellversion dokumentieren. Ein Anwalt, der Verträge mit KI entwirft, muss beweisen können, dass die Ausgabe von einem geprüften, unvoreingenommenen Modell stammt. Der On-Chain-Audit-Trail von Judge liefert diesen Beweis.

Prognosemärkte und Orakel: Projekte wie Polymarket nutzen KI, um Wettergebnisse zu klären (z. B. „Wird dieses Ereignis eintreten?“). Wenn die Klärung von einem KI-Modell abhängt, das Nachrichtenartikel analysiert, benötigen die Teilnehmer den Beweis, dass das Modell nicht manipuliert wurde. Judge verifiziert die KI-Inferenz des Orakels und verhindert so Streitigkeiten.

In jedem dieser Fälle ist der gemeinsame Nenner, dass Vertrauen ohne Transparenz unzureichend ist. Wie VeritasChain anmerkt, benötigen KI-Systeme „kryptografische Flugschreiber“ – unveränderliche Protokolle, die beweisen, was passiert ist, wenn Streitigkeiten auftreten.

Die Zero-Knowledge-Proof-Alternative: Vergleich zwischen Verde und ZKML​

Judge ist nicht der einzige Ansatz für verifizierbare KI. Zero-Knowledge Machine Learning (ZKML) erreicht ähnliche Ziele mittels zk-SNARKs: kryptografische Beweise, dass eine Berechnung korrekt durchgeführt wurde, ohne Eingaben oder Gewichtungen offenzulegen.

Wie schneidet Verde im Vergleich zu ZKML ab?

Verifizierungskosten: ZKML erfordert etwa 1.000× mehr Rechenaufwand als die ursprüngliche Inferenz, um Beweise zu generieren (Forschungsschätzungen). Ein Modell mit 70 Milliarden Parametern, das 10 GPU-Stunden für die Inferenz benötigt, könnte 10.000 GPU-Stunden für den Beweis erfordern. Die referenzierte Delegation von Verde ist logarithmisch: Die Überprüfung von ca. 7 Schichten anstelle von 80 entspricht einer 10-fachen Reduktion, nicht einer 1.000-fachen.

Prover-Komplexität: ZKML verlangt spezialisierte Hardware (wie maßgeschneiderte ASICs für zk-SNARK-Schaltkreise), um Beweise effizient zu erstellen. Verde funktioniert auf handelsüblichen GPUs – jeder Miner mit einem Gaming-PC kann teilnehmen.

Datenschutz-Abwägungen: Die Stärke von ZKML ist der Datenschutz – Beweise verraten nichts über Eingaben oder Modellgewichte. Die deterministische Ausführung von Verde ist transparent: Eingaben und Ausgaben sind öffentlich (obwohl Gewichte verschlüsselt werden können). Für weitreichende Entscheidungsfindungen ist Transparenz oft wünschenswert. Eine DAO, die über die Zuweisung von Treasury-Mitteln abstimmt, möchte öffentliche Audit-Trails, keine verborgenen Beweise.

Umfang der Beweisführung: ZKML ist praktisch auf die Inferenz beschränkt – der Nachweis des Trainings ist bei den aktuellen Rechenkosten nicht machbar. Verde unterstützt sowohl die Verifizierung von Inferenz als auch von Training (das umfassendere Protokoll von Gensyn verifiziert verteiltes Training).

Praxisnahe Einführung: ZKML-Projekte wie Modulus Labs haben Durchbrüche erzielt (Verifizierung von Modellen mit 18 Mio. Parametern auf der Chain), bleiben aber auf kleinere Modelle beschränkt. Die deterministische Runtime von Verde bewältigt Modelle mit mehr als 70 Mrd. Parametern in der Produktion.

ZKML glänzt dort, wo Datenschutz an oberster Stelle steht – etwa bei der Verifizierung biometrischer Authentifizierung (Worldcoin), ohne Iris-Scans preiszugeben. Verde glänzt dort, wo Transparenz das Ziel ist – der Nachweis, dass ein bestimmtes öffentliches Modell korrekt ausgeführt wurde. Beide Ansätze ergänzen sich und stehen nicht im Wettbewerb.

Das Gensyn-Ökosystem: Von Judge zum dezentralen Training​

Judge ist ein Bestandteil der umfassenderen Vision von Gensyn: ein dezentrales Netzwerk für Machine-Learning-Rechenleistung. Das Protokoll umfasst:

Execution Layer: Konsistente ML-Ausführung auf heterogener Hardware (Consumer-GPUs, Enterprise-Cluster, Edge-Geräte). Gensyn standardisiert Inferenz- und Trainings-Workloads und gewährleistet Kompatibilität.

Verification Layer (Verde): Vertrauenslose Verifizierung durch referenzierte Delegation. Unehrliche Ausführer werden erkannt und bestraft.

Peer-to-Peer-Kommunikation: Workload-Verteilung über Geräte hinweg ohne zentrale Koordination. Miner erhalten Aufgaben, führen sie aus und übermitteln Beweise direkt an die Blockchain.

Dezentrale Koordination: Smart Contracts auf einem Ethereum-Rollup identifizieren Teilnehmer, weisen Aufgaben zu und verarbeiten Zahlungen erlaubnisfrei.

Das öffentliche Testnetz von Gensyn startete im März 2025, das Mainnet ist für 2026 geplant. Der öffentliche Verkauf des $AI-Tokens fand im Dezember 2025 statt und schuf wirtschaftliche Anreize für Miner und Validatoren.

Judge fügt sich als Evaluierungsebene in dieses Ökosystem ein: Während das Kernprotokoll von Gensyn Training und Inferenz übernimmt, stellt Judge sicher, dass diese Ausgaben verifizierbar sind. Dies schafft einen Flywheel-Effekt:

Entwickler trainieren Modelle im dezentralen Netzwerk von Gensyn (günstiger als AWS aufgrund von nicht ausgelasteten Consumer-GPUs, die Rechenleistung beisteuern).

Modelle werden bereitgestellt, wobei Judge die Integrität der Evaluierung garantiert. Anwendungen nutzen Inferenz über die APIs von Gensyn, aber im Gegensatz zu OpenAI enthält jede Ausgabe einen kryptografischen Beweis.

Validatoren verdienen Gebühren, indem sie Beweise prüfen und Betrug aufdecken, wodurch wirtschaftliche Anreize mit der Netzwerksicherheit in Einklang gebracht werden.

Vertrauen skaliert, da immer mehr Anwendungen verifizierbare KI übernehmen und die Abhängigkeit von zentralisierten Anbietern verringern.

Das Endziel: KI-Training und -Inferenz, die nachweislich korrekt, dezentral und für jeden zugänglich sind – nicht nur für Big Tech.

Herausforderungen und offene Fragen​

Der Ansatz von Judge ist bahnbrechend, doch es bleiben einige Herausforderungen:

Performance-Overhead: Die Verlangsamung von RepOps um 30 % ist für die Verifizierung akzeptabel. Wenn jedoch jede Inferenz deterministisch laufen muss, könnten latenzkritische Anwendungen (Echtzeithandel, autonome Fahrzeuge) schnellere, nicht verifizierbare Alternativen bevorzugen. Die Roadmap von Gensyn sieht wahrscheinlich eine weitere Optimierung von RepOps vor – es gibt jedoch einen grundlegenden Kompromiss zwischen Geschwindigkeit und Determinismus.

Fragmentierung der Treiberversionen: Verde setzt auf festgeschriebene Treiberversionen, aber GPU-Hersteller veröffentlichen ständig Updates. Wenn einige Miner CUDA 12.4 und andere 12.5 verwenden, bricht die bitweise Reproduzierbarkeit zusammen. Gensyn muss ein striktes Versionsmanagement durchsetzen – was das Onboarding von Minern verkompliziert.

Geheimhaltung von Modellgewichten: Die Transparenz von Judge ist ein Vorteil für öffentliche Modelle, aber ein Nachteil für proprietäre. Wenn ein Hedgefonds ein wertvolles Handelsmodell trainiert, legt die Bereitstellung auf Judge die Gewichte gegenüber Konkurrenten offen (über das On-Chain-Commitment). ZKML-basierte Alternativen könnten für geheime Modelle bevorzugt werden – was darauf hindeutet, dass Judge auf offene oder halb-offene KI-Anwendungen abzielt.

Latenz bei der Streitbeilegung: Wenn ein Challenger Betrug behauptet, erfordert die Lösung des Streits via binärer Suche mehrere On-Chain-Transaktionen (jede Runde grenzt den Suchraum ein). Hochfrequenzanwendungen können nicht Stunden auf die Finalität warten. Gensyn könnte eine optimistische Verifizierung einführen (Korrektheit annehmen, sofern nicht innerhalb eines Zeitfensters angefochten), um die Latenz zu verringern.

Sybil-Resistenz in der referenzierten Delegation: Wenn mehrere Ausführer zustimmen müssen, was hindert eine einzelne Entität daran, alle Ausführer über Sybil-Identitäten zu kontrollieren? Gensyn nutzt wahrscheinlich eine Stake-gewichtete Auswahl (Validatoren mit hoher Reputation werden bevorzugt ausgewählt) sowie Slashing, um Absprachen abzuschrecken – die wirtschaftlichen Schwellenwerte müssen jedoch sorgfältig kalibriert werden.

Dies sind keine Ausschlusskriterien – es sind technische Herausforderungen. Die Kerninnovation (deterministische KI + kryptografische Verifizierung) ist solide. Die Details der Ausführung werden mit dem Übergang vom Testnet zum Mainnet ausreifen.

Der Weg zur verifizierbaren KI: Adaptionspfade und Marktpassung​

Der Erfolg von Judge hängt von der Adaption ab. Welche Anwendungen werden verifizierbare KI zuerst einsetzen?

DeFi-Protokolle mit autonomen Agenten: DAOs wie Aave, Compound oder Uniswap könnten durch Judge verifizierte Agenten für das Treasury-Management integrieren. Die Community stimmt über die Genehmigung eines Modell-Hashs ab, und alle Entscheidungen der Agenten enthalten Beweise. Diese Transparenz schafft Vertrauen – entscheidend für die Legitimität von DeFi.

Prognosemärkte und Orakel: Plattformen wie Polymarket oder Chainlink könnten Judge nutzen, um Wetten aufzulösen oder Preis-Feeds bereitzustellen. KI-Modelle, die Stimmungslagen, Nachrichten oder On-Chain-Aktivitäten analysieren, würden verifizierbare Ausgaben produzieren – was Streitigkeiten über Orakel-Manipulationen eliminiert.

Dezentrale Identität und KYC: Projekte, die eine KI-basierte Identitätsverifizierung erfordern (Altersschätzung anhand von Selfies, Echtheitsprüfungen von Dokumenten), profitieren vom Audit-Trail von Judge. Regulierungsbehörden akzeptieren kryptografische Compliance-Nachweise, ohne zentralen Identitätsanbietern vertrauen zu müssen.

Inhaltsmoderation für soziale Medien: Dezentrale soziale Netzwerke (Farcaster, Lens Protocol) könnten durch Judge verifizierte KI-Moderatoren einsetzen. Community-Mitglieder verifizieren, dass das Moderationsmodell nicht voreingenommen oder zensiert ist – was die Neutralität der Plattform sicherstellt.

AI-as-a-Service-Plattformen: Entwickler, die KI-Anwendungen erstellen, können "verifizierbare Inferenz" als Premium-Funktion anbieten. Nutzer zahlen extra für Beweise und differenzieren so Dienste von undurchsichtigen Alternativen.

Die Gemeinsamkeit: Anwendungen, bei denen Vertrauen teuer ist (aufgrund von Regulierung, Dezentralisierung oder hohen Einsätzen) und die Verifizierungskosten akzeptabel sind (im Vergleich zum Wert der Gewissheit).

Judge wird OpenAI bei Consumer-Chatbots nicht ersetzen – Nutzer legen keinen Wert darauf, ob GPT-4 verifizierbar ist, wenn sie nach Rezeptideen fragen. Aber für Finanzalgorithmen, medizinische Werkzeuge und Governance-Systeme ist verifizierbare KI die Zukunft.

Verifizierbarkeit als neuer Standard​

Der Judge von Gensyn stellt einen Paradigmenwechsel dar: Die KI-Evaluierung bewegt sich von "Vertrauen in den Anbieter" hin zu "Verifizierung des Beweises". Die technische Grundlage – bitgenaue Reproduzierbarkeit via Verde, effiziente Verifizierung durch referenzierte Delegation (refereed delegation) und On-Chain-Audit-Trails – macht diesen Übergang praktisch und nicht nur erstrebenswert.

Die Auswirkungen reichen weit über Gensyn hinaus. Wenn verifizierbare KI zum Standard wird, verlieren zentrale Anbieter ihre Wettbewerbsvorteile (Moats). Das Wertversprechen von OpenAI sind nicht nur die Fähigkeiten von GPT-4 – es ist die Bequemlichkeit, die Infrastruktur nicht selbst verwalten zu müssen. Aber wenn Gensyn beweist, dass dezentrale KI mit der Leistung zentralisierter Systeme mithalten kann und zusätzlich Verifizierbarkeit bietet, haben Entwickler keinen Grund mehr, sich an proprietäre APIs zu binden.

Das Rennen läuft. ZKML-Projekte (Modulus Labs, Worldcoins biometrisches System) setzen auf Zero-Knowledge-Proofs. Deterministische Laufzeiten (Gensyns Verde, EigenAI) setzen auf Reproduzierbarkeit. Optimistische Ansätze (Blockchain-KI-Orakel) setzen auf Betrugsbeweise (Fraud Proofs). Jeder Pfad hat Kompromisse – aber das Ziel ist dasselbe: KI-Systeme, deren Ausgaben beweisbar und nicht nur plausibel sind.

Für folgenschwere Entscheidungen ist dies nicht optional. Regulierungsbehörden werden in Finanz-, Gesundheits- oder Rechtsanwendungen kein "Vertrauen Sie uns" von KI-Anbietern akzeptieren. DAOs werden das Treasury-Management nicht an Black-Box-Agenten delegieren. Und da autonome KI-Systeme immer leistungsfähiger werden, wird die Öffentlichkeit Transparenz fordern.

Judge ist das erste produktionsreife System, das dieses Versprechen einlöst. Das Testnet ist live. Die kryptografischen Grundlagen sind solide. Der Markt – 27 Milliarden US-Dollar in Krypto-KI-Agenten, Milliarden an DeFi-Vermögenswerten, die von Algorithmen verwaltet werden, und der zunehmende regulatorische Druck – ist bereit.

Die Ära der undurchsichtigen KI-APIs endet. Das Zeitalter der verifizierbaren Intelligenz beginnt. Und der Judge von Gensyn weist den Weg.

---

Quellen:

• Introducing Judge | Gensyn Blog
• Gensyn launches verifiable AI evaluation system Judge | Bitget News
• Verde Verification System In Production | Gensyn
• Verde: a verification system for machine learning over untrusted nodes | Gensyn
• Verde: Verification via Refereed Delegation for Machine Learning Programs | arXiv
• EigenAI: Deterministic Inference, Verifiable Results | arXiv
• Deterministic Verification Architecture for AI Systems | Medium
• The Gensyn Protocol | Gensyn Docs
• Gensyn | the network for machine intelligence
• Gensyn Public Testnet | Gensyn Docs
• ZKML: Verifiable Machine Learning using Zero-Knowledge Proof | Kudelski Security
• The Verification Imperative: Why AI Trading Systems Need Cryptographic Flight Recorders | Medium
• Verifiable AI Agents: A Cryptographic Approach to Creating a Transparent Financial Ecosystem | CoinCentral
• A Framework for Cryptographic Verifiability of End-to-End AI Pipelines | arXiv

Am 2. Februar 2026 machte die Ökonomie der KI-Agenten einen entscheidenden Schritt nach vorne. Nillion startete Blacklight, einen Verification Layer, der den ERC-8004-Standard implementiert, um eine der dringlichsten Fragen der Blockchain zu lösen: Wie vertraut man einem KI-Agenten, dem man noch nie begegnet ist?

Die Antwort ist nicht ein einfacher Reputation Score oder ein zentralisiertes Register. Es ist ein fünfstufiger Verifizierungsprozess, der durch kryptografische Beweise, programmierbare Audits und ein Netzwerk von gemeinschaftlich betriebenen Nodes gestützt wird. Da autonome Agenten zunehmend Trades ausführen, Treasuries verwalten und Cross-Chain-Aktivitäten koordinieren, stellt Blacklight die Infrastruktur dar, die eine trustless KI-Koordination in großem Maßstab ermöglicht.

Das Vertrauensproblem, das KI-Agenten nicht alleine lösen können​

Die Zahlen sprechen für sich. KI-Agenten tragen mittlerweile 30 % des Handelsvolumens von Polymarket bei, verwalten DeFi-Yield-Strategien über mehrere Protokolle hinweg und führen autonom komplexe Workflows aus. Aber es gibt einen grundlegenden Engpass: Wie verifizieren Agenten die Vertrauenswürdigkeit des jeweils anderen ohne bestehende Beziehungen?

Traditionelle Systeme verlassen sich auf zentrale Instanzen, die Credentials ausstellen. Das Versprechen von Web3 ist ein anderes – trustless Verifizierung durch Kryptografie und Konsens. Doch bis ERC-8004 gab es keinen standardisierten Weg für Agenten, ihre Authentizität zu beweisen, ihr Verhalten zu verfolgen oder ihre Entscheidungslogik On-Chain zu validieren.

Dies ist kein rein theoretisches Problem. Wie Davide Crapis erklärt: „ERC-8004 ermöglicht dezentrale Interaktionen von KI-Agenten, etabliert trustless Handel und verbessert Reputationssysteme auf Ethereum.“ Ohne diesen Standard bleibt der Handel von Agent zu Agent auf geschlossene Systeme beschränkt oder erfordert manuelle Aufsicht – was den Zweck der Autonomie zunichtemacht.

ERC-8004: Die Trust-Infrastruktur aus drei Registern​

Der ERC-8004-Standard, der am 29. Januar 2026 im Ethereum-Mainnet live ging, etabliert einen modularen Trust Layer durch drei On-Chain-Register:

Identity Registry: Nutzt ERC-721, um portable Agenten-Identifikatoren bereitzustellen. Jeder Agent erhält einen Non-Fungible Token, der seine einzigartige On-Chain-Identität repräsentiert, was eine plattformübergreifende Erkennung ermöglicht und Identitäts-Spoofing verhindert.

Reputation Registry: Sammelt standardisiertes Feedback und Bewertungen. Im Gegensatz zu zentralisierten Bewertungssystemen wird das Feedback On-Chain mit kryptografischen Signaturen aufgezeichnet, wodurch ein unveränderlicher Audit-Trail entsteht. Jeder kann diese Historie durchsuchen und eigene Reputationsalgorithmen erstellen.

Validation Registry: Unterstützt die kryptografische und ökonomische Verifizierung der Arbeit von Agenten. Hier finden programmierbare Audits statt – Validatoren können Berechnungen erneut ausführen, Zero-Knowledge-Proofs verifizieren oder Trusted Execution Environments (TEEs) nutzen, um zu bestätigen, dass ein Agent korrekt gehandelt hat.

Die Brillanz von ERC-8004 liegt in seinem unvoreingenommenen Design. Wie die technische Spezifikation anmerkt, unterstützt der Standard verschiedene Validierungstechniken: „Stake-gesicherte Neuausführung von Aufgaben (inspiriert von Systemen wie EigenLayer), Verifizierung von Zero-Knowledge Machine Learning (zkML) Proofs und Attestierungen von Trusted Execution Environments.“

Diese Flexibilität ist wichtig. Ein DeFi-Arbitrage-Agent könnte zkML-Proofs verwenden, um seine Handelslogik zu verifizieren, ohne Alpha preiszugeben. Ein Supply-Chain-Agent könnte TEE-Attestierungen nutzen, um zu beweisen, dass er korrekt auf Real-World-Daten zugegriffen hat. Ein Cross-Chain-Bridge-Agent könnte auf krypto-ökonomische Validierung mit Slashing setzen, um eine ehrliche Ausführung zu gewährleisten.

Blacklights fünfstufiger Verifizierungsprozess​

Nillions Implementierung von ERC-8004 auf Blacklight fügt eine entscheidende Ebene hinzu: gemeinschaftlich betriebene Verifizierungs-Nodes. So funktioniert der Prozess:

1. Agenten-Registrierung: Ein Agent registriert seine Identität in der Identity Registry und erhält ein ERC-721 NFT. Dies erstellt einen eindeutigen On-Chain-Identifikator, der an den öffentlichen Schlüssel des Agenten gebunden ist.

2. Initiierung der Verifizierungsanfrage: Wenn ein Agent eine Aktion ausführt, die eine Validierung erfordert (z. B. Ausführung eines Trades, Überweisung von Geldern oder Aktualisierung des Status), sendet er eine Verifizierungsanfrage an Blacklight.

3. Zuweisung des Komitees: Das Protokoll von Blacklight weist zufällig ein Komitee aus Verifizierungs-Nodes zu, um die Anfrage zu prüfen. Diese Nodes werden von Community-Mitgliedern betrieben, die 70.000 NIL-Token staken, wodurch Anreize für die Netzwerkintegrität geschaffen werden.

4. Node-Prüfungen: Komitee-Mitglieder führen die Berechnung erneut aus oder validieren kryptografische Proofs. Wenn Validatoren fehlerhaftes Verhalten feststellen, können sie den Stake des Agenten kürzen (in Systemen, die krypto-ökonomische Validierung nutzen) oder die Identität in der Reputation Registry markieren.

5. On-Chain-Reporting: Die Ergebnisse werden On-Chain veröffentlicht. Die Validation Registry zeichnet auf, ob die Arbeit des Agenten verifiziert wurde, und schafft so einen permanenten Ausführungsbeweis. Die Reputation Registry wird entsprechend aktualisiert.

Dieser Prozess erfolgt asynchron und nicht blockierend, was bedeutet, dass Agenten bei Routineaufgaben nicht auf die Verifizierung warten müssen – aber bei risikoreichen Aktionen (große Überweisungen, Cross-Chain-Operationen) kann eine Vorab-Validierung erforderlich sein.

Programmierbare Audits: Jenseits von binärem Vertrauen​

Das ehrgeizigste Feature von Blacklight ist die „programmierbare Verifizierung“ – die Fähigkeit zu prüfen, wie ein Agent Entscheidungen trifft, und nicht nur, was er tut.

Betrachten wir einen DeFi-Agenten, der eine Treasury verwaltet. Traditionelle Audits verifizieren, dass Gelder korrekt bewegt wurden. Programmierbare Audits verifizieren:

• Konsistenz der Entscheidungslogik: Hat der Agent seine angegebene Investmentstrategie befolgt oder ist er davon abgewichen?
• Ausführung mehrstufiger Workflows: Wenn der Agent Portfolios über drei Chains hinweg umschichten sollte, hat er alle Schritte abgeschlossen?
• Sicherheitsbeschränkungen: Hat der Agent Gas-Limits, Slippage-Toleranzen und Exposure-Obergrenzen eingehalten?

Dies ist möglich, da die Validation Registry von ERC-8004 beliebige Proof-Systeme unterstützt. Ein Agent kann sich on-chain auf einen Entscheidungsalgorithmus festlegen (z. B. ein Hash seiner neuronalen Netzwerkgewichtungen oder ein zk-SNARK-Schaltkreis, der seine Logik darstellt) und dann beweisen, dass jede Aktion diesem Algorithmus entspricht, ohne proprietäre Details offenzulegen.

Nillions Roadmap zielt explizit auf diese Anwendungsfälle ab: „Nillion plant, die Fähigkeiten von Blacklight auf die ‚programmierbare Verifizierung‘ auszuweiten, was dezentrale Audits komplexer Verhaltensweisen wie die Konsistenz der Entscheidungslogik von Agenten, die Ausführung mehrstufiger Workflows und Sicherheitsbeschränkungen ermöglicht.“

Dies verschiebt die Verifizierung von reaktiv (Fehler im Nachhinein finden) zu proaktiv (korrektes Verhalten durch Design erzwingen).

Blind Computation: Privatsphäre trifft auf Verifizierung​

Nillions zugrunde liegende Technologie – Nil Message Compute (NMC) – fügt der Agenten-Verifizierung eine Datenschutz-Dimension hinzu. Im Gegensatz zu herkömmlichen Blockchains, bei denen alle Daten öffentlich sind, ermöglicht Nillions „Blind Computation“ Operationen auf verschlüsselten Daten ohne Entschlüsselung.

Warum das für Agenten wichtig ist: Ein KI-Agent muss möglicherweise seine Handelsstrategie verifizieren, ohne sein Alpha an Konkurrenten preiszugeben. Oder er muss beweisen, dass er korrekt auf vertrauliche medizinische Unterlagen zugegriffen hat, ohne Patientendaten offenzulegen. Oder er muss die Einhaltung regulatorischer Auflagen nachweisen, ohne proprietäre Geschäftslogik zu enthüllen.

Nillions NMC erreicht dies durch Multi-Party Computation (MPC), bei der Nodes gemeinsam „Blinding Factors“ generieren – korrelierte Zufälligkeit, die zur Verschlüsselung von Daten verwendet wird. Wie DAIC Capital erklärt: „Nodes generieren die wichtigste Netzwerkressource, die für die Datenverarbeitung benötigt wird – eine Art korrelierte Zufälligkeit, die als Blinding Factor bezeichnet wird. Dabei speichert jeder Node seinen Anteil am Blinding Factor sicher und verteilt das Vertrauen quantensicher über das Netzwerk.“

Diese Architektur ist von Grund auf quantenresistent. Selbst wenn ein Quantencomputer die heutige Elliptische-Kurven-Kryptographie knackt, bleiben verteilte Blinding Factors sicher, da kein einzelner Node über genügend Informationen verfügt, um Daten zu entschlüsseln.

Für KI-Agenten bedeutet dies, dass die Verifizierung nicht auf Kosten der Vertraulichkeit geht. Ein Agent kann beweisen, dass er eine Aufgabe korrekt ausgeführt hat, während er seine Methoden, Datenquellen und Entscheidungslogik privat hält.

Der 4,3 Milliarden $ Infrastruktur-Ansatz der Agent-Economy​

Der Start von Blacklight erfolgt zu einem Zeitpunkt, an dem der Blockchain-KI-Sektor in ein Hyperwachstum eintritt. Es wird prognostiziert, dass der Markt von 680 Millionen $(2025) auf 4,3 Milliarden$ (2034) mit einer CAGR von 22,9 % wachsen wird, während der breitere Markt für Confidential Computing bis 2032 ein Volumen von 350 Milliarden $ erreicht.

Aber Nillion setzt nicht nur auf die Marktexpansion – es positioniert sich als kritische Infrastruktur. Der Engpass der Agent-Economy ist nicht Rechenleistung oder Speicherplatz, sondern Vertrauen in großem Maßstab. Wie der Ausblick von KuCoin für 2026 anmerkt, gestalten drei Haupttrends die KI-Identität und den Wertefluss neu:

Agent-Wrapping-Agent-Systeme: Agenten, die sich mit anderen Agenten koordinieren, um komplexe mehrstufige Aufgaben auszuführen. Dies erfordert standardisierte Identität und Verifizierung – genau das, was ERC-8004 bietet.

KYA (Know Your Agent): Finanzielle Infrastruktur, die Agenten-Credentials verlangt. Regulierungsbehörden werden keine autonomen Agenten zulassen, die Gelder verwalten, ohne dass ein Beweis für korrektes Verhalten vorliegt. Die programmierbaren Audits von Blacklight adressieren dies direkt.

Nano-Zahlungen: Agenten müssen Mikrozahlungen effizient abwickeln. Das x402-Zahlungsprotokoll, das im Januar 2026 über 20 Millionen Transaktionen verarbeitete, ergänzt ERC-8004, indem es die Abwicklung übernimmt, während Blacklight für das Vertrauen sorgt.

Zusammen erreichten diese Standards innerhalb weniger Wochen nacheinander die Produktionsreife – ein Durchbruch in der Koordination, der die Reifung der Infrastruktur signalisiert.

Ethereums Agent-zentrierte Zukunft​

Die Einführung von ERC-8004 geht weit über Nillion hinaus. Seit Anfang 2026 haben mehrere Projekte den Standard integriert:

• Oasis Network: Implementierung von ERC-8004 für Confidential Computing mit TEE-basierter Validierung
• The Graph: Unterstützung von ERC-8004 und x402 zur Ermöglichung verifizierbarer Agenten-Interaktionen in der dezentralen Indexierung
• MetaMask: Erforschung von Agent-Wallets mit integrierter ERC-8004-Identität
• Coinbase: Integration von ERC-8004 für institutionelle Verwahrungslösungen für Agenten

Diese schnelle Akzeptanz spiegelt einen breiteren Wandel in Ethereums Roadmap wider. Vitalik Buterin hat wiederholt betont, dass die Rolle der Blockchain zunehmend „nur noch die Rohrleitungen“ für KI-Agenten wird – nicht die Ebene für Endverbraucher, sondern die Vertrauensinfrastruktur, die autonome Koordination ermöglicht.

Nillions Blacklight beschleunigt diese Vision, indem es die Verifizierung programmierbar, datenschutzfreundlich und dezentral macht. Anstatt sich auf zentralisierte Orakel oder menschliche Prüfer zu verlassen, können Agenten ihre Korrektheit kryptographisch beweisen.

Was als nächstes kommt: Mainnet-Integration und Ökosystem-Erweiterung​

Die 2026 Roadmap von Nillion priorisiert Ethereum-Kompatibilität und nachhaltige Dezentralisierung. Die Ethereum-Bridge ging im Februar 2026 live, gefolgt von nativen Smart Contracts für Staking und Blind Computation.

Community-Mitglieder, die 70.000 NIL-Token staken, können Blacklight-Verifizierungs-Nodes betreiben und Belohnungen verdienen, während sie die Netzwerkintegrität aufrechterhalten. Dieses Design spiegelt die Validator-Ökonomie von Ethereum wider, fügt jedoch eine verifizierungsspezifische Rolle hinzu.

Die nächsten Meilensteine umfassen:

• Erweiterte zkML-Unterstützung: Integration mit Projekten wie Modulus Labs zur Verifizierung von KI-Inferenzen On-Chain
• Cross-Chain-Verifizierung: Ermöglichung von Blacklight, Agenten zu verifizieren, die über Ethereum, Cosmos und Solana hinweg agieren
• Institutionelle Partnerschaften: Kooperationen mit Coinbase und Alibaba Cloud für den Einsatz von Enterprise-Agenten
• Tools für regulatorische Compliance: Entwicklung von KYA-Frameworks (Know Your Agent) für die Einführung im Finanzdienstleistungssektor

Vielleicht am wichtigsten ist, dass Nillion nilGPT entwickelt — einen vollständig privaten KI-Chatbot, der demonstriert, wie Blind Computation vertrauliche Agenten-Interaktionen ermöglicht. Dies ist nicht nur eine Demo; es ist eine Blaupause für Agenten, die sensible Daten im Gesundheitswesen, im Finanzwesen und im öffentlichen Sektor verarbeiten.

Das Endgame der trustlosen Koordination​

Der Start von Blacklight markiert einen Wendepunkt für die Agent-Ökonomie. Vor ERC-8004 operierten Agenten in Silos — vertrauenswürdig innerhalb ihrer eigenen Ökosysteme, aber unfähig, sich ohne menschliche Vermittler plattformübergreifend zu koordinieren. Nach ERC-8004 können Agenten die Identität des jeweils anderen verifizieren, das Verhalten des anderen prüfen und Zahlungen autonom abwickeln.

Dies erschließt völlig neue Kategorien von Anwendungen:

• Dezentrale Hedgefonds: Agenten, die Portfolios über verschiedene Chains hinweg verwalten, mit verifizierbaren Investmentstrategien und transparenten Performance-Audits
• Autonome Lieferketten: Agenten, die Logistik, Zahlungen und Compliance ohne zentrale Aufsicht koordinieren
• KI-gestützte DAOs: Organisationen, die von Agenten gesteuert werden, die auf Basis einer kryptografisch verifizierten Entscheidungslogik abstimmen, Vorschläge machen und diese ausführen
• Protokollübergreifendes Liquiditätsmanagement: Agenten, die Vermögenswerte über DeFi-Protokolle hinweg mit programmierbaren Risikobeschränkungen umschichten

Der rote Faden? Alle erfordern trustlose Koordination — die Fähigkeit von Agenten, ohne bestehende Beziehungen oder zentrale Vertrauensanker zusammenzuarbeiten.

Nillions Blacklight bietet genau das. Durch die Kombination der Identitäts- und Reputationsinfrastruktur von ERC-8004 mit programmierbarer Verifizierung und Blind Computation schafft es eine Vertrauensebene, die skalierbar genug für die bevorstehende Billionen-Agenten-Ökonomie ist.

Da die Blockchain zum Grundgerüst für KI-Agenten und das globale Finanzwesen wird, ist die Frage nicht, ob wir eine Verifizierungsinfrastruktur benötigen — sondern wer sie baut und ob sie dezentralisiert ist oder von einigen wenigen Gatekeepern kontrolliert wird. Die von der Community betriebenen Nodes und der offene Standard von Blacklight sprechen für Letzteres.

Das Zeitalter der autonomen On-Chain-Akteure ist angebrochen. Die Infrastruktur ist live. Die einzige offene Frage ist, was darauf aufgebaut wird.

---

Quellen:

• Nillion Launches ERC-8004 Verification on Blacklight | Phemex News
• ERC-8004: Trustless Agents | Ethereum Improvement Proposals
• ERC-8004: Infrastructure for Autonomous AI Agents | QuillAudits
• Davide Crapis: ERC 8004 enables decentralized AI agent interactions | Unchained
• Nillion's Blind Computer Fixes the Internet | Nillion
• Nillion (NIL): Humanity's First Blind Computation Network | DAIC Capital
• 2026 AI Agent Economy Outlook | KuCoin
• The Graph Backs x402 and ERC-8004 Standards for AI Agent Economy | Blockchain News
• ‍ERC-8004: A Standard for Trustless Agents | Oasis Network
• Nillion 2.0 Goes Live on Ethereum | MEXC News
• Nillion: Blind Compute Broke Out in 2025 | Medium
• 2026: When Blockchain Becomes Just the Plumbing for AI Agents | Blockmanity

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.