5 Beiträge getaggt mit „cryptographic proofs“

Wenn ein DeFi-Lending-Protokoll eine Position liquidiert, wie können Sie sicher sein, dass die Risikokalkulation korrekt war? Was, wenn das Modell fehlerhaft, manipuliert oder schlichtweg undurchsichtig war? Seit Jahren operiert DeFi nach einem Paradoxon: Protokolle fordern Transparenz für die On-Chain-Ausführung, doch die KI-Modelle, die kritische Risikoentscheidungen treffen, bleiben Blackboxen. Zero-Knowledge Machine Learning (ZK-ML) schließt nun endlich diese Vertrauenslücke – und die Auswirkungen auf die institutionelle DeFi-Adoption im Jahr 2026 sind tiefgreifend.

Die Vertrauenskrise in DeFi-Risikomodellen​

Das explosive Wachstum von DeFi auf über 50 Milliarden US-Dollar an Total Value Locked (TVL) hat ein neues Problem geschaffen: Institutionelles Kapital verlangt verifizierbare Risikobewertungen, aber aktuelle Lösungen erzwingen einen inakzeptablen Kompromiss zwischen Transparenz und Vertraulichkeit.

Traditionelle Oracle-basierte Risikosysteme setzen Protokolle drei kritischen Schwachstellen aus. Erstens: Latenz tötet Kapitaleffizienz. Bei Ereignissen mit hoher Volatilität verhindern langsame oder ungenaue Preis-Feeds, dass Lending-Protokolle Positionen rechtzeitig liquidieren, was zu Kaskaden von uneinbringlichen Forderungen (Bad Debt) führt. Legacy-Push-basierte Oracles zwingen Protokolle dazu, konservative Loan-to-Value-Verhältnisse (LTV) – typischerweise 50–70 % – zu verwenden, um Aktualisierungsverzögerungen auszugleichen, was die Kapitaleffizienz der Kreditnehmer direkt verringert.

Zweitens: Manipulation bleibt endemisch. Ohne kryptographische Verifizierung der Berechnung von Risikowerten verlassen sich Protokolle auf das Vertrauen in zentralisierte Datenanbieter. Ein kompromittiertes Oracle kann falsche Liquidationen auslösen oder, schlimmer noch, zulassen, dass unterbesicherte Positionen bis zum Systemversagen bestehen bleiben.

Drittens: Proprietäre Modelle verursachen regulatorische Alpträume. Institutionelle Teilnehmer müssen beweisen, dass ihre Risikobewertungen fundiert sind, ohne ihre proprietären Algorithmen offenzulegen. Banken können keine Lending-Protokolle einsetzen, bei denen die Risikologik vollständig öffentlich ist, doch Regulierungsbehörden akzeptieren keine undurchsichtigen „Vertrauen Sie uns“-Systeme. Dieses regulatorische Dilemma hat die institutionelle DeFi-Integration ins Stocken gebracht.

Die Zahlen sprechen für sich: DeFi-Liquidationsereignisse im Jahr 2025 führten zu Verlusten von über 2,3 Milliarden US-Dollar, wobei 40 % auf Oracle-Latenz und Manipulationsanfälligkeiten zurückzuführen waren. Institutionelle Teilnehmer warten an der Seitenlinie – nicht weil sie am Potenzial der Blockchain zweifeln, sondern weil sie die aktuelle Risikoinfrastruktur nicht akzeptieren können.

Der Einzug von Zero-Knowledge Machine Learning​

ZK-ML stellt einen Paradigmenwechsel dar: Es ermöglicht KI-generierte Risikobewertungen, die kryptografisch verifiziert werden können, ohne die zugrunde liegenden Daten oder Modellparameter preiszugeben. Man kann es sich wie einen mathematischen Beweis vorstellen, der besagt: „Diese Liquidationsprognose wurde korrekt mit unserem proprietären Modell und Ihren verschlüsselten Daten berechnet“ – ohne eines von beidem offenzulegen.

Die Technologie funktioniert durch die Umwandlung von Machine-Learning-Inferenz in Zero-Knowledge-Proofs. Wenn ein DeFi-Protokoll das Liquidationsrisiko bewerten muss, geht das ZK-ML-System wie folgt vor:

1. Führt das KI-Modell aus auf verschlüsselten Benutzerdaten (Besicherungspositionen, Handelsverlauf, Wallet-Verhalten).
2. Erzeugt einen kryptographischen Beweis, dass die Berechnung korrekt durchgeführt wurde.
3. Veröffentlicht den Beweis On-Chain, damit er für jeden verifizierbar ist, ohne die Modellarchitektur oder sensible Benutzerdaten preiszugeben.
4. Löst Smart-Contract-Aktionen aus (wie Liquidationen), basierend auf verifizierbar korrekten Risikowerten.

Dies ist keine Theorie. Projekte wie EZKL, Modulus Labs und Gensyn demonstrieren bereits produktionsreife ZK-ML-Frameworks. Die jüngsten Benchmarks von EZKL zeigen Verifizierungsgeschwindigkeiten, die 65,88-mal schneller sind als frühere ZK-Systeme, bei Unterstützung für Modelle mit bis zu 18 Millionen Parametern. Modulus Labs bewies die On-Chain-Inferenz komplexer neuronaler Netze, während Gensyn eine dezentrale Trainingsinfrastruktur mit integrierter Verifizierung aufbaut.

Die Auswirkungen in der realen Welt sind bereits sichtbar. Das Marine-Liquidationssystem von ORA nutzt zkOracle-basierte Implementierungen, um vertrauenslose Liquidationen auf Compound Finance durchzuführen. Durch die Einführung von Oracle-Updates ohne Latenz, die genau dann auslösen, wenn Liquidationen möglich werden, ermöglicht Marine es Lending-Protokollen, höhere LTV-Verhältnisse anzubieten – bis zu 85–90 % – und dabei Sicherheitsmargen einzuhalten, die bei herkömmlichen Oracles leichtsinnig wären.

