Zero-Knowledge-Proofs außerhalb von Crypto: KYC, Altersverifikation, Supply Chain

Zero-Knowledge entkommt der Crypto-Sandbox. Die Technologie, mit der du eine Aussage beweisen kannst, ohne die zugrundeliegenden Daten preiszugeben, ist jetzt ein tragfähiges Integrationswerkzeug für KYC, Altersverifikation, Supply-Chain-Provenance, Credential-Checks und Confidential ML. Die Latte liegt niedriger als vor drei Jahren. Das Tooling ist real. Die Audit-Landschaft ist dünner als bei Crypto, aber sie existiert. Dieser Post deckt sechs konkrete Nicht-Crypto-Use-Cases ab, die Wavect gescopt oder gebaut hat, mit Kostenbändern, Komplexitäts-Ratings und der ehrlichen Q&A, ob es das für dein Team wert ist.

Was löst ZK für Nicht-Crypto-Produkte tatsächlich?

Ein Satz: Beweise eine Tatsache über private Daten, ohne die Daten preiszugeben. Das mappt auf eine überraschende Zahl von Compliance- und Privacy-Problemen, die Regulatoren seit 2024 stärker pushen. Age Gates, EU-Residenz-Checks, Supply-Chain-Provenance, Credential-Verifikation, private ML-Inferenz. Das alles wurde früher gelöst, indem das zugrundeliegende Dokument übergeben oder einem zentralen Attester vertraut wurde. ZK gibt dir eine dritte Option.

Use-Case 1: Privacy-preserving KYC

Das Problem. Dein Produkt muss wissen, dass ein Nutzer über 18 und EU-Resident ist. Es muss nicht das Geburtsdatum, die Straße oder die Passnummer kennen. Diese Daten zu speichern ist eine Verbindlichkeit unter DSGVO und ein verlockendes Ziel für Angreifer.

Die passende ZK-Tech. zk-SNARKs über ein Verifiable Credential, signiert von der Government-Wallet des Nutzers oder einem Attestation-Provider. Groth16 oder PLONK, je nach Circuit-Komplexität. Der eIDAS-2.0-Wallet-Rollout in der EU macht die Attestation-Seite 2026 zunehmend tragfähig.

Komplexität. Medium. Der Circuit ist klein. Die Integration mit Attestation-Providern ist die eigentliche Arbeit.

Kostenband. Engineering-Wochen: 4 bis 8 für eine Produktionsintegration. Verifier-Infra-Kosten: vernachlässigbar. Audit-Kosten: separates Engagement mit einer ZK-Spezialfirma.

Use-Case 2: Altersverifikation für regulierte Inhalte

Das Problem. Die EU-Regeln zu Altersverifikation für Adult Content, Glücksspiel und bestimmte regulierte Content-Kategorien haben sich 2024 und 2025 verschärft. Selbsterklärung ist in mehreren Jurisdiktionen nicht mehr konform. Einen Pass hochzuladen ist eine UX-Katastrophe und ein Datenschutz-Risiko.

Die passende ZK-Tech. Ein kleiner Circuit, der "Geburtsjahr liegt am oder vor X" aus einem behördlichen Credential beweist. zk-SNARKs sind hier meist Overkill; ein eng gefasster Circuit mit bekanntem Attester gibt dir schnelle Proofs und kleine Verifier.

Komplexität. Niedrig bis Medium, größtenteils niedrig, sobald die Attestation-Quelle gewählt ist.

Kostenband. 3 bis 6 Engineering-Wochen für einen Single-Jurisdiktion-Launch.

Use-Case 3: Supply-Chain-Provenance

Das Problem. Du musst beweisen, dass deine Sendung zertifizierte Stationen (Ursprung, Verarbeitung, Versand, Zoll) durchlaufen hat, ohne deine spezifischen Lieferanten, Handelsrouten oder kommerziellen Bedingungen an Wettbewerber oder Gegenparteien preiszugeben.

Die passende ZK-Tech. zk-STARKs wegen Transparenz (kein Trusted Setup) und Post-Quantum-Resistenz, oder rekursive SNARKs, wenn Proof-Größe mehr zählt als Prover-Zeit. Proofs werden über Stationen aggregiert; nur der finale Verifier sieht das Ergebnis.

Komplexität. Hoch. Der schwere Teil ist das Datenmodell, nicht die Kryptographie. Lieferanten zum Attestieren zu bewegen, ist der Workstream.

Kostenband. 8 bis 16 Engineering-Wochen für einen Piloten, der eine Produktlinie abdeckt.

Use-Case 4: Private Credentials

Das Problem. Eine Plattform will "dieser Nutzer hält einen Abschluss einer akkreditierten Universität" oder "dieser Nutzer ist ein lizenzierter Profi" verifizieren, ohne das vollständige Dokument zu speichern oder preiszugeben.

