Une fois que DuskEVM a existé, le réseau Dusk aurait pu proposer un argument plus simple : un seul environnement d’exécution, Solidity pour tout le monde, et c’est réglé. À la place, la documentation indique clairement que le développement natif de Dusk, c’est-à-dire des contrats Rust compilés en WASM et exécutés par DuskVM, reste la voie recommandée chaque fois qu’une application a besoin d’un contrôle au niveau du protocole, de modèles de transactions personnalisés ou de capacités de preuve à divulgation nulle (zero-knowledge) qui se situent au plus près de la couche de base. Je trouve cette décision intéressante à défendre, car maintenir deux voies d’exécution coûte plus cher à concevoir et à expliquer que n’en maintenir qu’une.
La logique semble être que DuskEVM et DuskVM sont optimisés pour des clients différents plutôt que pour se concurrencer auprès du même public. Une équipe qui porte un protocole DeFi Ethereum existant veut des outils familiers, des audits déjà réalisés et des portefeuilles qui fonctionnent déjà : c’est à cela que sert DuskEVM. Une équipe qui construit une logique de règlement de titres avec des transferts plafonnés, une distribution de dividendes ou des règles de conformité intégrées directement dans un contrat se rapproche davantage de ce que Zedger et les contrats natifs de DuskVM étaient conçus pour dès le départ, car ce modèle hybride de transactions a été pensé pour ce type précis de tenue de registres de jetons de sécurité, plutôt que d’avoir été adapté a posteriori à partir d’un schéma générique.
Je ne suis pas entièrement convaincu que cette approche à double voie évite de fragmenter la base de développeurs de Dusk Network et l’effort documentaire entre deux publics, au lieu de les concentrer derrière une seule direction. Deux environnements d’exécution signifient deux ensembles d’outils à maintenir, deux modèles mentaux pour les nouveaux contributeurs, et deux réponses à la question simple de l’endroit où une nouvelle application devrait réellement être construite. Je comprends le pari, car se limiter très tôt à une seule voie aurait silencieusement mis de côté le public dont on aurait abandonné la démarche. La question de savoir si Dusk Network restera suffisamment grand pour soutenir correctement les deux voies au cours des prochaines années mérite d’être suivie.
#dusk $DUSK @Dusk
La logique semble être que DuskEVM et DuskVM sont optimisés pour des clients différents plutôt que pour se concurrencer auprès du même public. Une équipe qui porte un protocole DeFi Ethereum existant veut des outils familiers, des audits déjà réalisés et des portefeuilles qui fonctionnent déjà : c’est à cela que sert DuskEVM. Une équipe qui construit une logique de règlement de titres avec des transferts plafonnés, une distribution de dividendes ou des règles de conformité intégrées directement dans un contrat se rapproche davantage de ce que Zedger et les contrats natifs de DuskVM étaient conçus pour dès le départ, car ce modèle hybride de transactions a été pensé pour ce type précis de tenue de registres de jetons de sécurité, plutôt que d’avoir été adapté a posteriori à partir d’un schéma générique.
Je ne suis pas entièrement convaincu que cette approche à double voie évite de fragmenter la base de développeurs de Dusk Network et l’effort documentaire entre deux publics, au lieu de les concentrer derrière une seule direction. Deux environnements d’exécution signifient deux ensembles d’outils à maintenir, deux modèles mentaux pour les nouveaux contributeurs, et deux réponses à la question simple de l’endroit où une nouvelle application devrait réellement être construite. Je comprends le pari, car se limiter très tôt à une seule voie aurait silencieusement mis de côté le public dont on aurait abandonné la démarche. La question de savoir si Dusk Network restera suffisamment grand pour soutenir correctement les deux voies au cours des prochaines années mérite d’être suivie.
#dusk $DUSK @Dusk
