Dusk macht heute um 15:00 CEST ein Binance Square AMA und es lohnt sich, deinen Kalender freizuhalten. Du bekommst sowohl Emanuele Francioni (CEO) als auch Hein Dauven (CTO) in derselben Session – das ist selten, normalerweise ist es entweder der eine oder der andere. Wenn du den DuskDS-, DuskEVM- und DuskVM-Aufbau verfolgst und noch Fragen hast, ist das der richtige Ort, um sie mitzubringen.

Lass mich für den Anfang erklären, was ich gelernt habe: Ich habe immer wieder „privacy“ von verschiedenen Chains gehört und ehrlich gesagt war ich skeptisch, weil es in der Regel einfach bedeutet, dass nur ein einzelner privater Pool an eine ansonsten öffentliche Kette „angeflanscht“ wird. Also habe ich genauer nachgeforscht, wie Dusk das in seinem Stack tatsächlich strukturiert – und es war nicht das, was ich erwartet hatte.

Grundsätzlich teilt Dusk die Aufgabe in drei Ebenen auf, statt alles in eine zu quetschen. Unten sitzt DuskDS und kümmert sich um Settlement-Consensus und Data Availability. Es betreibt ein Proof-of-Stake-System namens Succinct Attestation, das deterministische Finalität liefert – das ist wichtig, wenn man regulierte Assets abwickelt und sich keine probabilistische Bestätigung leisten kann.

Das hat mich überrascht: Darauf sitzt DuskEVM. Es ist als OP-Stack-Rollup gebaut, sodass Solidity-Entwickler ganz normales EVM-Tooling nutzen können. Die Privacy kommt dort über etwas namens Hedger, das homomorphe Verschlüsselung mit Zero-Knowledge-Proofs kombiniert – statt sich nur auf ZK allein zu verlassen.

Dann gibt es noch DuskVM: die native Rust- und WASM-Umgebung, in der Contracts von Anfang an privacy-aware sind, statt dass man die Privacy erst später „draufpackt“.

Da hat es bei mir Klick gemacht: Die gleichen Settlement-Garantien gelten im Hintergrund die ganze Zeit, aber jede Ebene bekommt Privacy auf eine Art, die wirklich zu dem passt, wie Entwickler dort arbeiten – statt einen einzigen Ansatz überall aufzuzwingen.

#dusk $DUSK @Dusk

Auf welcher Ebene würdest du tatsächlich aufbauen?