J’ai relu hier le livre blanc @Dusk , et quand je suis arrivé à la page sur « l’architecture à double VM », je me suis bloqué.
Commençons par l’architecture. Piecrust est une VM à connaissance nulle native, basée sur WASM, avec un règlement ramené à 2–3 secondes. DuskEVM est compatible avec Solidity : Hardhat et MetaMask s’y branchent directement et ça tourne, la confidentialité étant complétée au niveau ZK par Hedger. L’idée de la double voie est intéressante : l’une s’occupe des contrats de confidentialité, l’autre de la compatibilité, chacune son rôle.
Mais plus j’avance, plus je sens que quelque chose ne colle pas. Piecrust a développé sa propre VM ; l’audit AEGIS de ce mois de mars a révélé 39 problèmes, dont 7 critiques. Deux vulnérabilités clés sont bloquées au niveau de la couche sandbox. Même en faisant tourner le même code sur un nœud honnête, les résultats peuvent différer ; un contrat malveillant peut pousser l’exécution dans un état où la garantie de propriété n’est plus valable. Si la sandbox est percée, tous les contrats confidentiels de la couche supérieure sont foutus. DuskEVM, lui, ne prend en charge que les transactions publiques ; la confidentialité dépend d’un module supplémentaire pour faire le travail. Au final, deux VM s’attaquent chacune de leur côté : la taille du code et la surface d’attaque sont doublées.
Regardons ensuite la coopération. NPEX, Chainlink, Cordial, Quantoz, 21X : sur le site, il est indiqué €300M+ en émission confirmée, 50K+ d’accès investisseurs, 210M+ DUSK mis en jeu. Les ressources sont vraiment plus solides que des projets qui ne font que raconter des histoires RWA. Mais même leur propre équipe admet que la tokenisation peut réduire les frictions : elle ne fabrique pas à elle seule des acheteurs, des vendeurs et de la profondeur de marché. Le Dusk Trade est encore en Building/Waitlist, et DuskEVM ainsi que Hedger sont aussi en Testnet. La liste de partenaires montre qu’ils sont prêts à collaborer ; en revanche, pour que ça tourne vraiment, il faudra juger sur des indicateurs concrets : volume d’actifs on-chain, nombre de traders, profondeur sur le marché secondaire, etc.
Enfin, l’articulation entre conformité et confidentialité. Zedger, lors de l’émission, intègre dans le protocole la whitelist, le principe « une identité, un compte », et l’approbation explicite du destinataire : le transfert est découpé en deux étapes, avec annulation automatique en cas de délai. Phoenix utilise une architecture UTXO : les fonds sont stockés sous forme de notes chiffrées ; lors de la transaction, le ZK vérifie simultanément cinq éléments. Les Pedersen Commitments cachent complètement montants et adresses. DuskDS confirme en trois étapes : dès que le bloc est produit, c’est définitif. Les règles portent sur ce qui peut exister, Phoenix gère quels aspects n’ont pas besoin d’être publics, et DuskDS gère quel état fait foi. Ces trois maillons complètent le même point de rupture : de l’émission à la compensation des titres, en évitant autant que possible de devoir revenir hors-chaîne pour recoordiner.
La liste de collaboration est déjà assez « institutionnelle » côté finance. Pour la prochaine étape, je veux surtout voir de vraies données de migration et d’exécution, pas rester uniquement sur des slides. #dusk $DUSK
Commençons par l’architecture. Piecrust est une VM à connaissance nulle native, basée sur WASM, avec un règlement ramené à 2–3 secondes. DuskEVM est compatible avec Solidity : Hardhat et MetaMask s’y branchent directement et ça tourne, la confidentialité étant complétée au niveau ZK par Hedger. L’idée de la double voie est intéressante : l’une s’occupe des contrats de confidentialité, l’autre de la compatibilité, chacune son rôle.
Mais plus j’avance, plus je sens que quelque chose ne colle pas. Piecrust a développé sa propre VM ; l’audit AEGIS de ce mois de mars a révélé 39 problèmes, dont 7 critiques. Deux vulnérabilités clés sont bloquées au niveau de la couche sandbox. Même en faisant tourner le même code sur un nœud honnête, les résultats peuvent différer ; un contrat malveillant peut pousser l’exécution dans un état où la garantie de propriété n’est plus valable. Si la sandbox est percée, tous les contrats confidentiels de la couche supérieure sont foutus. DuskEVM, lui, ne prend en charge que les transactions publiques ; la confidentialité dépend d’un module supplémentaire pour faire le travail. Au final, deux VM s’attaquent chacune de leur côté : la taille du code et la surface d’attaque sont doublées.
Regardons ensuite la coopération. NPEX, Chainlink, Cordial, Quantoz, 21X : sur le site, il est indiqué €300M+ en émission confirmée, 50K+ d’accès investisseurs, 210M+ DUSK mis en jeu. Les ressources sont vraiment plus solides que des projets qui ne font que raconter des histoires RWA. Mais même leur propre équipe admet que la tokenisation peut réduire les frictions : elle ne fabrique pas à elle seule des acheteurs, des vendeurs et de la profondeur de marché. Le Dusk Trade est encore en Building/Waitlist, et DuskEVM ainsi que Hedger sont aussi en Testnet. La liste de partenaires montre qu’ils sont prêts à collaborer ; en revanche, pour que ça tourne vraiment, il faudra juger sur des indicateurs concrets : volume d’actifs on-chain, nombre de traders, profondeur sur le marché secondaire, etc.
Enfin, l’articulation entre conformité et confidentialité. Zedger, lors de l’émission, intègre dans le protocole la whitelist, le principe « une identité, un compte », et l’approbation explicite du destinataire : le transfert est découpé en deux étapes, avec annulation automatique en cas de délai. Phoenix utilise une architecture UTXO : les fonds sont stockés sous forme de notes chiffrées ; lors de la transaction, le ZK vérifie simultanément cinq éléments. Les Pedersen Commitments cachent complètement montants et adresses. DuskDS confirme en trois étapes : dès que le bloc est produit, c’est définitif. Les règles portent sur ce qui peut exister, Phoenix gère quels aspects n’ont pas besoin d’être publics, et DuskDS gère quel état fait foi. Ces trois maillons complètent le même point de rupture : de l’émission à la compensation des titres, en évitant autant que possible de devoir revenir hors-chaîne pour recoordiner.
La liste de collaboration est déjà assez « institutionnelle » côté finance. Pour la prochaine étape, je veux surtout voir de vraies données de migration et d’exécution, pas rester uniquement sur des slides. #dusk $DUSK