#dusk $DUSK @Dusk
Was ich an Dusk’ Compliance-Modell interessant finde, ist, dass es Identität weniger als etwas behandelt, das man speichert, und mehr als etwas, das man nachweist.
Citadel 2 trennt die Rollen sauber. Ein Lizenzanbieter überprüft den Nutzer off-chain und signiert die relevanten Attribute. Die Berechtigung wird registriert, ohne ihre Inhalte offenzulegen, dann kann der Nutzer einen Zero-Knowledge-Beweis erzeugen, der zeigt, dass er eine gültige Berechtigung besitzt, ohne offenzulegen, welche Berechtigung, seine Identität oder die zugrunde liegenden Attribute. Der Dienstanbieter entscheidet weiterhin, was als qualifizierend gilt und ob der Zugriff gewährt werden soll.
Das ist eine subtile, aber wichtige Abgrenzung gegenüber dem Ansatz, KYC-Daten on-chain zu stellen und das als compliant zu bezeichnen. Die Chain sollte eine Aussage wie „dieser Teilnehmer ist akkreditiert“ oder „dieser Inhaber erfüllt die Jurisdiktionsregel“ verifizieren – und nicht den Pass, die Adresse oder das Geburtsdatum dauerhaft hinter dieser Aussage offenlegen.
Die breitere kryptografische Ausrichtung unterstützt diese Architektur. W3C’s Arbeit an Digital Credentials für 2026 behandelt selektive Offenlegung und unverknüpfbare Präsentationen als zentrale Datenschutz-Eigenschaften, während seine BBS-Kryptosuite abgeleitete Beweise formalisiert, bei denen Inhaber ausgewählte Ansprüche offenlegen können, ohne dass sich separate Präsentationen trivial verknüpfen lassen.
Meine Ansicht ist, dass Dusk’s schwieriges Problem nicht mehr darin besteht, ob Zero Knowledge KYC-Daten verbergen kann. Es geht darum, die Policy-Ebene darum herum zu gestalten: Ausstellervertrauen, Ablauf, Widerruf, Änderungen der Jurisdiktion, Wallet-Bindung und Anti-Korrelation.
Dort wird On-Chain-Compliance interessant: nicht Offenlegung von Identität, sondern programmierbarer Nachweis der Berechtigung.
Was ich an Dusk’ Compliance-Modell interessant finde, ist, dass es Identität weniger als etwas behandelt, das man speichert, und mehr als etwas, das man nachweist.
Citadel 2 trennt die Rollen sauber. Ein Lizenzanbieter überprüft den Nutzer off-chain und signiert die relevanten Attribute. Die Berechtigung wird registriert, ohne ihre Inhalte offenzulegen, dann kann der Nutzer einen Zero-Knowledge-Beweis erzeugen, der zeigt, dass er eine gültige Berechtigung besitzt, ohne offenzulegen, welche Berechtigung, seine Identität oder die zugrunde liegenden Attribute. Der Dienstanbieter entscheidet weiterhin, was als qualifizierend gilt und ob der Zugriff gewährt werden soll.
Das ist eine subtile, aber wichtige Abgrenzung gegenüber dem Ansatz, KYC-Daten on-chain zu stellen und das als compliant zu bezeichnen. Die Chain sollte eine Aussage wie „dieser Teilnehmer ist akkreditiert“ oder „dieser Inhaber erfüllt die Jurisdiktionsregel“ verifizieren – und nicht den Pass, die Adresse oder das Geburtsdatum dauerhaft hinter dieser Aussage offenlegen.
Die breitere kryptografische Ausrichtung unterstützt diese Architektur. W3C’s Arbeit an Digital Credentials für 2026 behandelt selektive Offenlegung und unverknüpfbare Präsentationen als zentrale Datenschutz-Eigenschaften, während seine BBS-Kryptosuite abgeleitete Beweise formalisiert, bei denen Inhaber ausgewählte Ansprüche offenlegen können, ohne dass sich separate Präsentationen trivial verknüpfen lassen.
Meine Ansicht ist, dass Dusk’s schwieriges Problem nicht mehr darin besteht, ob Zero Knowledge KYC-Daten verbergen kann. Es geht darum, die Policy-Ebene darum herum zu gestalten: Ausstellervertrauen, Ablauf, Widerruf, Änderungen der Jurisdiktion, Wallet-Bindung und Anti-Korrelation.
Dort wird On-Chain-Compliance interessant: nicht Offenlegung von Identität, sondern programmierbarer Nachweis der Berechtigung.
