Wo Zero-Knowledge tatsächlich eingesetzt wird: zkLogin, Coprozessoren und Identitätsprüfungen

2026-08-12

Zero-Knowledge-Systeme lassen sich am besten verstehen, wenn jeder Beweis an eine konkrete Aussage gebunden ist. Ein Beweis kann ein Credential-Feld verbergen, eine Berechnung off-chain bestätigen oder zeigen, dass eine Identitätsregel erfüllt wurde, ohne das zugrunde liegende Dokument zu veröffentlichen. Er macht nicht automatisch jede Komponente trustless und verwandelt einen Login nicht in eine universelle Identität. Dieser Text wurde anhand der genannten Dokumentation am 10. August 2026 geprüft und verfolgt die Grenze von ZK-Proofs über zkLogin und ZK-Coprocessors bis zu Identitätsprüfungen.

Was ein Zero-Knowledge-Proof tatsächlich verbirgt

Ein Zero-Knowledge-Proof ermöglicht es einem Prover, einen Verifier von der Wahrheit einer Aussage zu überzeugen und ausgewählte Witness-Daten trotzdem geheim zu halten. Die Aussage kann lauten, dass ein signiertes Token eine bestimmte Beziehung enthält, dass ein Programm ein bestimmtes Ergebnis erzeugt hat oder dass ein Credential eine Regel erfüllt. Der Proof ist nicht die Aussage selbst. Er belegt eine Beziehung zwischen öffentlichen und privaten Eingaben, die durch eine bestimmte Schaltung oder ein Programm festgelegt ist.

Diese Unterscheidung ist wichtig, weil Privatsphäre selektiv ist. Ein Verifier kann ein boolesches Ergebnis, ein öffentliches Commitment, eine Netzwerkkennung, eine Programmkennung oder einen Zeitstempel sehen, ohne die private Eingabe zu sehen. Ein Proof für eine Altersgrenze kann das Geburtsdatum verbergen, beweist aber nicht von selbst, wer das Credential ausgestellt hat, ob der Issuer vertrauenswürdig ist oder ob der Verifier die richtige Policy verwendet.

Die praktische Frage lautet daher nicht, ob ein Produkt ZK verwendet. Man muss fragen, was öffentlich und was privat ist, wer den Witness erzeugt, welchen Schlüsseln oder Setup-Parametern vertraut wird und wer das Ergebnis prüft. Auch ein sound Proof kann von einem OAuth-Anbieter, einem Salt-Service, einem Indexer, einer Datenverfügbarkeits-Schicht, einem Credential-Issuer oder einer Anwendung mit einer schwachen Regel abhängen.

Wie zkLogin einen Web-Login an eine Adresse bindet

Wer nach zkLogin explained sucht, sollte mit der Identitätsbindung beginnen und nicht mit dem Wort Wallet. Sui zkLogin verwendet eine OpenID-Connect-Anmeldung, die ein signiertes JSON Web Token liefert. Die Anwendung erzeugt zusätzlich ein kurzlebiges ephemeres Schlüsselpaar. Die Nonce im Token wird aus dem öffentlichen ephemeren Schlüssel, Zufälligkeit und einer Ablauf-Epoch gebildet. Dadurch ist die spätere Transaktionssitzung an den Login-Ablauf gebunden.

Die Sui-Dokumentation beschreibt Salt-Service und Proving-Service als getrennte Backend-Rollen. Der Salt wird zusammen mit Issuer, Audience der Anwendung und Subject-Claim verwendet, um einen Adress-Seed abzuleiten. Bleibt der Salt privat, kann die OAuth-Kennung von der Onchain-Adresse entkoppelt werden. Der Proving-Service erhält das Token und die relevanten Eingaben und erzeugt einen Groth16-Proof, der die Beziehungen zwischen Provider-Signatur, Nonce, Claim und Adressableitung prüft.

Adresse und Sitzungsschlüssel haben unterschiedliche Lebensdauern. Die Adresse kann stabil bleiben, solange Issuer, Audience, Subject und User-Salt gleich bleiben, während der ephemere Schlüssel bei der festgelegten Epoch abläuft. Ein neuer Login erzeugt einen neuen Sitzungsschlüssel und Proof für dieselbe Adresse. Validatoren prüfen Proof und ephemere Signatur, bevor die Transaktion ausgeführt wird. Das ist ein protokollspezifischer Ablauf und keine Behauptung, dass jeder Social Login eine selbstverwahrte Identität erzeugt.

