Update EIP-4762: tweaks to support 7702 #8896
Conversation
Signed-off-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com>
github-actions
bot
added
c-update
|
✅ All reviewers have approved. |
eth-bot
changed the title
| @@ -62,10 +70,10 @@ If a `*CALL` or `SELFDESTRUCT` is value-bearing (ie. it transfers nonzero wei), | |||
|
|
|||
| Note: when checking for the existence of the `callee`, the existence check is done by validating that there is an extension-and-suffix tree at the corresponding stem, and does not rely on `CODEHASH_LEAF_KEY`. | |||
|
|
|||
| When calling `EXTCODEHASH`, process the access event: | |||
| When calling `*CALL`, `SELFDESTRUCT`, `EXTCODESIZE`, `EXTCODECOPY` or `EXTCODEHASH` on an EIP-7702 delegating contract, process the additional access event: | |||
There was a problem hiding this comment.
@lightclient in the case of a (same-tx) selfdestruct, and assuming it is executed by a delegating EoA, what is being destroyed? the EoA or the delegated contract? Presumably the former?
| When calling `*CALL`, `SELFDESTRUCT`, `EXTCODESIZE`, `EXTCODECOPY` or `EXTCODEHASH` on an EIP-7702 delegating contract, process the additional access event: | |
| When calling `*CALL`, `EXTCODESIZE`, `EXTCODECOPY` or `EXTCODEHASH` on an EIP-7702 delegating contract, process the additional access event: |
| ### Witness gas costs | ||
|
|
||
| Remove the following gas costs: | ||
|
|
||
| * Increased gas cost of `CALL` if it is nonzero-value-sending | ||
| * [EIP-2200](./eip-2200.md) `SSTORE` gas costs except for the `SLOAD_GAS` | ||
| * 200 per byte contract code cost | ||
| * `PER_EMPTY_ACCOUNT_COST` and `PER_AUTH_BASE_COST` |
There was a problem hiding this comment.
This is potentially a controversial move, but since we have the stateless costs to cover for the writes to the state, that should match. Currently, they are covered by the 21000 intrinsic gas. Are these extra costs related to the transaction itself, or the state being written?
- If it's the state being written, then I think we should drop them in verkle
- if it's to disincentivize growing the transaction payload, then this line needs to be removed.
| (address, 0, CODEHASH_LEAF_KEY) | ||
| ``` | ||
|
|
||
| Note: this latter access is mean to check whether the contract is a [EIP-7702](./eip-7702.md) contract, or an EOF contract. |
There was a problem hiding this comment.
So this is the weird bit, I am using the code hash to determine if it's a 7702 contract. Come to think of it, it should be reading the first code chunk directly because then you will also know what is the delegation address.
So yeah, the question is: apart from EXTCODEHASH, is there any reason to read the code hash for all these extra instructions?
There was a problem hiding this comment.
Yes, I believe we should ask to read the first code-chunk to check if there's a delegation. Also, it might worth clarifying (as 7702 does) that we shouldn't follow a chain of delegations.
So yeah, the question is: apart from EXTCODEHASH, is there any reason to read the code hash for all these extra instructions?
I don't think so, since if there's a delegation that's irrelevant?
Also, I'd recommend removing the EOF mentions in this PR.
|
|
||
| ``` | ||
| (address, 0, CODEHASH_LEAF_KEY) | ||
| (delegated_address, 0, CODEHASH_LEAF_KEY) |
There was a problem hiding this comment.
I'm a bit confused by this change.
For example, if you're executing an EXTCODESIZE as mentioned above:
- We should provide the first-code chunk to allow a stateless client to detect if there's a delegation and setup the right context of the target.
- If there is a delegation, we'll include the
BASIC_DATAof the delegated address which contains the code size.
Why there is a need for this CODEHASH_LEAF_KEY of the delegated address?
There was a problem hiding this comment.
More generally, I think we should only explain impact on the witness for the delegation resolving step. Then that might change the context of which address is used for the EXTCODEHASH/EXTCODESIZE/etc and simply apply already existing rules to include the witness for that address (which now can be address or delegated_address)
As in, the new 7702 rule is about right context setup of the target address. After that is done, the corresponding instructions should do what we already explained in the current version of the EIP.
We could try doing some renames to make this clear and always use (a new) target_address as the placeholder for 99% of witness addition rules. And explain what target_address is e.g: address if there's no delegation, or delegated_address. Food for thought.
There was a problem hiding this comment.
Why there is a need for this
CODEHASH_LEAF_KEYof the delegated address?
that's an open question for @lightclient but the idea was that you wouldn't read the code directly, but the code hash. I don't think it's a good idea after all, but I'm waiting on his input.
| ``` | ||
| (address, 0, BASIC_DATA_LEAF_KEY) | ||
| (address, 0, CODEHASH_LEAF_KEY) | ||
| (address, 0, CODE_OFFSET) |
There was a problem hiding this comment.
CODE_OFFSET is defined in eip-6800 at 128: it's the start of the code.
There was a problem hiding this comment.
i.e. the first code chunk is being read
This is a proposed tweak to the stateless gas costs EIP in order to take into account the extra cases introduced in EIP 4762.