Skip to content
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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

gballet
Copy link
Member

@gballet gballet commented Sep 20, 2024

This is a proposed tweak to the stateless gas costs EIP in order to take into account the extra cases introduced in EIP 4762.

Signed-off-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com>
@github-actions github-actions bot added c-update Modifies an existing proposal s-draft This EIP is a Draft t-core labels Sep 20, 2024
@eth-bot
Copy link
Collaborator

eth-bot commented Sep 20, 2024

✅ All reviewers have approved.

@eth-bot eth-bot changed the title EIP-4762: tweaks to support 7702 Update EIP-4762: tweaks to support 7702 Sep 20, 2024
@@ -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:
Copy link
Member Author

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?

Suggested change
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`
Copy link
Member Author

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

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.
Copy link
Member Author

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?

Copy link
Contributor

@jsign jsign Sep 20, 2024

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)
Copy link
Contributor

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?

Copy link
Contributor

@jsign jsign Sep 20, 2024

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.

Copy link
Member Author

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is CODE_OFFSET?

Copy link
Member Author

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.

Copy link
Member Author

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😃

@beage666
Copy link

What dose this mean

@Scamreno
Copy link

Scamreno commented Sep 24, 2024 via email

Comment on lines +201 to +206
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)

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:

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`

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

Comment on lines +212 to +213
(address, 0, BASIC_DATA_LEAF_KEY)
(address, 0, CODE_OFFSET)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(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)

Comment on lines +204 to +206
(address, 0, BASIC_DATA_LEAF_KEY)
(address, 0, CODEHASH_LEAF_KEY)
(address, 0, CODE_OFFSET)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c-update Modifies an existing proposal s-draft This EIP is a Draft t-core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants