#dusk $DUSK
Auparavant, quand je voyais « EVM compatible », je n’y pensais pas plus que ça.
Si Solidity peut s’écrire, si Foundry peut s’exécuter, et si le portefeuille peut aussi se connecter, alors ce n’est pas juste repartir sur les choses d’Ethereum ?
Récemment, en lisant la référence de DuskEVM de @Dusk , j’ai compris qu’en conditions réelles de déploiement, on ne peut pas se permettre de faire ça à la légère.
Le plus simple : DuskEVM possède désormais son propre séquenceur.
Quand on obtient le receipt de la transaction, cela signifie qu’elle a bien été empaquetée,
mais ce n’est pas la même notion que le settlement qui suit.
Il y a aussi prevrandao.
Sur Ethereum, certains développeurs s’en servent parfois au passage pour des logiques liées à des nombres aléatoires, mais la documentation officielle de Dusk prévient spécifiquement : dans DuskEVM, ne le considérez pas comme une source d’aléatoire sûre et impartiale.
Ce genre de chose, si on ne consulte pas la Reference au quotidien, on risque facilement de l’écrire directement comme on le faisait avant, par habitude.
Du coup, aujourd’hui, ma compréhension de la compatibilité EVM est plus réaliste qu’avant :
Oui, ça permet d’économiser beaucoup de coûts de migration, pas de doute.
Mais « interface familière » et « environnement sous-jacent identique » ne sont pas la même chose.
Pour un vrai déploiement, il faudra quand même relire et reconsidérer le séquenceur, la finalité et l’état inter-couches.
Au fond, j’apprécie même que l’officiel écrive clairement ces limites.
Le pire n’est pas qu’il y ait des différences.
C’est quand tu penses qu’il n’y en a pas.
Auparavant, quand je voyais « EVM compatible », je n’y pensais pas plus que ça.
Si Solidity peut s’écrire, si Foundry peut s’exécuter, et si le portefeuille peut aussi se connecter, alors ce n’est pas juste repartir sur les choses d’Ethereum ?
Récemment, en lisant la référence de DuskEVM de @Dusk , j’ai compris qu’en conditions réelles de déploiement, on ne peut pas se permettre de faire ça à la légère.
Le plus simple : DuskEVM possède désormais son propre séquenceur.
Quand on obtient le receipt de la transaction, cela signifie qu’elle a bien été empaquetée,
mais ce n’est pas la même notion que le settlement qui suit.
Il y a aussi prevrandao.
Sur Ethereum, certains développeurs s’en servent parfois au passage pour des logiques liées à des nombres aléatoires, mais la documentation officielle de Dusk prévient spécifiquement : dans DuskEVM, ne le considérez pas comme une source d’aléatoire sûre et impartiale.
Ce genre de chose, si on ne consulte pas la Reference au quotidien, on risque facilement de l’écrire directement comme on le faisait avant, par habitude.
Du coup, aujourd’hui, ma compréhension de la compatibilité EVM est plus réaliste qu’avant :
Oui, ça permet d’économiser beaucoup de coûts de migration, pas de doute.
Mais « interface familière » et « environnement sous-jacent identique » ne sont pas la même chose.
Pour un vrai déploiement, il faudra quand même relire et reconsidérer le séquenceur, la finalité et l’état inter-couches.
Au fond, j’apprécie même que l’officiel écrive clairement ces limites.
Le pire n’est pas qu’il y ait des différences.
C’est quand tu penses qu’il n’y en a pas.