Skip to content

Update EIP-7761: clarify how EXTCODETYPE deals with EOF versions #9591

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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
+8 −1
Draft

Update EIP-7761: clarify how EXTCODETYPE deals with EOF versions #9591

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
9 changes: 8 additions & 1 deletion EIPS/eip-7761.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,7 @@ EOF code which contains this instruction before `FORK_BLKNUM` is considered inva
- If `loaded_code` indicates a delegation designator (for example, `0xef0100` as defined in [EIP-7702]),
- replace `loaded_code` with the delegated code.
- deduct gas in accordance with the delegation designation rules
- If `loaded_code` indicates an EOFv1 packaged contract (starts with the bytes `0xef0001`) push `TYPE_EOF_CONTRACT` onto the stack and stop processing the operation
- If `loaded_code` indicates an EOF packaged contract (starts with the bytes `0xef00`) push `TYPE_EOF_CONTRACT` onto the stack and stop processing the operation
- Otherwise, push `TYPE_LEGACY_CONTRACT` onto the stack and stop processing the operation

Note: if there is not enough gas to deduct for delegation designation the whole message frame will halt, making updating the `accessed_addresses` irrelevant.
Expand All @@ -68,6 +68,13 @@ Note: If `target_address` or the delegation designator points to an account with

## Rationale

### Commit to not discriminate between EOF versions

`EXTCODETYPE` could be specced out to say that it returns `TYPE_EOF_CONTRACT` for EOFv1 contracts (starting with bytes `0xef0001`), therefore committing to return different values for future versions of EOF (presumably `TYPE_EOF_CONTRACT + 1` for a hypothetical EOFv2).

It is cleaner to commit to the opposite - that the return value of `EXTCODETYPE` will not change for targets having a newer version of EOFv1. Otherwise, contract developers coding against EOFv1 will face the dilemma of whether to compare `EXTCODETYPE == 2` or `EXTCODETYPE >= 2` to check for EOF.
In the unlikely event that discrimination between EOF versions is absolutely necessary for EOFv2, this could be handled by an extra opcode like `EXTEOFVERSION`, or, EOFv2 contracts may have `EXTCODETYPE` gain the ability to tell EOFv1 from EOFv2, while EOFv1 will not do so.

### Alternative solutions

There have been other solutions proposed to alleviate the problems related to lack of code introspection required for ERC-721 and ERC-1155 standards:
Expand Down