Privatsphäre-wahrendes Credit-Scoring: Der Schlüssel für Institutionen​

Für die institutionelle DeFi-Adoption ist das Credit-Scoring der heilige Gral. Das traditionelle Finanzwesen stützt sich auf FICO-Scores und Kreditauskunfteien, doch diese Systeme sind grundlegend inkompatibel mit dem pseudonymen Design der Blockchain. Wie bewertet man die Kreditwürdigkeit ohne KYC? Wie beweist man die Rückzahlungshistorie eines Kreditnehmers, ohne dessen Transaktionsgraph preiszugeben?

ZK-ML löst dies durch privatsphäre-wahrendes Credit-Scoring. Forschungen von IEEE und Springer zeigen vollständige Credit-Score-Systeme unter Verwendung von Blockchain und Zero-Knowledge-Proofs. Die Architektur funktioniert folgendermaßen:

• Verschlüsselung von Kreditdaten über mehrere DeFi-Protokolle hinweg (Rückzahlungshistorie, Liquidationsereignisse, Wallet-Alter, Transaktionsmuster).
• Ausführung von ML-Kreditmodellen auf diesen verschlüsselten Daten mittels homomorpher Verschlüsselung oder sicherer Mehrparteienberechnung (Secure Multi-Party Computation).
• Erzeugung von Zero-Knowledge-Proofs, dass eine bestimmte Wallet-Adresse in einem bestimmten Credit-Score-Bereich liegt, ohne offenzulegen, welche Protokolle Daten beigesteuert haben oder wie die vollständige Historie der Wallet aussieht.
• Erstellung portabler On-Chain-Attestierungen, die es Nutzern ermöglichen, ihre verifizierte Kreditwürdigkeit über verschiedene Plattformen hinweg mitzunehmen.

Dies ist kein bloßes „Privacy Theater“ – es ist eine regulatorische Notwendigkeit. Eine kürzlich in Science Direct veröffentlichte Studie zeigte, dass Blockchain-basierte Verifizierungsschichten mit kryptographischen Proof-of-SQL-Mechanismen es Institutionen ermöglichen, Kreditnehmer-Anmeldedaten zu validieren und gleichzeitig die DSGVO-Konformität zu wahren. Das VeriNet-Framework erreichte dies sowohl bei der Erkennung von Deepfakes als auch bei Anwendungen für das Fintech-Credit-Scoring und bewies damit, dass der Ansatz in großem Maßstab funktioniert.

Der Business Case ist überzeugend: Institutionelle Kreditgeber können nun Kapital in DeFi-Lending-Pools mit verifizierbarer Risikosegmentierung bereitstellen. Anstatt alle anonymen Kreditnehmer als risikoreich zu behandeln (und 15–25 % APY zum Ausgleich zu verlangen), können Protokolle differenzierte Zinssätze anbieten – 8 % für verifizierte risikoarme Wallets, 12 % für mittleres Risiko, 20 % für hohes Risiko – und das alles unter Wahrung der Privatsphäre der Nutzer und der regulatorischen Compliance.

ZK-ML vs. traditionelle Oracles: Der Performance-Unterschied​

Der Geschwindigkeitsvorteil von ZK-ML gegenüber herkömmlichen Oracle-Systemen ist verblüffend. Traditionelle Price-Oracles aktualisieren sich alle 1 - 60 Sekunden, je nach Implementierung (der Heartbeat von Chainlink liegt typischerweise bei 1 - 3 % Preisabweichung oder stündlichen Updates). Während der Volatilitätsspitze im März 2024 stiegen die Ethereum-Gas-Preise auf über 500 + Gwei an, was zu Oracle-Update-Verzögerungen von 10 - 15 Minuten führte.

ZK-ML-Systeme eliminieren diese Latenz, indem sie Risikobewertungen on-demand berechnen, wobei die kryptographische Beweiserstellung für typische DeFi-Risikomodelle lediglich 100 - 500 Millisekunden dauert. Marines zkOracle-Implementierung demonstrierte dies in der Praxis: Liquidationen wurden innerhalb von 1 - 2 Blöcken ausgelöst, nachdem Positionen unterbesichert waren, im Vergleich zu 10 - 50 Blöcken bei Oracle-abhängigen Systemen.

Die Gewinne bei der Kapitaleffizienz sind messbar. Konservative Schätzungen deuten darauf hin, dass ZK-ML-gestützte Lending-Protokolle die LTV-Verhältnisse sicher um 15 - 20 Prozentpunkte erhöhen können. Bei einem Protokoll mit $1 Milliarde TVL entspricht dies einer zusätzlichen Kreditkapazität von$ 150 - 200 Millionen – wodurch Hunderte Millionen an jährlichen Zinserträgen freigesetzt werden, die bei einer Legacy-Infrastruktur ungenutzt bleiben würden.

Über die Geschwindigkeit hinaus bietet ZK-ML eine Manipulationsresistenz, mit der Oracles nicht mithalten können. Traditionelle Price-Feeds können durch Flash-Loan-Angriffe, Validator-Kollusion oder Kompromittierungen von API-Schlüsseln manipuliert werden. ZK-ML-Risikomodelle arbeiten On-Chain mit kryptographischer Verifizierung jedes Berechnungsschritts. Ein Angreifer müsste das zugrunde liegende Zero-Knowledge-Proof-System knacken (was das Durchbrechen grundlegender kryptographischer Annahmen wie der Härte des diskreten Logarithmus erfordern würde), anstatt nur einen einzelnen Oracle-Feed zu kompromittieren.

Der Bericht des Financial Stability Board aus dem Jahr 2023 zu DeFi-Risiken identifizierte Oracle-Manipulation explizit als systemische Schwachstelle. ZK-ML adressiert dies direkt: Wenn Liquidationsentscheidungen auf kryptografisch bewiesenen Risikomodellen basieren und nicht auf vertrauensbasierten Price-Feeds, schrumpft die Angriffsfläche um Größenordnungen.

