Die Privatsphäre, die ich in Dusk nicht erwartet habe, hat nichts damit zu tun, Guthaben zu verbergen. Es geht darum, was passiert, nachdem ein Zero-Knowledge-Identitätsnachweis erfolgreich ist.
Der Entwurf der Spezifikation für Citadel 2 (Stand Mai 2026) verwendet auf der Blockchain eine „session_id“ als Nullifier. Für die gleiche versteckte Lizenz und die akzeptierte Challenge kann der Vertrag eine doppelte Session ablehnen. Das klingt zunächst wie Replay-Schutz.
Aber die Spezifikation zieht eine schärfere Grenze: Der Nullifier verhindert die doppelte Erstellung einer On-Chain-Session; er verhindert nicht, dass jemand den gleichen offengelegten Session-Cookie off-chain erneut verwendet.
Das hat mich zweimal hinschauen lassen.
In Citadel prüft die Chain die kryptografische Gültigkeit und protokolliert die Session. Der Service Provider muss jedoch weiterhin eigene Replay-Regeln, Issuer-Vertrauen, Sperrungen (Revocation), Ablauf (Expiration), Account-Bindung und Rate Limits durchsetzen.
Ich finde diese Trennung spannender als ein simples „Datenschutz + Compliance“-Slogan. So wird verhindert, dass das Basisprotokoll jede Zugriffsrichtlinie jeder Institution fest verdrahtet, während die echte Verantwortung für die Autorisierung in die Anwendungsschicht verlagert wird.
Der Trade-off ist offensichtlich: Entwickler können „gültiger ZK-Nachweis“ nicht als gleichbedeutend mit „sichere wiederverwendbare Zugriffserlaubnis“ behandeln.
Für @Dusk_Foundation and $DUSK würde ich mir ansehen, wie die Produktions-Profile von Citadel die Einmalverwendung, Bindung und Sperrung standardisieren, ohne den Datenschutz zu schwächen. Welche Richtlinienentscheidungen werden zu Defaults — und welche bleiben anwendungsspezifisch? #dusk
#dusk $DUSK @Dusk
Der Entwurf der Spezifikation für Citadel 2 (Stand Mai 2026) verwendet auf der Blockchain eine „session_id“ als Nullifier. Für die gleiche versteckte Lizenz und die akzeptierte Challenge kann der Vertrag eine doppelte Session ablehnen. Das klingt zunächst wie Replay-Schutz.
Aber die Spezifikation zieht eine schärfere Grenze: Der Nullifier verhindert die doppelte Erstellung einer On-Chain-Session; er verhindert nicht, dass jemand den gleichen offengelegten Session-Cookie off-chain erneut verwendet.
Das hat mich zweimal hinschauen lassen.
In Citadel prüft die Chain die kryptografische Gültigkeit und protokolliert die Session. Der Service Provider muss jedoch weiterhin eigene Replay-Regeln, Issuer-Vertrauen, Sperrungen (Revocation), Ablauf (Expiration), Account-Bindung und Rate Limits durchsetzen.
Ich finde diese Trennung spannender als ein simples „Datenschutz + Compliance“-Slogan. So wird verhindert, dass das Basisprotokoll jede Zugriffsrichtlinie jeder Institution fest verdrahtet, während die echte Verantwortung für die Autorisierung in die Anwendungsschicht verlagert wird.
Der Trade-off ist offensichtlich: Entwickler können „gültiger ZK-Nachweis“ nicht als gleichbedeutend mit „sichere wiederverwendbare Zugriffserlaubnis“ behandeln.
Für @Dusk_Foundation and $DUSK würde ich mir ansehen, wie die Produktions-Profile von Citadel die Einmalverwendung, Bindung und Sperrung standardisieren, ohne den Datenschutz zu schwächen. Welche Richtlinienentscheidungen werden zu Defaults — und welche bleiben anwendungsspezifisch? #dusk
#dusk $DUSK @Dusk