Ce qui m’a accroché, ce n’est pas le fait que Dusk prenne en charge deux environnements d’exécution. C’est la raison pour laquelle ce choix pourrait devenir délicat plus tard.

Ainsi, DuskVM offre aux développeurs natifs Rust/WASM leur propre voie, tandis que DuskEVM maintient les équipes Solidity dans des outils familiers. C’est du concret. Les développeurs n’ont pas besoin de tout jeter ce qu’ils savent déjà pour construire avec Dusk.

La complication apparaît une fois que l’adoption commence à fonctionner.
Si les deux environnements attirent de vraies applications, Dusk pourrait se retrouver avec deux cultures de développeurs qui grandissent côte à côte. Des outils différents, des habitudes de contrats différentes, des attentes différentes quant à la manière dont les applications interagissent.

Cela ne casse pas forcément quoi que ce soit. Mais cela peut rendre l’écosystème plus difficile à maintenir cohérent.

Ce que je trouve intéressant, c’est que Dusk pourrait réduire un type de friction tout en en créant discrètement un autre. Mettre les développeurs dans la boucle devient plus simple. Faire en sorte que les deux univers semblent former un seul réseau pourrait devenir plus difficile.
Je surveillerais ce qui se passe quand les utilisateurs cesseront de se soucier de l’environnement dans lequel une application vit. C’est probablement à ce moment-là que ce choix de conception sera réellement mis à l’épreuve.
@Dusk_Foundation $DUSK #dusk