Warum Institutionen transparente und dennoch vertrauliche Modelle benötigen​

Der Engpass für die institutionelle DeFi-Adoption ist nicht die Technologie – es ist die Vertrauensinfrastruktur. Wenn J.P. Morgan oder State Street DeFi-Lending-Protokolle bewerten, fragen ihre Due-Diligence-Teams: „Wie berechnen Sie das Liquidationsrisiko?“, „Können wir Ihr Modell prüfen?“, „Wie verhindern Sie Manipulationen?“

Bei traditionellen DeFi-Protokollen sind die Antworten unbefriedigend:

• Vollständig transparente Modelle: Open-Source-Risikologik bedeutet, dass Konkurrenten Liquidationen front-runnen können, Market-Maker das System manipulieren können und proprietäre Wettbewerbsvorteile verloren gehen
• Black-Box-Modelle: Institutionelle Compliance-Teams lehnen Systeme ab, bei denen Risikoberechnungen nicht prüfbar sind
• Oracle-Abhängigkeit: Die Abhängigkeit von externen Price-Feeds führt zu Gegenparteirisiken, die Banken nicht akzeptieren können

ZK-ML löst diesen Stillstand auf. Institutionen können nun Protokolle mit selektiv transparenten Risikomodellen einsetzen:

1. Prüfbare Verifizierung: Regulierungsbehörden und Prüfer können verifizieren, dass Liquidationsentscheidungen dem angegebenen Algorithmus folgen, ohne proprietäre Parameter einsehen zu müssen
2. Wettbewerbsschutz: Modellarchitektur und Trainingsdaten bleiben vertraulich, wodurch Wettbewerbsvorteile gewahrt bleiben
3. On-Chain-Rechenschaftspflicht: Jede Risikoentscheidung generiert einen unveränderlichen kryptographischen Beweis, der perfekte Audit-Trails für die Compliance erstellt
4. Protokollübergreifende Portabilität: Nutzer können ihre Kreditwürdigkeit beweisen, ohne offenzulegen, welche Protokolle sie verwendet haben

Die regulatorischen Auswirkungen sind tiefgreifend. Die DeFi-Risikobewertungsrichtlinien (Version 1) der Enterprise Ethereum Alliance fordern explizit „verifizierbare Berechnungs-Frameworks, die die Vertraulichkeit wahren und gleichzeitig Audits ermöglichen“. ZK-ML ist die einzige Technologie, die diese Spezifikation erfüllt.

Ein aktuelles Strategiepapier von Georgetown zur institutionellen DeFi-Integration identifizierte die Compliance-Herausforderung: „Anstatt traditionelle Finanzregulierung nachträglich auf vermittlerlose Systeme anzuwenden, betten neue Lösungen Compliance-Funktionen direkt in die DeFi-Infrastruktur ein.“ ZK-ML tut genau das – es ist eine Compliance-native Architektur, kein nachträglich hinzugefügtes Element.

Der Durchbruch 2026: Von der Theorie zur Produktion​

Der Wendepunkt ist erreicht. Während ZK-ML-Konzepte seit 2021 existieren, erreichen praktische Implementierungen erst jetzt die Produktionsreife. Die Belege:

Reifung der Infrastruktur: EZKL demonstrierte Unterstützung für Attention-Mechanismen – im Jahr 2024 kaum machbar, jetzt für den Produktionseinsatz optimiert. Modulus Labs bewies On-Chain-Inferenz für Modelle mit 18 Millionen Parametern und überschritt damit die Schwelle, ab der reale Kreditmodelle rentabel werden.

Kapitaleinsatz: Gensyn sammelte erhebliche Mittel ein, um dezentrales KI-Training mit kryptographischer Verifizierung aufzubauen. Institutionen finanzieren keine Forschungsprojekte – sie finanzieren Produktionsinfrastruktur.

Ökosystem-Integration: Die Zero-Knowledge-Proof-Technologie hat sich von der Kryptografieforschung zu Anwendungen im Blockchain-Maßstab entwickelt. Chainalysis und TRM Labs entwickeln ZK-kompatible Compliance-Tools. Die Infrastrukturebene reift heran.

Developer-Tools: Die Hürde für die Implementierung von ZK-ML ist massiv gesunken. Was 2023 noch Kryptografie-Doktortitel erforderte, kann heute von Standard-Blockchain-Entwicklern mit EZKL, Modulus oder neuen Frameworks umgesetzt werden. Wenn Entwickler ZK-ML-Systeme in Wochen statt Jahren bereitstellen können, beschleunigt sich die Adoption exponentiell.

Die Entwicklung spiegelt die Evolution von DeFi selbst wider. Im Jahr 2020 war DeFi eine Forschungs-Kuriosität mit $1 Milliarde TVL. Bis 2021 reifte die Infrastruktur und der TVL explodierte um das 50-Fache auf$ 50 Milliarden. ZK-ML folgt derselben Kurve – 2024 war das Jahr der Forschung und Machbarkeitsnachweise, 2025 gab es die ersten Produktionseinsätze und 2026 ist das Jahr des Durchbruchs.

Marktsignale bestätigen dies. Der PayFi-Sektor (programmierbare Zahlungsinfrastruktur) erreichte eine Marktkapitalisierung von $2,27 Milliarden mit einem täglichen Volumen von$ 148 Millionen. Institutionen schichten Kapital von spekulativem DeFi in umsatzgenerierende Zahlungsinfrastruktur um – und sie verlangen die Risikomanagement-Tools, um diesen Kapitaleinsatz sicher zu machen. ZK-ML ist das fehlende Puzzleteil.

Der Weg vor uns: Herausforderungen und Chancen​

