#dusk $DUSK Dansk a choisi WASM comme environnement d’exécution des smart contracts, plutôt que d’utiliser EVM comme la plupart des chaînes. Je pensais auparavant que ce n’était qu’une question de préférence technique, jusqu’à ce que je mette ensemble la documentation d’architecture de la Rusk VM et la position de Dusk en matière de conformité : j’ai alors réalisé que ce choix avait une logique bien plus profonde que ce qu’il semblait être en surface.#dusk $SPCXB
WASM est ce bac à sable qui fait tourner WebAssembly dans le navigateur. Il permet de compiler des langages comme le C, le C++ et le Rust en bytecode, avec une efficacité d’exécution qui est d’un ordre de grandeur supérieure à celle du bytecode interprété d’EVM. Mais surtout, l’enjeu n’est pas la performance : c’est l’écosystème. Le langage principal d’EVM, Solidity, n’est utilisé que dans le milieu des blockchains, tandis que Rust et C++ sont des outils de productivité pour toute l’industrie fintech.@Dusk
Qu’est-ce que cela implique ? Une institution financière qui a déjà écrit ses systèmes de trading internes en Rust, et qui veut déployer des contrats d’actifs conformes sur Dusk, n’a pas besoin de réapprendre un nouveau langage ni une nouvelle chaîne d’outillage. Le seuil d’entrée passe de « recruter des ingénieurs blockchain » à « faire écrire un module supplémentaire à l’équipe existante ».$SNDKB
Mais ce choix a aussi un coût. La compatibilité EVM est presque un standard actuel de Layer 1. Renoncer à EVM, c’est renoncer au vaste vivier de développeurs Solidity et à l’écosystème d’outils déjà prêt. Le pari de Dusk est le suivant : les développeurs des institutions développant des actifs réglementés ne viennent pas, à la base, de la communauté Solidity.
Donc, la stratégie WASM de Dusk pourra-t-elle fonctionner ? Ce n’est pas en regardant les indicateurs techniques qu’on le saura, mais en se demandant si, concrètement, les développeurs de la finance traditionnelle viendront réellement écrire des contrats on-chain.#dusk DUSK @Dusk