Contract Verification
Closed this issue · 2 comments
snow-farmer commented
Background
We reach an error verifying contracts on Avalanche Explorer.
Steps to reproduce
This example uses DexStrategyV4.sol
for 0xA544b965C2a05b97C44f3126cec916332aFb3175
.
- Compile and flatten contract
npx hardhat flatten contracts/strategies/DexStrategyV4.sol > DexStrategyV4.sol
- Remove all duplicate license and pragma lines from flattened file.
- Visit contract verification page
- Fill out details using the solcInputs from deployments file.
Contract name: DexStrategyV4
Compiler: v0.7.3
Optimization: Yes
Runs: 200
Expected result
Contract is verified here
Actual result
Error message:
There was an error compiling your contract: The "chainid" instruction is only available for Istanbul-compatible VMs (you are currently compiling for "byzantium").
snow-farmer commented
Update:
- One contract was successfully verified - note: optimization is disabled
- Other contracts have slightly mismatched bytecode - note: optimization is enabled
- We no longer receive the error message for "Chain ID" by switching EVM Version to default. However, we still receive error
Connection lost
ASlowCheetah commented
In regards to the issue, we did reverse engineer the issue and there was many problems at play, I spent some time together with two other community members, and Avalabs troubleshooting the issue, here are key takeaways:
- Blockscout sometimes parsers comments, so we should avoid commenting codelines, instead, stick to use only verbal comments.
- ABIEncoderV2 is experimental and should be avoided whenever possible as it can lead to issues with flatten files, as the experimental encoder definition leaks to other classes
- Always deploy to FUJI(testnet) and verify the contract there first, it's a good indicative that if it doesn't verify, we should fix this issue before deploying on mainnet.
- Deploying from flatten file can be a good idea to avoid bytecode mismatching from separated files to the flatten ones, this makes the process easier
- Supplying the ABI constructor to the blockscout sometimes is the answer, to identify the ABI constructor you can look into the transaction that deployed the contract, in the Trace tab, you'll see a json, you're looking into the end of the field 'init'. 43 + compiler version(00073) + 0033 is the bytecode that you're looking at the end, everything after this bytecode sequence is the constructor.