-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Add EIP: Deterministic Factory Predeploy #10092
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
Conversation
✅ All reviewers have approved. |
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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
Co-authored-by: Andrew B Coathup <[email protected]>
Co-authored-by: Andrew B Coathup <[email protected]>
@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. |
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.
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` |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Updated in 9d0aad3.
The commit 9d0aad3 (as a parent of e3e94e2) contains errors. |
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
This reverts commit 01def41.
This reverts commit fab9d80.
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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this 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...
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