Asumí que «DuskEVM admite Solidity» significaba que los desarrolladores podían presentarse con la infraestructura existente de Ethereum y ya estaría. Los propios documentos de inicio rápido de Dusk agregan en silencio un paso que la mayoría de la gente se salta: verificar el origen.
Implementar es la parte fácil. DuskEVM usa Blockscout como su explorador, y hacer que un contrato se verifique allí, «Verify & Publish», significa que los ajustes de compilación relevantes, la versión del compilador, la configuración del optimizador, los archivos de origen, los argumentos del constructor, deben poder reproducir el bytecode que realmente se implementó.
Eso es una exigencia diferente a la compatibilidad con EVM. La implementación prueba que el código puede ejecutarse. La verificación permite que otra persona compruebe qué es lo que realmente se está ejecutando. Un contrato puede implementarse y funcionar mientras sigue sin estar verificado, dejando a cualquiera más sin la posibilidad de comprobar de forma independiente si el código fuente publicado coincide realmente con lo que está en vivo.
Lo que significa que «compatible con EVM» y «listo para desarrolladores» no son exactamente la misma afirmación. Una trata sobre si tu código se ejecuta aquí. La otra trata sobre si un auditor, una institución o un usuario pueden confirmar realmente que lo que se está ejecutando coincide con lo que se ha afirmado.
«Una cadena puede ejecutar tu contrato de Solidity y aun así dejarte incapaz de demostrar qué es realmente ese contrato.»
Lo que me gustaría ver a continuación: si un contrato implementado a través de la ruta estándar de Solidity/Hardhat se puede verificar de forma fiable con respecto a su bytecode implementado, en lugar de simplemente haberse implementado con éxito.
#dusk $DUSK @Dusk
Implementar es la parte fácil. DuskEVM usa Blockscout como su explorador, y hacer que un contrato se verifique allí, «Verify & Publish», significa que los ajustes de compilación relevantes, la versión del compilador, la configuración del optimizador, los archivos de origen, los argumentos del constructor, deben poder reproducir el bytecode que realmente se implementó.
Eso es una exigencia diferente a la compatibilidad con EVM. La implementación prueba que el código puede ejecutarse. La verificación permite que otra persona compruebe qué es lo que realmente se está ejecutando. Un contrato puede implementarse y funcionar mientras sigue sin estar verificado, dejando a cualquiera más sin la posibilidad de comprobar de forma independiente si el código fuente publicado coincide realmente con lo que está en vivo.
Lo que significa que «compatible con EVM» y «listo para desarrolladores» no son exactamente la misma afirmación. Una trata sobre si tu código se ejecuta aquí. La otra trata sobre si un auditor, una institución o un usuario pueden confirmar realmente que lo que se está ejecutando coincide con lo que se ha afirmado.
«Una cadena puede ejecutar tu contrato de Solidity y aun así dejarte incapaz de demostrar qué es realmente ese contrato.»
Lo que me gustaría ver a continuación: si un contrato implementado a través de la ruta estándar de Solidity/Hardhat se puede verificar de forma fiable con respecto a su bytecode implementado, en lugar de simplemente haberse implementado con éxito.
#dusk $DUSK @Dusk
