vyperlang / vyper

Pythonic Smart Contract Language for the EVM
https://vyperlang.org
Other
4.84k stars 789 forks source link

Issues matching up runtime bytecode with onchain (eth.getCode) bytecode for some contracts #2296

Closed Enigmatic331 closed 2 years ago

Enigmatic331 commented 3 years ago

Version Information

What'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:

# @version 0.2.8
decimals: public(uint256)
onepct: public(uint256)

@external
def __init__(_decimals: uint256):
    self.decimals = _decimals
    deciCalc: decimal = convert(10 ** _decimals, decimal)
    self.onepct = convert(0.01 * deciCalc, uint256)

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 :)

fubuloubu commented 3 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.

Enigmatic331 commented 3 years ago

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).

fubuloubu commented 3 years ago

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.

charles-cooper commented 2 years ago

closing this as can't repro, and it looks like a compiler version mismatch. please re-open if the issue happens again!