Die Vertrauensgrenze ist in den Details sichtbar. Der OAuth-Anbieter authentifiziert das Konto und signiert das Token. Die Anwendung kontrolliert Frontend und ephemeren Schlüssel. Ein Salt-Service kann je nach Design sensible Eingaben sehen, während der Proving-Service Token und Proof-Eingaben verarbeitet. Sui weist darauf hin, dass diese Dienste Identität und Salt in ihrer eigenen Sicht verknüpfen können, obwohl das JWT nicht Onchain veröffentlicht wird. Das Ergebnis hängt von diesen Annahmen und vom Schutz von Salt und Sitzungsschlüssel ab.

Was ein ZK-Coprocessor berechnet

Die Formulierung zk coprocessor explained sollte als Architekturfrage verstanden werden. Ein Coprocessor verlagert daten- oder rechenintensive Aufgaben aus der Anwendungskette und liefert anschließend ein Ergebnis mit einem Nachweis zurück, dass authentifizierte Eingaben und die erklärte Berechnung verwendet wurden. In einem reinen ZK-Modell kann ein Verifier-Contract den Proof prüfen und das Ergebnis verwenden, ohne die gesamte Berechnung zu wiederholen.

ZK-Proof-Fluss von privater Eingabe zu einem überprüfbaren Anwendungsergebnis

Die Brevis-Dokumentation beschreibt drei Stufen: Datenzugriff, Anwendungsberechnung und Nutzung des Ergebnisses. Die Anwendung fordert historische Onchain-Daten an, ein Offchain-Prover führt eine eigene Logik aus, und Ergebnis plus Proof werden zur Onchain-Prüfung übermittelt. Das Muster kann einen Aktivitätsschwellenwert, eine Membership-Regel, eine Reward-Berechnung oder ein Risk Flag unterstützen. Der Proof bestätigt nicht automatisch, dass die Datenquelle geeignet war, sondern nur die tatsächlich bewiesene Relation.

Das ist etwas anderes als eine bloße Antwort eines Indexers. Eine nicht bewiesene Indexer-Antwort verlangt Vertrauen in die Partei, die Daten ausgewählt und das Ergebnis berechnet hat. Ein ZK-Coprocessor kann das Ergebnis mit authentifizierten Chain-Daten und einer Circuit verbinden und dieses Vertrauen verringern. Circuit, Commitments, Proof-System, Verifier und Aktualisierungsprozess werden dadurch selbst zu prüfenden Komponenten.

Ein Coprocessor ist außerdem keine unveränderliche Produktfunktion. Brevis unterscheidet ein reines ZK-Modell von einem coChain- oder optimistischen Modell mit unterschiedlichen Annahmen zu Latenz, Kosten und Challenges. RISC Zero beschreibt verifiable computation allgemeiner als ein Programm-Output mit einer Receipt, die ein Verifier ohne erneute Ausführung und ohne private Eingaben prüfen kann. Jede Bereitstellung braucht trotzdem eine eigene Prüfung von Statement, Input-Authentifizierung und Fehlerpolitik.

Wo der Beweis einer ID-Prüfung endet

Eine ID-Prüfung kann als Aussage über ein Credential dargestellt werden, nicht als magischer Beweis über eine Person. Der Verifier kann prüfen, ob ein Issuer das Credential signiert hat, ob es gültig ist, ob ein Subject eine Altersgrenze überschreitet oder ob eine Dokumentkennung auf einer Widerrufsliste steht. Eine ZK-Circuit verbirgt nicht benötigte Felder und legt nur das für die Anwendung erforderliche Ergebnis offen.

Der Ausdruck zero knowledge identity verification sollte deshalb in die Rollen Issuer, Holder und Verifier aufgeteilt werden. W3C Verifiable Credentials beschreibt ein Credential als Claims eines Issuers, die ein Subject oder Holder besitzt und einem Verifier mit Mechanismen für Authentizität und Integrität vorlegt. W3C DID beschreibt Identifikatoren und Verifikationsmethoden. Keiner dieser Standards garantiert allein, dass eine reale Person, Organisation oder ein Dokument wahr ist.

