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?
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 ?
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.
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).
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.
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