Pour évaluer l’avancement d’un projet, je ne regarde pas ce qu’il dit de son mainnet, mais son dépôt GitHub. Dans le code de @Dusk , il y a un signal très honnête : dans une issue du dépôt de documentation, il est indiqué qu’après l’introduction d’une architecture modulaire, il est recommandé aux développeurs d’utiliser DuskEVM, alors que l’essentiel de la documentation développeur existante parle encore de DuskVM. Autrement dit, l’orientation produit a déjà changé, mais la documentation et le code n’ont pas encore totalement suivi.

Les dépôts GitHub publics officiels de Dusk confirment aussi ce décalage. dusk-network/rusk est une implémentation de référence, où l’on trouve des modules essentiels comme dusk-vm, dusk-core et la preuve à divulgation nulle de connaissance PLONK ; mais le dépôt autonome rusk-vm, plus proche des capacités natives, suscite peu d’intérêt, et ses étoiles comme ses signaux de mise à jour paraissent bien plus discrets que le récit principal. À l’inverse, la documentation officielle place déjà le quickstart de DuskEVM, Solidity et la chaîne d’outils Ethereum dans l’endroit le plus accessible. Pour un projet qui se présente comme natif à la confidentialité et aux contrats intelligents WASM, orienter concrètement les nouveaux développeurs vers la voie EVM est en soi une prise de position silencieuse. #dusk

Je ne considère pas encore le nombre d’étoiles comme une conclusion, car l’activité du code doit aussi se juger à la fréquence des commits, au nombre de contributeurs et au taux de fermeture des issues. Mais en assemblant ces fragments, la direction est déjà claire : $DUSK centre sa transition sur la migration, et la partie VM native ressemble davantage à une capacité conservée sur le long terme qu’à la porte d’entrée de développement actuellement mise en avant. L’annonce officielle de « mainnet coming » doit être soutenue par un rythme correspondant de livraison du code, et non seulement par un changement de répertoire dans la documentation technique.

La conclusion est donc la suivante : à ce stade, les signaux de code public ne suffisent pas à appuyer l’idée de « deux environnements d’exécution également matures ». DuskEVM est manifestement la direction la plus active et la plus promue, tandis que DuskVM ressemble davantage à une réserve encore peu travaillée. Le véritable avancement se verra dans la capacité à fermer régulièrement les prochaines issues de jalons, et non dans l’ajout de nouvelles pages de concept sur la page d’accueil.