#dusk $DUSK @Dusk
L’ensemble de la pile de Dusk est construite de façon modulaire. DuskDS est la couche de règlement et de disponibilité des données — elle exécute le consensus d’attestation succincte, gère le staking et détient l’actif de base DUSK. DuskEVM est une couche d’exécution distincte, compatible Solidity, construite sur l’OP Stack (un séquenceur exécutant op-geth, plus un batcher qui publie les données des transactions sur DuskDS sous forme de blobs) et qui se règle à nouveau sur DuskDS au lieu de s’appuyer sur sa propre sécurité indépendante. DuskVM est un environnement d’exécution natif supplémentaire, encore en émergence, pour les contrats Rust/WASM, destiné aux applications qui ont besoin d’une confidentialité native ou d’une intégration au niveau du protocole. Piecrust est l’exécution WASM (construite sur Wasmer) qui était à l’origine intégrée à DuskDS et qui est désormais extraite vers DuskVM. Le réseau fonctionne sur Kadcast — un protocole de diffusion structuré de type Kademlia plutôt qu’un gossip aléatoire.
La logique derrière cette architecture est que « un seul environnement d’exécution pour tout » ne fonctionne pas pour une chaîne qui doit à la fois servir la composabilité façon DeFi et l’émission d’actifs réglementés. Plutôt que de forcer les développeurs Solidity vers un environnement natif Rust/WASM, ou de contraindre les applications de confidentialité native aux limites de l’EVM, le règlement et le consensus reposent sur une couche de base partagée tandis que les environnements d’exécution se spécialisent au-dessus. Kadcast s’inscrit dans la même logique — une diffusion structurée signifie une bande passante et une latence plus prévisibles, ce qui compte davantage pour une chaîne qui revendique une finalité déterministe que pour une chaîne qui traite la finalité de manière probabiliste.
Dissocier l’exécution du règlement signifie aussi que les garanties de DuskEVM ne sont aussi solides que l’est le pont et le mécanisme de batching qui le relie à nouveau à DuskDS. À mesure que DuskVM mûrit aux côtés de DuskEVM, le réseau finit par faire fonctionner trois surfaces d’exécution pour une seule couche de règlement. Ce découpage réduit-il réellement la friction d’intégration pour les développeurs, ou déplace-t-il simplement la complexité de « quel VM dois-je utiliser » à « quelle couche détient réellement ma garantie » ?
L’ensemble de la pile de Dusk est construite de façon modulaire. DuskDS est la couche de règlement et de disponibilité des données — elle exécute le consensus d’attestation succincte, gère le staking et détient l’actif de base DUSK. DuskEVM est une couche d’exécution distincte, compatible Solidity, construite sur l’OP Stack (un séquenceur exécutant op-geth, plus un batcher qui publie les données des transactions sur DuskDS sous forme de blobs) et qui se règle à nouveau sur DuskDS au lieu de s’appuyer sur sa propre sécurité indépendante. DuskVM est un environnement d’exécution natif supplémentaire, encore en émergence, pour les contrats Rust/WASM, destiné aux applications qui ont besoin d’une confidentialité native ou d’une intégration au niveau du protocole. Piecrust est l’exécution WASM (construite sur Wasmer) qui était à l’origine intégrée à DuskDS et qui est désormais extraite vers DuskVM. Le réseau fonctionne sur Kadcast — un protocole de diffusion structuré de type Kademlia plutôt qu’un gossip aléatoire.
La logique derrière cette architecture est que « un seul environnement d’exécution pour tout » ne fonctionne pas pour une chaîne qui doit à la fois servir la composabilité façon DeFi et l’émission d’actifs réglementés. Plutôt que de forcer les développeurs Solidity vers un environnement natif Rust/WASM, ou de contraindre les applications de confidentialité native aux limites de l’EVM, le règlement et le consensus reposent sur une couche de base partagée tandis que les environnements d’exécution se spécialisent au-dessus. Kadcast s’inscrit dans la même logique — une diffusion structurée signifie une bande passante et une latence plus prévisibles, ce qui compte davantage pour une chaîne qui revendique une finalité déterministe que pour une chaîne qui traite la finalité de manière probabiliste.
Dissocier l’exécution du règlement signifie aussi que les garanties de DuskEVM ne sont aussi solides que l’est le pont et le mécanisme de batching qui le relie à nouveau à DuskDS. À mesure que DuskVM mûrit aux côtés de DuskEVM, le réseau finit par faire fonctionner trois surfaces d’exécution pour une seule couche de règlement. Ce découpage réduit-il réellement la friction d’intégration pour les développeurs, ou déplace-t-il simplement la complexité de « quel VM dois-je utiliser » à « quelle couche détient réellement ma garantie » ?