Ich habe das neulich nicht durchdringen können: Wenn sowohl der Transaktionsbetrag als auch die Teilnehmer verborgen sind, wie werden regulierte Vermögenswerte dann auditiert? Und falls alles zur Compliance vollständig offengelegt wird, was bleibt dann überhaupt noch an Privatsphäre?
Ich dachte, Dusk sei nur „eine Schicht Zero-Knowledge-Beweise über eine Überweisung“. Erst als ich in den offiziellen Dokumenten auf Moonlight und Phoenix stieß, merkte ich, dass es zwei native Spuren auf derselben Abrechnungsschicht nebeneinanderlegt.
Moonlight ist ein öffentliches Kontomodell: Absender, Empfänger und Betrag sind sichtbar; Phoenix hingegen zeichnet Geld über verschlüsselte Tickets auf. Mit Zero-Knowledge-Beweisen wird verhindert, dass es doppelt ausgegeben wird, und es wird nachgewiesen, dass das Guthaben ausreicht – aber die Transaktionsdetails werden nicht offengelegt. Beide münden schließlich in DuskDS, wo der Transfer Contract sie jeweils separat verifiziert.
Das ist wie bei demselben Bahnhof: eine normale Linie und eine Privatsphäre-Linie. Erstere macht die Informationen der Bahnsteige öffentlich; bei der letzteren werden die Vorhänge zugezogen. Für Audits kann man die Prüfung jedoch gezielt mit einem viewing key öffnen. Citadel 2 erweitert das außerdem in die Identitätsschicht: Nutzer können beweisen, dass sie über gültige Nachweise verfügen, ohne persönliche Attribute oder konkrete Nachweisinhalte offenlegen zu müssen.
Daher glaube ich, dass Dusk nicht darauf abzielt, wie man sich der Regulierung entzieht, sondern darauf, wem gegenüber Finanzdaten transparent sein müssen. Und hier liegt auch das Risiko: Die Nachweise werden vom License Provider ausgestellt, während der Service Provider weiterhin entscheiden muss, wem man vertraut. Außerdem schaffen die Aufbewahrung und die Erteilung von Berechtigungen für viewing keys neue Governance-Grenzen. Ob Offenlegungsbefugnisse auditierbar, widerrufbar und ordnungsgemäß verwaltet werden können – das möchte ich als Nächstes genauer beobachten.
#dusk $DUSK @Dusk
Ich dachte, Dusk sei nur „eine Schicht Zero-Knowledge-Beweise über eine Überweisung“. Erst als ich in den offiziellen Dokumenten auf Moonlight und Phoenix stieß, merkte ich, dass es zwei native Spuren auf derselben Abrechnungsschicht nebeneinanderlegt.
Moonlight ist ein öffentliches Kontomodell: Absender, Empfänger und Betrag sind sichtbar; Phoenix hingegen zeichnet Geld über verschlüsselte Tickets auf. Mit Zero-Knowledge-Beweisen wird verhindert, dass es doppelt ausgegeben wird, und es wird nachgewiesen, dass das Guthaben ausreicht – aber die Transaktionsdetails werden nicht offengelegt. Beide münden schließlich in DuskDS, wo der Transfer Contract sie jeweils separat verifiziert.
Das ist wie bei demselben Bahnhof: eine normale Linie und eine Privatsphäre-Linie. Erstere macht die Informationen der Bahnsteige öffentlich; bei der letzteren werden die Vorhänge zugezogen. Für Audits kann man die Prüfung jedoch gezielt mit einem viewing key öffnen. Citadel 2 erweitert das außerdem in die Identitätsschicht: Nutzer können beweisen, dass sie über gültige Nachweise verfügen, ohne persönliche Attribute oder konkrete Nachweisinhalte offenlegen zu müssen.
Daher glaube ich, dass Dusk nicht darauf abzielt, wie man sich der Regulierung entzieht, sondern darauf, wem gegenüber Finanzdaten transparent sein müssen. Und hier liegt auch das Risiko: Die Nachweise werden vom License Provider ausgestellt, während der Service Provider weiterhin entscheiden muss, wem man vertraut. Außerdem schaffen die Aufbewahrung und die Erteilung von Berechtigungen für viewing keys neue Governance-Grenzen. Ob Offenlegungsbefugnisse auditierbar, widerrufbar und ordnungsgemäß verwaltet werden können – das möchte ich als Nächstes genauer beobachten.
#dusk $DUSK @Dusk