-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update EIP-4762: tweaks to support 7702 #8896
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com>
✅ All reviewers have approved. |
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, its done is a different way and i dont understand the reason behind that
we charge the PER_EMPTY_ACCOUNT_COST
always and then refund PER_AUTH_BASE_COST
if the account exists
looking at how the gas costs are implemented in this EIP. I think we should keep the gas costs as it is and deal with them in the way we deal with intrisic gas costs for transactions right now
(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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_DATA
of 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why there is a need for this
CODEHASH_LEAF_KEY
of 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is CODE_OFFSET
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CODE_OFFSET
is defined in eip-6800 at 128
: it's the start of the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i.e. the first code chunk is being read
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bc1qdfs6vkttw7fj7t4m73humszxmgeq78a8we4ncf that's my address wallet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😃
What dose this mean |
Okay 👍
…On Mon, Sep 23, 2024, 10:05 PM beage666 ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In EIPS/eip-4762.md
<#8896 (comment)>:
> @@ -186,13 +196,37 @@ If `value` is non-zero:
(tx.target, 0, BASIC_DATA_LEAF_KEY)
```
+#### Setcode transactions
+
+For EIP-7702 transactions, for each `[[chain_id, address, nonce, y_parity, r, s], ...]` entry in the authorization list, process the additional access events:
+
+```
+(address, 0, BASIC_DATA_LEAF_KEY)
+(address, 0, CODEHASH_LEAF_KEY)
+(address, 0, CODE_OFFSET)
bc1qdfs6vkttw7fj7t4m73humszxmgeq78a8we4ncf that's my address wallet
—
Reply to this email directly, view it on GitHub
<#8896 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJB7T4MVJRVNOBI2I4W7GZLZYDCF3AVCNFSM6AAAAABOSC4FAOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGMRTHA2DONJXGI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
For EIP-7702 transactions, for each `[[chain_id, address, nonce, y_parity, r, s], ...]` entry in the authorization list, process the additional access events: | ||
|
||
``` | ||
(address, 0, BASIC_DATA_LEAF_KEY) | ||
(address, 0, CODEHASH_LEAF_KEY) | ||
(address, 0, CODE_OFFSET) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this does not look right to me, it should be authority
, insted of address
(address, 0, CODE_OFFSET) | ||
``` | ||
|
||
If `address` is not present in the state, also process the write event: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should always process the write event
(authority, 0, CODEHASH_LEAF_KEY)
### 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, its done is a different way and i dont understand the reason behind that
we charge the PER_EMPTY_ACCOUNT_COST
always and then refund PER_AUTH_BASE_COST
if the account exists
looking at how the gas costs are implemented in this EIP. I think we should keep the gas costs as it is and deal with them in the way we deal with intrisic gas costs for transactions right now
(address, 0, BASIC_DATA_LEAF_KEY) | ||
(address, 0, CODE_OFFSET) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(address, 0, BASIC_DATA_LEAF_KEY) | |
(address, 0, CODE_OFFSET) | |
(authority, 0, BASIC_DATA_LEAF_KEY) | |
(authority, 0, CODE_OFFSET) | |
(authority, 0, CODEHASH_LEAF_KEY) |
(address, 0, BASIC_DATA_LEAF_KEY) | ||
(address, 0, CODEHASH_LEAF_KEY) | ||
(address, 0, CODE_OFFSET) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(address, 0, BASIC_DATA_LEAF_KEY) | |
(address, 0, CODEHASH_LEAF_KEY) | |
(address, 0, CODE_OFFSET) | |
(authority, 0, BASIC_DATA_LEAF_KEY) | |
(authority, 0, CODEHASH_LEAF_KEY) | |
(authority, 0, CODE_OFFSET) |
This is a proposed tweak to the stateless gas costs EIP in order to take into account the extra cases introduced in EIP 4762.