Apply suggestions from code review

Co-authored-by: Andrei Maiboroda <andrei@ethereum.org>

EIPS/eip-7620.md

@@ -21,6 +21,8 @@ This EIP uses terminology from the [EIP-3540](./eip-3540.md) which introduces th
 
 EOF aims to remove code observability, which is a prerequisite to legacy EVM contract creation logic using legacy-style create transactions, `CREATE` or `CREATE2`, because both the initcode and code are available to the EVM and can be manipulated. On the same premise, EOF removes opcodes like `CODECOPY` and `EXTCODECOPY`, introducing EOF subcontainers as a replacement to cater for factory contracts creating other contracts.
 
+The new instructions introduced in this EIP operate on EOF containers enabling factory contract use case that legacy EVM has.
+
 ## 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.
@@ -51,7 +53,7 @@ We introduce two new instructions on the same block number [EIP-3540](./eip-3540
 
 In EOF EVM, new bytecode is delivered by means of creation transactions (with an empty `to`) in the form of an EOF container (`initcontainer`). Such a container may contain arbitrarily deeply nesting subcontainers. The `initcontainer` and its subcontainers are recursively validated according to all the validation rules applicable for the EOF version in question. Next, the 0th code section of the `initcontainer` is executed and may eventually call a `RETURNCONTRACT` instruction, which will refer to a subcontainer to be finally deployed to an address.
 
-EOF creation transactions (ones with an empty `to` and with `data` starts with `EF00` magic) are specced out in detail in a separate EIP.
+EOF creation transactions (ones with an empty `to` and with `data` starting with `EF00` magic) are defined in detail in a separate EIP.
 
 `EOFCREATE` instruction is in turn a replacement of the `CREATE` and `CREATE2` legacy instructions allowing factory contracts to create other contracts. The main difference to the creation transaction is that the `initcontainer` is selected to be one of the subcontainers of the EOF container calling `EOFCREATE`. It is worth noting that no validation is performed at this point, as it has already been done when the factory contract containing `EOFCREATE` was deployed.