#dusk Tout le monde a dû en faire l’expérience avec Ethereum (#ETH ), ou avec des plateformes L2 comme Arbitrum et Optimism. Coder des contrats Solidity, c’est facile, mais dès qu’on se retrouve face à des calculs complexes ou à des preuves à divulgation nulle (ZKP), les performances de la machine virtuelle EVM (Ethereum Virtual Machine) deviennent aussi lentes qu’une vieille voiture ancienne. En plus, les frais de Gas sont carrément exorbitants. En revanche, si l’on veut obtenir de meilleures performances en créant un tout nouveau langage de bas niveau, ni les développeurs ni les utilisateurs ne sont vraiment prêts à déménager, et l’écosystème finit par se refroidir.
Aujourd’hui, en feuilletant les choix de conception de @Dusk ($DUSK ), j’ai trouvé l’approche vraiment intéressante : elle transforme littéralement le système en un ensemble de “briques Lego” modulaires.
En résumé, elle sépare la couche de base en trois parties :
La “grande comptabilité” et la salle de compensation (DuskDS) : dédiée au consensus SA et au règlement des données. C’est un peu comme le serveur principal d’une banque : il s’occupe uniquement de la reconnaissance définitive et de la sécurité des actifs au niveau le plus fondamental, sans s’éparpiller, afin de garantir une très forte disponibilité des données et une détermination certaine du règlement.
Le moteur natif “ultra-rapide” (DuskVM / Piecrust) : une machine virtuelle native exécutée avec Rust et WASM, conçue pour traiter les preuves à divulgation nulle et les calculs de confidentialité très difficiles. C’est comme ajouter une carte graphique professionnelle au système : les transactions de confidentialité ZK sont alors calculées à une vitesse qui décoiffe.
“L’interface universelle d’Ethereum pour transporter les briques” (DuskEVM) : une couche de compatibilité spécialement pensée pour les développeurs de l’écosystème Ethereum. Les développeurs n’ont pas besoin d’apprendre un nouveau langage : avec leur environnement habituel (Hardhat, Metamask), ils peuvent directement “faire un copier-coller” des applications construites sur ETH, puis payer le Gas en utilisant $DUSK .
Cette séparation entre la couche de règlement et la couche d’exécution donne vraiment l’impression d’avoir branché “sans douleur” l’énorme écosystème d’Ethereum sur une base ultra-performante dotée d’un accélérateur de confidentialité ZKP.
Mais, pour être honnête : l’idée d’une architecture en couches est excellente, toutefois les interactions entre plusieurs couches mettent surtout à l’épreuve la sécurité. Quand des actifs sont transférés d’une couche à l’autre, entre DuskEVM et la couche native de confidentialité, la complexité logique double : le contrat contient-il des failles ? Le délai de règlement inter-couche que les utilisateurs vont subir est-il acceptable ? Ce sont là de véritables examens à passer avant que l’écosystème du réseau principal puisse vraiment prospérer.
Échangez dans la section commentaires !
Aujourd’hui, en feuilletant les choix de conception de @Dusk ($DUSK ), j’ai trouvé l’approche vraiment intéressante : elle transforme littéralement le système en un ensemble de “briques Lego” modulaires.
En résumé, elle sépare la couche de base en trois parties :
La “grande comptabilité” et la salle de compensation (DuskDS) : dédiée au consensus SA et au règlement des données. C’est un peu comme le serveur principal d’une banque : il s’occupe uniquement de la reconnaissance définitive et de la sécurité des actifs au niveau le plus fondamental, sans s’éparpiller, afin de garantir une très forte disponibilité des données et une détermination certaine du règlement.
Le moteur natif “ultra-rapide” (DuskVM / Piecrust) : une machine virtuelle native exécutée avec Rust et WASM, conçue pour traiter les preuves à divulgation nulle et les calculs de confidentialité très difficiles. C’est comme ajouter une carte graphique professionnelle au système : les transactions de confidentialité ZK sont alors calculées à une vitesse qui décoiffe.
“L’interface universelle d’Ethereum pour transporter les briques” (DuskEVM) : une couche de compatibilité spécialement pensée pour les développeurs de l’écosystème Ethereum. Les développeurs n’ont pas besoin d’apprendre un nouveau langage : avec leur environnement habituel (Hardhat, Metamask), ils peuvent directement “faire un copier-coller” des applications construites sur ETH, puis payer le Gas en utilisant $DUSK .
Cette séparation entre la couche de règlement et la couche d’exécution donne vraiment l’impression d’avoir branché “sans douleur” l’énorme écosystème d’Ethereum sur une base ultra-performante dotée d’un accélérateur de confidentialité ZKP.
Mais, pour être honnête : l’idée d’une architecture en couches est excellente, toutefois les interactions entre plusieurs couches mettent surtout à l’épreuve la sécurité. Quand des actifs sont transférés d’une couche à l’autre, entre DuskEVM et la couche native de confidentialité, la complexité logique double : le contrat contient-il des failles ? Le délai de règlement inter-couche que les utilisateurs vont subir est-il acceptable ? Ce sont là de véritables examens à passer avant que l’écosystème du réseau principal puisse vraiment prospérer.
Échangez dans la section commentaires !
