Port CREATE3

[cyotee]

CREATE3 will be useful for deploying Diamond proxies and new Facets. Makes it possible to deploy code to the consistent addresses across chains, regardless of bytecode. The bytecode decoupling is desirable so Facets can include chain specific modifications, just a ZK support, while maintaining the same address.

[panditdhamdhere]

@cyotee would you like to work on this ?

[cyotee]

Possibly. But I find I dislike many of the design choices Nick is mandating in how he wants the underlying libraries to be implemented. I think the storage struct to be passed to the library functions. That way it doesn't force the struct storage pointer to be loaded and bound to the pointer multiple time when several library functions need to be called. Then a wrapper that loads and binds the storage pointer as a option to simplify usage.

I also don't think there should be a public version of a Create3 factory. Decoupling the bytecode from the deployment address makes it more feasible for a malicious user to "claim" salts by deploying a small amount of bytecode. So it will have to be restricted to an approved set of deployers. Likely better to just expect developers to deploy their own Create3 factory so no one can steal salts. And that means it's probably better to make a smart wallet contract for developers. And I don't have the energy to debate the point.

So I'm going to continue building my own version of a diamond first framework. If you want me to handle this based on what I already ported and built I can do this portion, and anything that doesn't require using Nick's library style.

My version of a owned CREATE2/Create3 factory.

CREATE2/Create3 owned factory

I can remove the CREATE2 metadata exposure. But that would also mean it can't be idempotent. And I think idempotency is useful to minimize the gas needed to check if a call is safe, then executing the call.

[mudgen]

Hold on development of this, I need to do some research on this first.