This proposal introduces a set of deployment factory contracts to be preinstalled at common addresses. This will enable deterministic contract deployment to the same address across different networks.
Many projects rely on deployment factories that make use of create2 to increase the security and determinism of deployments. Utilizing create2 has a couple of major advantages:
The downside is that it is still necessary to deploy these deployment factories. There are two common ways to do so:
Using a randomly generated signature for a fixed deployment transaction has the advantage that this is a fully trustless process, and no deployment key has to be managed. But the parameter of the signed deployment transaction cannot be changed, therefore it is not possible to adjust the gas price, gas limits or set the chain ID.
Providing a stable way for deterministic and trustless deployments will become even more important with EIPs like EIP-7702. The strong guarantees provided by a deployment factory are extremely helpful in this case, as this EIP depends on the code at a specific address.
This RIP proposes aligning on a set of deterministic deployment factories and preinstalling these on all Rollups to enable developers to rely on such libraries. Some rollups, such as Optimism, already have a set of preinstalled contracts for deterministic deployments, and this proposal aims to extend this set to other Rollup stacks to prevent fragmentation.
The following factories should be added:
0x4e59b44847b379578588920ca78fbf26c0b4956c0x914d7Fec6aaC8cd542e72Bca78B30650d45643d70xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2For factories with a managed key, the nonce of the deployer account should be kept as is since the factories are not destructible and CREATE opcodes revert in case of a collision.
The listed factories are already in active use on multiple networks. To ensure future compatibility without having to redeploy existing contracts, it makes the most sense to enable a set of deployment factories that also cover a large part of the existing ecosystem.
One potential issue that is unlikely to arise is a rogue actor obtaining access to a deployer key of one of the key-managed factories and deploying a different bytecode at the factory address to one of the networks affected by the proposal. If this happens before the proposal is implemented, the Authors propose two potential solutions:
No other backward compatibility issues were found.