#dusk @Dusk Le crépuscule n’avait en fait même pas besoin de construire DuskEVM. Il dispose déjà de son propre environnement d’exécution natif, DuskVM, qui exécute du Rust compilé en WASM plutôt que du Solidity. Le fait que les deux existent côte à côte, plutôt que d’en choisir un et d’y engager pleinement, vous dit quelque chose sur ce pour quoi chacun est réellement optimisé et sur ce qui a été sacrifié pour parvenir à cela.
DuskVM est la voie native. Rust et WASM vous donnent un contrôle plus bas niveau, des caractéristiques de performance généralement plus serrées, et un accès direct à toutes les primitives propres à Dusk que la couche de base expose, sans passer par une couche de compatibilité pour y parvenir. Le compromis est évident dès que vous le formulez : presque personne dans la crypto ne connaît Rust comme tout le monde connaît Solidity, et bâtir sur DuskVM signifie apprendre un écosystème au lieu d’en amener un existant avec soi.
DuskEVM existe précisément pour supprimer cette barrière. Solidity est, de loin, le langage de contrats intelligents le plus connu dans l’industrie, et la compatibilité avec l’EVM signifie que les outils existants, les habitudes des développeurs, les modèles de contrats audités existants peuvent simplement être transférés en grande partie tels quels. Le coût, c’est que vous exécutez désormais sur une machine virtuelle qui n’a pas été conçue à l’origine pour cette chaîne, avec une couche supplémentaire : la structure du rollup a été couverte en arrière-plan, et elle se trouve entre votre contrat et les garanties de règlement de base qui se trouvent en dessous.
Ainsi, le vrai choix proposé n’est pas « mieux contre pire », mais « quelle contrainte souhaitez-vous ». DuskVM échange la familiarité des développeurs contre une intégration native plus étroite. DuskEVM échange une partie de cette finesse native contre un accès instantané à l’ensemble de l’écosystème Solidity existant et à tout le monde qui y est déjà habitué.
Donc, pour un projet qui construit réellement une infrastructure financière réglementée sur Dusk, ce choix dépend-il surtout du fait que la familiarité développeur l’emporte par défaut, ou y a-t-il des cas d’usage techniques spécifiques où la voie native de DuskVM est clairement le meilleur appel, malgré le fait de demander aux développeurs d’apprendre quelque chose de nouveau.
$DUSK
DuskVM est la voie native. Rust et WASM vous donnent un contrôle plus bas niveau, des caractéristiques de performance généralement plus serrées, et un accès direct à toutes les primitives propres à Dusk que la couche de base expose, sans passer par une couche de compatibilité pour y parvenir. Le compromis est évident dès que vous le formulez : presque personne dans la crypto ne connaît Rust comme tout le monde connaît Solidity, et bâtir sur DuskVM signifie apprendre un écosystème au lieu d’en amener un existant avec soi.
DuskEVM existe précisément pour supprimer cette barrière. Solidity est, de loin, le langage de contrats intelligents le plus connu dans l’industrie, et la compatibilité avec l’EVM signifie que les outils existants, les habitudes des développeurs, les modèles de contrats audités existants peuvent simplement être transférés en grande partie tels quels. Le coût, c’est que vous exécutez désormais sur une machine virtuelle qui n’a pas été conçue à l’origine pour cette chaîne, avec une couche supplémentaire : la structure du rollup a été couverte en arrière-plan, et elle se trouve entre votre contrat et les garanties de règlement de base qui se trouvent en dessous.
Ainsi, le vrai choix proposé n’est pas « mieux contre pire », mais « quelle contrainte souhaitez-vous ». DuskVM échange la familiarité des développeurs contre une intégration native plus étroite. DuskEVM échange une partie de cette finesse native contre un accès instantané à l’ensemble de l’écosystème Solidity existant et à tout le monde qui y est déjà habitué.
Donc, pour un projet qui construit réellement une infrastructure financière réglementée sur Dusk, ce choix dépend-il surtout du fait que la familiarité développeur l’emporte par défaut, ou y a-t-il des cas d’usage techniques spécifiques où la voie native de DuskVM est clairement le meilleur appel, malgré le fait de demander aux développeurs d’apprendre quelque chose de nouveau.
$DUSK