Skip to content

Conversation

frangio
Copy link
Contributor

@frangio frangio commented Aug 4, 2025

A minimal CREATE2 factory is inserted as a system contract in the precompile range, to enable deterministic deployments at identical addresses across EVM chains that adopt it.

https://ethereum-magicians.org/t/eip-7997-deterministic-factory-predeploy/24998

@frangio frangio requested a review from eth-bot as a code owner August 4, 2025 01:53
@github-actions github-actions bot added c-new Creates a brand new proposal s-draft This EIP is a Draft t-core labels Aug 4, 2025
@eth-bot
Copy link
Collaborator

eth-bot commented Aug 4, 2025

✅ All reviewers have approved.

@eth-bot eth-bot added the e-consensus Waiting on editor consensus label Aug 4, 2025
@eth-bot eth-bot added the e-review Waiting on editor to review label Aug 4, 2025
EIPS/eip-.md Outdated

1. A keyless transaction is crafted using Nick's method that can be posted permissionlessly to new chains. For this to work, the chain must support legacy transactions without [EIP-155](./eip-155.md) replay protection, and the fixed gas price and gas limit must be sufficiently high, but not so high as to exceed the limits of the chain.
2. Private keys held by some party are used to sign creation transactions for each chain as needed. This creates a dependency on that party, does not provide a hard guarantee that the factory will be available on every chain, and can also irreversibly fail if transactions are not properly parameterized.
3. [ERC-7955](./eip-7955.md): A private key is intentionally leaked so that any party can permissionlessly create an [EIP-7702](./eip-7702.md) signed delegation and deploy a factory from the leaked account. While this approach improves on the previous two, its reliance on ECDSA keys makes it non-quantum-resistant, and will fail once chains stop supporting ECDSA keys.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Pending merge: ethereum/ERCs#1052

Copy link

Choose a reason for hiding this comment

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

I would also add as another downside that it stops working once there are network upgrades that accounts to permanently upgrade their code (which is loosely planed AFAIU).

Copy link
Contributor Author

@frangio frangio Aug 5, 2025

Choose a reason for hiding this comment

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

which is loosely planed AFAIU

Will add the note but although this idea has been floated I actually don't think it's planned or likely. Because many contracts rely on ECRECOVER for authorization (eg, Permit), permanently setting a delegation doesn't effectively change the account logic. Messing with ECRECOVER to patch that is extremely unlikely.

@github-actions github-actions bot added the w-ci Waiting on CI to pass label Aug 4, 2025
frangio and others added 2 commits August 5, 2025 09:37
Co-authored-by: Andrew B Coathup <[email protected]>
Co-authored-by: Andrew B Coathup <[email protected]>
@github-actions github-actions bot added w-ci Waiting on CI to pass and removed w-ci Waiting on CI to pass labels Aug 5, 2025
@frangio frangio changed the title Add EIP: Multi-chain Deterministic Deployment Factory Add EIP-7997: Multi-chain Deterministic Deployment Factory Aug 5, 2025
@github-actions github-actions bot removed the w-ci Waiting on CI to pass label Aug 5, 2025
@eth-bot eth-bot changed the title Add EIP-7997: Multi-chain Deterministic Deployment Factory Add EIP: Multi-chain Deterministic Deployment Factory Aug 5, 2025
@github-actions github-actions bot added the w-ci Waiting on CI to pass label Aug 5, 2025
@frangio
Copy link
Contributor Author

frangio commented Aug 13, 2025

@lightclient This is now unblocked since ethereum/ERCs#1052 was merged. However, the validator bot doesn't support links to post-split ERCs, so it's not going to succeed even though the link will work fine once published.

