I assumed "DuskEVM supports Solidity" meant developers could show up with existing Ethereum tooling and be done. Dusk's own quickstart docs quietly add a step most people skip past: verifying the source.
Deploying is the easy part. DuskEVM uses Blockscout as its explorer, and getting a contract verified there, "Verify & Publish", means the relevant build settings, compiler version, optimizer configuration, source files, constructor arguments, have to reproduce the bytecode that's actually deployed.
That's a different bar than EVM compatibility. Deployment proves the code can run. Verification lets someone else check what's actually running. A contract can be deployed and functioning while still being unverified, leaving anyone else unable to independently check whether the published source actually matches what's live.
Which means "EVM-compatible" and "developer-ready" aren't quite the same claim. One is about whether your code runs here. The other is about whether an auditor, an institution, or a user can actually confirm what's running matches what's claimed.
"A chain can run your Solidity contract and still leave you unable to prove what that contract actually is."
What I'd want to see next: whether a contract deployed through the standard Solidity/Hardhat path can be reliably verified against its deployed bytecode, rather than merely deployed successfully.
#dusk $DUSK @Dusk
Deploying is the easy part. DuskEVM uses Blockscout as its explorer, and getting a contract verified there, "Verify & Publish", means the relevant build settings, compiler version, optimizer configuration, source files, constructor arguments, have to reproduce the bytecode that's actually deployed.
That's a different bar than EVM compatibility. Deployment proves the code can run. Verification lets someone else check what's actually running. A contract can be deployed and functioning while still being unverified, leaving anyone else unable to independently check whether the published source actually matches what's live.
Which means "EVM-compatible" and "developer-ready" aren't quite the same claim. One is about whether your code runs here. The other is about whether an auditor, an institution, or a user can actually confirm what's running matches what's claimed.
"A chain can run your Solidity contract and still leave you unable to prove what that contract actually is."
What I'd want to see next: whether a contract deployed through the standard Solidity/Hardhat path can be reliably verified against its deployed bytecode, rather than merely deployed successfully.
#dusk $DUSK @Dusk
