Closed Enigmatic331 closed 2 years ago
So, I ran the above code with Vyper version 0.2.8 and got your first answer:
$ vyper --version
0.2.8+commit.069936f
$ vyper -f bytecode_runtime test.vy
0x341561000a57600080fd5b600436101561001857610057565b600035601c5263313ce567600051141561003a5760005460005260206000f350005b633bbfe01560005114156100565760015460005260206000f350005b5b60006000fd
There was a change in 0.2.5 that led to this code getting smaller. Prior to that it was:
0x600436101561000d576100f0565b600035601c52740100000000000000000000000000000000000000006020526f7fffffffffffffffffffffffffffffff6040527fffffffffffffffffffffffffffffffff8000000000000000000000000000000060605274012a05f1fffffffffffffffffffffffffdabf41c006080527ffffffffffffffffffffffffed5fa0e000000000000000000000000000000000060a05263313ce56760005114156100c85734156100ba57600080fd5b60005460005260206000f350005b633bbfe01560005114156100ef5734156100e157600080fd5b60015460005260206000f350005b5b60006000fd
So no match on different versions (the version pragma should've caught that though anyways).
Can the deployer share how they deployed that code? It doesn't seem right to me.
Oh this is cool! Super curious what was introduced.
I just used Remix + MM for the above (wanted to keep things as simple as possible).
I just used Remix + MM for the above (wanted to keep things as simple as possible).
Yeah, I think the way you and I did it is correct,. I'm curious how that contract was deployed, what OS, vyper version, deployment framework, etc. was used.
closing this as can't repro, and it looks like a compiler version mismatch. please re-open if the issue happens again!
Version Information
vyper --version
): v0.2.8python --version
): Python 2.7.9/3.8What's your issue about?
First off, ❤️ Vyper
Here at Etherscan we recently came across a contract which we weren't able to match its compiled runtime bytecode with its onchain bytecode no matter what we attempted to do. A short snippet would be as such:
Deployed contract at: https://ropsten.etherscan.io/address/0xc9fb22a3733deaf12324c66b302965601b3c74da#code
The runtime bytecode produced by Remix:
0x341561000a57600080fd5b600436101561001857610057565b600035601c5263313ce567600051141561003a5760005460005260206000f350005b633bbfe01560005114156100565760015460005260206000f350005b5b60006000fd
The onchain bytecode as on the address above:
0x341561000a57600080fd5b600436101561001857610094565b600035601c5274012a05f1fffffffffffffffffffffffffdabf41c006080527ffffffffffffffffffffffffed5fa0e000000000000000000000000000000000060a05263313ce56760005114156100775760005460005260206000f350005b633bbfe01560005114156100935760015460005260206000f350005b5b60006000fd
At Etherscan our verification process involves comparing the compiled runtime bytecode with the onchain bytecode, so it would fail at this point, The deployment bytecode do match up perfectly though.
Perhaps, would it be advisable for us to switch to deployment bytecode-checks-only for such situations? Or perhaps there's something else we are missing and should explore further - Stand to be guided by the snek experts.
Addendum: No additional options involved. Just copy pasted the code as is to Remix, compiled and deployed... And one would observe the above...
===
PS: I know I said on our other channel that there's another strange one I've stumbled on, but thinking about it and further testing it across vs Solidity, I think it's a non-issue in the end, so don't worry about it :)