draft: migrate from Nick's factory to CreateX

[zerosnacks]

Motivation

Start of migration to CreateX

Previous implementation is Nick's deterministic-deployment-proxy also referred to as Nick's factory.

Implementation is written in Yul: https://github.com/Arachnid/deterministic-deployment-proxy/blob/master/source/deterministic-deployment-proxy.yul and therefore does not verify.

Documentation is non-existent, its contract cannot be verified on Etherscan and the token field displays a glitchy name. It does not support CREATE3.

Goals of the migration, stated requirements:

• Contract must be easily human readable on explorers like Etherscan.
• Contract must be displayed on Etherscan as being a factory.
• Contract must be easily verifiable, preferably written in plain Solidity.
• Documentation must be excellent and extensive.
• Adoption must be wide and included in pre-installs like OP-stack (which circumvents permissioning all together) or on track to be.
• If deployments are permissioned and keys are held we have a clear view on how it is managed and keys are secured. We need direct lines of contact / know the authors.
• If possible, improve on security / have guardrails.

CreateX adheres to all these goals.

• Verified source code on explorers
• Written in plain Solidity
• Extensive and well written documentation
• Supports CREATE3
• Has wide adoption, wide distribution and included in OP-stack pre-installs already: https://docs.optimism.io/operators/chain-operators/features/preinstalls
• We have direct lines of contact with the authors and the management of private keys is well documented: 📖 Private Key Management of `CreateX` Deployer pcaversaccio/createx#61 (comment)

Concerns:

• Not formally audited
• Contract is large
• It halves the efficiency of mining vanity addresses since you need to hash twice to get the deployed address
• We could technically introduce CREATE3 functionality through a separate factory
• We need to be extremely careful in how we introduce this breaking change; we cannot modify the behavior of existing deployment scripts

Notably, Foundry already makes it possible for developers through the --create2-deployer flag to control which CREATE2 factory is used.

With the migration we want to support the full range of benefits CreateX offers, partly through changes in Foundry, cheatcodes where applicable and relevant changes in forge-std (https://github.com/radeksvarz/createx-forge)

Closes: #2638

Solution

This is known to be a large breaking change and we need to figure out how to communicate this and let users migrate themselves. We likely need a transition path where we initially still default to Nick's factory, introduce CreateX and its extensive functionality and then in a breaking release mark Nick's factory's path as deprecated (user receives a warning) followed by full deprecation and switch to CreateX.

Please note that the current state of the PR does not yet reflect this migration path.

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[0xrusowsky]

shouldn't all CREATE2 references be renamed to CREATEX?

[zerosnacks]

yes let's do that, considering we are planning to use the entire feature set of CREATEX, not merely its CREATE2 methods

[zerosnacks]

we do however still allow users to define their own preferred factory using --create2-deployer so we would lose symmetry there

[0xrusowsky]

i think it's fine, as createX is a valid create2-deployer

[DaniPopes]

since we're here can we use this constant everywhere?

[akshatmittal]

Please do not do this, here's why:

1. CreateX uses a non-standard salt scheme, applying a guard on top of the provided salt, this makes debugging the default deployments significantly harder. Even more so if you use custom salts.
2. CreateX includes several other things such as permissioned deployment and cross-chain deployment protection. (see end of this comment)
3. Given the first two, CreateX requires custom functions to calculate resulting addresses and is very easy to mess up.
4. Needless to say, this is a significant breaking change for most.

I'd be favour of including CreateX as an alternative deployment paradigm, but not replace the existing Create2 deployments. The existing implementation is unopinionated and requires minimal understanding of Create2 itself, which isn't true for CreateX. This implementation should also expose the additional capability that CreateX brings. These are different enough to warrant explicit choice. There are other (better) alternatives which are less opinionated such as Safe's Deployer or the KeylessCreate2Factory from 0age/OpenSea, if you're looking for a replacement (idk why).

On a related note: Foundry should be recommending people to deploy their own Create2 factories, either permissioned or not, and defining the interface on how Foundry uses it.

[zerosnacks]

Hi @akshatmittal thanks for your feedback! I have updated the description of the ticket with our motivation and a suggested path of how we may implement the migration.

Please note that it is always possible for users to pass the --create2-deployer flag to control the CREATE2 factory or configure it in foundry.toml as create2_deployer.

[zerosnacks]

Some more relevant links to CreateX:

• https://sourcify.dev/#/lookup/0xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed aggregates all deployments and shows exact matches
• https://createx.rocks/ to look up deployments, ABI, etc

[Zodomo]

In strong support of this change. CreateX is basically universally deployed, freely deployable, and easily verifiable. The guarded salt mechanism, while misunderstood by most, is very helpful for preventing deployment frontrunning and enabling crosschain address control. Salts can be keyed to specific deployer addresses such that anyone other than the deployer will get a different address if they attempt to deploy with it, and deployment addresses can be made chain-specific (literally restricted to a single chain). Address computation can be easily performed in Solidity with helper functions. Despite being a breaking change, this is a good one.

[akshatmittal]

Thanks for the additional context, @zerosnacks! Some more thoughts:

1. I like the direction, I think it's very much warranted. To be clear, I'm in favour of including CreateX deployment path.
2. It is important to note that all of these factories have different ABI and require different calldata for deployment, so forge will need to support some generalized method of working with them. Setting the create2_deployer deployer in config probably only works when you also know how to use the deployer.
3. I feel like a good way to do this is probably deployment plugins where foundry defines the interface on how it can use the factory where the plugin implement the actual functions, just brainstorming here, don't have a design for this myself.

Just want to note here, I like CreateX and use it fairly often. It just has some additional things to keep in mind which are often hard for newcomers to fully grasp. All I want to push towards is having a good experience for both newcomers and us who can write whatever deployment pattern we want either way.

I'm very much looking forward to this, I've been maintaining my own deployment flow for way too long and this would simplify a bunch of it.

[zerosnacks]

Based on the feedback and positive signals received I feel comfortable moving ahead to continue development on this PR but we need to spend (much) more time working out the migration path in detail in regards to how to introduce this breaking change in a way that existing script suites do not break / silently fail. There is significant concern of loss of funds / misconfiguration / etc.. if we simply swap out the default implementation.

I've pinged Etherscan to see if it would be possible to improve the developer experience of Nick's factory (https://etherscan.io/address/0x4e59b44847b379578588920ca78fbf26c0b4956c) so that the source code is verified and the Tracker field name no longer displays a glitchy name.