EIP Proposal: CREATE2 contract factory precompile for deployment at consistent addresses across networks

Moving here a conversation started on Twitter to further discuss before going into opening an EIP.

The idea behind this EIP is adding a precompile that executes a CREATE2 with whatever data is sent to it and a fixed salt. The rationale for it being a precompile is not performance, but rather being available at the same address across all networks. This allows any contract deployed through this factory to also have the same address across all networks where it’s deployed.

The aim is to provide a more robust alternative to Nick’s method, used for example in the deployment of the 1820 registry. Nick’s method requires hardcoding the gas price of the deployment tx, which may be reasonable for a chain at a certain time, but not so much in other chains which use a different currency altogether.

With the proliferation of EVM-compatible sidechains and L2s, it’s critical to have consistent addresses across chains for well-known contracts that provide global services, such as EIP3074 invoker contracts.

I’m curious to hear others’ thoughts about this idea, before turning it into a full-fledged EIP.

1 Like

That is a good point that gas price is hard coded in, that certainly complicates things. I’m not sure if there is bandwidth for something like this atm, but it does seem like a reasonable proposal.

1 Like

Individual projects are already capable of doing this without a precompile, so I’m opposed.

Nick’s method can be expanded by signing additional transactions with different gas prices. It won’t matter which confirms but you can use whichever according to how much you use to fund the deployer address. I recommend powers of 10: 1 wei, 10 wei, 100 wei, etc.

But don’t you get different deployment addresses? The whole goal of this is getting consistent addresses across chains.

If I understand it correctly, you shouldn’t get a different address. The result address of a creation is only based on sender and nonce, so it is easy to duplicate addresses across chains. If they only sign the deployer contract deployment transactions (intentionally without replay protection), it should be secure and permissionless to deploy that standard anywhere.

The problem is having a trustless sender. Nick’s method works by not knowing the private key of the sender, but rather setting up a random signature and deriving the sender address from that, so any change on the signed tx payload (such as gas price) yields a different sender, and thus a different address.

The alternative is having someone in control of the private key used for signing the deployment, who can sign deployment txs with multiple gas prices as you say, but there are no guarantees that that someone won’t send another tx with the same key that takes up the deployment nonce and hence the address.

1 Like

The alternative is having someone in control of the private key used for signing the deployment, who can sign deployment txs with multiple gas prices as you say, but there are no guarantees that that someone won’t send another tx with the same key that takes up the deployment nonce and hence the address.

I see the limitation of Nick’s method now; I didn’t previously see how the signature was generated.

To sign with a private key of similar security you can do a “trusted setup” similar to EY Nightfall where the private key is generated and destroyed in some docker image live on some streaming platform for everyone to verify the steps and the cleanup, It should be possible to verify the process was live by pulling some data that could not have been known in advance, while showing the hashes of every program and library used as well perhaps as the entire system image, e.g. Docker.

Even then, it is possible that the private key was recorded by some emulator enveloping the whole charade, so I am not sure how to guarantee security on the key, except that whoever was generating the signatures probably had no motivation to exploit, and as soon as funds needed to deploy such a contract (likely minimal in value) were stolen on one network the process would need to be repeated by someone who was not now living in disgrace. So I suspect a complete trustless setup might not be necessary from a cost-benefit analysis, though posterity would appreciate whatever diligence we can engineer.

Separately, if EIP-1820 is no-good due to your gas price observation, this provides an opportunity to optimize the deployment contract by rewriting it in assembly and scrapping the features it does not truly need, such as support for ERC-165.