Über private Transaktionen hinaus: Die DUSK-Architektur verstehen. Ich ging hinein in der Erwartung, dass die Privacy-Layer der Standard-Übertragungsweg ist, und fand das Gegenteil. Dusk ($DUSK , #dusk , @Dusk ) betreibt zwei Transaktionsmodelle parallel, Phoenix und Moonlight. In den Dokumenten wird Moonlight, das transparente kontenbasierte Modell, auf Protokollebene als „einfach der transparente Weg, um DUSK zu bewegen“ beschrieben. Phoenix, das eigentliche Zero-Knowledge-geschützte Modell mit verschlüsselten Notizen und Nullifiers, ist dasjenige, das die anspruchsvollere kryptografische Arbeit leistet, wirkt aber wie der bewusste, optionale Pfad statt wie der Ruhezustand. Beide lösen über denselben Transfer-Vertrag aus, beide zahlen Gas, beide können einen Contract-Call starten, sodass die Entscheidung keine funktionale Reibung ist—sondern eine Designentscheidung darüber, welches Verhalten als selbstverständlich behandelt wird. Eine Kette, die speziell dafür gebaut wurde, private Smart-Contract-Ausführung zu ermöglichen, beschreibt ihre schlichten Konten als Standard-Erklärung und ihre Privacy-Engine als die Funktion, nach der man greifen soll. Vielleicht ist das einfach eine stimmige UX-Sequenzierung für das Onboarding von Institutionen. Oder vielleicht sagt es etwas darüber, welcher Use Case tatsächlich als Erstes ausgeführt wird, sobald die echte Nutzung einsetzt. Welches optimiert Dusk tatsächlich in Bezug auf die Akzeptanz?