#dusk $DUSK @Dusk
Dusk's gesamter Stack ist modular aufgebaut. DuskDS ist die Settlement- und Data-Availability-Schicht — sie führt den Succinct-Attestation-Konsens aus, übernimmt das Staking und hält das grundlegende DUSK-Asset. DuskEVM ist eine separate Solidity-kompatible Execution-Layer, die auf dem OP Stack basiert (ein Sequencer, der op-geth ausführt, plus ein Batcher, der Transaktionsdaten als Blobs zurück an DuskDS postet), und sie settles wieder in DuskDS ein, statt sich auf eine eigene unabhängige Sicherheit zu verlassen. DuskVM ist eine weitere, noch im Entstehen befindliche native Ausführungsumgebung für Rust/WASM-Contracts — gedacht für Anwendungen, die native Privatsphäre oder eine Integration auf Protokoll-Ebene benötigen. Piecrust ist die WASM-Laufzeitumgebung (basierend auf Wasmer), die ursprünglich in DuskDS eingebettet war und nun in DuskVM extrahiert wird. Das Networking läuft über Kadcast — ein strukturierter, Kademlia-ähnlicher Broadcast-Standard statt eines zufälligen Gossip.
Die Logik hinter dieser Architektur ist, dass „eine Ausführungsumgebung für alles“ nicht funktioniert, wenn eine Kette gleichzeitig DeFi-ähnliche Komponierbarkeit und regulierte Asset-Ausgabe bedienen soll. Anstatt Solidity-Entwickler in eine native Rust/WASM-Umgebung zu zwingen oder native Privacy-Anwendungen in die EVM-Grenzen zu pressen, sitzen Settlement und Konsens auf einer gemeinsamen Basisschicht, während sich die Ausführungsumgebungen darüber spezialisieren. Kadcast passt zu derselben Logik — strukturierter Broadcast bedeutet vorhersehbarere Bandbreite und Latenz. Das ist wichtiger für eine Kette, die deterministische Finalität verspricht, als für eine, die Finalität probabilistisch behandelt.
Die Trennung von Ausführung und Settlement bedeutet außerdem, dass die Garantien von DuskEVM nur so stark sind wie die Bridge und der Batching-Mechanismus, die es zurück mit DuskDS verbinden. Während DuskVM neben DuskEVM reift, läuft das Netzwerk am Ende drei Ausführungsoberflächen gegenüber einer einzigen Settlement-Schicht. Verringert diese Aufteilung die Integrationsreibung für Entwickler tatsächlich, oder verlagert sie nur die Komplexität von „Welche VM verwende ich?“ zu „Welche Schicht hält eigentlich meine Garantie?“
Dusk's gesamter Stack ist modular aufgebaut. DuskDS ist die Settlement- und Data-Availability-Schicht — sie führt den Succinct-Attestation-Konsens aus, übernimmt das Staking und hält das grundlegende DUSK-Asset. DuskEVM ist eine separate Solidity-kompatible Execution-Layer, die auf dem OP Stack basiert (ein Sequencer, der op-geth ausführt, plus ein Batcher, der Transaktionsdaten als Blobs zurück an DuskDS postet), und sie settles wieder in DuskDS ein, statt sich auf eine eigene unabhängige Sicherheit zu verlassen. DuskVM ist eine weitere, noch im Entstehen befindliche native Ausführungsumgebung für Rust/WASM-Contracts — gedacht für Anwendungen, die native Privatsphäre oder eine Integration auf Protokoll-Ebene benötigen. Piecrust ist die WASM-Laufzeitumgebung (basierend auf Wasmer), die ursprünglich in DuskDS eingebettet war und nun in DuskVM extrahiert wird. Das Networking läuft über Kadcast — ein strukturierter, Kademlia-ähnlicher Broadcast-Standard statt eines zufälligen Gossip.
Die Logik hinter dieser Architektur ist, dass „eine Ausführungsumgebung für alles“ nicht funktioniert, wenn eine Kette gleichzeitig DeFi-ähnliche Komponierbarkeit und regulierte Asset-Ausgabe bedienen soll. Anstatt Solidity-Entwickler in eine native Rust/WASM-Umgebung zu zwingen oder native Privacy-Anwendungen in die EVM-Grenzen zu pressen, sitzen Settlement und Konsens auf einer gemeinsamen Basisschicht, während sich die Ausführungsumgebungen darüber spezialisieren. Kadcast passt zu derselben Logik — strukturierter Broadcast bedeutet vorhersehbarere Bandbreite und Latenz. Das ist wichtiger für eine Kette, die deterministische Finalität verspricht, als für eine, die Finalität probabilistisch behandelt.
Die Trennung von Ausführung und Settlement bedeutet außerdem, dass die Garantien von DuskEVM nur so stark sind wie die Bridge und der Batching-Mechanismus, die es zurück mit DuskDS verbinden. Während DuskVM neben DuskEVM reift, läuft das Netzwerk am Ende drei Ausführungsoberflächen gegenüber einer einzigen Settlement-Schicht. Verringert diese Aufteilung die Integrationsreibung für Entwickler tatsächlich, oder verlagert sie nur die Komplexität von „Welche VM verwende ich?“ zu „Welche Schicht hält eigentlich meine Garantie?“