Update EIP-7620: Remove initcode/runtime container definitions

Merged by EIP-Bot.

Author: pdobacz

EIPS/eip-7620.md

@@ -66,7 +66,7 @@ Details on each instruction follow in the next sections.
 - pop `value`, `salt`, `input_offset`, `input_size` from the operand stack
 - perform (and charge for) memory expansion using `[input_offset, input_size]`
 - load initcode EOF subcontainer at `initcontainer_index` in the container from which `EOFCREATE` is executed
-    - let `initcontainer_size` be the declared size of that EOF subcontainer in its parent container header
+    - let `initcontainer` be that EOF container, and `initcontainer_size` its length in bytes declared in its parent container header
 - deduct `GAS_KECCAK256_WORD * ((initcontainer_size + 31) // 32)` gas (hashing charge)
 - check that current call depth is below `STACK_DEPTH_LIMIT` and that caller balance is enough to transfer `value`
   - in case of failure return 0 on the stack, caller's nonce is not updated and gas for initcode execution is not consumed.
@@ -93,24 +93,16 @@ Details on each instruction follow in the next sections.
 - 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
-    
-
-For terminology purposes, the following concepts are defined:
-
-- an "initcode" container is one which does not contain `RETURN` or `STOP`
-- a "runtime" container is one which does not contain `RETURNCONTRACT`
-
-Note a container can be both "initcode" and "runtime" if it does not contain any of `RETURN`, `STOP` or `RETURNCONTRACT` (for instance, if its code sections terminate with `REVERT` or `INVALID`).
 
 We extend code section validation rules (as defined in [EIP-3670](./eip-3670.md)).
 
 1. `EOFCREATE` `initcontainer_index` must be less than `num_container_sections`
 2. `EOFCREATE` the subcontainer pointed to by `initcontainer_index` must have its `len(data_section)` equal `data_size`, i.e. data section content is exactly as the size declared in the header (see [Data section lifecycle](#data-section-lifecycle))
-3. `EOFCREATE` the subcontainer pointed to by `initcontainer_index` must be an "initcode" subcontainer
+3. `EOFCREATE` the subcontainer pointed to by `initcontainer_index` must not contain either a `RETURN` or `STOP` instruction
 4. `RETURNCONTRACT` `deploy_container_index` must be less than `num_container_sections`
-5. `RETURNCONTRACT` the subcontainer pointed to `deploy_container_index` must be a "runtime" subcontainer
+5. `RETURNCONTRACT` the subcontainer pointed to `deploy_container_index` must not contain a `RETURNCONTRACT` instruction
 6. It is an error for a container to contain both `RETURNCONTRACT` and either of `RETURN` or `STOP`
-7. It is an error for a subcontainer to never be referenced in code sections of its parent container
+7. It is an error for a subcontainer to never be referenced in its parent container
 8. `RJUMP`, `RJUMPI` and `RJUMPV` immediate argument value (jump destination relative offset) validation: code section is invalid in case offset points to the byte directly following either `EOFCREATE` or `RETURNCONTRACT` instruction.
 
 ### Data Section Lifecycle

EIPS/eip-7698.md

@@ -8,7 +8,7 @@ status: Review
 type: Standards Track
 category: Core
 created: 2024-04-24
-requires: 3540, 7620
+requires: 3540
 ---
 
 ## Abstract
@@ -39,7 +39,7 @@ In case a creation transaction (transaction with empty `to`) has `data` starting
     - Find `intcontainer` size by reading all section sizes from the header and adding them up with the header size to get the full container size.
 3. Validate the `initcontainer` and all its subcontainers recursively.
     - Unlike in general validation, `initcontainer` is additionally required to have `data_size` declared in the header equal to actual `data_section` size.
-    - Validation includes checking that the container is an "initcode" container as defined in [EIP-7620](./eip-7620.md), that is, it does not contain `RETURN` or `STOP`
+    - Validation includes checking that the `initcontainer` does not contain `RETURN` or `STOP`
 4. If EOF header parsing or full container validation fails, transaction is considered valid and failing. Gas for initcode execution is not consumed, only intrinsic creation transaction costs are charged.
 5. `calldata` part of transaction `data` that follows `initcontainer` is treated as calldata to pass into the execution frame.
 6. Execute the container and deduct gas for execution.
@@ -63,7 +63,7 @@ Originally it was proposed to deploy the first EOF contract via irregular state
 Alternative mechanism for providing constructor arguments to initcontainer execution was considered, where they are concatenated with data section of the initcontainer and are accessed via `DATA*` instructions instead of `CALLDATA*`. This has a benefit of not requiring the step finding the split of `transaction.data` into `initcontainer` and `calldata`, as entire `transaction.data` is an EOF container. However it was rejected for the following reasons:
 
 - Existing tooling could not be used for deploying EOF without modification. To construct EOF creation transaction, the tooling would need to append constructor arguments to the container, as well as update data section size in the EOF header. Compiler could predict the size of constructor arguments to put the anticipated data size in the header, but it would not be possible for variadic length constructor arguments.
-- In case a specialized EOF creation transaction is introduced in a later upgrade (such as `InitcodeTransaction` defined in [EIP-7620](./eip-7620.md)), it would have a dedicated field for initcontainer execution input (`calldata`), and it will be accessed with `CALLDATA*` instructions in initcode. It is better to avoid the situation where compilers would need to generate initcontainer code differently depending on which context it will be used in.
+- In case a specialized EOF creation transaction is introduced in a later upgrade (such as the `InitcodeTransaction`), it would have a dedicated field for initcontainer execution input (`calldata`), and it will be accessed with `CALLDATA*` instructions in initcode. It is better to avoid the situation where compilers would need to generate initcontainer code differently depending on which context it will be used in.
 - As a general argument, data section can be seen to contain the data that execution considers validated and being closely coupled with the code definition, whereas calldata is an input from the outside that may be arbitrary and not validated.
 
 ## Backwards Compatibility