Add support for CREATE2 clones and address prediction

[Arachnid]

No description provided.

[wighawag]

Thanks @Arachnid for the PR, I posted a comment on the CREATE3 PR: #17 where I mentioned that it would be good to also think about CREATE2 in regard to naming convention

right now the naming convention might be pretty confusing if we accept both PR.

clone2 might work but predictAddress could apply to both

I did not think that through but cloneWithCREATE2 and predictAddressOfCloneWithCREATE2 would at least have more clear meaning.

What do you think ? @ZeframLou ?

[Arachnid]

I think clone2 is to clone as create2 is to create, so that naming makes sense, while also remaining fairly compact.

predictAddressOfCloneWithCREATE2 seems way too long. Could we do something like addressOfClone2?

[wighawag]

Yes, clone2 and addressOfClone2 works for me

[ZeframLou]

Yeah this seems good, will update my PR

[Arachnid]

I've done the rename, and also refactored the library to return creation bytecode, which is necessary in order for addressOfClone2 to be a view function.

Unfortunately this does have some impact on gas usage; testGas_clone goes from 64,579 gas to 64,738 (+159 gas).

[wighawag]

Thanks for that.

I am personally ok with extra gas but another solution would be to duplicate the code between the view function and the write function at the cost of later maintainability.

[Arachnid]

I did consider that, but it seems like a lot of bloat and maintenance hassle.