#dusk $DUSK @Dusk
Der Dämmerung liegen zwei Transaktionsmodelle zugrunde, und ich habe sie weiterhin behandelt, als wären es ein einziges Privatsystem mit zwei Namen.
Ich bin noch einmal in die Dokumente gegangen, weil das so nicht ganz stimmig war. Und heraus kam: Sie lösen zwei unterschiedliche Probleme.
MOONLIGHT ist das transparente Modell: kontobasiert, sichtbare Salden, Absender, Empfänger und Betrag. Nützlich, wenn ein Ablauf beobachtbar sein soll.
PHOENIX funktioniert komplett anders. Es ist UTXO-basiert: Die Gelder existieren als verschlüsselte Notizen (Shielded Notes), statt als sichtbarer laufender Kontostand. Anstatt die Transaktionsdetails offenzulegen, prüft das Netzwerk mit einem Zero-Knowledge-Beweis, dass die Ausgabe gültig ist — einschließlich der Tatsache, dass die Gelder existieren und nicht doppelt ausgegeben werden.
Der Teil, den ich besonders interessant fand:
Keines ist ein Fallback für das andere.
Beide sind native Transaktionsmodelle auf DuskDS und sie werden auf derselben Kette abgewickelt. Ein Wallet-Profil kann Moonlight- und Phoenix-Konto parallel verwalten.
Privatsphäre ist also keine Einstellung, die man einmal einschaltet.
Sie ist eine Entscheidung auf Transaktionsebene.
Soll die Übertragung sichtbar sein? Moonlight.
Müssen Betrag und Teilnehmende abgeschirmt werden? Phoenix.
Und falls eine autorisierte Partei später Belege benötigt, unterstützt Dusk die selektive Offenlegung über Viewing Keys.
Das ist eine ziemlich andere Designentscheidung, als ein einzelnes Transaktionsmodell zu nehmen und einfach eine Privatsphäre-Schicht daran anzubauen.
Aber es lässt mich mit einer Frage zurück, die mich tatsächlich umtreibt:
Wird die Pflege zweier grundlegend unterschiedlicher Transaktionsmodelle zu einer Stärke, wenn Dusk skaliert — oder wird das langfristig eher ein Engineering-Albtraum?
Und in der realen Nutzung: Brauchen regulierte Märkte wirklich beides — oder wird am Ende eines davon den Großteil der Arbeit übernehmen?
Der Dämmerung liegen zwei Transaktionsmodelle zugrunde, und ich habe sie weiterhin behandelt, als wären es ein einziges Privatsystem mit zwei Namen.
Ich bin noch einmal in die Dokumente gegangen, weil das so nicht ganz stimmig war. Und heraus kam: Sie lösen zwei unterschiedliche Probleme.
MOONLIGHT ist das transparente Modell: kontobasiert, sichtbare Salden, Absender, Empfänger und Betrag. Nützlich, wenn ein Ablauf beobachtbar sein soll.
PHOENIX funktioniert komplett anders. Es ist UTXO-basiert: Die Gelder existieren als verschlüsselte Notizen (Shielded Notes), statt als sichtbarer laufender Kontostand. Anstatt die Transaktionsdetails offenzulegen, prüft das Netzwerk mit einem Zero-Knowledge-Beweis, dass die Ausgabe gültig ist — einschließlich der Tatsache, dass die Gelder existieren und nicht doppelt ausgegeben werden.
Der Teil, den ich besonders interessant fand:
Keines ist ein Fallback für das andere.
Beide sind native Transaktionsmodelle auf DuskDS und sie werden auf derselben Kette abgewickelt. Ein Wallet-Profil kann Moonlight- und Phoenix-Konto parallel verwalten.
Privatsphäre ist also keine Einstellung, die man einmal einschaltet.
Sie ist eine Entscheidung auf Transaktionsebene.
Soll die Übertragung sichtbar sein? Moonlight.
Müssen Betrag und Teilnehmende abgeschirmt werden? Phoenix.
Und falls eine autorisierte Partei später Belege benötigt, unterstützt Dusk die selektive Offenlegung über Viewing Keys.
Das ist eine ziemlich andere Designentscheidung, als ein einzelnes Transaktionsmodell zu nehmen und einfach eine Privatsphäre-Schicht daran anzubauen.
Aber es lässt mich mit einer Frage zurück, die mich tatsächlich umtreibt:
Wird die Pflege zweier grundlegend unterschiedlicher Transaktionsmodelle zu einer Stärke, wenn Dusk skaliert — oder wird das langfristig eher ein Engineering-Albtraum?
Und in der realen Nutzung: Brauchen regulierte Märkte wirklich beides — oder wird am Ende eines davon den Großteil der Arbeit übernehmen?
