Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add pre-installs for deployment factories #30

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from
62 changes: 62 additions & 0 deletions RIPS/rip-7740.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
---
rip: 7740
title: Preinstall deterministic deployment factories
description: Proposal to add deployment factory contracts at common addresses to enable deterministic contract deployments
author: Richard Meissner (@rmeissner), Mikhail Mikheev (@mmv08), Nicholas Rodrigues Lordello (@nlordell)
discussions-to: https://ethereum-magicians.org/t/eip-proposal-create2-contract-factory-precompile-for-deployment-at-consistent-addresses-across-networks/6083/29
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest creating a new topic on Eth Magicians to discuss this RIP

status: Draft
type: Standards Track
category: Core
created: 2024-06-24
---

## Abstract

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.

## Motivation

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 address does not depend on the deployment key, therefore reducing the need to manage a deployment key
- The address of the contract is tied to the deployment code, which provides strong guarantees on the deployed code
- Contracts can be redeployed in case of a selfdestruct

The downside is that it is still necessary to deploy these deployment factories. There are two common ways to do so:
- Utilize a randomly generated signature for fixed deployment transactions
- Manage a deployment key for the deployment factory.

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.

## Specification

### Factories

The following factories should be added:
- [Deterministic Deployment Proxy](https://github.com/Arachnid/deterministic-deployment-proxy) at `0x4e59b44847b379578588920ca78fbf26c0b4956c`
- [Safe Singleton Factory](https://github.com/safe-global/safe-singleton-factory) at `0x914d7Fec6aaC8cd542e72Bca78B30650d45643d7`
- [CreateX](https://github.com/pcaversaccio/createx) at `0xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed`
- [Create2 Deployer](https://github.com/pcaversaccio/create2deployer) at `0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2`

For 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](https://eips.ethereum.org/EIPS/eip-684) in case of a collision.

### References

- [OP Stack Preinstalls](https://docs.optimism.io/builders/chain-operators/features/preinstalls)

## Rationale

### Why not align on one factory?

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.

## Backwards Compatibility

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:
- Revisit the list of factories
- Overwrite the code at the address.

No other backward compatibility issues were found.