#dusk $DUSK @Dusk
J’ai changé de téléphone il y a un moment, et la partie la plus étrange n’était pas d’apprendre les nouvelles fonctionnalités. C’était de découvrir quelles vieilles habitudes fonctionnaient encore. Les mêmes gestes, les mêmes applis, tout semblait familier… jusqu’au moment où j’ai tendu la main vers quelque chose et que ce n’était pas à l’endroit où mon cerveau s’attendait à le trouver.
C’est un peu comme ça que je vois DuskEVM.
J’ai vu “EVM-compatible” tellement de fois que j’ignore presque maintenant cette expression. Ce qui m’intéresse vraiment avec @dusk, c’est quelque chose de plus simple : est-ce qu’un développeur peut s’asseoir et travailler ? Solidity, Hardhat, Foundry, ethers, viem, le wallet qu’ils connaissent déjà. Pas une semaine passée à se battre contre un environnement totalement nouveau avant que quelque chose d’utile soit construit.
Mais je continue à réfléchir à ce qui se passe en dessous de cette surface familière.
$DUSK est utilisé pour l’exécution ; il peut passer entre Dusk L1 et DuskEVM via le pont, et l’activité finit par revenir s’ancrer via DuskDS. Ainsi, vous travaillez au sein de quelque chose qui ressemble à ce que vous connaissez, tout en dépendant d’une infrastructure qui n’est vraiment pas la configuration EVM habituelle.
Et c’est là que je doute encore au sujet de @dusk. La familiarité est une excellente chose quand tout fonctionne. Le vrai test commence quand quelque chose ne marche pas. Un problème de pont, un délai de règlement, un problème d’intégration étrange… soudain, le développeur devra peut-être comprendre toute la mécanique spécifique à Dusk dont il ne pensait à peine auparavant.
Peut-être que c’est la partie que les gens passent sous silence.
Faire essayer aux développeurs un autre environnement EVM n’est plus le plus difficile. Les faire oublier qu’ils utilisent une architecture différente jusqu’au moment où cette différence devient réellement importante… ça, ça paraît beaucoup plus dur.
$DUSK
J’ai changé de téléphone il y a un moment, et la partie la plus étrange n’était pas d’apprendre les nouvelles fonctionnalités. C’était de découvrir quelles vieilles habitudes fonctionnaient encore. Les mêmes gestes, les mêmes applis, tout semblait familier… jusqu’au moment où j’ai tendu la main vers quelque chose et que ce n’était pas à l’endroit où mon cerveau s’attendait à le trouver.
C’est un peu comme ça que je vois DuskEVM.
J’ai vu “EVM-compatible” tellement de fois que j’ignore presque maintenant cette expression. Ce qui m’intéresse vraiment avec @dusk, c’est quelque chose de plus simple : est-ce qu’un développeur peut s’asseoir et travailler ? Solidity, Hardhat, Foundry, ethers, viem, le wallet qu’ils connaissent déjà. Pas une semaine passée à se battre contre un environnement totalement nouveau avant que quelque chose d’utile soit construit.
Mais je continue à réfléchir à ce qui se passe en dessous de cette surface familière.
$DUSK est utilisé pour l’exécution ; il peut passer entre Dusk L1 et DuskEVM via le pont, et l’activité finit par revenir s’ancrer via DuskDS. Ainsi, vous travaillez au sein de quelque chose qui ressemble à ce que vous connaissez, tout en dépendant d’une infrastructure qui n’est vraiment pas la configuration EVM habituelle.
Et c’est là que je doute encore au sujet de @dusk. La familiarité est une excellente chose quand tout fonctionne. Le vrai test commence quand quelque chose ne marche pas. Un problème de pont, un délai de règlement, un problème d’intégration étrange… soudain, le développeur devra peut-être comprendre toute la mécanique spécifique à Dusk dont il ne pensait à peine auparavant.
Peut-être que c’est la partie que les gens passent sous silence.
Faire essayer aux développeurs un autre environnement EVM n’est plus le plus difficile. Les faire oublier qu’ils utilisent une architecture différente jusqu’au moment où cette différence devient réellement importante… ça, ça paraît beaucoup plus dur.
$DUSK