HI, I've done a deployment of some implementations via the OZ plugin, and now I notice that in my code some hashes for those implementations have changed (not all of them only a few).
However we didnt do any code changes to our contracts! What would be the explanation for this? Something at the time they were compiled and deployed that is now different?
Here are some examples of the difference. The variables, slots, types, ALL MATCH, but seems like these numbers differ in many variables. Seems like happens with variables that reference other contracts that differ.
It also calls our attention that this happens for 2 out of 10 implementations. The other ones match exactly the hash in the network file.
We basically want to confirm if this is not a big deal. I did a POC and was able to upgrade the code with no problems but we are still surprised of the change and would like to understand it better.
Thanks a lot!
Julian
@ericglau Sorry to escale this one as well!!(yeah, im the one that had the Alchemy RPC issue in deploy implementation). I promise this is the last one.
But is very important for us to understand if we need to redeploy everything or there is some explanation to this.We are very close to a release on Mainnet of these implementations. Thanks you a lot for you great help and support as usual!!
Hi @julianmrodri, which hashes specifically are you referring to and at what point do you notice that they changed? Can you clarify what is the diff being shown in your screenshot? e.g. what files are you comparing, are they two different files or different sections or versions of the same file?
If possible, please provide more information on what you are trying to do so that we can determine if this makes sense for your use case.
Some background information:
The numbers in the type strings such as 53516_storage come from AST node IDs generated by the Solidity compiler, and AST node IDs can change between compilation runs if there are other (even if unrelated) contracts that changed in your project.
The plugin accounts for the possibility of the AST node IDs being different between compilation runs.
If there were no code changes, then what should match are the version hashes of each contract. In the impls section of the network file, each child object starts with a hex string which is a hash of the contract's creation bytecode and is how we determine whether a contract has changed. As long as the compiled bytecode of your implementation contract is the same (and if there are constructors, the constructor arguments must also be the same as before), then that is treated as the same implementation contract. Note that even minor changes in the source code or compiler settings could result in different bytecode leading to a different version hash.
But when comparing contracts with different version hashes (for example during an upgrade to a new version of the implementation contract), the storage layouts are compared but the AST node IDs in the type suffixes do not have to match between the versions.
Eric, thanks for your explanation. Sorry if I did not provide enough information.
By hashes that differ I mean the key in the impls section. We did not do any changes to those contracts, and when I compare the storage layouts of the new implementation (which should be identical) I was only seeing the AST Node Ids different and I thought that was the cause. But based on you were saying this is NOT the cause, and something else had to change, right?
One thing I just noticed is that the two implementations that now produce a different hash than the one done at deployment use external library linking and those were deployed with different addresses for those libraries than the ones Im using now. Could that explain this? Im thinking this is the reason, if they work kind as constructor args.
UPDATE: Was able to confirm this. Sorry, Ive should have known better specially when I did the initial PR to be able to use external libs 
Plugin working as expected! Thanks Eric!
1 Like