Nehmen wir eine Altersprüfung. Ein Proof kann zeigen, dass ein signiertes Geburtsdatum vor einem Policy-Stichtag liegt, ohne das Datum offenzulegen. Er entscheidet aber nicht, ob der Issuer das Dokument zuverlässig geprüft hat, ob das Credential dem aktuellen Holder gehört, ob der Stichtag in einer bestimmten Jurisdiktion gilt oder ob das Credential widerrufen wurde. Das sind getrennte Fragen zu Issuer, Binding, Policy und Lebenszyklus.

Dieselbe Grenze gilt für Sanktionen, Wohnsitz, Akkreditierung und Kontoeindeutigkeit. Eine Circuit kann das Prädikat codieren, dass ein Issuer zu einer genehmigten Menge gehört und ein Claim eine Regel erfüllt. Sie repariert kein schwaches Issuer-Register, kein gestohlenes Credential, keine kompromittierte Wallet, keinen falschen Quelldatensatz und keinen unvollständigen Widerrufsfeed. True bedeutet, dass das codierte Prädikat für die gelieferten Eingaben verifiziert wurde, nicht dass alle dahinterliegenden Tatsachen wahr sind.

Privatsphäre ist eine Designentscheidung

ZK kann die Offenlegung reduzieren, aber Privatsphäre hängt vom gesamten Ablauf ab. Der Verifier kann weiterhin öffentliche Adresse, Zeit, Netzwerk, Application Audience, Proof-Häufigkeit oder den Versuch einer Policy sehen. Wiederholte Präsentationen können verknüpft werden, wenn eine Anwendung dieselben Identifikatoren oder öffentlichen Commitments verwendet. Metadaten können mehr verraten als der vom Circuit verborgene Witness.

zkLogin zeigt dies durch Salt und OpenID-Claims. Der Salt hilft, OAuth-Kennung und Onchain-Adresse zu entkoppeln. Sein Verlust kann jedoch den Zugriff auf die Adresse verhindern, und seine Offenlegung kann den Subject-Claim verknüpfbar machen. OAuth-Provider, Frontend, Salt-Service, Proving-Service und Validatoren sehen jeweils andere Teile des Ablaufs. Eine Privacy Review sollte diese Sichtweisen abbilden und den Proof nicht als einen einzigen Datenschutzschalter behandeln.

Bei Coprocessors hängt Privatsphäre außerdem davon ab, wo Rohdaten und Witness verarbeitet werden. Ein Onchain-Verifier kann das Ergebnis prüfen, ohne private Eingaben zu sehen, aber der Offchain-Prover oder Datenanbieter kann sie bei der Berechnung gesehen haben. Die Anwendung kann Ergebnis, Query-Kennung, Blockbereich oder Commitment veröffentlichen. Wenn Eingaben auch vor dem Prover verborgen bleiben sollen, genügt ein öffentlicher ZK-Verifier möglicherweise nicht. Dann können private Proving, sichere Ausführung oder verschlüsselte Berechnung erforderlich sein.

Das Prinzip der minimalen Offenlegung hilft: Nur das für die Anwendung benötigte Prädikat beweisen, eine zweckgebundene Audience oder Domain-Trennung verwenden, Sitzungselemente nach Protokollvorgabe wechseln und Aufbewahrungs- sowie Korrelationsrisiken dokumentieren. Diese Maßnahmen beseitigen Vertrauen nicht, machen die verbleibenden Pfade aber prüfbar.

Welche Rollen das Trust Model nennen muss

Beginne mit Statement und Public Inputs. Schreibe genau auf, was der Verifier akzeptiert, welche Daten committed sind, wie Chain State oder Credential authentifiziert werden und welche Software- oder Circuit-Version den Proof erzeugt hat. Wenn ein Contract das Ergebnis verwenden kann, müssen Verifier-Code, Upgrade-Rechte, Notfallpfad und Umgang mit veralteten Daten benannt werden.

