J’ai supposé que « DuskEVM prend en charge Solidity » signifiait que les développeurs pouvaient arriver avec leurs outils Ethereum existants et en rester là. La propre documentation de démarrage rapide de Dusk ajoute discrètement une étape que la plupart des gens sautent : vérifier le code source.
Déployer est la partie facile. DuskEVM utilise Blockscout comme explorateur, et obtenir la vérification d’un contrat là-bas, « Verify & Publish », signifie que les paramètres de build pertinents, la version du compilateur, la configuration de l’optimiseur, les fichiers source et les arguments du constructeur doivent reproduire l’octetcode réellement déployé.
C’est une exigence différente de la simple compatibilité EVM. Le déploiement prouve que le code peut s’exécuter. La vérification permet à quelqu’un d’autre de contrôler ce qui s’exécute réellement. Un contrat peut être déployé et fonctionner tout en restant non vérifié, laissant les autres incapables de vérifier indépendamment si le code source publié correspond réellement à ce qui est en ligne.
Ce qui signifie que « compatible EVM » et « prêt pour les développeurs » ne sont pas tout à fait la même promesse. L’une concerne le fait de savoir si votre code s’exécute ici. L’autre concerne le fait de savoir si un auditeur, une institution ou un utilisateur peut réellement confirmer que ce qui s’exécute correspond à ce qui est déclaré.
« Une chaîne peut exécuter votre contrat Solidity et vous laisser malgré tout incapable de prouver ce qu’est réellement ce contrat. »
Ce que j’aimerais voir ensuite : si un contrat déployé via le parcours standard Solidity/Hardhat peut être vérifié de manière fiable par rapport à son octetcode déployé, plutôt que simplement déployé avec succès.
#dusk $DUSK @Dusk
Déployer est la partie facile. DuskEVM utilise Blockscout comme explorateur, et obtenir la vérification d’un contrat là-bas, « Verify & Publish », signifie que les paramètres de build pertinents, la version du compilateur, la configuration de l’optimiseur, les fichiers source et les arguments du constructeur doivent reproduire l’octetcode réellement déployé.
C’est une exigence différente de la simple compatibilité EVM. Le déploiement prouve que le code peut s’exécuter. La vérification permet à quelqu’un d’autre de contrôler ce qui s’exécute réellement. Un contrat peut être déployé et fonctionner tout en restant non vérifié, laissant les autres incapables de vérifier indépendamment si le code source publié correspond réellement à ce qui est en ligne.
Ce qui signifie que « compatible EVM » et « prêt pour les développeurs » ne sont pas tout à fait la même promesse. L’une concerne le fait de savoir si votre code s’exécute ici. L’autre concerne le fait de savoir si un auditeur, une institution ou un utilisateur peut réellement confirmer que ce qui s’exécute correspond à ce qui est déclaré.
« Une chaîne peut exécuter votre contrat Solidity et vous laisser malgré tout incapable de prouver ce qu’est réellement ce contrat. »
Ce que j’aimerais voir ensuite : si un contrat déployé via le parcours standard Solidity/Hardhat peut être vérifié de manière fiable par rapport à son octetcode déployé, plutôt que simplement déployé avec succès.
#dusk $DUSK @Dusk
