Au début, Dusk a surtout attiré des geeks et de vieux joueurs : beaucoup ont été séduits par sa stack sous-jacente développée en interne — un runtime Rusk construit sur Rust, une machine virtuelle ZK native, Piecrust, ainsi qu’un modèle de transactions Phoenix. L’intention de ce système conçu de bout en bout est très claire : faire reposer l’environnement de preuve à connaissance nulle sur du « pur sang », avec un support natif, dès le niveau du virtual machine, pour des smart contracts confidentiels et une divulgation sélective.
Mais la réalité a offert une leçon à toutes les chaînes cherchant à « fabriquer leurs propres roues » : sans base de développeurs comparable à l’écosystème Ethereum, même la plus élégante des architectures développées en interne ne serait qu’une île.
C’est ainsi qu’on a vu Dusk opérer un tournant majeur : d’un L1 monolithique, elle est passée à une architecture modulaire en trois couches — une couche de consensus et de règlement (DuskDS) au niveau du bas, une couche de confidentialité (DuskVM/Piecrust) pour le niveau intermédiaire, et enfin DuskEVM, récemment mis en ligne sur le réseau de test et activement promu.
Le raisonnement officiel est très séduisant : permettre aux développeurs de déployer sans friction en utilisant Solidity et Hardhat, familiers, tout en héritant des capacités de conformité et de confidentialité de la couche inférieure.
Mais c’est précisément ce qui fait naître un paradoxe d’ingénierie particulièrement percutant :
L’EVM est, par essence, une machine globale à état entièrement transparent, tandis que le cœur de la confidentialité ZK repose sur la dissimulation de l’état.
Accrocher un EVM standard à la couche de règlement peut certes attirer rapidement des développeurs externes ; mais si les développeurs se contentent d’aller vite, en continuant à écrire sur DuskEVM ces smart contracts Solidity standard et transparents, les Piecrust et la couche native de confidentialité ZK que Dusk a mis des années à polir ne risquent-ils pas de devenir une simple « vitrine », vidée de sa substance ?
Le point plus concret encore est la complexité de la synchronisation d’état entre couches. Quand un actif conforme est réglé sur DuskDS, circule sur DuskEVM, puis cherche à appeler une preuve à connaissance nulle sur DuskVM, jusqu’où faut-il aller en termes de coût invisible — en latence d’exécution et en sécurité transversale — pour que les mécanismes d’engagement d’état et de pré-vérification (Pre-verifier) entre plusieurs couches soient correctement gérés ?
Dans l’histoire de l’évolution des infrastructures cryptographiques, nous avons vu trop de blockchains sombrer dans une « adoption totale de l’EVM » par crainte de l’écosystème, puis polir leur singularité technique jusqu’à la dissoudre, pour finalement devenir une énième banale sidechain d’Ethereum. La modularité en trois couches de Dusk est certes très ambitieuse : elle cherche à concilier « habitudes de développement d’Ethereum » et « conformité confidentialité nativement native » ; mais, dans le déploiement réel, cette mosaïque complexe parviendra-t-elle à libérer la puissance de la finance conforme, ou bien sera-t-elle diluée par des compromis d’ingénierie, au point de perdre la pureté initiale ?
#dusk $DUSK @Dusk
Mais la réalité a offert une leçon à toutes les chaînes cherchant à « fabriquer leurs propres roues » : sans base de développeurs comparable à l’écosystème Ethereum, même la plus élégante des architectures développées en interne ne serait qu’une île.
C’est ainsi qu’on a vu Dusk opérer un tournant majeur : d’un L1 monolithique, elle est passée à une architecture modulaire en trois couches — une couche de consensus et de règlement (DuskDS) au niveau du bas, une couche de confidentialité (DuskVM/Piecrust) pour le niveau intermédiaire, et enfin DuskEVM, récemment mis en ligne sur le réseau de test et activement promu.
Le raisonnement officiel est très séduisant : permettre aux développeurs de déployer sans friction en utilisant Solidity et Hardhat, familiers, tout en héritant des capacités de conformité et de confidentialité de la couche inférieure.
Mais c’est précisément ce qui fait naître un paradoxe d’ingénierie particulièrement percutant :
L’EVM est, par essence, une machine globale à état entièrement transparent, tandis que le cœur de la confidentialité ZK repose sur la dissimulation de l’état.
Accrocher un EVM standard à la couche de règlement peut certes attirer rapidement des développeurs externes ; mais si les développeurs se contentent d’aller vite, en continuant à écrire sur DuskEVM ces smart contracts Solidity standard et transparents, les Piecrust et la couche native de confidentialité ZK que Dusk a mis des années à polir ne risquent-ils pas de devenir une simple « vitrine », vidée de sa substance ?
Le point plus concret encore est la complexité de la synchronisation d’état entre couches. Quand un actif conforme est réglé sur DuskDS, circule sur DuskEVM, puis cherche à appeler une preuve à connaissance nulle sur DuskVM, jusqu’où faut-il aller en termes de coût invisible — en latence d’exécution et en sécurité transversale — pour que les mécanismes d’engagement d’état et de pré-vérification (Pre-verifier) entre plusieurs couches soient correctement gérés ?
Dans l’histoire de l’évolution des infrastructures cryptographiques, nous avons vu trop de blockchains sombrer dans une « adoption totale de l’EVM » par crainte de l’écosystème, puis polir leur singularité technique jusqu’à la dissoudre, pour finalement devenir une énième banale sidechain d’Ethereum. La modularité en trois couches de Dusk est certes très ambitieuse : elle cherche à concilier « habitudes de développement d’Ethereum » et « conformité confidentialité nativement native » ; mais, dans le déploiement réel, cette mosaïque complexe parviendra-t-elle à libérer la puissance de la finance conforme, ou bien sera-t-elle diluée par des compromis d’ingénierie, au point de perdre la pureté initiale ?
#dusk $DUSK @Dusk
