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

Zero-Knowledge ist für ausgewählte KYC-, Alters-, Supply-Chain-, Credential- und Verifiable-ML-Flows eine reale Integrationsoption. Production Readiness hängt von Proof-Aussage, Issuer, Zielhardware und Audit-Oberfläche ab. Die Kostenbänder in diesem Post sind Wavect-Planungsschätzungen, keine Branchenbenchmarks oder Fixangebote.

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

Ein Satz: Beweise eine Tatsache über private Daten, ohne die Daten preiszugeben. Das trifft auf überraschend viele Compliance- und Privacy-Probleme zu, auf die Regulatoren seit 2024 stärker drängen. 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. EU-Institutionen und mehrere Mitgliedstaaten bewegen sich zu stärkerer, privacy-preserving Age Assurance. Der Rechtsstandard und die akzeptierte Methode hängen von Dienst und Jurisdiktion ab; eine pauschale Aussage gegen Selbsterklärung wäre falsch. Pass-Uploads erzeugen zusätzlich UX- und Datenschutzrisiken.

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 Selective Disclosure und bei Bedarf ein Predikat-Proof. W3C VC Data Model 2.0 ist eine Recommendation; die W3C-BBS-Cryptosuite war im April 2026 noch Candidate Recommendation Draft.

Komplexität. Medium. Issuer-Integration, Revocation, Wallet-Interoperabilität und Reife der gewählten Cryptosuite sind die Hauptprobleme.

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

Use-Case 5: Confidential ML-Inferenz

Das Problem. Ein Nutzer will Evidenz, dass ein bestimmtes Modell den Output erzeugt hat. Input- und Modell-Privacy sind getrennte Anforderungen, die zusätzlich FHE, MPC oder TEE brauchen können.

Die passende ZK-Tech. zkML für Proof of Inference. Hersteller melden inzwischen Llama-Klasse, aber Latenz, Kosten, Operator-Support, Quantisierung und Security müssen für das konkrete Modell reproduziert werden.

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 Planungsbild über alle sechs aus?

Die Engineering-Wochen sind Wavect-Schätzungen für einen engen ersten Release. Audit, Issuer-Onboarding, Zertifizierung, Legal Review und Produktions-Prover-Infrastruktur kommen separat dazu.

"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?

Das hängt von Circuit, Proof-System, Implementierung, Hardware, Memory, Wrapper und Runtime ab. Mopro veröffentlicht Werte von Hunderten Millisekunden bis zu vielen Sekunden; einige Halo2-Verifikationen überschreiten 100 Millisekunden, große Circuits erreichen Sekunden oder scheitern am Mobile-Memory. Benchmarke Prover und Verifier auf den Zielgeräten.

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

Ein kleines Team kann ein auditiertes Credential-Protokoll oder SDK integrieren. Einen Production Circuit zu schreiben oder wesentlich zu ändern erzeugt aber eine andere Assurance-Last. Ramp-up ersetzt kein Protocol Review, Circuit Testing, Fuzzing, Version Pinning und unabhängiges Audit.

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

Beides lässt sich kombinieren: Eine Account-Abstraction-Wallet kann einen frischen Credential- oder ZK-Proof in ihrer Authorization Policy verlangen. Das ist ein nützliches Muster, aber noch kein universeller Standard und bringt Recovery-, Revocation-, Replay-, Privacy- und Upgrade-Anforderungen mit.

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.

Wenn du tiefer gehen willst: Unser pragmatischer Guide zum Bauen mit ZK und FHE behandelt das Entscheidungs-Framework und die Failure-Modes, der 2026er-ZK-State-of-the-Art-Post enthält aktuelle zkVM-Benchmarks und Proving-Kosten, und ZK vs FHE vs MPC vs TEE vergleicht die Alternativen.

Quellen und Verifikation

1. European Commission (2026). European Digital Identity and the end-of-2026 wallet availability deadline. commission.europa.eu
2. European Commission (2026). EU age-verification blueprint and implementation status. digital-strategy.ec.europa.eu
3. W3C (2025). Verifiable Credentials Data Model 2.0. w3.org
4. W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. w3.org
5. Mopro (2026). Mobile and browser proof-generation and verification benchmarks. zkmopro.org
6. Lagrange (2026). DeepProve open-source release and vendor-reported zkML results. lagrange.dev