feat: migrate to `CreateX` for `CREATE2` factory

[sambacha]

Component

Forge

Describe the feature you would like

Define CREATE2 Factory

I do not want to use your factory, I want to use my own factory.

Additional context

https://etherscan.io/address/0x4e59b44847b379578588920ca78fbf26c0b4956c no
https://goerli.etherscan.io/address/0x179c98f5ccdb3bc7d7aefffa06fb7f608a301877#code yes

[mds1]

This is a good config option to add, e.g. create2_deployer = 0x123.... Alternative name ideas: create2_deployer_contract or create2_factory

[sambacha]

Especially considering how etherscan represents the current factory, teams may prefer to have their own canonical factory (nothing preventing other people from using it ofc) etc etc

[mds1]

The main reasons to use another create2 deployer are (1) pass init data to be called after deploy, (2) more leading zeros for cheaper deploy, and I think that's it? Given that, an alternative is to mine a cheap address, agree on the deploy contract's code, deploy it to all the chains, and replace the current default. One downside here is this is a breaking change for anyone relying on the current deployer for vanity addresses.

@sambacha would that work as an alternative / are there other reasons people might need a custom deployer?

[sambacha]

The main reasons to use another create2 deployer are (1) pass init data to be called after deploy, (2) more leading zeros for cheaper deploy, and I think that's it? Given that, an alternative is to mine a cheap address, agree on the deploy contract's code, deploy it to all the chains, and replace the current default. One downside here is this is a breaking change for anyone relying on the current deployer for vanity addresses.

@sambacha would that work as an alternative / are there other reasons people might need a custom deployer?

The factory contract I linked has additional benefits such as:

• There is also a view function that computes the address of the contract that will be created when submitting a given salt or nonce along with a given block of initialization code.

• Determine if a contract has already been deployed by the factory to a given address.

• Modifier to ensure that the first 20 bytes of a submitted salt match those of the calling account. This provides protection against the salt being stolen by frontrunners or other attackers.

Yes for leading zeros, I am using this: https://github.com/0age/create2crunch

wdyt @mds1

[mds1]

I think all of those are good ideas to include in a canonical create2 deployer contract 👌

Perhaps next week I can scaffold out a proposed interface

[joshieDo]

The way we verify contracts or create the transaction depends on the factory we use. So just letting anyone use their own factory implementation is not that straightforward imo. So... if we can agree to a certain interface, it should be fine.

One downside here is this is a breaking change for anyone relying on the current deployer for vanity addresses

True...

[sambacha]

The way we verify contracts or create the transaction depends on the factory we use. So just letting anyone use their own factory implementation is not that straightforward imo. So... if we can agree to a certain interface, it should be fine.

One downside here is this is a breaking change for anyone relying on the current deployer for vanity addresses

True...

if your gonna break it, break it before v1.0

[sambacha]

This is a good config option to add, e.g. create2_deployer = 0x123.... Alternative name ideas: create2_deployer_contract or create2_factory

FoundryCreate2FactoryV8