TECHNOLOGIE

Zero-Knowledge

Zero-Knowledge Proof (ZK)

Eine kryptographische Technik, die eine Aussage als wahr beweist, ohne die zugrundeliegenden Daten preiszugeben.

Zuletzt geprüft: vonKevin Riedl wiki ↗

Ein Zero-Knowledge-Beweis erlaubt einer Partei (dem Prover), eine andere Partei (den Verifier) davon zu überzeugen, dass sie eine Information besitzt, ohne die Information selbst zu offenbaren. Klassisches Beispiel: nachweisen, dass man über 18 ist, ohne das Geburtsdatum zu nennen.

In Produktion erscheinen ZK-Verfahren in zwei Ausprägungen. ZK-SNARKs sind kleiner und schneller verifizierbar, brauchen aber ein Trusted Setup. ZK-STARKs sind größer und langsamer, benötigen kein Trusted Setup und sind post-quanten-sicher. Die meisten Chains bieten inzwischen fertige Circuits für gängige Beweise (Identität, Saldo, Wahlberechtigung) an, sodass kein Kryptograph im Haus nötig ist, um einen Smart Contract zu shippen, der sie verifiziert.

Beispiel, wo ZK sich verdient: Eine regulierte Exchange muss einem Prüfer beweisen, dass jeder Nutzer KYC bestanden hat, ohne dem Prüfer eine Datenbank aus Namen und Passnummern auszuhändigen. Ein Zero-Knowledge-Beweis lässt die Exchange bezeugen „diese Menge an Accounts ist vollständig KYC-verifiziert", während die zugrundeliegenden Identitäten privat bleiben. In der EU, wo die DSGVO diese Passdatenbank zu einer Haftung macht, die man lieber nicht hält, ist die Privatsphäre kein Nice-to-have, sondern der Punkt. Das Gegenbeispiel ist genauso lehrreich: Würde eine vertrauenswürdige Datenbankabfrage den Verifier zufriedenstellen, ist ZK teures Theater.

Der ehrliche Engineering-Trade-off und der häufigste Founder-Fehler: anzunehmen, der schwere Teil sei die Kryptografie. Die Mathematik ist solide. Das Risiko liegt im Circuit. Ein subtil falscher Circuit produziert einen Beweis, der perfekt verifiziert, während er die falsche Aussage beweist, und dieser Bug ist unsichtbar, bis ihn jemand ausnutzt. Deshalb gehört ZK-Arbeit in die Nähe von Account Abstraction und anderen On-Chain-Primitiven, bei denen Audits nicht verhandelbar sind, nicht als Marketing-Feature drangeschraubt. Der Business Case ist enger als der Hype: ZK ist tatsächlich wertvoll, wenn man on-chain (oder gegenüber einer Gegenpartei) eine Eigenschaft beweisen muss, ohne die Daten zu leaken. Für die meisten Consumer-Apps und die meisten Web3-Projekte, die es als Schlagwort nennen, ist es Overkill.

// FAQ

Häufige Fragen

Für Standard-Beweise (Identität, Saldo, Mitgliedschaft) nein. Fertige Circuits und Frameworks wie Circom, Noir oder zkLogin decken die meisten Use-Cases ab. Für eigene Circuits ja, mit Audit. Custom-Kryptographie ohne Audit ist eine Vulnerability mit Roadmap.
SNARK, wenn On-Chain-Verifikationskosten zählen und ein Trusted Setup akzeptabel ist. STARK, wenn Du Trusted Setup vermeiden willst oder Post-Quantum-Sicherheit brauchst. Für die meisten Consumer-Apps ist SNARK derzeit pragmatischer.
An der Prover-Performance. Beweis-Generierung ist rechenintensiv und kann mobile Geräte überfordern. Wer Client-side Proofs plant, sollte früh auf realer Hardware messen, nicht erst nach dem Audit.