#dusk @Dusk $DUSK Dusk behauptet datenschutz-by-default für regulierte Finanzen, aber die tatsächliche Build-Reihenfolge erzählt eine leisere Geschichte. Die native Chain von $DUSK wird mit Vertraulichkeit direkt eingebaut ausgeliefert — Salden und Gegenparteien sind standardmäßig maskiert. DuskEVM, der Teil, der gewöhnliche Solidity-Entwickler anziehen soll, startet nicht so. Vertrauliche Transaktionen kommen dort über Hedger, eine separate Schicht, die erst später aufgesetzt wird — sie kombiniert homomorphe Verschlüsselung mit Zero-Knowledge-Proofs. So erhalten Institutionen, die über etwas wie die NPEX-Integration in #Dusk einsteigen, Privatsphäre als Baseline-Annahme, ausgelegt auf ihre Compliance-Anforderungen von Tag eins an. Der Entwickler, der über die EVM-Seite kommt, bekommt standardmäßig öffentliche Daten — Privatsphäre ist etwas, in das man erst einsteigen kann, sobald die Tools nachziehen. Das ist eine kleine Reihenfolge-Entscheidung, aber sie sagt etwas darüber, für wen die Architektur tatsächlich zuerst gezeichnet wurde. Nicht ganz ein Fehler — eher ein Hinweis. Die regulierte Institution war die Design-Vorgabe; der Allzweck-Builder wird nachträglich nachgerüstet. Das lässt einen fragen, ob „Privatsphäre für alle“ am Ende Privatsphäre für diejenigen bedeutet, die zuerst angefragt haben.