Trotz des Momentums steht ZK-ML vor echten technischen und adaptiven Hürden. Der Rechenaufwand bleibt erheblich — die Generierung von Zero-Knowledge-Proofs für komplexe ML-Modelle erfordert eine 10 - bis 1000 - mal höhere Rechenleistung als die Standard-Inferenz. Die 65 - fache Beschleunigung von EZKL gegenüber früheren Systemen ist beeindruckend, bedeutet aber immer noch, dass eine Risikoberechnung, die nativ 10 ms dauert, mit ZK-Proofs 650 ms benötigt.

Für den Hochfrequenzhandel und Liquidationssysteme, bei denen Mikrosekunden zählen, ist diese Latenz akzeptabel. Für Echtzeitanwendungen, die Tausende von Inferenzen pro Sekunde erfordern, haben aktuelle ZK-ML-Systeme Schwierigkeiten. Die Branche benötigt eine weitere 5 - bis 10 - fache Leistungssteigerung, bevor ZK-ML für alle DeFi-Anwendungsfälle rentabel wird.

Grenzen der Modellkomplexität sind real. Während Modulus Labs 18 Millionen Parameter demonstrierte, überschreiten modernste KI-Modelle heute 100 Milliarden Parameter (GPT-4) oder sogar Billionen (dichte Transformer-Modelle). Aktuelle ZK-ML-Systeme können Berechnungen in diesem Umfang nicht beweisen. Für DeFi-Risikomodelle — typischerweise 1 - 50 Millionen Parameter — ist dies kein Hindernis. Aber für bahnbrechende KI-Anwendungen benötigt ZK-ML grundlegende algorithmische Durchbrüche.

Die Standardisierung bleibt fragmentiert. EZKL, Modulus, Gensyn und Orion von Worldcoin verwenden alle unterschiedliche Proof-Systeme, Circuit-Designs und Verifizierungsmechanismen. Diese Fragmentierung schafft Integrationsprobleme: Ein DeFi-Protokoll, das EZKL-Proofs verwendet, kann von Modulus generierte Kredit-Scores nicht einfach verifizieren, ohne mehrere Verifizierungssysteme zu betreiben.

Die Branche benötigt ZK-ML-Standards, ähnlich wie ERC-20 Token standardisierte oder EIP-1559 die Gas-Gebühren vereinheitlichte. Die Enterprise Ethereum Alliance arbeitet daran, aber umfassende Standards werden erst Ende 2026 oder 2027 erwartet.

Dennoch stellen die Chancen diese Herausforderungen in den Schatten. Cross-Chain-Credit-Scoring wird möglich, wenn ZK-Proofs das Wallet-Verhalten über mehrere Blockchains hinweg bestätigen können, ohne den zugrunde liegenden Transaktionsgraphen offenzulegen. Ein Nutzer könnte mit einem einzigen kryptographischen Proof belegen: „Ich wurde auf Ethereum, Polygon und Arbitrum noch nie liquidiert“.

Automatisierte risikobasierte Kreditvergabe wandelt sich vom Konzept zur Realität. Stellen Sie sich vor, Sie hinterlegen Sicherheiten in einem DeFi-Protokoll und erhalten sofort eine Kreditlinie, die auf Ihre verifizierbare On-Chain-Historie abgestimmt ist — ohne manuelle Genehmigung, ohne zentrale Auskunftei, nur durch Mathematik und Kryptografie.

Die Automatisierung der regulatorischen Compliance wird machbar. Anstatt Compliance-Teams einzustellen, um DeFi-Transaktionen manuell zu prüfen, setzen Institutionen ZK-ML-Systeme ein, die kryptografisch die AML / KYC-Konformität beweisen, ohne die Identität der Nutzer auf der Blockchain preiszugeben.

Die Vision ist ein Finanzsystem, das gleichzeitig transparenter (jede Entscheidung ist nachweislich korrekt) und privater (sensible Daten verlassen niemals die verschlüsselte Form) ist, als alles, was im traditionellen Finanzwesen oder im aktuellen DeFi möglich ist.

Warum dies über DeFi hinaus wichtig ist​

Die Auswirkungen reichen weit über Kreditprotokolle und Liquidationen hinaus. Jedes System, das verifizierbare KI-Entscheidungen unter Wahrung der Privatsphäre erfordert, wird zu einem ZK-ML-Anwendungsfall:

• KI im Gesundheitswesen: Nachweis einer korrekten Diagnose, ohne Patientenakten offenzulegen
• Lieferkette: Überprüfung der ESG-Konformität durch ML-Audits, ohne proprietäre Lieferantennetzwerke preiszugeben
• Versicherungen: Berechnung von Prämien mithilfe von KI-Risikomodellen, während die Daten der Versicherungsnehmer vertraulich bleiben
• Abstimmungssysteme: Einsatz von ML zur Erkennung gefälschter Stimmzettel bei gleichzeitiger Wahrung des Wahlgeheimnisses

Aber DeFi ist das Testfeld. Es verfügt über die wirtschaftlichen Anreize (Milliarden an gefährdetem TVL), die technische Raffinesse (kryptografie-affine Entwickler) und den regulatorischen Druck (institutionelle Akzeptanz hängt davon ab), um ZK-ML von der Forschung in die Produktion zu bringen.

Wenn ZK-ML zum Standard-Infrastrukturbestandteil der DeFi-Kreditvergabe wird — basierend auf der aktuellen Entwicklungsgeschwindigkeit bis zum 4. Quartal 2026 erwartet — wird die Technologie produktionserprobt und bereit für den Einsatz in jedem Sektor sein, in dem vertrauenswürdige KI eine Rolle spielt.

Das Fazit​

Zero-Knowledge Machine Learning ist nicht nur ein technisches Upgrade — es ist die Vertrauensinfrastruktur, auf die das institutionelle DeFi gewartet hat. Durch die Ermöglichung kryptografisch verifizierbarer Risikobewertungen, die sowohl die Vertraulichkeit proprietärer Modelle als auch die Privatsphäre der Nutzer wahren, löst ZK-ML das regulatorische Paradoxon, das bisher Milliarden an institutionellem Kapital blockiert hat.

