EIP-7997: Deterministic Factory Predeploy

EIPs
1

Discussion topic for EIP-7997: Deterministic Factory Predeploy

Update Log

9 Likes
2

This would be, IMO at least, an even more ideal way to have a CREATE2 factory on the same address on every chain and prefer it compared to the proposed ERC-7955.

I also like your minimal CREATE2 factory bytecode (notably how it explicitly handles cases where CALLDATASIZE is smaller than 32, and revert data propagation) and might backport some of it to ERC-7955 :smile:.

One question I have is why you opted this to be an EIP instead of pushing RIP-7740 or another equivalent RIP? I feel like the former requires adoption by Ethereum + Rollups, while the latter only requires adoption by Rollups – so fewer parties.

Edit: Also worth pointing out that there was a similar discussion to have a CREATE2 precompile a few years ago which unfortunately did not lead anywhere: EIP Proposal: CREATE2 contract factory precompile for deployment at consistent addresses across networks

4 Likes
3

Please do! I hadn’t noticed revert data isn’t propagated in ERC-7955, it definitely should IMO.

I think if this is standardized in Ethereum L1 and implemented in upstream clients it has the best chance of becoming widely available, even in other L1s.

RIP-7740 is a bit radical in including factories with managed keys. That’s like taking over user accounts in the protocol and I imagine it being unappealing to chain developers. Perhaps if those factories are removed it might be a better proposition. But I don’t know how those conversations have gone so far.

As long as we get a permissionless factory that’s available everywhere I don’t mind if it’s this EIP, ERC-7955, or Deterministic Deployment Proxy via RIP-7740. We might as well try all approaches!

4

That is a good point. You could argue to restrict RIP-7740 to just Nick’s deployment (cc @rmeissner). That being said - we’ve seen some success at Safe with just convincing chains that they should include Safe’s CREATE2 factory deployment as a “preinstall”, just standardization efforts have not been that successful AFAIK :sweat_smile:.

I personally prefer this or RIP-7740, ERC-7955 is nice because it works without network changes, but has some weaknesses IMO:

  1. It relies on EIP-7702 which not all networks implement AFAIK
  2. It will pontentially break in the future if permanent account upgrades becomes a thing.
5

Sorry if I missed the relevant explanation, but what is this intended to solve compared to the status quo?

The status quo being that most chain deploy this deterministic deployment factory (GitHub - Arachnid/deterministic-deployment-proxy: An Ethereum proxy contract that can be used for deploying contracts to a deterministic address on any chain.) at address 0x4e59b44847b379578588920ca78fbf26c0b4956c (this is deployed using Nick’s method).

This is widely integrated:

  • Foundry uses it by default when you deploy contracts from a deploy script.
  • All OP stack chain come with the factory pre-deployed.

Weaknesses of this method are:

  • gas limit is hardcoded, so changes to the gas schedule could break it
  • chains need to support legacy transactions

Here’s a writeup I have that explains this in more detail: Notion

6

To provide a native solution to this problem that doesn’t rely on shaky assumptions.

The weaknesses are the ones you listed. For reference, this is mentioned in the Motivation section of this EIP:

For this to work, the chain must support legacy transactions without EIP-155 replay protection, and the fixed gas price and gas limit must be sufficiently high, but not so high as to exceed the limits of the chain.

Additionally, here’s the relevant section from ERC-7955:

  • It does not work on chains that only accept EIP-155 replay-protected transactions.
  • It is sensitive to changes in gas parameters on the target chain since the gas price and limit in the deployment transaction is sealed, and a new one cannot be signed without a private key.
  • Reverts, such as those caused by alternative gas schedules, make the CREATE2 factory no longer deployable.

And here are notes from @pcaversaccio based on his experience developing the CreateX factory:

Also, there are many RPCs that don’t support per-EIP-155 transactions even though at the network level it would be supported (reason being that Geth defaults to non-support of pre-EIP-155 transactions since Berlin; see ethereum/go-ethereum#22339) as well as networks that simply don’t support pre-EIP-155 transactions. Furthermore, some note on why Nick’s method doesn’t scale: I have 3 presigned transactions for CreateX creation available (see here), with one having 45m gasLimit. The last one couldn’t be broadcasted on Ethereum due to today’s block gasLimit. But even that one wouldn’t be enough to e.g. deploy on Filecoin, which requires more than 100m gasLimit.

I think Nick’s Method as well as ERC-7955 are beautiful workarounds, but they’re not reliable solutions and this seems to be widely understood, so the status quo in my opinion is that this problem is not solved. @norswap Let me know if you disagree with this!

7

Thanks for clarifying, and sorry, I read the bulleted list in the EIP as being what you were proposing, not what the previous method was.

So I suppose the succinct version of your proposal is “create a new precompile (actually a pre-deploy) for the deterministic deployment factory”.

That makes a lot of sense, I think it’s great :+1:

8

Got it, will try to clarify in the EIP.

Yeah, I’m avoiding the term precompile because it’s quite different, and predeploys in Ethereum so far have been done using Nick’s method, so this is a new category of thing.

9

Hi @frangio, I have a question about the approach taken in this EIP.

Could EIP-7702 + Nick’s method solve the same problem?

Essentially, Nick’s method can’t be replicated in every chain given EIP-155 and the chainId. However, this is not an issue for EIP-7702 delegations since they allow the chainId to be 0. In this way, one could:

  1. Use Nick’s method to create a “keyless” address with a random signature
  2. Use EIP-7702 to delegate that address to the factory code on every chain
  3. Result: The same factory exists at the same address everywhere, deterministically and trustlessly (nobody has the private key)

If this is correct, then the deterministic factory could be achieved without requiring protocol changes. Thanks for your thoughts!

10

Yes, EIP-7702 can help. The exact scheme you described doesn’t work because the random signature can only be generated for a specific delegation, so it’s tied to the address of the delegation target, and you’d need the delegation target to be a multi-chain factory which is exactly what you don’t have and are trying to obtain, so it’s back to step 0. But EIP-7702 can be used in the way that ERC-7955 has proposed. This is mentioned in one of the alternatives in the Motivation section, along with why I don’t think it’s a complete solution.

1 Like
11

it’s tied to the address of the delegation target

Yes, I missed that.

In any case, deploying the delegation target on every EVM chain is already possible with the same mechanism as pcversaccio’s CreateX. I would’ve thought the delegation target doesn’t really matter if it’s the bytecode described in EIP-7997

Thanks for clarifying!