-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Different bytecode with same metadata for CRPFactory
from configurable-rights-pool
on 0.6.12
#12415
Comments
This unfortunately does seem to be the same issue as #12281. Extra files included in compilation can affect bytecode on 0.6.12 and Truffle includes all files from the project. You'll be able to reproduce bytecode exactly only if you include the same files in your JSON input. Truffle includes all of these in the input:
I managed to reproduce In that case I'm going to close this since it's a known issue in 0.6.12 and 0.7.0 and is fixed in the latest version of the compiler. |
Great, i'll reproduce the bytecode now. Thanks so much again cameel :) |
CRPFactory
from configurable-rights-pool
on 0.6.12
CRPFactory
from configurable-rights-pool
on 0.6.12CRPFactory
from configurable-rights-pool
on 0.6.12
@chriseth While debugging this I noticed one weird thing - Truffle is still producing the old-style linker references on 0.6.12. (e.g. That's not the first time I see this. Saw it also in NomicFoundation/hardhat#1147 (0.6.12 as well). |
Description
Hello everyone, a few days i asked on the git but now im posting here. I am in a project that use the contracts made by balancer-labs, specificaly the balancer-core and configurable-rights-pool. The project made a fork from those repos, compile (this fork use Truffle as you see) and made a npm package (because we want to deploy to different chains). We use the artifacts (abi and bytecode) from the package to deploy with Hardhat. This is fine, all the contracts work perfectly.
The problem is that i want to verify those contracts using Input JSON Description to make make easier the process (and as we are deploying with artifact, i cannot use Hardhat plugins to verify). So, i get the Input JSON Description from the metadata inside the artifacts in the package. Later, i remove all the quotes and stuff to convert it to an Input JSON Description. In total are 5 contracts, and i already can verify 4 of them (so 4/5).
The last one is the CRPFactory, but i cannot replicate this bytecode and doesnt work to verify. This contract need to link the libraries so could be the reason, but even compiling from the Input JSON without libraries addresses i cannot get the same bytecode that the artifact. I compiled with Hardhat and i get different bytecode. I made a fork from the repo too and compile to see if i get the same bytecode that from package, so i check the settings inside the Input JSON and hardhat, but i have the same settings and some of them are by default (like i bytecodeHash or useLiteralContent) but i wrote them to double check. Also i double check the sources path but i got the same result.
The werid thing is that the metadata generated by the Input JSON and the metada inside the artifact from the package are the same. Event the metadata hash in the bytecode is the same. So, could be a bug like #12281 as cameel told me before but im not sure about this :).
I really like verify all the contracts that the projects manage. I already handle the verification of thecontracts that we made thanks a cameel, and about this contracts just need the last one :) Hope is enough info/context. Thanks for any help and solution :)
Environment
Steps to Reproduce
I'll provide all the files that i think could be necessaries.
Just run the solc-input-crpfactory with solc 0.6.12:
solc --standard-json solc-input-crpfactory
and you can check the different bytecode but the same metadata hash.CRPFactory.zip
NOTE: If you want to check and compile the contracts by your hand, you can make the fork from configurable-rights-pool and check the CRPFactory contract build after compile them.
The text was updated successfully, but these errors were encountered: