#dusk $DUSK
@Dusk_Foundation früher dachte ich, eine Privacy-Kette bedeute, dass jede Transaktion standardmäßig abgeschirmt ist – ohne Ausnahmen.
dann las ich, was Moonlight tatsächlich auf Dusk macht.
Dusk betreibt zwei native Transaktionsmodelle auf derselben Settlement-Ebene. Moonlight ist konto-basiert, öffentlich: Absender, Empfänger und Betrag sind alle sichtbar. Phoenix ist note-basiert, abgeschirmt: Die Mittel liegen als verschlüsselte Notes vor, statt als laufender Kontostand – näher an ausgebbaren Einheiten als an einer Kontogesamtsumme. #dusk
das ist das „standardmäßig“, das meine Sicht darauf verändert hat, und ich bin zurückgegangen, um diesen Abschnitt zweimal erneut zu lesen, um sicherzugehen.
eine einzelne Überweisung wählt jeweils ein Modell oder das andere – nie eine Mischung. Sende DUSK über Moonlight, dann ist alles vollständig transparent: gebaut für Abläufe, die beobachtbar bleiben müssen, etwa ein Treasury- oder Reporting-Szenario – so ein Beispiel deuten die Doks an. Sende es über Phoenix, dann bleiben Betrag, Absender und welche konkreten Notes verschoben wurden verborgen; bewiesen wird das mit Zero-Knowledge-Proofs statt offengelegt zu werden, obwohl ein View- Key genau diese versteckten Daten für denjenigen, den der Staker auswählt, wieder sichtbar machen kann. $DUSK
ein Transfer-Contract übernimmt beides: Er routet jede Payload an die passende Verifikationslogik und hält den globalen Zustand in jedem Fall konsistent.
Datenschutz ist hier also auch auf Protokollebene nicht binär – es ist eine Entscheidung pro Überweisung, und sogar die abgeschirmte Option hat einen dokumentierten Weg, auf Anfrage wieder sichtbar zu werden.
diese Entscheidung liegt beim Absender, nicht beim Protokoll.
untergräbt es die Privacy-Versprechen, wenn man Nutzern eine öffentliche Option anbietet – oder ist optionale, widerrufbare Privacy eigentlich das ehrlichere Design für regulierte Märkte?
ist optionale Privacy immer noch Privacy?
@Dusk_Foundation früher dachte ich, eine Privacy-Kette bedeute, dass jede Transaktion standardmäßig abgeschirmt ist – ohne Ausnahmen.
dann las ich, was Moonlight tatsächlich auf Dusk macht.
Dusk betreibt zwei native Transaktionsmodelle auf derselben Settlement-Ebene. Moonlight ist konto-basiert, öffentlich: Absender, Empfänger und Betrag sind alle sichtbar. Phoenix ist note-basiert, abgeschirmt: Die Mittel liegen als verschlüsselte Notes vor, statt als laufender Kontostand – näher an ausgebbaren Einheiten als an einer Kontogesamtsumme. #dusk
das ist das „standardmäßig“, das meine Sicht darauf verändert hat, und ich bin zurückgegangen, um diesen Abschnitt zweimal erneut zu lesen, um sicherzugehen.
eine einzelne Überweisung wählt jeweils ein Modell oder das andere – nie eine Mischung. Sende DUSK über Moonlight, dann ist alles vollständig transparent: gebaut für Abläufe, die beobachtbar bleiben müssen, etwa ein Treasury- oder Reporting-Szenario – so ein Beispiel deuten die Doks an. Sende es über Phoenix, dann bleiben Betrag, Absender und welche konkreten Notes verschoben wurden verborgen; bewiesen wird das mit Zero-Knowledge-Proofs statt offengelegt zu werden, obwohl ein View- Key genau diese versteckten Daten für denjenigen, den der Staker auswählt, wieder sichtbar machen kann. $DUSK
ein Transfer-Contract übernimmt beides: Er routet jede Payload an die passende Verifikationslogik und hält den globalen Zustand in jedem Fall konsistent.
Datenschutz ist hier also auch auf Protokollebene nicht binär – es ist eine Entscheidung pro Überweisung, und sogar die abgeschirmte Option hat einen dokumentierten Weg, auf Anfrage wieder sichtbar zu werden.
diese Entscheidung liegt beim Absender, nicht beim Protokoll.
untergräbt es die Privacy-Versprechen, wenn man Nutzern eine öffentliche Option anbietet – oder ist optionale, widerrufbare Privacy eigentlich das ehrlichere Design für regulierte Märkte?
ist optionale Privacy immer noch Privacy?