Ich habe mir in den letzten Tagen @Dusk erneut angeschaut. Am meisten beschäftigt mich dabei nicht die zwei Worte „Privatsphäre“, sondern wie es mit dem umgeht, was in einer Transaktion am leichtesten übersehen wird: dem Status.
Moonlight und Phoenix geben mir einen sehr anschaulichen Einstieg. Ersteres stellt den Kontostand, den Absender, den Empfänger und den Betrag in einem öffentlichen Konto dar; letzteres macht aus den Mitteln eine kryptografische note. Die Transaktion legt Betrag, Absender und die konkrete note nicht direkt offen, sondern nutzt ZKP, um nachzuweisen, ob die Mittel ausreichen und ob es Double-Spends gibt. Beim Audit kann das zudem über einen viewing key offengelegt werden. Beide Modelle sehen auf den ersten Blick sehr unterschiedlich aus, doch am Ende müssen sie alle dieselbe Frage beantworten: Wenn diese Transaktion abgeschlossen ist—wie sollte sich der Status auf der Chain denn tatsächlich verändern? Worüber ich wirklich nachdenke, ist der Transfer Contract: Er nimmt unterschiedliche Arten von payload entgegen, reicht sie an die jeweils passende Verifikationslogik weiter und integriert das Ergebnis in denselben Satz globaler Zustände. Genau dieser Schritt entscheidet im Grunde, dass eine Privacy-Transaktion nicht zu einem weiteren, isolierten Ledger wird.
Wenn man entlang des Status weiter nach unten schaut, ist DuskDS für Konsens, Finalität, Datenverfügbarkeit und Abwicklung zuständig; DuskVM führt die in WASM kompilierten Verträge aus und ist damit direkt an die Ausführung auf Dusk L1 gekoppelt; DuskEVM bietet einen alternativen EVM-Ausführungspfad. Hedger läuft auf DuskEVM und realisiert Confidential Transactions mittels Homomorpher Verschlüsselung und ZKP. In der Gesamtschau ist das Spannende an Dusk also nicht „Transaktionen zu verstecken“, sondern sicherzustellen, dass Transaktionen mit unterschiedlicher Sichtbarkeit dennoch in dieselbe Statusaktualisierungs- und Abrechnungslogik eingehen.
$DUSK übernimmt dabei gas und staking—also, dass Ausführungskosten und Netzwerksicherheit auf derselben ökonomischen Ebene landen. Für mich ist der nächste Schritt das, was wirklich zählt: Nachdem diese Gestaltung in echte Finanzprozesse überführt wurde—kann sie dann genau das verstecken, was versteckt werden muss, genau das verifizieren, was verifiziert werden muss, und am Ende einen Status liefern, der ausreichend eindeutig und ausreichend nutzbar ist.
#dusk $DUSK @Dusk
Moonlight und Phoenix geben mir einen sehr anschaulichen Einstieg. Ersteres stellt den Kontostand, den Absender, den Empfänger und den Betrag in einem öffentlichen Konto dar; letzteres macht aus den Mitteln eine kryptografische note. Die Transaktion legt Betrag, Absender und die konkrete note nicht direkt offen, sondern nutzt ZKP, um nachzuweisen, ob die Mittel ausreichen und ob es Double-Spends gibt. Beim Audit kann das zudem über einen viewing key offengelegt werden. Beide Modelle sehen auf den ersten Blick sehr unterschiedlich aus, doch am Ende müssen sie alle dieselbe Frage beantworten: Wenn diese Transaktion abgeschlossen ist—wie sollte sich der Status auf der Chain denn tatsächlich verändern? Worüber ich wirklich nachdenke, ist der Transfer Contract: Er nimmt unterschiedliche Arten von payload entgegen, reicht sie an die jeweils passende Verifikationslogik weiter und integriert das Ergebnis in denselben Satz globaler Zustände. Genau dieser Schritt entscheidet im Grunde, dass eine Privacy-Transaktion nicht zu einem weiteren, isolierten Ledger wird.
Wenn man entlang des Status weiter nach unten schaut, ist DuskDS für Konsens, Finalität, Datenverfügbarkeit und Abwicklung zuständig; DuskVM führt die in WASM kompilierten Verträge aus und ist damit direkt an die Ausführung auf Dusk L1 gekoppelt; DuskEVM bietet einen alternativen EVM-Ausführungspfad. Hedger läuft auf DuskEVM und realisiert Confidential Transactions mittels Homomorpher Verschlüsselung und ZKP. In der Gesamtschau ist das Spannende an Dusk also nicht „Transaktionen zu verstecken“, sondern sicherzustellen, dass Transaktionen mit unterschiedlicher Sichtbarkeit dennoch in dieselbe Statusaktualisierungs- und Abrechnungslogik eingehen.
$DUSK übernimmt dabei gas und staking—also, dass Ausführungskosten und Netzwerksicherheit auf derselben ökonomischen Ebene landen. Für mich ist der nächste Schritt das, was wirklich zählt: Nachdem diese Gestaltung in echte Finanzprozesse überführt wurde—kann sie dann genau das verstecken, was versteckt werden muss, genau das verifizieren, was verifiziert werden muss, und am Ende einen Status liefern, der ausreichend eindeutig und ausreichend nutzbar ist.
#dusk $DUSK @Dusk
