Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EIP-3540: align with recent clarifications and updates #8670

Merged
merged 3 commits into from
Jun 20, 2024
Merged

Update EIP-3540: align with recent clarifications and updates #8670

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7a2e811
Update EIP-3540: note on mid-creation EXTCODE* behavior
pdobacz Jun 13, 2024
38bd7fa
Update EIP-3540: limit container size to `MAX_INITCODE_SIZE`
pdobacz Jun 13, 2024
06b5075
Update EIPS/eip-3540.md
pdobacz Jun 20, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions EIPS/eip-3540.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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.
Expand Down Expand Up @@ -236,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, as it is what contract creation currently allows for.
pdobacz marked this conversation as resolved.
Show resolved Hide resolved

## 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.
Expand Down
Loading