@github-actions github-actions bot added the w-ci Waiting on CI to pass label Aug 13, 2025
nlordell added a commit to safe-research/erc-7955 that referenced this pull request Aug 14, 2025
This PR changes the permissionless CREATE2 factory to propagate revert
data (like [EIP-7997](ethereum/EIPs#10092))
instead of just reverting with empty data.

Note that we no longer have the init code fiting into 32-byte :'(, but
the runtime code still does :). That being said, the usability
improvement of propagating revert data is worth the extra code size
IMO. Note that deployment gas costs _still remain the same_, as the
extra code is just in the `revert` branch for contract deployments.

I also chose to keep `calldatasize() - 32` overflow behaviour as it is
now. That is, it will revert with OOG (from trying to copy ~2**256
bytes of calldata to memory) instead of handling the revert manually.
The rationale here is:

1. The call reverts one way or the other, so we don't have bad
   state (different from the suggestion in EIP-7997 which uses a
   saturating subtraction, where incorrect deployments will silently
   fail)
2. Additional gas costs would be paid on **every** create2 deployment
   to handle the conditional jump (basically, the "if calldatasize() <
   32" check), for arguably very little benefit: it will only save gas
   for incorrect invocations, which shouldn't be used anywhere anyway.
nlordell added a commit to safe-research/erc-7955 that referenced this pull request Aug 14, 2025
This PR changes the permissionless CREATE2 factory to propagate revert
data (like [EIP-7997](ethereum/EIPs#10092))
instead of just reverting with empty data.

Note that we no longer have the init code fiting into 32-byte :'(, but
the runtime code still does :). That being said, the usability
improvement of propagating revert data is worth the extra code size
IMO. Note that deployment gas costs _still remain the same_, as the
extra code is just in the `revert` branch for contract deployments.

I also chose to keep `calldatasize() - 32` overflow behaviour as it is
now. That is, it will revert with OOG (from trying to copy ~2**256
bytes of calldata to memory) instead of handling the revert manually.
The rationale here is:

1. The call reverts one way or the other, so we don't have bad
   state (different from the suggestion in EIP-7997 which uses a
   saturating subtraction, where incorrect deployments will silently
   fail)
2. Additional gas costs would be paid on **every** create2 deployment
   to handle the conditional jump (basically, the "if calldatasize() <
   32" check), for arguably very little benefit: it will only save gas
   for incorrect invocations, which shouldn't be used anywhere anyway.
EIPS/eip-7997.md Outdated

### Parameters

* `FORK_BLOCK_NUMBER` = `TBD`
Copy link
Contributor

@g11tech g11tech Aug 18, 2025

Choose a reason for hiding this comment

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

now we don't refer to fork block number in EIPs, we say on activation of EIP...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks! Updated in 9d0aad3.

Copy link

The commit 9d0aad3 (as a parent of e3e94e2) contains errors.
Please inspect the Run Summary for details.

nlordell added a commit to safe-research/erc-7955 that referenced this pull request Aug 19, 2025
This PR changes the permissionless CREATE2 factory to propagate revert
data (like [EIP-7997](ethereum/EIPs#10092))
instead of just reverting with empty data.

Note that we no longer have the init code fiting into 32-byte :'(, but
the runtime code still does :). That being said, the usability
improvement of propagating revert data is worth the extra code size IMO.
Note that deployment gas costs _still remain the same_, as the extra
code is just in the `revert` branch for contract deployments.

I also chose to keep `calldatasize() - 32` overflow behaviour as it is
now. That is, it will revert with OOG (from trying to copy ~2**256 bytes
of calldata to memory) instead of handling the revert manually. The
rationale here is:

1. The call reverts one way or the other, so we don't have bad state
(different from the suggestion in EIP-7997 which uses a saturating
subtraction, where incorrect deployments will silently fail)
2. Additional gas costs would be paid on **every** create2 deployment to
handle the conditional jump (basically, the "if calldatasize() < 32"
check), for arguably very little benefit: it will only save gas for
incorrect invocations, which shouldn't be used anywhere anyway.

The corresponding ERC changes are included here:
safe-research/ERCs#5
@github-actions github-actions bot removed the w-ci Waiting on CI to pass label Aug 19, 2025
@frangio
Copy link
Contributor Author

frangio commented Aug 19, 2025

Removing reference to ERC-7955 until #10140 is merged.


There is currently no native or fully robust way to perform multi-chain deterministic deployments. While `CREATE2` enables deterministic deployments, the created address is computed from that of the contract that invokes the instruction, so a *factory* that is itself multi-chain is required for bootstrapping. Four workarounds are currently known to deploy such a factory, each with their own issues:

1. A keyless transaction is crafted using Nick's method that can be posted permissionlessly to new chains. For this to work, the chain must support legacy transactions without [EIP-155](./eip-155.md) replay protection, and the fixed gas price and gas limit must be sufficiently high, but not so high as to exceed the limits of the chain.
Copy link
Contributor

Choose a reason for hiding this comment

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

is it common knowledge what Nick's method is? else pls define/elaborate it

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes it is common knowledge.

@eth-bot eth-bot enabled auto-merge (squash) August 19, 2025 16:29
Copy link
Collaborator

@eth-bot eth-bot left a comment

Choose a reason for hiding this comment

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

All Reviewers Have Approved; Performing Automatic Merge...

@eth-bot eth-bot merged commit f8be9ce into ethereum:master Aug 19, 2025
13 checks passed
@frangio frangio deleted the multi-deploy branch August 19, 2025 16:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c-new Creates a brand new proposal e-consensus Waiting on editor consensus e-review Waiting on editor to review s-draft This EIP is a Draft t-core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants