Add EIP: EOF - EXTCODEADDRESS instruction

[shemnon]

Add an instruction to EOF that reads code delegation designations from the account without requiring code introspection.

[eth-bot]

File EIPS/eip-7880.md

Requires 1 more reviewers from @g11tech, @lightclient, @SamWilsn

[github-actions]

The commit 8c86b82 (as a parent of c6b3f75) contains errors.
Please inspect the Run Summary for details.

[Marchhill]

Forks are done based on timestamp rather than block number

[g11tech]

also we don't now mention a block num/timestamp constant which would need to be updated. we can say on activation of this EIP if this is just a standard timestamp hf activation, else just refer to FORK_TIMESTAMP if needed for a fork boundary logic

[shemnon]

Good catch. On deeper reflection referring to a specific activation block or timestamp is also not quite right, we should be referenceing the block the fork is activated, which will be different on mainnet, devnets, and L2s.

Reworded it to reference fork activation, agnostic of how it is activagted.

[pdobacz]

To me, the motivation skips the case, out of which the entire premise of delegation introspection came about: https://hackmd.io/@otim/H1Q7yCHDyl#Why-is-%E2%80%9Cdelegation-introspection%E2%80%9D-useful . Without EXTCODEADDRESS, when an untrusted 7702 address is called, that call can be frontrun with a SetCode tx making it point to a different, malicious implementation.

[pdobacz]

should it also be added in form of a note, that EXTCODEADDRESS belongs (somewhat awkwardly) to the group of code executing instructions, in the language of 7702

[gumb0]

I don't think it's necessary, and would be awkward indeed

[pdobacz]

Suggested change

	created: 2024-09-01
	created: 2025-02-08

[gumb0]

Suggested change

	- If `loaded_code` indicates a delegation designator (for example, `0xef0100` as defined in [EIP-7702]) push the address of the designation onto the stack.
	- If `loaded_code` indicates a delegation designator (for example, prefixed with `0xef0100` as defined in [EIP-7702]) push the address of the designation onto the stack.

[gumb0]

In case of delegation designator pointing to address mid-creation, it's true that EXTCODESIZE returns 0, but why would EXTCODEADDRESS do so? I think it should still return the delegate address.

Suggested change

	Note: If `target_address` or the delegation designator points to an account with a contract mid-creation then the code is empty and returns `0` (`TYPE_NONE`). This is aligned with similar behavior of instructions like `EXTCODESIZE`.
	Note: If `target_address` points to an account with a contract mid-creation then the code is empty and returns `0` (`TYPE_NONE`). This is aligned with similar behavior of instructions like `EXTCODESIZE`.

[pdobacz]

Good point, but I would even go further. If target_address points to an account with a contract mid-creation, it should return target_address, in line with the generic rule "Otherwise, push target_adress onto the stack." above.

I missed this on first read. EXTCODEADDRESS should by principle return the address which holds the code which would execute if target_address was CALLed, regardless of what that code is.

[gumb0]

EXTCODEADDRESS should by principle return the address which holds the code which would execute if target_address was CALLed, regardless of what that code is.

If it is called when delegate is mid-creation, empty code is executed, right? not the delegation designator interpreted as code.

[pdobacz]

right, but we're returning the address of that empty code, not the empty code. I'd say that mid-creationness should have nothing to do here, and this Note could be removed.

[gumb0]

right, but we're returning the address of that empty code, not the empty code.

This confused me, but my logic is:

• EXTCODEADDRESS(target) where target has regular code, returns target because CALL(target) executes target.code
• EXTCODEADDRESS(target) where target has delegation designator, returns delegate_address because CALL(target) executes delegate_address.code
• EXTCODEADDRESS(target) where target has delegation designator, but delegate_address is mid-creation, returns delegate_address because CALL(target) executes delegate_address.code (empty code), and not target.code (delegation designator)

[gumb0]

Good point, but I would even go further. If target_address points to an account with a contract mid-creation, it should return target_address

Ah yes, this I misdunderstood on the first read, actually I think I agree, so target_address should be returned in both these cases, but I would keep the note about it to be explicit.

[gumb0]

Suggested change

	Note: If `target_address` or the delegation designator points to an account with a contract mid-creation then the code is empty and returns `0` (`TYPE_NONE`). This is aligned with similar behavior of instructions like `EXTCODESIZE`.
	Note: If `target_address` points to an account with a contract mid-creation, then `target_address` is returned. If delegation designator points to an account with a contract mid-creation, then address of the designation is returned.

[pdobacz]

target_address should be returned in both these cases, but I would keep the note about it to be explicit.

Wait, no :). Your above 3 points seem correct to me, but not this (assuming you're referring to the original two cases in the Note). The mid-creation cases should just follow the general logic specced above (and to not confuse, we'd better remove the Note):

So:

• EXTCODEADDRESS(target) where target has delegation designator, but delegate_address is mid-creation, returns delegate_address, just like if delegate_address held empty code, code or another delegation
• otherwise EXTCODEADDRESS(target) where target is mid-creation, returns target, just like if target held empty code or code

Mid-creationnes has no effect, the only branch of the logic is on whether target.code has delegation designator or not.

[pdobacz]

Yea, your second suggested change looks ok to me (I'd still at least add that being midcreation has no effect whatsoever, in addition to the scenarios you've given).

[gumb0]

Suggested change

	[Ethereum Execution Layer Spec Constants] :https://github.com/ethereum/execution-specs/blob/1adcc1bfe774798bcacc685aebc17bd9935078c3/src/ethereum/cancun/vm/gas.py#L65-L66
	[Ethereum Execution Layer Spec Constants]: https://github.com/ethereum/execution-specs/blob/1adcc1bfe774798bcacc685aebc17bd9935078c3/src/ethereum/cancun/vm/gas.py#L65-L66