Je creuse plus profondément le @Dusk et ses deux voies d’exécution : DuskEVM pour Solidity et DuskVM pour les contrats natifs en Rust/WASM.

La conception technique a du sens. Mais ce qui m’a vraiment fait marquer une pause, c’est le comportement de développement qu’elle pourrait engendrer.

J’ai cessé de ne regarder que la documentation et commencé à réfléchir à ce que les développeurs choisiront réellement.

DuskEVM est familier, avec les outils EVM que les développeurs connaissent déjà. DuskVM approfondit l’exécution via Forge, en gérant le code répétitif, les exportations WASM et les data drivers, tandis que l’état du contrat réside directement dans la mémoire linéaire et est sérialisé avec rkyv.

Attendez - cela crée une contradiction intéressante.

DuskVM peut offrir un environnement d’exécution plus natif et potentiellement moins coûteux, mais DuskEVM pourrait encore rester le choix évident simplement parce qu’il est plus facile à construire.

C’est ce décalage que je trouve plus intéressant que l’architecture Rust/WASM elle-même.

Je ne dis pas que DuskVM est défaillant ici. Le modèle d’exécution natif fait exactement ce pour quoi il a été conçu.

La vraie question est de savoir si l’avantage technique est suffisamment fort pour modifier le comportement des développeurs.

Ça me rappelle le choix entre un outil familier qui fait le travail et un outil plus spécialisé qui vous donne un contrôle plus poussé - mais qui vous demande d’apprendre d’abord un nouveau workflow.

Si les développeurs continuent de choisir DuskEVM, est-ce que DuskVM devient un environnement d’exécution techniquement puissant mais de niche ?

Ou le déploiement natif pourrait-il finir par devenir un signal significatif de l’utilité réseau plus profonde du #Dusk ?
$DUSK $KII $AKE
#RedditToJoinSP500 #US30YBondAuctionYieldHighestSince2001 #GlobalStocksNearRecordHighs #ProCapFilesBitcoinTreasuryDiscountETF