Forge verification multiple failures

[amp2122]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (f9fc929 2023-06-29T00:12:09.234859595Z)

What command(s) is the bug in?

forge verify-contract and tied procedures (--verify) in create and script

Operating System

Linux

Describe the bug

Reporting this here because it is possibly a bug and also I don't have the capabilities to use Telegram.

Errors

Forge verification via verify-contract or via the --verify flag using create is failing with the error:

Fail - Unable to verify. Compiled contract deployment bytecode does NOT match the transaction deployment bytecode.

It also fails to verify the same contract when deploying via forge script <...> --broadcast --verify, but with the error:

Error: expected value at line 1 column 1

The errors are thrown for both mainnet and goerli deployments.

Project setup

The foundry.toml file:

[profile.default]
# General
src = 'src'
out = 'out'
libs = [ "lib"]

# Compiler
evm_version = 'shanghai'
auto_detect_solc = true
optimizer-runs = 1_000_000
optimizer = true
via_ir = false

# Tests
verbosity = 2

[rpc_endpoints]
mainnet = "${MAINNET_RPC_URL}"
goerli = "${GOERLI_RPC_URL}"

[etherscan]
mainnet = { key = "${ETHERSCAN_KEY}" }
goerli = { key = "${ETHERSCAN_KEY"}

I've also tried fixing solc_version, removing evm_version, turning the optimizer on and off. As you can note via_ir is stricly set to false. The compiler version being used is 0.6.12+commit.27d51765.

Example create call:

forge create --rpc-url "$GOERLI_RPC_URL" --constructor-args <address> --private-key <key> --etherscan-api-key "$ETHERSCAN_KEY" --verify src/v1/Contract.sol:Contract

Example script call:

forge script --rpc-url $GOERLI_RPC_URL --broadcast --verify -vvvv script/Deploys.sol:ContractDeployer

Example verify-contract call:

forge verify-contract --chain-id 5 --num-of-optimizations 1000000 --watch --constructor-args $(cast abi-encode "constructor(address)" <ADDRESS>) --etherscan-api-key $ETHERSCAN_KEY --compiler-version '0.6.12+commit.27d51765' <DEPLOYED ADDRESS> src/v1/Contract.sol:Contract

Example deployment script:

abstract contract BaseDeployer is Addresses, Script {
    function _createContract() internal virtual;

    function run() external {
        uint256 key = vm.envUint("PRIVATE_KEY");

        vm.startBroadcast(key);

        _createContract();

        vm.stopBroadcast();
    }
}

import { Contract } from "../src/v1/Contract.sol";

contract ContractDeployer is BaseDeployer {
    function _createContract() internal virtual override {
        new Contract(getSomeAddress());
    }
}

Contract.sol dependencies are only imported from files under lib or under src. A clean setup has also been tested (push the repo then clone it to another dir), and it fails too. The deployed contract by itself doesn't do anything weird, at most it inherits from Initializable.sol, and it uses a few other contracts which are imported into the file.

I've also checked the compiler version. It is correct.

Note that this issue also existed under 20230616, but I attempted an upgrade, and it didn't help.

Other

I've also attempted use Etherscan manually, then doing standard json input and then comparing the output of verify-contract when piped to a file. Essentially, for a chunk of say 200 bytes, within that chunk there is going to be maybe a 16 byte difference and these changes are all going to be on average in chunks of 1-2 bytes, but some also with larger difference. Some smaller chunks (1 and 2 bytes chunks) then map to the same byte length but with a different value.

[mattsse]

Essentially, for a chunk of say 200 bytes, within that chunk there is going to be maybe a 16 byte difference and these changes are all going to be on average in chunks of 1-2 bytes, but some also with larger difference. Most notably, the chunks then map to the same byte length but with a different value.

sorry can you elaborate on this again, I don't follow, perhaps you can attach both variants

[amp2122]

I will split out a small example part, hold on for a second.

[amp2122]

Ok so that last statement (edited it now to be correct) wasn't fully right, for example, there are many small parts in bytecode like:

61169356

which then map to

6116ad56

But I've just noticed that there are in fact some larger parts which don't map to the same length like that, so I don't think it matters too much.

[amp2122]

I've actually went ahead and disabled every option in the toml file and it still doesn't verify. Same errors as specified. It has got to be something with the contracts, but those compile and simply compile with different bytecode according to Etherscan.

[amp2122]

So Hardhat manages to deploy and verify some of the contracts which I'm working with, but even it fails verifying one contract. EDIT: Seems the last contract verifies with Hardhat after optimizations are off. EDIT 2: It seems that either the entire contract history or a subset thereof has to have optimizations turned off it to deploy.

[alxlacayo]

I just ran into this exact error:
Error: expected value at line 1 column 1
and it was due to a bad etherscan api key.

[amp2122]

I just ran into this exact error: Error: expected value at line 1 column 1 and it was due to a bad etherscan api key.

Right, for me the problem is though that I've used the same API key to verify properly and also it gives the bytecode difference error when verify-contract is used.

[kazazor]

I can confirm I'm getting the same issue when trying to use --verify. Doesn't seem to work.

Any news on that?

[QYuQianchen]

Hi team! Is there any update on this? I encountered similar issue as described in #5656 and unfortunately appending \? doesn't help. I'd appreciate some update!