$DUSK $aDUSK #dusk — die Schicht, die für die Entwicklerübernahme gedacht ist, startet standardmäßig als transparent und nicht als privat.
Die meisten „privaten“ Ketten behandeln Compliance als nachträglichen Zusatz, der an ein öffentliches Ledger angeschraubt wird — Mischer, optionale Abschirmung, ein KYC-Tor, das außerhalb des Protokolls sitzt. Dusks Ansatz war anders: Privatsphäre ist direkt in der Abwicklung selbst eingebettet. Laut den eigenen Dusk-Dokumenten gibt dir Native DuskDS zwei Transaktionsmodelle — Moonlight (transparent, sichtbare Salden) oder Phoenix (geschützte Notizen, Zero-Knowledge standardmäßig). @DuskFoundation hat seine Compliance-Erzählung auf diesem Standard aufgebaut, nicht als Add-on.
Dann sah ich mir DuskEVM an, die Solidity-kompatible Schicht, die tatsächlich Entwickler anziehen soll. Die Dokus beschreiben Hedger, das Modul für homomorphe Verschlüsselung/ZK-Privatsphäre, als ein Werkzeug, zu dem man „je nach Bedarf“ greift. Normale Contracts auf DuskEVM verhalten sich wie ganz normale EVM-Contracts — transparent, außer jemand verbindet explizit Hedger. Das angeprangerte „angeschraubte“ Muster, das Dusk bei anderen Ketten kritisiert, taucht in der eigenen Wachstumsoberfläche wieder auf.
Was sich für mich geändert hat: „Privatsphäre by Design“ ist hier keine einzelne Eigenschaft, sondern zwei Defaults, die zusammengeklebt sind — und die Schicht, die die meisten Builder tatsächlich anfassen werden, erbt die schwächere. Das tötet die These nicht, aber macht enger, wo sie gilt. Lohnt sich zu prüfen: Integrieren frühe DuskEVM-Deployments tatsächlich Hedger, oder werden sie transparent ausgeliefert wie jede andere EVM-Kette?
#dusk $DUSK @Dusk
Die meisten „privaten“ Ketten behandeln Compliance als nachträglichen Zusatz, der an ein öffentliches Ledger angeschraubt wird — Mischer, optionale Abschirmung, ein KYC-Tor, das außerhalb des Protokolls sitzt. Dusks Ansatz war anders: Privatsphäre ist direkt in der Abwicklung selbst eingebettet. Laut den eigenen Dusk-Dokumenten gibt dir Native DuskDS zwei Transaktionsmodelle — Moonlight (transparent, sichtbare Salden) oder Phoenix (geschützte Notizen, Zero-Knowledge standardmäßig). @DuskFoundation hat seine Compliance-Erzählung auf diesem Standard aufgebaut, nicht als Add-on.
Dann sah ich mir DuskEVM an, die Solidity-kompatible Schicht, die tatsächlich Entwickler anziehen soll. Die Dokus beschreiben Hedger, das Modul für homomorphe Verschlüsselung/ZK-Privatsphäre, als ein Werkzeug, zu dem man „je nach Bedarf“ greift. Normale Contracts auf DuskEVM verhalten sich wie ganz normale EVM-Contracts — transparent, außer jemand verbindet explizit Hedger. Das angeprangerte „angeschraubte“ Muster, das Dusk bei anderen Ketten kritisiert, taucht in der eigenen Wachstumsoberfläche wieder auf.
Was sich für mich geändert hat: „Privatsphäre by Design“ ist hier keine einzelne Eigenschaft, sondern zwei Defaults, die zusammengeklebt sind — und die Schicht, die die meisten Builder tatsächlich anfassen werden, erbt die schwächere. Das tötet die These nicht, aber macht enger, wo sie gilt. Lohnt sich zu prüfen: Integrieren frühe DuskEVM-Deployments tatsächlich Hedger, oder werden sie transparent ausgeliefert wie jede andere EVM-Kette?
#dusk $DUSK @Dusk
