Update EIP-7702: Remove delegation behavior of EXTCODE*

Merged by EIP-Bot.

EIPS/eip-7702.md

@@ -13,7 +13,7 @@ requires: 2, 161, 1052, 2718, 2929, 2930, 3541, 3607
 
 ## Abstract
 
-Add a new transaction type that adds a list of `[chain_id, address, nonce, y_parity, r, s]` authorization tuples. For each tuple, write a delegation designator `(0xef0100 ++ address)` to the signing account's code. All code reading operations must load the code pointed to by the designator.
+Add a new transaction type that adds a list of `[chain_id, address, nonce, y_parity, r, s]` authorization tuples. For each tuple, write a delegation designator `(0xef0100 ++ address)` to the signing account's code. All code executing operations must load the code pointed to by the designator.
 
 ## Motivation
 
@@ -86,14 +86,12 @@ If transaction execution results in failure (any exceptional condition or code r
 
 ##### Delegation Designation
 
-The delegation designation uses the banned opcode `0xef` from [EIP-3541](./eip-3541.md) to designate the code has a special purpose. This designator requires all code retrieving operations to follow the address pointer to fill the account's observable code. The following instructions are impacted: `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, `CALL`, `CALLCODE`, `STATICCALL`, `DELEGATECALL`, as well as transactions with `destination` targeting the code with delegation designation..
+The delegation designation uses the banned opcode `0xef` from [EIP-3541](./eip-3541.md) to designate the code has a special purpose. This designator requires all code executing operations to follow the address pointer to get the account's executable code, and requires all other code reading operations to act only on the first 2 bytes of the designator (`0xef01`). The following instructions are impacted: `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, `CALL`, `CALLCODE`, `STATICCALL`, `DELEGATECALL`, as well as transactions with `destination` targeting the code with delegation designation.
 
-For example, `EXTCODESIZE` would return the size of the code pointed to by `address` instead of `23` which would represent the delegation designation. `CALL` would similarly load the code from `address` and execute it in the context of `authority`.
+For example, `EXTCODESIZE` would return `2` (the size of `0xef01`) instead of `23` which would represent the delegation designation, `EXTCODEHASH` would return `0xeadcdba66a79ab5dce91622d1d75c8cff5cff0b96944c3bf1072cd08ce018329` (`keccak256(0xef01)`), and `CALL` would load the code from `address` and execute it in the context of `authority`.
 
 In case a delegation designator points to a precompile address, retrieved code is considered empty and `CALL`, `CALLCODE`, `STATICCALL`, `DELEGATECALL` instructions targeting this account will execute empty code, i.e. succeed with no execution given enough gas.
 
-`EXTCODEHASH` instruction in line with [EIP-1052](./eip-1052.md) puts `0` on stack if delegation designation target does not exist in the trie, or is empty as defined by [EIP-161](./eip-161.md). Emptiness is determined using nonce, balance and code of delegation designation target account. In case target is not empty, but has empty code, keccak256 hash of empty data is put on stack.
-
 In case a delegation designator points to another designator, creating a potential chain or loop of designators, clients must retrieve only the first code and then stop following the designator chain.
 
 #### Gas Costs
@@ -204,6 +202,10 @@ For most intents and purposes, an account delegated to `0x0` is indistinguishabl
 
 This is not ideal and may be a significant enough concern to impact the overall adoption of the EIP. For these reasons, we have opted to include a mechanism which allow users to restore their EOA to its original pureness.
 
+### Delegation of code execution only
+
+Other code retrieving operations like `EXTCODEHASH` do not automatically follow delegations, they operate on the delegation designator itself. If instead delegations were followed, an account would be able to temporarily masquerade as having a particular codehash, which would break contracts that rely on codehashes as an indicator of possible account behavior. A change of behavior in a contract is currently only possible if its code explicitly allows it (in particular via `DELEGATECALL`), and a change of codehash is only possible in the presence of `SELFDESTRUCT` (and as of Cancun only in the same transaction as contract creation), so choosing to follow delegations in `EXTCODE*` opcodes would have created a new type of account that broke prior assumptions.
+
 ## Backwards Compatibility
 
 This EIP breaks the invariant that an account balance can only decrease as a result of transactions originating from that account. It also breaks the invariant that an EOA nonce may not increase after transaction execution has begun. These breakages have consequences for mempool design, and for other EIPs such as inclusion lists. However, because the accounts are listed statically in the outer transaction, it is possible to modify transaction propagation rules so that conflicting transactions are not forwarded.