L’architecture actuelle de Dusk a une caractéristique très évidente — elle est délibérément « découplée ».
Contrairement à la plupart des blockchains publiques qui entassent le consensus, l’exécution et le règlement dans une pile monolithique, Dusk sépare ces trois éléments. Tout en bas se trouve DuskDS, qui gère le consensus, la disponibilité des données et le règlement ; au milieu, un DuskEVM, entièrement compatible avec Solidity, permettant aux développeurs venant d’Ethereum de migrer presque sans modifier le code ; et tout en haut, une couche DuskVM, dédiée à l’exécution d’applications natives axées sur la confidentialité. Les trois couches gèrent chacune leur domaine, et sont reliées par le même jeton DUSK.
La logique derrière ce choix n’est pas difficile à comprendre. Pour bâtir une chaîne autonome, le coût le plus important est que les développeurs doivent réapprendre toute la chaîne d’outils, et la montée en puissance de l’écosystème sera très lente. Une fois une couche EVM ajoutée, Solidity, Hardhat, MetaMask et les autres outils déjà existants peuvent être utilisés directement, ce qui réduit immédiatement les frictions pour recruter des développeurs.
Mais le coût de ce choix est lui aussi très direct — la complexité augmente, et elle augmente dans la zone la plus critique.
Les flux inter-couches impliquent de nouvelles hypothèses de confiance et de nouvelles surfaces d’attaque. Le transfert d’actifs entre DuskDS et DuskEVM nécessite un pont natif ; même s’il n’est pas nécessaire d’envelopper les actifs ni de recourir à un dépositaire, le simple fait de traverser les couches introduit déjà des étapes de vérification supplémentaires. Au cours des dernières années, il y a eu bien plus d’incidents dus à des conceptions inter-couches qu’à des problèmes liés aux machines virtuelles elles-mêmes.
Il y a aussi un problème facilement négligé — la répartition des nœuds. Dusk utilise un consensus SBA, qui exige que les nœuds restent en ligne en permanence et soient correctement configurés. Ces exigences garantissent certes la sécurité du réseau, mais elles signifient aussi que le coût matériel et opérationnel pour les participants ordinaires n’est pas faible s’ils veulent faire tourner un nœud sur le long terme. Si les nœuds finissent peu à peu par se concentrer entre les mains de quelques gros détenteurs, même la meilleure architecture perdra sa substance.
Donc, quand j’examine Dusk aujourd’hui, ce qui m’importe, ce n’est pas le nombre de couches ni le TPS. Je regarde deux choses : premièrement, si l’état des actifs et les frontières de confidentialité entre les couches sont clairement expliqués ; deuxièmement, quels types d’applications apparaissent sur la couche EVM — si ce ne sont que des protocoles génériques importés, alors la modularité n’est qu’un nouveau mode de commercialisation ; si, en revanche, des applications commencent réellement à exploiter les capacités confidentielles de la couche de base (par exemple un carnet d’ordres chiffré via Hedger ou des titres confidentiels conformes au standard XSC), alors cela signifie que la différenciation de cette architecture est réellement utilisée.
L’architecture est en place ; la question est maintenant de voir ce qui peut pousser dessus.
#dusk $DUSK @Dusk
Contrairement à la plupart des blockchains publiques qui entassent le consensus, l’exécution et le règlement dans une pile monolithique, Dusk sépare ces trois éléments. Tout en bas se trouve DuskDS, qui gère le consensus, la disponibilité des données et le règlement ; au milieu, un DuskEVM, entièrement compatible avec Solidity, permettant aux développeurs venant d’Ethereum de migrer presque sans modifier le code ; et tout en haut, une couche DuskVM, dédiée à l’exécution d’applications natives axées sur la confidentialité. Les trois couches gèrent chacune leur domaine, et sont reliées par le même jeton DUSK.
La logique derrière ce choix n’est pas difficile à comprendre. Pour bâtir une chaîne autonome, le coût le plus important est que les développeurs doivent réapprendre toute la chaîne d’outils, et la montée en puissance de l’écosystème sera très lente. Une fois une couche EVM ajoutée, Solidity, Hardhat, MetaMask et les autres outils déjà existants peuvent être utilisés directement, ce qui réduit immédiatement les frictions pour recruter des développeurs.
Mais le coût de ce choix est lui aussi très direct — la complexité augmente, et elle augmente dans la zone la plus critique.
Les flux inter-couches impliquent de nouvelles hypothèses de confiance et de nouvelles surfaces d’attaque. Le transfert d’actifs entre DuskDS et DuskEVM nécessite un pont natif ; même s’il n’est pas nécessaire d’envelopper les actifs ni de recourir à un dépositaire, le simple fait de traverser les couches introduit déjà des étapes de vérification supplémentaires. Au cours des dernières années, il y a eu bien plus d’incidents dus à des conceptions inter-couches qu’à des problèmes liés aux machines virtuelles elles-mêmes.
Il y a aussi un problème facilement négligé — la répartition des nœuds. Dusk utilise un consensus SBA, qui exige que les nœuds restent en ligne en permanence et soient correctement configurés. Ces exigences garantissent certes la sécurité du réseau, mais elles signifient aussi que le coût matériel et opérationnel pour les participants ordinaires n’est pas faible s’ils veulent faire tourner un nœud sur le long terme. Si les nœuds finissent peu à peu par se concentrer entre les mains de quelques gros détenteurs, même la meilleure architecture perdra sa substance.
Donc, quand j’examine Dusk aujourd’hui, ce qui m’importe, ce n’est pas le nombre de couches ni le TPS. Je regarde deux choses : premièrement, si l’état des actifs et les frontières de confidentialité entre les couches sont clairement expliqués ; deuxièmement, quels types d’applications apparaissent sur la couche EVM — si ce ne sont que des protocoles génériques importés, alors la modularité n’est qu’un nouveau mode de commercialisation ; si, en revanche, des applications commencent réellement à exploiter les capacités confidentielles de la couche de base (par exemple un carnet d’ordres chiffré via Hedger ou des titres confidentiels conformes au standard XSC), alors cela signifie que la différenciation de cette architecture est réellement utilisée.
L’architecture est en place ; la question est maintenant de voir ce qui peut pousser dessus.
#dusk $DUSK @Dusk
