Update EIP-3540: limit container size to MAX_INITCODE_SIZE

Align with ipsilon/eof#125

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
 
@@ -238,6 +239,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.