eth: Compare on chain bytecode with local copy

[martonp]

Add a shell script that generates go code containing the runtime
bytecode of the ETHSwap contract. Add a function to rpcclient to
retrieve the on chain bytecode, and add a test that compares them.

Closes #1198

[JoeGruffins]

This is pretty perfect. Quick work of it.

Is it possible to have the github cli download the correct version of solc, run genruntime.sh and compare those files, so we would know if something changed in the hex bin? Maybe also a good idea for contract.go in that case, although that also requires a certain version of abigen I believe. Can be a different pr if others think it's a good idea.

[chappjc]

Even though we're not going to be using ethClient.getCodeAt on the first iteration, it's a good method to have.

How do you guys control solc versions? I have 0.8.7 and this was a pain for me. Maybe we can allow different patch versions, at least until we are ready to lock it down?

[chappjc]

We can leave this, but it's really a job for //go:embed.

e.g.

import _ "embed"

//go:embed contracts/ETHSwap.bin.dat
var ETHSwapRuntimeBin []byte

In the above I'm loading a []byte instead of string because I converted the output of solc into an actual binary, so you don't have to do DecodeString, but it can load the hex text too. But even with a hex string, we won't actually need to generate this file.

To make an binary file, not hexadecimal text I did solc --bin-runtime --optimize ETHSwapV0.sol | xxd -r -p > ETHSwap.bin.dat, but maybe solc can be coaxed into writing a bin file.

[martonp]

That is definitely nicer, but the only reason I prefer the current technique is that it's consistent with what the abigen does (this is what generates contract.go). There's a really long string in there as well.

[chappjc]

That's fine. Either we check in a ~2kb binary file to use go:embed, or we put the string right in the .go file with a shell script. No biggie to me either way.
The contract bindings are actual code though, not just variables, so I see that a little differently. It's fine this way, just a little unfortunate that it's a string when we really want bytes (any conceivable use for this would have to hex.DecodeString).

[chappjc]

It's not clear to me what switches to use here. These are the output options I see:

  --asm                EVM assembly of the contracts.
  --asm-json           EVM assembly of the contracts in JSON format.
  --opcodes            Opcodes of the contracts.
  --bin                Binary of the contracts in hex.
  --bin-runtime        Binary of the runtime part of the contracts in hex.
  --abi                ABI specification of the contracts.

The output of --bin is larger than --bin-runtime. Which one is better to compare? I mean CodeAt worked with bin-runtime obviously, but what's the difference between these two?

Also I'm wondering if the use of optimize (and specific compiler version) are going to make this extremely fragile.

Asking for no changes here... just a conversation.

[martonp]

--bin returns the creation bytecode. This is what has to be sent in a transaction when you initialize a new smart contract. --bin-runtime returns the runtime bytecode, which is the code that ends up being stored on chain. This includes everything in the creation bytecode, except the constructor function and constructor arguments, as they will not need to be used again after initialization.

Why do you say that using a specific compiler version would make this fragile? I would think that not having a specific version would make it fragile. Optimize just applies some simplification rules to the unoptimized bytecode. This is a deterministic operation. If the same compiler version is used to optimize both what is deployed and what is used to compare, then we will get the same results.

[chappjc]

Why do you say that using a specific compiler version would make this fragile?

Ah I was thinking about optimize and how there are different levels, but you are right, the same considerations apply there as with compiler version. I was just referring to how identical contracts compiled with newer solc versions probably would get rejected, but I guess that's the point.

[martonp]

I haven't really thought much about managing the solidity version. I think the whole point of locking down the version was in order to be able to do these comparisons. It definitely was a pain to work with for me as well, since 0.8.6 is no longer the most recent version. Maybe a script that downloads the correct abigen and solc versions would be nice? This could be used in the github workflow that @JoeGruffins was talking about too. I think it's a good idea to do that too, since they might patch the released version which causes a diff.

[JoeGruffins]

How do you guys control solc versions?

@chappjc I know you use arch, sudo downgrade solidity (after installing solidty and downgrade) and put on the ignore packages list

[chappjc]

I was thinking a less system-wide approach, but that's probably fine for my purposes. Thanks

[JoeGruffins]

K.I.S.S.

But it can maybe be made better if one to were make the golang-cli script ,which would also download the correct solc to a temp location I suppose, and we could just use that to regenerate.