Hallo, liebe Freunde! Als ich tiefer in Dusk eingestiegen bin, hatte ich eine einfache Frage: Wenn das Netzwerk für regulierte Finanzmärkte gebaut wurde, wie kann es dann Transparenz und Privatsphäre in Einklang bringen?
Ich fand die Antwort in DuskDS. Auf dieser Ebene unterstützt Dusk zwei native Transaktionsmodelle: Moonlight und Phoenix.
Moonlight ist das öffentliche, kontobasierte Modell. Kontostände sind sichtbar, und Überweisungen zeigen den Absender, den Empfänger und den Betrag. Das macht es geeignet für Abläufe, die beobachtbar bleiben müssen, etwa für bestimmte Treasury- oder Reporting-Szenarien.
Phoenix funktioniert anders. Es handelt sich um ein verschlüsseltes, notenbasiertes Modell, das Zero-Knowledge-Proofs verwendet. Die Mittel existieren als verschlüsselte Notizen, während Transaktionen belegen, dass die Operation gültig ist, dass genügend Mittel vorhanden sind und dass kein Double-Spending auftritt – ohne den Überweisungsbetrag, die konkreten beteiligten Notizen oder den Absender der Notiz gegenüber Beobachtern offenzulegen.
Genau hier finde ich Dusk’s Ansatz besonders interessant: Privatsphäre bedeutet nicht, dass Informationen niemals offengelegt werden dürfen.
Phoenix unterstützt selektive Offenlegung über Viewing Keys. Wenn es für Regulierung oder Audits erforderlich ist, können Nutzer die relevanten Informationen selektiv offenlegen.
Das Ergebnis ist eine praktische Konfiguration: Ein Netzwerk kann öffentliche Überweisungen unterstützen, wenn Transparenz benötigt wird, und verschlüsselte Überweisungen, wenn Finanzinformationen privat bleiben müssen.
Und Moonlight und Phoenix sind keine separaten Netzwerke. Beide laufen auf DuskDS, während der Transfer Contract die unterschiedlichen Transaktionsdaten entgegennimmt, sie an die passende Verifikationslogik weiterleitet und den globalen Zustand konsistent hält.
Daher würde ich Privatsphäre in Dusk nicht einfach als die Fähigkeit beschreiben, eine Transaktion zu verbergen. Besser lässt sie sich verstehen als Kontrolle darüber, welche Informationen öffentlich sind, was vertraulich bleibt und was bei Bedarf selektiv offengelegt werden kann.
Im nächsten Beitrag schauen wir uns an, wie Zero-Knowledge-Proofs in Phoenix funktionieren und welche Rolle der Prover im Prozess spielt.
#dusk $DUSK @Dusk
Ich fand die Antwort in DuskDS. Auf dieser Ebene unterstützt Dusk zwei native Transaktionsmodelle: Moonlight und Phoenix.
Moonlight ist das öffentliche, kontobasierte Modell. Kontostände sind sichtbar, und Überweisungen zeigen den Absender, den Empfänger und den Betrag. Das macht es geeignet für Abläufe, die beobachtbar bleiben müssen, etwa für bestimmte Treasury- oder Reporting-Szenarien.
Phoenix funktioniert anders. Es handelt sich um ein verschlüsseltes, notenbasiertes Modell, das Zero-Knowledge-Proofs verwendet. Die Mittel existieren als verschlüsselte Notizen, während Transaktionen belegen, dass die Operation gültig ist, dass genügend Mittel vorhanden sind und dass kein Double-Spending auftritt – ohne den Überweisungsbetrag, die konkreten beteiligten Notizen oder den Absender der Notiz gegenüber Beobachtern offenzulegen.
Genau hier finde ich Dusk’s Ansatz besonders interessant: Privatsphäre bedeutet nicht, dass Informationen niemals offengelegt werden dürfen.
Phoenix unterstützt selektive Offenlegung über Viewing Keys. Wenn es für Regulierung oder Audits erforderlich ist, können Nutzer die relevanten Informationen selektiv offenlegen.
Das Ergebnis ist eine praktische Konfiguration: Ein Netzwerk kann öffentliche Überweisungen unterstützen, wenn Transparenz benötigt wird, und verschlüsselte Überweisungen, wenn Finanzinformationen privat bleiben müssen.
Und Moonlight und Phoenix sind keine separaten Netzwerke. Beide laufen auf DuskDS, während der Transfer Contract die unterschiedlichen Transaktionsdaten entgegennimmt, sie an die passende Verifikationslogik weiterleitet und den globalen Zustand konsistent hält.
Daher würde ich Privatsphäre in Dusk nicht einfach als die Fähigkeit beschreiben, eine Transaktion zu verbergen. Besser lässt sie sich verstehen als Kontrolle darüber, welche Informationen öffentlich sind, was vertraulich bleibt und was bei Bedarf selektiv offengelegt werden kann.
Im nächsten Beitrag schauen wir uns an, wie Zero-Knowledge-Proofs in Phoenix funktionieren und welche Rolle der Prover im Prozess spielt.
#dusk $DUSK @Dusk