Update EIP-7761: Change HASCODE to EXTCODETYPE #9229
Conversation
Change the EIP to return the type of the account (EOA, Legacy Code, EOFv1 code) instead of a boolean has/no code. Expand upon these decisions in the rationale and motivation.
github-actions
bot
added
c-update
|
✅ All reviewers have approved. |
eth-bot
changed the title
|
The commit aa8f602 (as a parent of 79737db) contains errors. |
| - `safeTransfers` to contract accounts call an `onERC721Received` (`onERC1155Received`) on them and expect to get a special magic return value, otherwise the transfer reverts (on the assumption that such a receipient may not be able to interact with the token) | ||
| - `safeTransfers` to contract accounts call an `onERC721Received` (`onERC1155Received`) on them and expect to get a special magic return value, otherwise the transfer reverts (on the assumption that such a recipient may not be able to interact with the token) | ||
|
|
||
| Appliction and library developers are also concerned about dynamic proxies written in EOF accidentally pointing to legacy accounts which cannot safely be called with EXTDELEGATECALL. They would like a way to differentiate between EOF and legacy contracts. |
There was a problem hiding this comment.
| Appliction and library developers are also concerned about dynamic proxies written in EOF accidentally pointing to legacy accounts which cannot safely be called with EXTDELEGATECALL. They would like a way to differentiate between EOF and legacy contracts. | |
| Application and library developers are also concerned about dynamic proxies written in EOF accidentally pointing to legacy accounts which cannot safely be called with EXTDELEGATECALL. They would like a way to differentiate between EOF and legacy contracts. |
| - deduct `GAS_COLD_ACCOUNT_ACCESS - GAS_WARM_ACCESS` if `target_address` is not in `accessed_addresses` and add `target_address` to `accessed_addresses` | ||
| - push `1` onto the stack if `target_address.code` is not empty, `0` otherwise | ||
| - Load the code from `target_address` and refer to it as `loaded_code` | ||
| - if `loaded_code` is empty (does not exist or has zero length), push `ACCOUNT_TYPE_EOA` onto the stack and stop processing the operation |
There was a problem hiding this comment.
"EOA" seems inaccurate since there isn't necessarily a private key owning the account.
Perhaps TYPE_EMPTY or TYPE_NULL?
There was a problem hiding this comment.
Hmm... yes. Because an account can gain code.
It's not an empty account, those are accounts without balance, code, or nonce. It may have balance.
I'm thinking TYPE_NONE - code type is it has no code.
This also make the name EXTCODETYPE better than ACCOUNTTYPE, because accounts shouldn't change type?
There was a problem hiding this comment.
TYPE_NONE is good! And yes I think EXTCODETYPE is a good name.
|
|
||
| Because of the requirement that EOF proxy contracts be able to determine if the new target is safe we cannot return a value for indicating that the account itself is delegated without also providing the delegated address. Instead, we return the code for the account that has the delegated code, applying the delegation. This is because the executable code is what matters for proxy updates. | ||
|
|
||
| This differs from EXTCODECOPY and EXTCODEHASH behavior which do return a hash and short code indicating the proxy. |
There was a problem hiding this comment.
A suggestion:
| This differs from EXTCODECOPY and EXTCODEHASH behavior which do return a hash and short code indicating the proxy. | |
| This differs from EXTCODECOPY and EXTCODEHASH behavior which do return a hash and short code indicating the proxy. While EXTCODETYPE is a "code reading operation" its purpose is to describe the execution behavior of the account. |
This references this part of the EIP-7702 spec:
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).
| | `TYPE_EOA` | 0 | | ||
| | `TYPE_LEGACY_CONTRACT` | 1 | | ||
| | `TYPE_EOF_CONTRACT` | 2 | |
There was a problem hiding this comment.
The spec below uses ACCOUNT_TYPE_* constants.
Change the EIP to return the type of the account (EOA, Legacy Code, EOFv1 code) instead of a boolean has/no code.
Expand upon these decisions in the rationale and motivation.
ATTENTION: ERC-RELATED PULL REQUESTS NOW OCCUR IN ETHEREUM/ERCS
--
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: