Update EIP-7702: Remove delegation behavior of EXTCODE* #8969
Conversation
github-actions
bot
added
c-update
|
✅ All reviewers have approved. |
Change of behavior without DELEGATECALL is the new reality that EIP-7702 brings regardless of this PR change. Change of codehash is still possible after this PR, when changing EOA => delegated account. |
| @@ -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. | |||
There was a problem hiding this comment.
Post-merge nit: it would be slightly more helpful to group the instructions now in the executing and reading operations, like:
| 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. | |
| 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 reading instructions are impacted: `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, and the following executing instructions are impacted: `CALL`, `CALLCODE`, `STATICCALL`, `DELEGATECALL`, as well as transactions with `destination` targeting the code with delegation designation. |
| @@ -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. | |||
There was a problem hiding this comment.
Retrieving/reading seems to be mixed in this PR.
Also, note that it is possible to reset the account delegation by authorizing the zero address. It is thus possible to change the code hash, from the empty hash, to the 0xef01 hash, and then back to the empty hash. This is possible also after the first authorization (so in two txs). So this introduces a new way to "change" the code hash (from non-empty to empty, which does not have to be in the same tx).
|
|
||
| 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`. |
There was a problem hiding this comment.
| 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`. | |
| For example, `EXTCODESIZE` would return `3` (the size of `0xef0100`) 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`. |
The separator is defined as 0xef0100. Would it therefore not be logical that this seperator is the code which is being used? So EXTCODESIZE is 3, and EXTCODEHASH is keccak256("0xef0100").
There was a problem hiding this comment.
EOF uses the code 0xef00 when code is being read from EOF contracts (from legacy contracts), so it would be similar to use 0xef01 here. If we would use 3 bytes then in the future the 3rd zero byte in 0xef0100 could change, for instance to note versioning. It is then possible to change the output of EXTCODECOPY and EXTCODEHASH, which is what we want to mitigate here. So, using 0xef01 as code is fine.
* apply feedback from @jochem-brouwer in #8969 * add security consideration about storage * fix eip->erc * rename path erc->eip * rearrange for clarity
Proposal to address latest point brought up in EthMagicians.