-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solidity 0.5.17 installed with Homebrew produces a different output than the version downloaded from solc-bin.ethereum.org #10183
Comments
Looks like a difference in metadata. Metadata includes compiler version and versions clearly differ. The build system adds the For example I had to modify the config to stop compiler from treating warnings as errors (there are warnings below 0.6.1) and to link The only sure-fire way to fix these builds I can think of would be to add another modification that would remove the |
I'm going to redo the builds for which the version does not match and just omit the |
Thanks for your reply, @cameel.
I'm actually surprised that the build info is included in the metadata that gets hashed and embedded into the bytecode. I just checked, and the example in the documentation includes it, but it would be great if you could make it more explicit, as it's not something you'd expect. While I get the idea behind doing that, I believe it makes it unfeasible to use the metadata hash at all. There's at least 4 different official builds for each We weren't having this kind of issue before because most of us were using the same Emscripten builds, but this will become increasingly common now that you published native versions for all the major platforms, and tools are adopting them.
I think sticking with the |
That's actually tripping many people up. See for example #10082. But I think that information about compiler version used to generate the bytecode is pretty important when it comes to reproducing it.
This is not a problem with official release builds because we do perform extensive checks that the generated byte code is identical on all platforms. We have the t_bytecode_compare CI job that runs for every PR and also on the final binaries that are published on the github release page. The job basically takes all the 4k+ The situation with these MacOS rebuilds is a special case because they were not originally included in releases and I built them independently in Lesson learned. I'm going to do the bytecode comparison when I rebuild the binaries now.
This really depends on how widely those builds are used. They have only been added recently so I was assuming that replacing them with ones that can produce bytecode identical with other platforms would be the lesser evil here. AFAIK Etherscan is using the emscripten builds from the We definitely could keep the old binaries in a separate directory in |
Sorry it took so long but I'm finally done with verifying the rebuilt binaries. Running the bytecode comparison on the historical binaries required adding extra functionality to our scripts and also making them backwards compatible with the CLI interface of older versions. I'm glad I did it because it turned out that there are more problems than just the macOS binaries and that binaries for 0.3.6, 0.4.7 and 0.4.8 won't produce the same bytecode even after the rebuild. So here's the overview of the situation:
So now getting the binaries out is just a matter of ethereum/solc-bin#76 passing review. After it's merged anyone who needs the old ones for verification will still be able to get them from the commit I tagged as |
Turns out that #10846 is not the only issue with the macOS binary for 0.3.6:
Since it's such an old version and resolving these issues will be pretty tedious I think it's not really worth it. So the question would be whether we should keep such a binary in @alcuadrado Do you have an opinion on that? |
Hi
@udwig, reported to us that he was unable to verify a contract on Etherscan, even when using the exact same solidity standard input json. We spent some time debugging it, and found this problem with solc or with its distribution:
If you install
solc
0.5.17+commit.d19bba13
using Homebrew and downloading it from solc-bin.ethereum.org, you can get a different output for the same input.Here's a script that can be used to reproduce it:
It will output
Another interesting thing is that Etherscan seems to be running the same version than the one distributed by Homebrew. It may actually be solcjs. I got into this other bug when trying to reproduce it with solcjs.
Any idea what's going on? Are the solc-bin.ethereum.org binaries somehow corrupted? This is really important to us, as it can lead to people deploying contracts that aren't verifiable on Etherscan.
The text was updated successfully, but these errors were encountered: