Update EIP-3540: align with recent clarifications and updates

Merged by EIP-Bot.

EIPS/eip-3540.md

@@ -164,6 +164,7 @@ The following validity constraints are placed on the container format:
 - `container_size` may not be `0`
 - data section is mandatory, but `data_size` may be `0`
 - data body length may be shorter than `data_size` for a not yet deployed container
+- the total size of a container must not exceed `MAX_INITCODE_SIZE` (as defined in [EIP-3860](./eip-3860.md))
 
 ### Changes to execution semantics
 
@@ -180,6 +181,8 @@ For a legacy contract:
 - If the target account of `EXTCODEHASH` is an EOF contract, then it will return `0x9dbf3648db8210552e9c4f75c6a1c3057c0ca432043bd648be15fe7be05646f5` (the hash of `EF00`, as if that would be the code).
 - If the target account of `EXTCODESIZE` is an EOF contract, then it will return 2.
 
+**NOTE** Like for legacy targets, the aforementioned behavior of `EXTCODECOPY`, `EXTCODEHASH` and `EXTCODESIZE` does not apply to EOF contract targets mid-creation, i.e. those report same as accounts without code.
+
 ## Rationale
 
 EVM and/or account versioning has been discussed numerous times over the past years. This proposal aims to learn from them.
@@ -236,6 +239,12 @@ See section [Lack of `EXTDATACOPY` in EIP-7480](./eip-7480.md#lack-of-extdatacop
 
 Currently contracts can selfdestruct in three different ways (directly through `SELFDESTRUCT`, indirectly through `CALLCODE` and indirectly through `DELEGATECALL`). [EIP-3670](./eip-3670.md) disables the first two possibilities, however the third possibility remains. Allowing EOF1 contracts to only `DELEGATECALL` other EOF1 contracts allows the following strong statement: EOF1 contract can never be destructed. Attacks based on `SELFDESTRUCT` completely disappear for EOF1 contracts. These include destructed library contracts (e.g. Parity Multisig).
 
+### EOF1 containers have a size limit
+
+Imposing an EOF-validation time limit for the size of EOF containers provides a reference limit of how large the containers should EVM implementations be able to handle when validating and processing containers. `MAX_INITCODE_SIZE` was chosen for EOF1, as it is what contract creation currently allows for.
+
+Given one of the main reasons for the limit is to avoid attack vectors on `JUMPDEST`-analysis, and EOF removes the need for `JUMPDEST`-analysis and introduces a cost structure for deploy-time analysis, in the future this limit could be increased or even lifted for EOF.
+
 ## Backwards Compatibility
 
 This is a breaking change given that any code starting with `0xEF` was not deployable before (and resulted in exceptional abort if executed), but now some subset of such codes can be deployed and executed successfully.