Update EIP-7620: Move to Review

EIPS/eip-7620.md

@@ -26,6 +26,13 @@ The new instructions introduced in this EIP operate on EOF containers enabling f
 ## Specification
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+Wherever not explicitly listed, the rules of EOF contract creation, as well as the `EOFCREATE` instruction, should be identical or analogous to those of `CREATE2` instruction. This includes but is not limited to:
+
+- behavior on `accessed_addresses` and address collision ([EIP-684](./eip-684.md) and [EIP-2929](./eip-2929.md))
+- EVM execution frame created for the `EOFCREATE` initcode - memory, account context etc.
+- nonce bumping of the account of newly created contract [EIP-161](./eip-161.md)
+- balance checking and transfer for the creation endowment (`value` argument)
 
 ### Parameters
 
@@ -75,7 +82,6 @@ Details on each instruction follow in the next sections.
 - 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:]`
-- 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
 - a successful execution ends with initcode executing `RETURNCONTRACT{deploy_container_index}(aux_data_offset, aux_data_size)` instruction (see below). After that:
@@ -91,7 +97,7 @@ Details on each instruction follow in the next sections.
 - read immediate operand `deploy_container_index`, encoded as 8-bit unsigned value
 - pop two values from the operand stack: `aux_data_offset`, `aux_data_size` referring to memory section that will be appended to deployed container's data
 - cost 0 gas + possible memory expansion for aux data
-- ends initcode frame execution and returns control to EOFCREATE/4 caller frame where `deploy_container_index` and `aux_data` are used to construct deployed contract (see above)
+- ends initcode frame execution and returns control to EOFCREATE caller frame where `deploy_container_index` and `aux_data` are used to construct deployed contract (see above)
 - instruction exceptionally aborts if after the appending, data section size would overflow the maximum data section size or underflow (i.e. be less than data section size declared in the header)
 
 ### Code Validation

EIPS/eip-7698.md

@@ -4,7 +4,7 @@ title: EOF - Creation transaction
 description: Deploy EOF contracts using creation transactions
 author: Piotr Dobaczewski (@pdobacz), Andrei Maiboroda (@gumb0), Paweł Bylica (@chfast), Alex Beregszaszi (@axic)
 discussions-to: https://ethereum-magicians.org/t/eip-7698-eof-creation-transaction/19784
-status: Stagnant
+status: Review
 type: Standards Track
 category: Core
 created: 2024-04-24
@@ -23,6 +23,13 @@ The mechanism for providing constructor arguments to initcontainer is exactly th
 
 ## Specification
 
+Wherever not explicitly listed, the rules of EOF contract creation should be identical or analogous to those of legacy creation transaction. This includes but is not limited to:
+
+- behavior on `accessed_addresses` and address collision ([EIP-684](./eip-684.md) and [EIP-2929](./eip-2929.md))
+- EVM execution frame created for the initcode - memory, account context etc.
+- nonce bumping of the account of newly created contract [EIP-161](./eip-161.md)
+- balance checking and transfer for the creation endowment
+
 ### Parameters
 
 | Constant | Value |

EIPS/eip-7873.md

@@ -103,6 +103,13 @@ keccak256(INITCODE_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, ma
 The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`.
 
 ### Execution Semantics
+
+Wherever not explicitly listed, the rules of EOF contract creation, as well as the `TXCREATE` instruction, should be identical or analogous to those of `CREATE2` instruction. This includes but is not limited to:
+
+- behavior on `accessed_addresses` and address collision ([EIP-684](./eip-684.md) and [EIP-2929](./eip-2929.md))
+- EVM execution frame created for the `TXCREATE` initcode - memory, account context etc.
+- nonce bumping of the account of newly created contract [EIP-161](./eip-161.md)
+- balance checking and transfer for the creation endowment (`value` argument)
 
 Introduce a new instruction on the same block number [EIP-3540](./eip-3540.md) is activated on: `TXCREATE` (`0xed`).
 
@@ -127,7 +134,6 @@ Introduce a new instruction on the same block number [EIP-3540](./eip-3540.md) i
 - 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)[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 `TXCREATE`)
 - an unsuccessful execution of initcode results in pushing `0` onto the stack
     - can populate returndata if execution `REVERT`ed
     - `sender`'s nonce stays updated
@@ -212,8 +218,6 @@ This change poses no risk to backwards compatibility, as it is introduced at the
 
 Needs discussion.
 
-<!-- TODO --> 
-
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).