#dusk $DUSK @Dusk Ich wollte mir letzte Nacht ansehen, wie selektive Offenlegung auf Dusk tatsächlich funktioniert. Ich hatte erwartet, dass es eine saubere Funktion ist: Regulierer sehen das, was sie brauchen, und die Privatsphäre bleibt intakt. Doch herausgestellt hat sich, dass die Mechanik chaotischer ist.
Denn es gibt einen Unterschied zwischen einem System, das regulatorisch grundsätzlich Informationen offenlegen *könnte*, und einem, bei dem diese Offenlegung in der Praxis auch wirklich passiert, ohne alles zu blockieren und zum Stillstand zu bringen.
Am meisten hängen geblieben ist mir der Koordinationsaspekt. Wenn ich ein Emittent bin und ein Regulierer möchte die Transaktionshistorie für einen bestimmten Investor sehen: Kann ich den Zugriff einseitig gewähren? Oder muss zuerst der Investor, dessen Transaktionen das sind, zustimmen? Wenn sie ablehnen können, bedeutet „autorisierte Prüfung“ dann einfach „eine Prüfung, die Zusammenarbeit erfordert“? Und wenn sie nicht ablehnen können: Was bedeutet das dann konkret für das Datenschutzversprechen, das Dusk macht?
Denn es gibt einen echten Unterschied zwischen „Privatsphäre mit Hintertür für Regulierer“ und „Privatsphäre, die sich nur öffnet, wenn alle an der Transaktion Beteiligten zustimmen“. Das eine ist regulatorische Compliance. Das andere ist eine Einverständniserklärung, die am Ende jeder unterschreiben muss.
Ich ertappte mich dabei, dass ich selektive Offenlegung behandelte, als wäre das Thema bereits geklärt — so, als würde das System das einfach erledigen. Aber die eigentliche Governance-Frage — wer die Offenlegung kontrolliert und was passiert, wenn sie „nein“ sagen — die liegt weiterhin im Hintergrund und ist durch die technische Ebene nicht gelöst.
Ich bin neugierig, ob die tatsächliche Implementierung von Dusk diese Fragen so beantwortet, wie ich es mir erhoffe, oder ob mir eine menschliche Ebene fehlt, in der „autorisert“ mehr Arbeit übernimmt, als die Leute es sich eingestehen.
@Dusk $DUSK #dusk
Denn es gibt einen Unterschied zwischen einem System, das regulatorisch grundsätzlich Informationen offenlegen *könnte*, und einem, bei dem diese Offenlegung in der Praxis auch wirklich passiert, ohne alles zu blockieren und zum Stillstand zu bringen.
Am meisten hängen geblieben ist mir der Koordinationsaspekt. Wenn ich ein Emittent bin und ein Regulierer möchte die Transaktionshistorie für einen bestimmten Investor sehen: Kann ich den Zugriff einseitig gewähren? Oder muss zuerst der Investor, dessen Transaktionen das sind, zustimmen? Wenn sie ablehnen können, bedeutet „autorisierte Prüfung“ dann einfach „eine Prüfung, die Zusammenarbeit erfordert“? Und wenn sie nicht ablehnen können: Was bedeutet das dann konkret für das Datenschutzversprechen, das Dusk macht?
Denn es gibt einen echten Unterschied zwischen „Privatsphäre mit Hintertür für Regulierer“ und „Privatsphäre, die sich nur öffnet, wenn alle an der Transaktion Beteiligten zustimmen“. Das eine ist regulatorische Compliance. Das andere ist eine Einverständniserklärung, die am Ende jeder unterschreiben muss.
Ich ertappte mich dabei, dass ich selektive Offenlegung behandelte, als wäre das Thema bereits geklärt — so, als würde das System das einfach erledigen. Aber die eigentliche Governance-Frage — wer die Offenlegung kontrolliert und was passiert, wenn sie „nein“ sagen — die liegt weiterhin im Hintergrund und ist durch die technische Ebene nicht gelöst.
Ich bin neugierig, ob die tatsächliche Implementierung von Dusk diese Fragen so beantwortet, wie ich es mir erhoffe, oder ob mir eine menschliche Ebene fehlt, in der „autorisert“ mehr Arbeit übernimmt, als die Leute es sich eingestehen.
@Dusk $DUSK #dusk
