tracking: default to `CreateX` for `CREATE2/3` factory for new scripts

[sambacha]

In order to remain backwards compatible for older scripts an approach was found by introducing a Script2.sol.

The existing Script would remain using Nick's factory whereas Script2 defaults to use CreateX. We will update the template generated by forge init to use the new Script2.

Action items:

• Introduce the relevant constants and bytecodes
• Add Script2 to forge-std & make it so that Script2 triggers the use of CreateX
• Expose various cheatcodes and helpers to use all the different functionalities of CreateX incl. CREATE3
• Add native support for CreateX mining (optional)

[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