But cannot this proxy be just deployed on all the networks via the same CREATE2 method to achieve the same address? 
Maybe I’m missing something, but an EOA cannot do a CREATE2, only a regular CREATE, so we’re stuck with Nick’s method for this which is a bit unreliable.
You can still deploy a create2 proxy contract on any chain and re-deploy the same via it to a deterministic address.
But doesn’t the address determined by CREATE2 depend on the deployer, which would be this proxy contract in question?
Yes, but you could use the same EOA for it on multiple chains. Can’t you?
Seems like this didn’t receive any attention for a long time. But I would like to pick this up again as this would be valuable for counterfactual deployment across multiple chains. Are any of the original posters still active on this?
I’m active, though not on this. Happy to help in pushing it forward if there’s more people interested, I still think it’s valuable. However, I’m afraid a problem in incentives here may be that this is an EIP to be adopted by Ethereum devs to benefit all chains that are not Ethereum.
1 Like
These are both deployed to Ethereum mainnet, and anyone on any other EVM chain should be able to deploy them to their blockchain without any permission or special access. I think some chains have manually deployed them as part of an irregular state chain in some cases as well.
Without salt: GitHub - Zoltu/deterministic-deployment-proxy: An Ethereum proxy contract that can be used for deploying contracts to a deterministic address on any chain.
With salt: GitHub - Arachnid/deterministic-deployment-proxy: An Ethereum proxy contract that can be used for deploying contracts to a deterministic address on any chain.
2 Likes
Problem is with chains that require the chainId to be part of the signature (EIP155 states should, but some chains have implemented it as a must), so that pre-signed tx is no good. It also breaks with chains for which 100 gwei is not a valid gas price, and have no PBS-like structure to sneak in the tx anyway.
1 Like
For those chains, a precompile or irregular state change can get them deployed so they maintain EVM compatibility.
Still would make sense to somehow agree on the factory and an address to use. If it is not defined as a “standard” it is unlikely that any “derivative” chain would do an “irregular state change” or custom precompile.
I forget which (maybe it was Optimism) but at least one EVM compatible change already did this, so I think we can assert it isn’t out of the question at least. I’m hesitant to bake this into Ethereum when it can be baked into other chains as needed instead. At the same time, I appreciate your desire to have all of the chains standardize on one of the many implementations.
Would it make sense to create an ERC around one of the existing Ethereum deployments (mine or Nick’s or both, depending on whether you want deployment transaction compatibility or salt support) and then Ethereum (and several other chains) can defacto support it because those contracts are already deployed there, and other chains can have something to rally around?
2 Likes
What’s the progress on this? This would be super helpful because there is an ongoing increase in the need for contract-at the same address, especially moving towards account abstraction, and the ability to have accounts on the same address across different chains.
After researching nick-method deeply in this article, I would say that it’s a nice workaround currently. Still, it’s not ideal to be a long-lasting solution because of the limitations described in this section such as networks disallowing unprotected transactions and considering future gasPrices and potential changes in opcode gas.
And considering the replies about having to manually store a private key, to ensure deploying the factory on the same address across different chains is a very bad solution (centralized and risky).
While spamming the EIP repo with non-sense standards, having an EIP for a simple CREATE2 precompile contract can be very helpful, simple, and gas efficient and I think most of the chains would consider adopting it as everyone is opting towards multi-chain contracts, and if some chains don’t want it then good for them. @spalladino Are you still willing to continue with this proposal ?
1 Like
I’d prefer to pass over ownership to whoever wants to keep pushing it. It’s also worth considering Micah’s proposal above, since it does not require a change in Ethereum itself but in all other chains. But I’m not sure how to best distribute it to make sure adoption in other chains does not require too many custom steps.
1 Like
I see other issues like networks that mess up with nonces (random nonces) or zkSync like networks which don’t follow the same derivation address scheme. IMHO it’s difficult to standarize for every network unless it’s something on the protocol itself (like a modification to the contract deployment process).
1 Like
We are having exactly the problem described by @spalladino trying to understand how we can deploy on many chains, including Celo, at the same address. It seems currently impossible without a precompiled approach like suggested by Santiago. I wonder if there has been any advancement on this proposal.
One possible risk I see is that someone uses someone else’s code to deploy the contract at the expected address taking ownership of it.
Just deploy Deterministic Deployment Proxy to Celo, or ask them to add it as a “precompile” at the pre-determined address. We essentially already have the equivalent of a precompile (for the sake of this conversation), it is just that not all chains implement it.
Thanks for the response. I will investigate more and try your approach.
Hi from 2023, @dcposch and I have a new proposal might be related to / could depend on this issue:
The basic idea is to allow to-be-precompiles to first have a tradition deployment and then if they gain adoption, the adoption can be used to justify a hardfork to include them as precompile, and such precompil-ify will be backward compatible and all existing using-contract will only experience lower gas on wards.
Our idea demonstrates one usage for the proposal of OP. In fact, if OP doesn’t get supported anytime soon, the incremental way is to treat Nick’s Deployer as the de facto “Precompile” of CREATE2