Die passende ZK-Tech. Verifiable Credentials plus ein ZK-Selective-Disclosure-Proof. zk-SNARKs funktionieren hier gut. Standards wie W3C VC und BBS+-Signaturen passen natürlich zusammen.

Komplexität. Medium. Die Standards sind reif; die Issuer-Seite ist die Friction.

Kostenband. 4 bis 10 Engineering-Wochen je nach Issuer-Integrationen.

Use-Case 5: Confidential ML-Inferenz

Das Problem. Ein Nutzer will ein Modell auf privatem Input laufen lassen und vertrauen, dass das richtige Modell genutzt wurde, ohne dass der Input dem Modell-Host oder die Modell-Weights dem Nutzer preisgegeben werden.

Die passende ZK-Tech. zkML-Frameworks. Das ist der Front der Liste. Proof-Generierung ist schwer. Use-Cases, in denen ein 30-Sekunden- bis mehrminütiger Proof akzeptabel ist.

Komplexität. Hoch. Ehrliche Einordnung: Das ist 2026 noch bleeding edge. Siehe unseren Bleeding-Edge-Service, wie wir dieses Risiko angehen.

Kostenband. 12 bis 24 Engineering-Wochen für einen engen vertikalen Piloten.

Use-Case 6: Dezentrale-Identität-Selective-Disclosure

Das Problem. Ein Nutzer hat ein Wallet, das mehrere Credentials hält. Die Relying Party sollte nur das spezifische Attribut erfahren, das sie braucht (Residenz, Beruf, Altersband), nichts anderes.

Die passende ZK-Tech. BBS+-Signaturen mit Selective Disclosure, plus ein optionaler ZK-Predikat-Proof für abgeleitete Attribute. Funktioniert sauber mit Account-Abstraction-Wallets auf der EVM-Seite.

Komplexität. Medium.

Kostenband. 5 bis 10 Engineering-Wochen.

Wie sieht das Kostenbild über alle sechs aus?

"ZK wird endlich ein Integrationswerkzeug, kein nur-Crypto-Forschungsprojekt."

Q&A: Ist ZK Overkill für KYC?

Für manche Teams, ja. Wenn du KYC an einen regulierten Anbieter abgeben kannst und die Daten nicht selbst speicherst, hast du für die meisten Jurisdiktionen schon eine akzeptable Antwort. ZK wird attraktiv, wenn (a) du wiederholte Verifikationen willst, ohne den Nutzer erneut zu fragen, (b) du in einer Jurisdiktion operierst, in der der eIDAS-2.0-Wallet-Flow live ist und Nutzer ihn erwarten, oder (c) die Kosten eines Breachs deiner KYC-Datenbank existenziell sind. Wenn eines davon gilt, zahlt sich ZK schnell aus.

Q&A: Wie lange dauert Proof-Generierung tatsächlich?

Hängt stark von Circuit-Größe und Prover ab. Für kleine KYC-artige Circuits läuft die Proof-Generierung in wenigen hundert Millisekunden auf einem modernen Laptop oder im Browser via wasm. Für komplexe Multi-Attestation-Circuits erwarte Sekunden. Für zkML erwarte zehn Sekunden bis Minuten. Verifikation ist immer günstig, typisch unter 100 ms. Plane die UX um die Prover-Seite, nicht die Verifier-Seite.

Q&A: Kann ein kleines Team das ohne Kryptographen bauen?

Für Use-Cases 1, 2, 4 und 6, ja, mit Sorgfalt. Das Tooling (Circom, Noir, Halo2, plonky2, neuere zkVMs) ist so weit gereift, dass ein starker Senior-Engineer mit wenigen Wochen fokussiertem Ramp-up einen Produktions-Circuit ausliefern kann. Für Use-Cases 3 und 5, nein. Du willst einen Kryptographie-Spezialisten im Team oder als externen Reviewer, plus ein ordentliches externes Audit. Wir holen Domain-Spezialisten dazu, wenn nötig. Siehe unseren Zero-Knowledge-Service, wie das funktioniert.

Q&A: Was ist mit Account-Abstraction und ZK zusammen?

Starke Kombination. AA-Wallets können ZK-Proofs on-chain oder off-chain als Teil ihrer Signatur-Logik verifizieren. Das schaltet Flows frei wie "dieses Wallet kann nur transagieren, wenn ein frischer Age-Verification-Proof angehängt ist". Für Web3-Produkte mit regulierten User-Basen wird das 2026 zum Standard-Muster.

Q&A: Müssen Smart Contracts überhaupt beteiligt sein?

Nein. ZK funktioniert komplett off-chain. Ein normales Web2-Backend kann einen SNARK oder STARK mit einer kleinen Bibliothek verifizieren. Die Chain wird nur gebraucht, wenn du öffentliche, zensurresistente Verifikation oder Komposabilität mit On-Chain-Logik willst. Die meisten KYC- und Altersverifikations-Deployments, die wir gescopt haben, sind rein off-chain.