Der Zeitplan ist klar: 2024 war das Jahr der Forschung, 2025 gab es die ersten Produktionsumgebungen und 2026 ist das Jahr des Durchbruchs. Mit Frameworks wie EZKL, die 65 - fache Leistungssteigerungen erzielen, Protokollen wie Marine, die latenzfreie Liquidationen demonstrieren, und einer institutionellen Nachfrage, die sich um eine konforme Risikoinfrastruktur kristallisiert, sind die Bedingungen für eine explosive Adoption gegeben.

Für DeFi-Protokolle ist die strategische Frage nicht, ob sie ZK-ML einführen sollen — sondern ob sie den Übergang anführen oder zusehen wollen, wie Wettbewerber das institutionelle Kapital gewinnen, das mit einem verifizierbaren, datenschutzfreundlichen Risikomanagement einhergeht. Für Institutionen, die ihr DeFi-Engagement bewerten, stellen ZK-ML-fähige Protokolle die erste Generation von Blockchain-basierten Finanzen dar, die die Compliance-, Prüfbarkeits- und Risikomanagementstandards erfüllen, die ihre Treuepflicht erfordert.

Die Revolution der Risikobewertung ist da. Die einzige Frage ist, wer sie zuerst aufbaut.

---

BlockEden.xyz bietet Blockchain-Infrastruktur der Enterprise-Klasse mit branchenführender Zuverlässigkeit und Leistung. Erkunden Sie unsere API-Services, um auf Fundamenten aufzubauen, die für die Ewigkeit ausgelegt sind.

Quellen​

• Zero-Knowledge Machine Learning (zkML) | Ledger
• ZKML: Verifizierbares maschinelles Lernen mittels Zero-Knowledge Proof - Kudelski Security
• KI-Agenten im DeFi-Sektor: Autonome Risikomanagementsysteme erklärt (2026) | Outlook India
• Dezentrales Zero-Knowledge Machine Learning: Auswirkungen und Chancen - Struck Capital
• Der ultimative Leitfaden zu ZKML (2025)
• Benchmarking von ZKML-Frameworks - EZKL Blog
• Der aktuelle Stand von Zero-Knowledge Machine Learning (zkML)
• Marine: Compound Liquidation Keeper mit zkGraph — ORA
• Ein vollständiges, die Privatsphäre schützendes Kreditbewertungssystem unter Verwendung von Blockchain und Zero-Knowledge Proof | IEEE
• Ermöglichung von datenschutzfreundlichem und verteiltem intelligentem Credit Scoring durch Zero-Knowledge Proof und funktionale Verschlüsselung | Springer
• EEA DeFi Risikobewertungs-Leitlinien - Version 1
• Berücksichtigung der institutionellen DeFi-Integration: Umgang mit Risiken illegaler Finanzgeschäfte - Georgetown
• Die nächste Phase von institutionellem DeFi auf XRPL: Kredit, Compliance und Vertraulichkeit

Während AWS $ 23 pro Terabyte monatlich für Standardspeicher berechnet, kostet Filecoin $ 0,19 für die gleiche Kapazität. Doch der Preis allein gewinnt niemals Kriege um die Infrastruktur. Die eigentliche Frage ist, ob dezentralisierter Speicher mit zentralisierten Cloud-Anbietern in den Kennzahlen mithalten kann, auf die es wirklich ankommt: Geschwindigkeit, Zuverlässigkeit und Entwicklererfahrung. Am 18. November 2025 gab Filecoin mit dem Start der Onchain Cloud eine klare Antwort – eine grundlegende Transformation, die 2,1 Exbibytes an Archivspeicher in eine programmierbare, verifizierbare Infrastruktur verwandelt, die für KI-Workloads und Echtzeitanwendungen konzipiert ist.

Dies ist keine schrittweise Verbesserung. Es ist Filecoins Schwenk vom „Blockchain-Speichernetzwerk“ zur „dezentralisierten Cloud-Plattform“, komplett mit automatisierten Zahlungen, kryptografischer Verifizierung und Leistungsgarantien. Nach monatelangen Tests mit über 100 Entwicklerteams startete das Mainnet im Januar 2026 und positionierte Filecoin so, dass es einen bedeutenden Anteil am 12-Milliarden-Dollar-Markt für KI-Infrastruktur erobern kann.

Die Onchain Cloud Architektur: Drei Säulen des programmierbaren Speichers​

Filecoin Onchain Cloud führt drei Kerndienste ein, die es Entwicklern gemeinsam ermöglichen, auf einer verifizierbaren, dezentralisierten Infrastruktur aufzubauen, ohne die Komplexität, die traditionell mit Blockchain-Speicher verbunden ist.

Filecoin Warm Storage Service hält Daten online und durch kontinuierliche Onchain-Beweise nachweislich verfügbar. Im Gegensatz zum Cold Archival Storage, der Abrufverzögerungen erfordert, hält Warm Storage die Daten in einem zugänglichen Zustand, während er weiterhin die kryptografische Verifizierung von Filecoin nutzt. Dies adressiert die Haupteinschränkung, die Filecoin bisher auf Backup- und Archivierungsszenarien beschränkte – die Daten waren nicht schnell genug für aktive Workloads.

Filecoin Pay automatisiert nutzungsbasierte Zahlungen durch Smart Contracts und gleicht Transaktionen erst ab, wenn die Bereitstellung Onchain bestätigt wurde. Dies ist eine grundlegende Infrastruktur für Pay-as-you-go-Cloud-Dienste: Zahlungen fließen automatisch, sobald Dienste nachgewiesen sind, wodurch manuelle Rechnungsstellung, Kreditsysteme und Vertrauensannahmen entfallen. Tausende von Zahlungskanälen haben bereits Transaktionen während der Testnet-Phase verarbeitet.

