Multi chain deployment process for a permissionless contract factory

ERCs
1

This ERC proposes a permissionless method to deploy a universal CREATE2 factory contract to a deterministic address (0xC0DE8E984dF1846E6AdE500972641ce0a9669e1b) across EVM-compatible chains. It leverages EIP-7702 and a publicly known private key to initiate the deployment.

This approach aims to overcome limitations of current methods, specifically the reliance on transactions without EIP-155 replay protection, guarded private keys, or chain-specific preinstalled contracts. This makes the mechanism both more permissionless and error resistant compared to existing CREATE2 factory deployments. However, while it does suffer from potential front-running attacks may cause delays and gas griefing, they cannot permanently prevent the factory’s deployment to the expected address.

The ERC specifies exact parameters for the CREATE2 factory, to ensure a single, universal CREATE2 factory for the community.

Edit:
More information and tooling can be found on the related Safe Research repo: GitHub - safe-research/permissionless-create2: Permissionless CREATE2 Factory

14 Likes
2

Some caveats coming from the guy who deployed CreateX on over 150 chains (cannot recommend lol):

  • This entire approach hinges on the assumption that the new transaction type 4 will be supported by all target chains. This approach scales well until you go beyond the standard EVM chains; example Linea is still running on london. The rollout of this EIP is probably best if the rollout of EIP-7702 has happened almost everywhere; but even then you probably cannot support more exotic use cases like Filecoin with their own EVM-compatible but not EVM-equivalent engine (I doubt they will upgrade to this tx type, but who knows). The fundamental question is: how much do we care about the exotic world of EVM-compatible but not EVM-equivalent world? I personally care and thus have chosen the “private key as backup” method for CreateX, which is definitely suboptimal.
  • You can have scenarios where EVM chains support transaction type 4 but e.g. not PUSH0. So if the CREATE2_FACTORY_INIT_CODE contains not supported opcodes, this can lead to scenarios where you would face contract creation failures.

That being said, I personally like the idea of the ERC overall. Based on my practical experience, I can envision already a couple of practical issues that can break the scalability of this proposal.

4 Likes
3

The only issue I see with this scheme is that it stops working in a post-quantum scenario where ECDSA keys are deactivated. However, if you keep the seed private (and safe for however many decades) it could probably just downgrade to the “secret private key” solution (assuming something like this is implemented).

Ideally I think multi-chain deployments should be provided as a native feature of the chain, but this is a great solution as long as we don’t have that.

4

I agree that having a native feature on chains is the preferred way. The Safe team (and also @pcaversaccio) are trying to get as many of the L2 providers to include them as pre-deployments for now.

if you keep the seed private

As the private key is publicly known (as part of the ERC) this shouldn’t bee an issue.

in a post-quantum scenario

Also agree here that with changes introduced to Ethereum related to Quantum Security will most likely trigger a lot of follow up changes. Lets see when this happen :slight_smile:

1 Like
5

Good point. We can use something like the RETURNDATASIZE opcode to push a 0 onto the stack to make things more compatible.

1 Like
6

In the latest version of the ERC, we changed the code to use RETURNDATASIZE for pushing 0’s to remove the dependency on EIP-3855 (i.e. PUSH0). So it should be more portable now.

1 Like