Update EIP-3540: limit container size to MAX_INITCODE_SIZE

Align with ipsilon/eof#125

EIPS/eip-3540.md

@@ -164,6 +164,8 @@ 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))
+    - **NOTE** this condition, in combination with the container format defined above, implies that validation should fail at the moment any section is found to be declared to end after the last byte of the container
 
 ### Changes to execution semantics
 
@@ -238,6 +240,10 @@ 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, but with the plan to increase in case the [EIP-3860](./eip-3860.md) limit is increased.
+
 ## 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.