Skip to content

Update EIP-3540: Restrict EOF version in create #6052

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

Merged
eth-bot merged 1 commit into from
Dec 1, 2022
Merged

Update EIP-3540: Restrict EOF version in create #6052

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
21 changes: 8 additions & 13 deletions EIPS/eip-3540.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -136,8 +136,10 @@ For clarity, the *container* refers to the complete account code, while *code* r

For clarity, the *EOF prefix* together with a version number *n* is denoted as the *EOFn prefix*, e.g. *EOF1 prefix*.

1. If *initcode's container* has EOF1 prefix it must be valid EOF1 code.
2. If *code's container* has EOF1 prefix it must be valid EOF1 code.
1. If *initcode's container* has EOF1 prefix it MUST be valid EOF1 code.
2. If *code's container* has EOF1 prefix it MUST be valid EOF1 code.
3. If *initcode's container* is valid EOF1 code the resulting *code's container* MUST be valid EOF1 code (i.e. it MUST NOT be empty and MUST NOT produce legacy code).
4. If `CREATE` or `CREATE2` instruction is executed in an EOF1 code the instruction's *initcode* MUST be valid EOF1 code (i.e. EOF1 contracts MUST NOT produce legacy code).

## Rationale

Expand Down Expand Up @@ -167,18 +169,11 @@ minimal set of restrictions related to the contract creation: if *initcode* or *
container prefix it must be validated. This adds two validation steps in the contract creation,
any of it failing will result in contract creation failure.

Since *initcode* and *code* are evaluated for EOF1 independently, number of interesting combinations are allowed:
Moreover, it is not allowed to create legacy contracts from EOF1 ones. And the EOF version of *initcode* must match the EOF version of the produced *code*.
The rule can be generalized in the future: EOFn contract must only create EOFm contracts, where m ≥ n.

- Create transaction with EOF1 *initcode* can deploy legacy contract,
- EOF1 contract can execute `CREATE` instruction with legacy *initcode* to create new legacy contract,
- Legacy contract can execute `CREATE` instruction with EOF1 *initcode* to create new EOF1 contract,
- Legacy contract can execute `CREATE` instruction with EOF1 *initcode* to create new legacy contract,
- etc.

To limit the number of exotic bytecode version combinations, additional restrictions are considered, but currently are not part of the specification:

1. The EOF version of *initcode* must much the version of *code*.
2. An EOF1 contract must not create legacy contracts.
This guarantees that a cluster of EOF contracts will never spawn new legacy contracts.
Furthermore, some exotic contract creation combinations are eliminated (e.g. EOF1 contract creating new EOF1 contract with legacy *initcode*).

Finally, create transaction must be allowed to contain legacy *initcode* and deploy legacy *code* because otherwise there is no transition period allowing upgrading transaction signing tools. Deprecating such transactions may be considered in the future.

Expand Down