Filecoin Beam ermöglicht gemessene, incentivierte Datenabrufe mit leistungsbasierten Anreizen. Speicheranbieter konkurrieren nicht nur um die Speicherkapazität, sondern auch um die Abrufgeschwindigkeit und Zuverlässigkeit. Dies schafft einen Abrufmarkt, auf dem Anbieter für ihre Leistung belohnt werden, was direkt die historische Schwäche des dezentralisierten Speichers anspricht: unvorhersehbare Abrufzeiten.

Entwickler greifen über das Synapse SDK auf diese Dienste zu, das die Komplexität der direkten Interaktion mit dem Filecoin-Protokoll abstrahiert. Frühe Integrationen kommen von der ERC-8004-Community, dem Ethereum Name Service (ENS), KYVE, Monad, Safe, Akave und Storacha – Projekten, die verifizierbaren Speicher für alles benötigen, vom Blockchain-Zustand bis hin zur dezentralisierten Identität.

Kryptografische Beweise: Das technische Fundament von verifizierbarem Speicher​

Was Filecoin von zentralisierten Cloud-Anbietern unterscheidet, ist nicht nur die Dezentralisierung – es ist der kryptografische Beweis, dass Speicherverpflichtungen eingehalten werden. Dies ist wichtig für KI-Trainingsdatensätze, die Herkunftsgarantien benötigen, für stark regulierte Branchen, die Audit-Trails erfordern, und für jede Anwendung, bei der Datenintegrität nicht verhandelbar ist.

Proof-of-Replication (PoRep) erzeugt durch einen rechenintensiven Sealing-Prozess eine eindeutige Kopie der Originaldaten eines Sektors. Dies beweist, dass ein Speicheranbieter eine physisch eindeutige Kopie der Daten des Clients speichert und nicht nur vorgibt, sie zu speichern oder eine einzige Kopie für mehrere Clients verwendet. Der versiegelte Sektor wird einer langsamen Kodierung unterzogen, was es für unehrliche Anbieter unmöglich macht, Daten bei Bedarf zu regenerieren, um Speicher vorzutäuschen.

Der Sealing-Prozess erzeugt einen Multi-SNARK-Beweis und eine Reihe von Verpflichtungen (CommR), die den versiegelten Sektor mit den ursprünglichen unversiegelten Daten verknüpfen. Diese Verpflichtungen sind auf der Blockchain öffentlich verifizierbar und erstellen eine unveränderliche Aufzeichnung von Speicher-Deals.

Proof-of-Spacetime (PoSt) beweist die kontinuierliche Speicherung über die Zeit durch regelmäßige kryptografische Challenges. Speicheranbieter haben eine 30-minütige Frist, um auf WindowPoSt-Herausforderungen zu reagieren, indem sie zk-SNARK-Beweise einreichen, die verifizieren, dass sie immer noch genau die Bytes besitzen, zu deren Speicherung sie sich verpflichtet haben. Dies geschieht kontinuierlich – nicht nur bei der Einleitung eines Speicher-Deals, sondern während seiner gesamten Dauer.

Der Verifizierungsprozess wählt zufällig Blattknoten aus dem kodierten Replikat aus und führt Merkle-Inklusionsbeweise durch, um zu zeigen, dass der Anbieter die spezifischen Bytes hat, die dort sein sollten. Die Anbieter verwenden dann den privat gespeicherten CommRLast, um zu beweisen, dass sie eine Wurzel für das Replikat kennen, die sowohl mit den Inklusionsbeweisen übereinstimmt als auch das öffentlich bekannte CommR ableiten kann. Die letzte Stufe komprimiert diese Beweise in einen einzigen zk-SNARK für eine effiziente Onchain-Verifizierung.

Das Versäumnis, WindowPoSt-Beweise innerhalb des 30-Minuten-Fensters einzureichen, löst Slashing aus: Der Speicheranbieter verliert einen Teil seiner Sicherheiten (die an die Adresse f099 verbrannt werden), und seine Speicherkraft wird reduziert. Dies schafft wirtschaftliche Konsequenzen für Speicherausfälle und richtet die Anreize der Anbieter auf die Netzwerkzuverlässigkeit aus.

Dieses zweistufige Beweissystem – PoRep für die Erstverifizierung, PoSt für die kontinuierliche Validierung – schafft verifizierbaren Speicher, den zentralisierte Clouds schlichtweg nicht bieten können. Wenn AWS sagt, dass sie Ihre Daten speichern, vertrauen Sie auf deren Infrastruktur und rechtliche Vereinbarungen. Wenn Filecoin es sagt, haben Sie einen kryptografischen Beweis, der alle 30 Minuten aktualisiert wird.

KI-Infrastrukturmarkt: Wo dezentraler Speicher auf echten Bedarf trifft​

Der Zeitpunkt des Launches der Filecoin Onchain Cloud fällt mit einer grundlegenden Verschiebung der KI-Infrastrukturanforderungen zusammen. Da sich künstliche Intelligenz von einer Forschungsneugier zu einer Produktionsinfrastruktur entwickelt, die ganze Branchen umgestaltet, wird der Speicherbedarf deutlich und massiv.

KI-Modelle benötigen massive Datensätze für das Training. Moderne große Sprachmodelle (LLMs) trainieren auf Hunderten von Milliarden Token. Computer-Vision-Modelle benötigen Millionen von beschrifteten Bildern. Empfehlungssysteme nehmen Verhaltensdaten von Nutzern in großem Umfang auf. Diese Datensätze passen nicht in den lokalen Speicher – sie benötigen Cloud-Infrastruktur. Sie benötigen aber auch Provenienzgarantien: Manipulierte Trainingsdaten erzeugen manipulierte Modelle, und es gibt keinen kryptografischen Weg, die Datenintegrität auf AWS zu verifizieren.

Kontinuierlicher Datenzugriff für Inferenz. Einmal trainiert, benötigen KI-Modelle ständigen Zugriff auf Referenzdaten, um Vorhersagen zu treffen. Retrieval-Augmented Generation (RAG)-Systeme fragen Wissensdatenbanken ab, um die Ausgaben von Sprachmodellen zu fundieren. Echtzeit-Empfehlungs-Engines rufen Nutzerprofile und Artikelkataloge ab. Dies sind keine einmaligen Abrufe – es handelt sich um kontinuierliche, hochfrequente Zugriffsmuster, die schnellen und zuverlässigen Speicher erfordern.

