Quelque chose dans la documentation m’a stoppé net pendant mon scroll aujourd’hui.
Dusk Network, $DUSK , #dusk , @Dusk — l’angle de compatibilité EVM, c’est ainsi que la plupart des gens découvrent ce projet. Portez vos contrats Solidity, utilisez les outils familiers, des portefeuilles EVM existants. Le dépôt duskevm-genesis sur GitHub a été mis à jour pour la dernière fois le 8 août, montrant un travail actif sur la configuration du rollup. La machinerie tourne donc. Mais le point plus profond que je n’ai pas pu effacer, c’est dans les docs d’architecture elles-mêmes, caché dans une seule ligne : « L’inclusion des transactions est rapide, mais l’inclusion et le règlement sont des étapes différentes. »
C’est le signal. DuskEVM fonctionne sur OP Stack — essentiellement op-geth comme séquenceur, regroupant les données de transactions et les renvoyant à DuskDS sous forme de blobs. Comportement standard des rollups. Mais DuskDS, l’objectif réel, la couche conçue sur mesure en dessous — règlement déterministe, smart contracts ZK, confidentialité native — est un environnement d’exécution entièrement distinct. Les docs sont explicites : construisez sur DuskEVM pour Solidity et les outils familiers, ou construisez nativement sur DuskDS avec Rust et WASM pour une confidentialité au niveau protocole et une logique de marché personnalisée. Deux trajectoires. Pas une seule chose unifiée.
hmm… j’ai passé un peu trop de temps à supposer que la compatibilité EVM ici signifiait que le code Solidity hériterait automatiquement de l’infrastructure financière de Dusk. Ce n’est pas le cas. Le pont entre ces deux couches est volontaire et optionnel, pas automatique.
Ce qui me fait me demander — combien de développeurs qui portent vers DuskEVM vont réellement revenir et ré-architecturer pour DuskDS une fois qu’ils réaliseront ce à quoi ils ont renoncé ?
Dusk Network, $DUSK , #dusk , @Dusk — l’angle de compatibilité EVM, c’est ainsi que la plupart des gens découvrent ce projet. Portez vos contrats Solidity, utilisez les outils familiers, des portefeuilles EVM existants. Le dépôt duskevm-genesis sur GitHub a été mis à jour pour la dernière fois le 8 août, montrant un travail actif sur la configuration du rollup. La machinerie tourne donc. Mais le point plus profond que je n’ai pas pu effacer, c’est dans les docs d’architecture elles-mêmes, caché dans une seule ligne : « L’inclusion des transactions est rapide, mais l’inclusion et le règlement sont des étapes différentes. »
C’est le signal. DuskEVM fonctionne sur OP Stack — essentiellement op-geth comme séquenceur, regroupant les données de transactions et les renvoyant à DuskDS sous forme de blobs. Comportement standard des rollups. Mais DuskDS, l’objectif réel, la couche conçue sur mesure en dessous — règlement déterministe, smart contracts ZK, confidentialité native — est un environnement d’exécution entièrement distinct. Les docs sont explicites : construisez sur DuskEVM pour Solidity et les outils familiers, ou construisez nativement sur DuskDS avec Rust et WASM pour une confidentialité au niveau protocole et une logique de marché personnalisée. Deux trajectoires. Pas une seule chose unifiée.
hmm… j’ai passé un peu trop de temps à supposer que la compatibilité EVM ici signifiait que le code Solidity hériterait automatiquement de l’infrastructure financière de Dusk. Ce n’est pas le cas. Le pont entre ces deux couches est volontaire et optionnel, pas automatique.
Ce qui me fait me demander — combien de développeurs qui portent vers DuskEVM vont réellement revenir et ré-architecturer pour DuskDS une fois qu’ils réaliseront ce à quoi ils ont renoncé ?
