@Dusk #dusk
$DUSK Kernkomponenten
Das Dusk-Netzwerk nutzt eine modulare Architektur für regulierten Finanzbereich: Privatsphäre, wenn sie benötigt wird, Transparenz, wenn sie nützlich ist, und deterministische Abwicklung, wenn Markt-Workflows dies erfordern. Auf hoher Ebene:
Komponente :
1. DuskDS
Rolle :
Grundlage für Abwicklung und Datenverfügbarkeit: Konsens, Finalität und Dusk-Transaktionsmodelle
Wohin als Nächstes :
Dusk hat eine Zwei-Schichten-Architektur:
DuskDS – die Abwicklungs- und Datenebene (Konsens, Datenverfügbarkeit, Transaktionsmodelle)
DuskEVM – die EVM-Ausführungsebene, auf der Smart Contracts laufen und in der der Hedger beheimatet ist
Diese Seite beschreibt die Transaktionsmodelle auf DuskDS. Sie bildet den Hintergrund für alle, die verstehen möchten, wie Abwicklung und Privatsphäre im Inneren funktionieren. Wenn du dApps auf DuskEVM entwickelst, wirst du meistens mit dem Hedger und EVM-Contracts statt mit diesen Modellen direkt interagieren.
Phoenix vs. Moonlight (auf DuskDS)Auf DuskDS kann sich der Wert auf zwei native Arten bewegen:
Moonlight – öffentliche, kontobasierte Überweisungen
Phoenix – geschützte, notenbasierte Überweisungen mittels Zero-Knowledge-Proofs
Beides wird letztlich auf derselben Kette abgewickelt, aber es werden unterschiedlichen Beobachtern jeweils unterschiedliche Informationen offengelegt.
Für vollständige Implementierungsdetails kannst du dich auf das Whitepaper beziehen.
Moonlight – öffentliche Guthaben
Moonlight ist das transparente Transaktionsmodell:
Konten haben sichtbare Guthaben.
Überweisungen zeigen Absender, Empfänger und Betrag.
Geeignet für Abläufe, die beobachtbar sein müssen (z. B. bestimmte Treasury- oder Reporting-Szenarien).
Konzeptionell verhält es sich wie ein Standard-Kontomodell.
Für die meisten Nutzer ist das „einfach der transparente Weg, DUSK auf Protokollebene zu transferieren“.
Phoenix – geschützte Guthaben
Phoenix ist das privatsphärefreundliche Modell:
Mittel leben als verschlüsselte „Notizen“ statt als explizite Guthaben.
Transaktionen belegen die Korrektheit (keine Doppelausgaben, genügend Mittel) mit Zero-Knowledge-Proofs, ohne offenzulegen:wie viel bewegt wird,wer die Note gesendet hat, außer an den Empfänger,zwischen welchen konkreten Notizen.
Nutzer können Informationen selektiv offenlegen, indem sie Viewing Keys verwenden, wenn Regulierung oder Auditing dies erfordert.
$DUSK Kernkomponenten
Das Dusk-Netzwerk nutzt eine modulare Architektur für regulierten Finanzbereich: Privatsphäre, wenn sie benötigt wird, Transparenz, wenn sie nützlich ist, und deterministische Abwicklung, wenn Markt-Workflows dies erfordern. Auf hoher Ebene:
Komponente :
1. DuskDS
Rolle :
Grundlage für Abwicklung und Datenverfügbarkeit: Konsens, Finalität und Dusk-Transaktionsmodelle
Wohin als Nächstes :
Dusk hat eine Zwei-Schichten-Architektur:
DuskDS – die Abwicklungs- und Datenebene (Konsens, Datenverfügbarkeit, Transaktionsmodelle)
DuskEVM – die EVM-Ausführungsebene, auf der Smart Contracts laufen und in der der Hedger beheimatet ist
Diese Seite beschreibt die Transaktionsmodelle auf DuskDS. Sie bildet den Hintergrund für alle, die verstehen möchten, wie Abwicklung und Privatsphäre im Inneren funktionieren. Wenn du dApps auf DuskEVM entwickelst, wirst du meistens mit dem Hedger und EVM-Contracts statt mit diesen Modellen direkt interagieren.
Phoenix vs. Moonlight (auf DuskDS)Auf DuskDS kann sich der Wert auf zwei native Arten bewegen:
Moonlight – öffentliche, kontobasierte Überweisungen
Phoenix – geschützte, notenbasierte Überweisungen mittels Zero-Knowledge-Proofs
Beides wird letztlich auf derselben Kette abgewickelt, aber es werden unterschiedlichen Beobachtern jeweils unterschiedliche Informationen offengelegt.
Für vollständige Implementierungsdetails kannst du dich auf das Whitepaper beziehen.
Moonlight – öffentliche Guthaben
Moonlight ist das transparente Transaktionsmodell:
Konten haben sichtbare Guthaben.
Überweisungen zeigen Absender, Empfänger und Betrag.
Geeignet für Abläufe, die beobachtbar sein müssen (z. B. bestimmte Treasury- oder Reporting-Szenarien).
Konzeptionell verhält es sich wie ein Standard-Kontomodell.
Für die meisten Nutzer ist das „einfach der transparente Weg, DUSK auf Protokollebene zu transferieren“.
Phoenix – geschützte Guthaben
Phoenix ist das privatsphärefreundliche Modell:
Mittel leben als verschlüsselte „Notizen“ statt als explizite Guthaben.
Transaktionen belegen die Korrektheit (keine Doppelausgaben, genügend Mittel) mit Zero-Knowledge-Proofs, ohne offenzulegen:wie viel bewegt wird,wer die Note gesendet hat, außer an den Empfänger,zwischen welchen konkreten Notizen.
Nutzer können Informationen selektiv offenlegen, indem sie Viewing Keys verwenden, wenn Regulierung oder Auditing dies erfordert.