Verifizierbare Datenprovenienz zur Verhinderung von Modell-Poisoning. Wenn ein Finanzinstitut ein Modell zur Betrugserkennung trainiert, muss es wissen, dass die Trainingsdaten nicht manipuliert wurden. Wenn eine Gesundheits-KI Patientenakten analysiert, ist die Herkunft (Provenienz) für Compliance und Haftung von Bedeutung. Die PoRep- und PoSt-Proofs von Filecoin erstellen einen Audit-Trail, den zentralisierter Speicher nicht replizieren kann, ohne vertrauenswürdige Zwischenhändler einzuführen.

Dezentraler Speicher zur Vermeidung von Konzentrationsrisiken. Die Abhängigkeit von einem einzigen Cloud-Anbieter schafft systemische Risiken. AWS-Ausfälle haben bereits erhebliche Teile des Internets lahmgelegt. Störungen bei Google Cloud beeinträchtigen Millionen von Diensten. Für eine KI-Infrastruktur, die kritische Systeme stützt, ist die geografische und organisatorische Verteilung keine philosophische Präferenz, sondern eine Anforderung an das Risikomanagement.

Das Filecoin-Netzwerk hält 2,1 Exbibyte an zugesichertem Speicher mit einer zusätzlichen Rohkapazität von 7,6 EiB. Die Netzwerkauslastung ist auf 36 % gestiegen (gegenüber 32 % im zweiten Quartal 2025), wobei die aktiven gespeicherten Daten bei nahezu 1.110 Petabyte liegen. Im Jahr 2025 wurden rund 2.500 Datensätze aufgenommen, was auf eine stetige Akzeptanz in Unternehmen hindeutet.

Das wirtschaftliche Argument ist überzeugend: Filecoin kostet im Durchschnitt 0,19 $pro Terabyte monatlich, verglichen mit etwa 23$ bei AWS für die gleiche Kapazität – eine Kostensenkung von 99 %. Aber das eigentliche Wertversprechen ist nicht nur billigerer Speicher. Es ist verifizierbarer Speicher in großem Maßstab mit programmierbarer Infrastruktur, der über entwicklerfreundliche Tools bereitgestellt wird.

Wettbewerb gegen die zentrale Cloud: Wo Filecoin im Jahr 2026 steht​

Die Frage ist nicht, ob dezentraler Speicher Vorteile hat – verifizierbare Proofs, Zensurresistenz und Kosteneffizienz liegen auf der Hand. Die Frage ist, ob diese Vorteile schwer genug wiegen, um die verbleibenden Nachteile zu überwinden: vor allem, dass das Speichern und Abrufen bei Filecoin immer noch langsamer und komplexer ist als bei zentralisierten Alternativen.

Performance-Lücke schließt sich, ist aber noch nicht geschlossen. AWS S3 liefert Latenzen im einstelligen Millisekundenbereich für Lesevorgänge. Filecoin Warm Storage und Beam-Abrufe können da – noch – nicht mithalten. Viele Workloads benötigen jedoch keine Millisekunden-Latenz. KI-Trainingsläufe greifen auf große Datensätze in sequenziellen Batch-Lesevorgängen zu. Archivspeicher für Compliance priorisiert die Geschwindigkeit nicht. Content Delivery Networks (CDNs) cachen häufig genutzte Daten unabhängig von der Geschwindigkeit des Ursprungsspeichers.

Das Onchain-Cloud-Upgrade führt eine Finalität von unter einer Minute für Speicherzusagen ein, eine erhebliche Verbesserung gegenüber den früheren mehrstündigen Sealing-Zeiten. Dies konkurriert zwar nicht mit AWS bei latenzkritischen Anwendungen, eröffnet aber neue Anwendungsfälle, die zuvor auf Filecoin unpraktisch waren.

Verbesserung der Developer Experience durch Abstraktion. Die direkte Interaktion mit dem Filecoin-Protokoll erfordert ein Verständnis von Sektoren, Sealing, WindowPoSt-Challenges und Zahlungskanälen – Konzepte, die Entwicklern fremd sind, die an die einfache API von AWS gewöhnt sind: Bucket erstellen, Objekt hochladen, Berechtigungen setzen. Das Synapse SDK abstrahiert diese Komplexität und bietet vertraute Schnittstellen, während es die kryptografische Verifizierung der Proofs im Hintergrund übernimmt.

Die frühe Akzeptanz durch ENS, KYVE, Monad und Safe deutet darauf hin, dass die Developer Experience eine Usability-Schwelle überschritten hat. Dies sind keine Blockchain-nativen Speicherprojekte, die aus ideologischen Gründen mit Filecoin experimentieren – es sind Infrastrukturprojekte mit echtem Speicherbedarf, die verifizierbaren dezentralen Speicher gegenüber zentralisierten Alternativen bevorzugen.

Zuverlässigkeit durch ökonomische Anreize versus vertragliche SLAs. AWS bietet für S3 Standard eine Haltbarkeit von 99,999999999 % (11 Neunen) durch Multi-Region-Replikation und vertragliche Service-Level-Agreements (SLAs). Filecoin erreicht Zuverlässigkeit durch ökonomische Anreize: Speicheranbieter, die WindowPoSt-Challenges nicht bestehen, verlieren Sicherheiten (Collateral) und Speicherkraft. Dies schafft unterschiedliche Risikoprofile – das eine abgesichert durch Unternehmensgarantien, das andere durch kryptografische Proofs und finanzielle Strafen.

