Ich habe während der Aufgabe den Citadel-Protocol von Dusk Network durchgelesen. Das Citadel-Repo auf GitHub hat am 8. August Commits aufgenommen – aktives Arbeiten, keine statische Spezifikation – und ich bin dann mit dem Drei-Parteien-Modell länger stecken geblieben, als ich beabsichtigt hatte.
Der Begriff „selektive Offenlegung“ wird in den $DUSK @Dusk #dusk Materialien sehr oft verwendet. Er trifft zu. Aber es gibt eine strukturelle Sache, die die Architektur offenbart, die der Pitch nicht in den Vordergrund stellt.
Citadel hat drei Parteien: User, License Provider (LP) und Service Provider (SP). Die ZK-Beweise schützen dich vor dem SP – sie prüfen, dass du eine Compliance-Schwelle erfüllst, ohne deine tatsächlichen Daten zu sehen. Dieser Teil funktioniert wie beschrieben. Aber der LP macht volles KYC. Sie halten deine Daten. Sie stellen die On-Chain-Lizenz aus. Jeder nachfolgende Service Provider erhält nur einen Beweis – das ist elegant. Die Reibung liegt früher, beim Onboarding, nicht an jeder Schranke.
Das Datenschutzmodell von Dusk ist also nicht „vor der Autorität verborgen“. Es ist „vor den Gegenparteien verborgen, sichtbar für die von dir gewählte Autorität“. Der LP weiß alles. Die SPs wissen nichts. Für regulierte Finanzen ist das wahrscheinlich das richtige Design – jemand muss der verantwortliche Daten-Custodian für Regulierungsbehörden sein. Aber es liest sich anders, als die meisten Menschen „Blockchain-Privatsphäre“ interpretieren, was tendenziell bedeutet: standardmäßig vor allen verborgen.
Hmm… die spannende offene Frage ist, wer in der Praxis eigentlich die Rolle des LP spielt. Wenn das ein regulierter Custodian oder ein lizenzierter KYC-Anbieter ist, dann ist das ausgelagerte Identitätsinfrastruktur mit besserer UX – nicht dezentrale Identität. Ich bin mir nicht sicher, ob sich diese beiden Sichtweisen jemals vollständig ineinander auflösen.
Der Begriff „selektive Offenlegung“ wird in den $DUSK @Dusk #dusk Materialien sehr oft verwendet. Er trifft zu. Aber es gibt eine strukturelle Sache, die die Architektur offenbart, die der Pitch nicht in den Vordergrund stellt.
Citadel hat drei Parteien: User, License Provider (LP) und Service Provider (SP). Die ZK-Beweise schützen dich vor dem SP – sie prüfen, dass du eine Compliance-Schwelle erfüllst, ohne deine tatsächlichen Daten zu sehen. Dieser Teil funktioniert wie beschrieben. Aber der LP macht volles KYC. Sie halten deine Daten. Sie stellen die On-Chain-Lizenz aus. Jeder nachfolgende Service Provider erhält nur einen Beweis – das ist elegant. Die Reibung liegt früher, beim Onboarding, nicht an jeder Schranke.
Das Datenschutzmodell von Dusk ist also nicht „vor der Autorität verborgen“. Es ist „vor den Gegenparteien verborgen, sichtbar für die von dir gewählte Autorität“. Der LP weiß alles. Die SPs wissen nichts. Für regulierte Finanzen ist das wahrscheinlich das richtige Design – jemand muss der verantwortliche Daten-Custodian für Regulierungsbehörden sein. Aber es liest sich anders, als die meisten Menschen „Blockchain-Privatsphäre“ interpretieren, was tendenziell bedeutet: standardmäßig vor allen verborgen.
Hmm… die spannende offene Frage ist, wer in der Praxis eigentlich die Rolle des LP spielt. Wenn das ein regulierter Custodian oder ein lizenzierter KYC-Anbieter ist, dann ist das ausgelagerte Identitätsinfrastruktur mit besserer UX – nicht dezentrale Identität. Ich bin mir nicht sicher, ob sich diese beiden Sichtweisen jemals vollständig ineinander auflösen.