From 88d8a566a35c72c94984cb05f503768b54ccf1c7 Mon Sep 17 00:00:00 2001 From: Andrei Maiboroda Date: Fri, 31 Jan 2025 14:52:34 +0100 Subject: [PATCH] Update EIP-7620: Simplify new address hashing scheme Co-authored-by: pdobacz <5735525+pdobacz@users.noreply.github.com> --- EIPS/eip-7620.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-7620.md b/EIPS/eip-7620.md index 7a664ec2184361..560a9e01bc9563 100644 --- a/EIPS/eip-7620.md +++ b/EIPS/eip-7620.md @@ -74,7 +74,7 @@ Details on each instruction follow in the next sections. - caller's memory slice `[input_offset:input_size]` is used as calldata - execute the container and deduct gas for execution. The 63/64th rule from [EIP-150](./eip-150.md) applies. - increment `sender` account's nonce -- calculate `new_address` as `keccak256(0xff || sender || salt || keccak256(initcontainer))[12:]` +- calculate `new_address` as `keccak256(0xff || sender || salt)[12:]` - behavior on `accessed_addresses` and address collision is same as `CREATE2` (rules for `CREATE2` from [EIP-684](./eip-684.md) and [EIP-2929](./eip-2929.md) apply to `EOFCREATE`) - an unsuccessful execution of initcode results in pushing `0` onto the stack - can populate returndata if execution `REVERT`ed @@ -155,6 +155,16 @@ The data section is appended to during contract creation and also its size needs All of these alternatives either complicated the otherwise simple data structures or took away useful features (like the dynamically sized portion of the data section). +### `keccak256(initcontainer)` in the `new_address` hashing scheme + +`new_address = keccak256(0xff || sender || salt || keccak256(initcontainer))[12:]` was originally proposed as the way to calculate the address of newly created contract, similar, but not exactly equal, to what `CREATE2` uses. + +This alternative however goes against code non-observability, because it locks in the contents of the initcontainer e.g. preventing re-writing it in some future upgrade. It also seems unnecessarily expensive: `EOFCREATE` can only pick up one of its subcontainers, yet the hash value would need to be recalculated on every execution of `EOFCREATE`. + +Other ways of removing code observability, yet keeping some form of witness of the code, were considered. However, keeping only `sender` and `salt` allows the implementer of the factory contract (i.e. one containing the `EOFCREATE` instruction) to include the code witness via the `salt` anyway, if that's necessary for the particular use case. Therefore, keeping the `new_address` formula minimal is the most flexible approach with better separation of concerns. + +Leaving the `keccak256(initcontainer)` out of the `new_address` hash has also the benefit of making the `new_address` independent of the metadata section (proposed for the EOF in a separate EIP), which is a desired property. Unfortunately, if a factory wants to opt into committing to a particular `initcontainer`, it needs to include it in the `salt`, and that will include the metadata section. + ## Backwards Compatibility This change poses no risk to backwards compatibility, as it is introduced at the same time EIP-3540 is. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted), and the contract creation options do not change for legacy bytecode.