From 1e05ba28aef2537495278a455849a23f71cc9bac Mon Sep 17 00:00:00 2001 From: pdobacz <5735525+pdobacz@users.noreply.github.com> Date: Thu, 20 Jun 2024 11:34:42 +0200 Subject: [PATCH] Update EIP-3540: align with recent clarifications and updates Merged by EIP-Bot. --- EIPS/eip-3540.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/EIPS/eip-3540.md b/EIPS/eip-3540.md index 137ecc2ae5d9ce..6b313505c75afa 100644 --- a/EIPS/eip-3540.md +++ b/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.