Für Anwendungen, die sowohl kryptografische Verifizierung als auch hohe Verfügbarkeit benötigen, umfasst die optimale Architektur wahrscheinlich Filecoin als verifizierbaren Referenzspeicher plus CDN-Caching für schnellen Abruf. Dieser hybride Ansatz nutzt die Stärken von Filecoin (Verifizierbarkeit, Kosten, Dezentralisierung) und mildert gleichzeitig dessen Schwächen (Abrufgeschwindigkeit) durch Edge-Caching.

Marktpositionierung: Kein Ersatz für AWS, sondern Erfüllung anderer Anforderungen. Filecoin wird AWS beim Allzweck-Cloud-Computing nicht ersetzen. Das muss es auch nicht. Der adressierbare Markt sind Anwendungen, bei denen verifizierbarer Speicher, Zensurresistenz oder Dezentralisierung einen Wert bieten, der über Kosteneinsparungen hinausgeht: KI-Trainingsdatensätze mit Provenienzanforderungen, Blockchain-Status, der permanente Verfügbarkeit benötigt, wissenschaftliche Forschungsdaten, die langfristige Integritätsgarantien erfordern, und regulatorisch stark geprägte Branchen, die kryptografische Audit-Trails benötigen.

Der 12-Milliarden-Dollar-Markt für KI-Infrastruktur stellt eine Teilmenge der gesamten Cloud-Ausgaben dar, in der das Wertversprechen von Filecoin am stärksten ist. Selbst die Eroberung von 5 % dieses Marktes würde eine jährliche Speichernachfrage von 600 Millionen Dollar bedeuten – ein bedeutendes Wachstum gegenüber dem aktuellen Nutzungsniveau.

Von 2,1 EiB zur Zukunft der verifizierbaren Infrastruktur​

Die gesamte zugesagte Speicherkapazität von Filecoin ist im Laufe des Jahres 2025 tatsächlich zurückgegangen – von 3,8 Exbibyte im ersten Quartal auf 3,3 EiB im zweiten Quartal und 3,0 EiB im dritten Quartal –, da ineffiziente Storage Provider nach dem Netzwerk v27 "Golden Week"-Upgrade ausschieden. Dieser Kapazitätsrückgang bei gleichzeitig steigender Auslastung (von 30 % auf 36 %) deutet auf einen reifenden Markt hin: geringere Gesamtkapazität, aber ein höherer Prozentsatz an bezahltem Speicher.

Das Netzwerk erwartet bis Ende 2025 über 1 Exbibyte an bezahlten Storage-Deals, was einen Übergang von spekulativer Kapazitätsbereitstellung zur tatsächlichen Kundennachfrage darstellt. Das ist wichtiger als reine Kapazitätszahlen – die Auslastung signalisiert echten Mehrwert und nicht nur Miner, die Speicher bereitstellen in der Hoffnung auf künftige Nachfrage.

Die Transformation zur Onchain Cloud positioniert Filecoin für einen anderen Wachstumspfad: nicht die Maximierung der Gesamtspeicherkapazität, sondern die Maximierung der Speicherauslastung durch Dienste, die Entwickler tatsächlich benötigen. Warm Storage, verifizierbares Retrieval und automatisierte Zahlungen adressieren die Barrieren, die Filecoin bisher auf Nischenanwendungen für die Archivierung beschränkt haben.

Die frühe Mainnet-Adoption wird der entscheidende Test sein. Entwicklerteams haben im Testnet getestet, aber Produktions-Deployments mit echten Daten und echten Zahlungen werden zeigen, ob Performance, Zuverlässigkeit und Developer Experience den für Infrastrukturentscheidungen erforderlichen Standards entsprechen. Die Projekte, die bereits experimentieren – ENS für dezentrale Identitätsspeicherung, KYVE für Blockchain-Datenarchive, Safe für Multi-Signature-Wallet-Infrastruktur – lassen auf vorsichtigen Optimismus schließen.

Die Marktchance für KI-Infrastruktur ist real, aber nicht garantiert. Filecoin steht im Wettbewerb mit zentralisierten Cloud-Anbietern, die massive Vorsprünge bei Performance und Entwickler-Ökosystemen haben, sowie dezentralen Speicher-Wettbewerbern wie Arweave (permanenter Speicher) und Storj (performanceorientierte S3-Alternative). Ein Sieg erfordert Umsetzung: Zuverlässigkeit, die Produktionsstandards erfüllt, wettbewerbsfähige Preise bei der Skalierung des Netzwerks sowie die kontinuierliche Verbesserung von Entwickler-Tools und Dokumentationen.

Die Transformation von Filecoin von "Blockchain-Speicher" zu einer "programmierbaren Onchain Cloud" stellt eine notwendige Evolution dar. Die Frage im Jahr 2026 ist nicht, ob dezentraler Speicher theoretische Vorteile hat – die hat er zweifellos. Die Frage ist, ob sich diese Vorteile in Entwickler-Adoption und Kundennachfrage in großem Maßstab übersetzen lassen. Die kryptographischen Beweise sind vorhanden. Die wirtschaftlichen Anreize sind abgestimmt. Jetzt kommt der schwierige Teil: der Aufbau einer Cloud-Plattform, der Entwickler ihre Produktions-Workloads anvertrauen.

BlockEden.xyz bietet Enterprise-Grade-Infrastruktur für Blockchain-Entwickler, die auf verifizierbaren Grundlagen aufbauen. Entdecken Sie unseren API-Marktplatz, um auf die Infrastruktur zuzugreifen, die Sie für langlebige Anwendungen benötigen.

Quellen​

• Introducing Filecoin Onchain Cloud: Verifiable, Developer-Owned Infrastructure
• Filecoin Onchain Cloud: The Network's Next Evolution | Messari
• State of Filecoin Q2 2025 | Messari
• State of Filecoin Q3 2025 | Messari
• Filecoin Reaches Historic Storage Milestone
• Why Filecoin's Jan 2026 1.58 Rally & Onchain Cloud Could Make It AI Infrastructure's 12B Hidden Gem
• Proofs | Filecoin Docs
• Storage proving | Filecoin Docs
• Filecoin features: verifiable storage

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.