Version build discrepancy vs. canonical list (v0.5.11 and others)

[brianmcmichael]

Description

The solc v0.5.11 that has been distributed widely does not appear to be the same version that is defined on the solc-bin list.txt

The snap distribution and the docker image both appear to be running 0.5.11+commit.22be8592, while the canonical version of 0.5.11 appears to be 0.5.11+commit.c082d0b4

The ReadTheDocs versions page also seems to be based on 22be8592

This discrepancy can become a problem because programmatic etherscan contract verification via the api relies on a compiler string matching one of the entries on the solc-bin/bin/list.txt source. A contract compiled on the command line using one of the distributed binaries version output would not match a compatible version and fail verification.

I also noticed a similar discrepancy with v0.5.9 and a few earlier versions. v0.5.12 (7709ece9) and v0.5.10 (5a6ea5b1) match as expected.

Environment

• Compiler version: v0.5.11, v0.5.9, others
• Target EVM version (as per compiler settings): N/A
• Framework/IDE (e.g. Truffle or Remix): N/A
• EVM execution environment / backend / blockchain client: N/A
• Operating system: Linux/OSX

Steps to Reproduce

$ snap run solc --version
solc, the solidity compiler commandline interface
Version: 0.5.11+commit.22be8592.Linux.g++

$ docker run ethereum/solc:0.5.11 --version
solc, the solidity compiler commandline interface
Version: 0.5.11+commit.22be8592.Linux.g++

Compare with list.txt entry.

[chriseth]

Thanks for opening this issue! You are indeed right, the solc-js version seems to be behind by one commit. This commit is only a change in the build scripts, but we should still point solc-js at the proper tag.

Note that source verification has to fail anyway if you are not using exactly the same compiler because the metadata includes the commit and platform of the compiler and thus the metadata hash will be different.

[brianmcmichael]

FWIW, only the binary output needs to match to do source verification, since the service regenerates the artifacts on the other end from the source and compares the bin with the contract code on-chain. In this case, I was able to verify a contract compiled with 0.5.11+commit.22be8592 using solc.js 0.5.11+commit.c082d0b4, probably because of the difference only being in the build scripts, but in the case of other compiler tag mismatches the bin may not match.

We're trying to programatically verify on this end though by stripping the platform and sending the version off that way, etherscan bases their list of supported compilers on the js versions though.

[chriseth]

@brianmcmichael etherscan does not do full source verification, it strips the metadata hash and only compares the opcodes. This is fine most of the time, but it can fool you with regards to variable names, comments and even worse: Code that uses codecopy to access the metadata hash.

My comment above is partly wrong, though, only the commit hash is part of the metadata, not the platform.

[chriseth]

@ekpyron is this related to what you are doing? :)

[ekpyron]

@chriseth For the rebuilds in ethereum/solc-bin#22 I specifically used the version defined in https://github.com/ethereum/solc-bin/blob/gh-pages/bin/list.txt - so I generated a new soljson-v0.5.11+commit.c082d0b4.js, not a soljson-v0.5.11+commit.22be8592.js. If we change the list in solc-bin, I'll need to change the respective release in ethereum/solc-bin#22 as well.

[chriseth]

It's maybe not so important what is in the list, but we should not delete a previously available compiler binary.

[chriseth]

@ekpyron can this be closed?