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

Zero-Knowledge ist nicht mehr auf Kryptowährungssysteme beschränkt. Es kann ausgewählte KYC-, Altersverifikations-, Supply-Chain-, Credential- und Verifiable-ML-Flows unterstützen. Production Readiness hängt von Proof-Aussage, Credential-Quelle, Zielhardware, Revocation und Recovery, Implementierungsreife sowie Audit-Oberfläche ab. Dieser Beitrag untersucht sechs mögliche Non-Crypto-Use-Cases. Die Kostenbänder 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 zu prüfende ZK-Tech. Ein unterstützter Selective-Disclosure- oder Predicate-Proof-Flow, der die erforderliche Altersgrenze anhand eines qualifizierten Credentials belegt. Wähle die einfachste interoperable Methode, die die Anforderungen des Dienstes an Assurance, Datenschutz, Revocation, Performance und Recht erfüllt. Gehe nicht davon aus, dass ein eigener Circuit nötig ist.

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 zu prüfende ZK-Tech. Ein transparentes Proof-System oder ein SNARK-basiertes Design, möglicherweise mit Rekursion oder Aggregation. Setup-Annahmen, Proof-Größe, Prover-Kosten, Verifier-Umgebung, kryptografische Abhängigkeiten und Implementierungsreife müssen gemeinsam bewertet werden. Ein hashbasiertes Proof-System macht nicht jede umgebende Komponente postquanten-sicher.

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. Ein herkömmliches Backend kann unterstützte Proofs ohne Blockchain verifizieren. Nutze einen Onchain-Verifier nur, wenn das Produkt dessen öffentlichen Zustand, gemeinsame Ausführung oder Komposabilität braucht und die daraus entstehenden Nachteile bei Datenschutz, Gebühren, Upgrades und Betrieb akzeptiert. Die richtige Platzierung hängt von Verifier, Vertrauensmodell, Nutzern und rechtlichen Pflichten ab.

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