Ich habe eine Stunde damit verbracht, in Dusk’ Dokumentation zur Contract-Deployment zu graben, und bin immer wieder bei einem Detail gelandet: Privatsphäre ist nicht der Standardzustand – sie ist ein Flag, das du setzt. Dusk ($DUSK , #dusk ,@Dusk ) vermarktet sich selbst als „privacy-first“-Execution-Layer für reguliertes Finance, aber Piecrust, seine VM, liefert sowohl vertrauliche als auch transparente Contracts parallel aus – nicht vertraulich-vorab mit Transparenz als Ausnahme. Ein Entwickler, der ohne Angabe der Vertraulichkeit deployed, erhält standardmäßig einen vollständig öffentlichen Zustand, wie bei den meisten anderen Chains ebenfalls. Die Compliance-Tools – Citadel, die ZK-Identity-Layer – existieren genau deshalb, weil Privatsphäre für Regulierer nachweisbar und rückgängig machbar sein muss; das ist ein stimmiges Design. Es bedeutet aber auch, dass das „privacy-first“-Framing eher eine verfügbare Fähigkeit beschreibt als ein Basisverhalten. Die meisten Aktivitäten, die ich nachverfolgen konnte, neigen weiterhin stark zu Transparenz – vermutlich, weil die Reife der Tools und die Vertrautheit der Auditoren den Weg des geringsten Widerstands begünstigen. Das ist eine nachvollziehbare Architektur für institutionelles Finance, bei der selektive Offenlegung wichtiger ist als pauschale Geheimhaltung. Und trotzdem gibt es eine Lücke zwischen einer Chain, die für Privatsphäre gebaut wurde, und einer Chain, bei der Privatsphäre genau das ist, wonach man greift. Das lässt mich darüber nachdenken, wie viel von „privacy-first“ in dieser Kategorie wirklich mit dem Default-Zustand zu tun hat – und wie viel mit einem verfügbaren Zustand.