Danach werden die Akteure aufgelistet. Bei zkLogin gehören OpenID-Provider, Anwendung, Halter des ephemeren Schlüssels, Salt-Service, Proving-Service und Sui-Validatoren dazu. Beim Coprocessor kommen Datenquelle, Indexer oder Light Client, Prover, Verifier und Challenge- oder Staking-Mechanismus hinzu. Bei der ID-Prüfung gehören Issuer, Holder, Wallet oder Presentation Layer, Verifier und Revocation- oder Status-Service dazu. Ein fehlender Akteur in der Darstellung ist ein Risikosignal.

Trenne Correctness von Availability und Recovery. Ein gültiger Proof kann zu spät eintreffen. Ein Provider kann Schlüssel rotieren. Ein Salt-Service kann ausfallen. Ein Credential kann ablaufen. Reorganisation oder Finalitätsregel kann die Eingabemenge ändern. Ein optimistischer Coprocessor-Pfad kann davon abhängen, dass innerhalb eines Challenge-Fensters jemand ehrlich widerspricht. Das sind Betriebseigenschaften, die ein mathematischer Proof nicht automatisch behebt.

Zum Schluss werden Setup- und Upgrade-Annahmen geprüft. Sui beschreibt eine Groth16-Ceremony für die Common Reference String von zkLogin. Andere Systeme nutzen transparente Proof-Systeme, zkVM-Receipts, Trusted Setups, Komitees, Staking-Schichten oder Kombinationen. Frage, wer Circuit, Verifier, Issuer-Register, Provider-Liste, Datenquelle oder Policy ändern kann. Ein Proof kann die Policy von gestern korrekt prüfen und heute trotzdem die falsche Antwort liefern.

Wie man eine ZK-Identitätsaussage liest

Wenn die Dokumentation eine Funktion als privat bezeichnet, übersetze das in eine Tabelle: privat gegenüber wem, sichtbar für wen, wie lange und mit welcher Korrelationsmethode. Wenn sie trustless sagt, frage, welcher Akteur entfernt wurde und wem für Eingaben, Schlüssel, Verfügbarkeit, Wiederherstellung und Governance weiterhin vertraut wird. Wenn sie verifiable sagt, frage nach der konkreten Berechnung oder Credential-Relation.

Prüfe die Sequenz dieses Artikels in fünf Schritten. Erstens Statement und Witness prüfen. Zweitens die Identitätsbindung vom Provider-Token oder Credential bis zur Anwendungsadresse oder Presentation verfolgen. Drittens jede Offchain-Berechnung und ihre authentifizierte Datenquelle bestimmen. Viertens Issuer-, Policy-, Revocation- und Holder-Annahmen der ID-Prüfung auflisten. Fünftens Privacy Leakage durch Metadaten, Wiederverwendung und Sichtbarkeit der Dienste testen.

So bleiben drei Ideen getrennt. zkLogin kann einen kurzlebigen Transaktionsschlüssel an Claims eines OpenID-Flows binden und ausgewählte Claim-Daten vor der Chain verbergen. Ein ZK-Coprocessor kann eine Offchain-Berechnung gegenüber erklärten Daten überprüfbar machen. Eine ID-Prüfung kann zeigen, dass ein definiertes Credential-Prädikat erfüllt wurde. Keine dieser Aussagen beweist allein Ehrlichkeit des Nutzers, Vertrauenswürdigkeit des Issuers, Aktualität der Daten oder Harmlosigkeit der umgebenden Dienste.

Genau dort wird Zero Knowledge tatsächlich eingesetzt: in einer klar begrenzten Beziehung zwischen Eingaben, Berechnung und Verifikation. Das Ergebnis ist kein Versprechen einer unsichtbaren Identität, sondern ein kleinerer, prüfbarer Claim mit ausdrücklich genannten Annahmen zu Privatsphäre und Vertrauen. Diese Annahmen sollten zusammen mit Protokollversion, Quelldatum und Policy gespeichert werden, damit spätere Änderungen nicht als dauerhafte Garantie missverstanden werden.

Haftungsausschluss: Dieser Artikel ist Bildungsinhalt der Bitbase Academy, nur zu Informationszwecken. Er ist keine Anlage-, Handels-, Steuer- oder Finanzberatung. Krypto-Assets sind volatil — schätze dein Risiko selbst ein. Stand August 2026; maßgeblich sind die aktuellen offiziellen Informationen.