#dusk $DUSK
En creusant enfin les fondations et la conception de bas niveau de Dusk, j’ai compris la véritable raison pour laquelle il persiste à choisir le WASM et à renoncer à l’EVM.
Honnêtement, avant, moi aussi — comme la plupart des gens — je pensais que c’était simplement une question de “propreté” technique de l’équipe, qui refusait de suivre la tendance et de se lancer dans la course à l’EVM.
Mais plus j’étudie les informations, plus je me rends compte que ce n’est pas du tout ça.
En réalité, Dusk n’a jamais eu l’intention de prendre d’assaut les développeurs DeFi des blockchains “grand public”, ni les utilisateurs ordinaires.
L’objectif ultime de $DUSK , c’est de s’adapter et de se connecter aux équipes des finances traditionnelles : courtiers, gestionnaires d’actifs, dépositaires, etc.
Dans notre milieu, on considère comme allant de soi que Solidity est un besoin incontournable, une configuration standard.
Mais les équipes techniques de la finance traditionnelle ont, depuis des années, des habitudes et des outils bien ancrés : Rust, C++.
Tout leur système de gestion des risques, de conformité et de compensation d’actifs est déjà stabilisé depuis des décennies.
Faire table rase, leur demander d’apprendre Solidity et de réécrire toute la logique métier, c’est fondamentalement irréaliste : le coût de migration est tout simplement effrayant.
Du coup, je comprends que le choix du WASM vise à ménager les institutions traditionnelles.
Pas besoin de reconstruire le code, ni de changer de pile technologique : les modules matures de conformité et de gestion des risques existants peuvent être directement compilés pour être mis en chaîne.
C’est précisément là que réside l’avantage implicite le plus important de Dusk pour s’adresser au RWA traditionnel.
Mais bon, soyons honnêtes : de mon point de vue, je suis quand même assez hésitant sur ce choix.
L’écosystème WASM est vraiment trop immature pour le moment : il y a peu d’outils, peu de cas d’audit, et encore moins de modules réellement utilisables.
Pour nous, développeurs natifs de la cryptographie, l’expérience n’a rien à voir avec la maturité de l’EVM.
Ce qui conduit à une situation assez gênante :
pour miser sur l’implémentation future par des institutions, Dusk a directement abandonné la dynamique brûlante actuelle de l’écosystème on-chain.
Si, par la suite, les activités de la finance traditionnelle mettent trop de temps à se concrétiser,
et s’il n’arrive pas à attirer de nouveaux développeurs,
alors l’avantage de différenciation d’aujourd’hui risque fort de se transformer en une île écologique fermée.
Personnellement, je pense que le plan WASM de Dusk, c’est sacrifier la chaleur à court terme pour construire une barrière défensive sur le long terme.
Et vous, dans l’assistance, qu’en pensez-vous ? Ce pari en vaut-il la peine ?
@Dusk
En creusant enfin les fondations et la conception de bas niveau de Dusk, j’ai compris la véritable raison pour laquelle il persiste à choisir le WASM et à renoncer à l’EVM.
Honnêtement, avant, moi aussi — comme la plupart des gens — je pensais que c’était simplement une question de “propreté” technique de l’équipe, qui refusait de suivre la tendance et de se lancer dans la course à l’EVM.
Mais plus j’étudie les informations, plus je me rends compte que ce n’est pas du tout ça.
En réalité, Dusk n’a jamais eu l’intention de prendre d’assaut les développeurs DeFi des blockchains “grand public”, ni les utilisateurs ordinaires.
L’objectif ultime de $DUSK , c’est de s’adapter et de se connecter aux équipes des finances traditionnelles : courtiers, gestionnaires d’actifs, dépositaires, etc.
Dans notre milieu, on considère comme allant de soi que Solidity est un besoin incontournable, une configuration standard.
Mais les équipes techniques de la finance traditionnelle ont, depuis des années, des habitudes et des outils bien ancrés : Rust, C++.
Tout leur système de gestion des risques, de conformité et de compensation d’actifs est déjà stabilisé depuis des décennies.
Faire table rase, leur demander d’apprendre Solidity et de réécrire toute la logique métier, c’est fondamentalement irréaliste : le coût de migration est tout simplement effrayant.
Du coup, je comprends que le choix du WASM vise à ménager les institutions traditionnelles.
Pas besoin de reconstruire le code, ni de changer de pile technologique : les modules matures de conformité et de gestion des risques existants peuvent être directement compilés pour être mis en chaîne.
C’est précisément là que réside l’avantage implicite le plus important de Dusk pour s’adresser au RWA traditionnel.
Mais bon, soyons honnêtes : de mon point de vue, je suis quand même assez hésitant sur ce choix.
L’écosystème WASM est vraiment trop immature pour le moment : il y a peu d’outils, peu de cas d’audit, et encore moins de modules réellement utilisables.
Pour nous, développeurs natifs de la cryptographie, l’expérience n’a rien à voir avec la maturité de l’EVM.
Ce qui conduit à une situation assez gênante :
pour miser sur l’implémentation future par des institutions, Dusk a directement abandonné la dynamique brûlante actuelle de l’écosystème on-chain.
Si, par la suite, les activités de la finance traditionnelle mettent trop de temps à se concrétiser,
et s’il n’arrive pas à attirer de nouveaux développeurs,
alors l’avantage de différenciation d’aujourd’hui risque fort de se transformer en une île écologique fermée.
Personnellement, je pense que le plan WASM de Dusk, c’est sacrifier la chaleur à court terme pour construire une barrière défensive sur le long terme.
Et vous, dans l’assistance, qu’en pensez-vous ? Ce pari en vaut-il la peine ?
@Dusk