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-7702: 7702 validity #8845

Merged
merged 3 commits into from
Sep 12, 2024

Conversation

lightclient
Copy link
Member

@lightclient lightclient commented Aug 30, 2024

Repost from #8840 as it should not have automatically merged.

The past few weeks we've been discussing validity conditions for 7702 transactions. Originally @rakita added the decoding limits for auth list items in #8746. Now we're looking at further constraining validity in #8833 to disallow chain ids other than zero or the current chain's id.

My philosophy here is 1) tx validity should be as simple as possible to ascertain and 2) we should retain as much similarity across tx types as possible.

The motivation for 1) is that tx originators are incentivized to not send junk authorizations with their txs, therefore they won't. What's the point of adding more constraints into the protocol when they aren't necessary?

For 2), I believe it's extremely important to follow existing conventions when possible. If every single tx type is designed as an ornate protocol fixture by core devs of that era, we will have a mess of formats that are extremely difficult to reason about as a whole or onboard new developers to understanding. Of course this doesn't mean we shouldn't improve the status quo when possible (see: separating chain id back out from v value), but unless the benefit is significant, let's not deviate from other tx formats.

@github-actions github-actions bot added c-update Modifies an existing proposal s-review This EIP is in Review t-core labels Aug 30, 2024
@eth-bot
Copy link
Collaborator

eth-bot commented Aug 30, 2024

✅ All reviewers have approved.

@eth-bot eth-bot changed the title 7702 validity Update EIP-7702: 7702 validity Aug 30, 2024
@rakita
Copy link
Contributor

rakita commented Aug 30, 2024

My stance on this is:

  • Sanity limits need to be made. We i think all agree on this.
  • @jochem-brouwer asked to add checks on s-value and v. I don't have a stance on this.
    • But If s-value and v are checked, I would request that we add the check for chain_Id

Side question for this PR, why not use u8 for v?

@lightclient
Copy link
Member Author

Agree sanity limits need to exist, I just think we should keep them minimal and inline with existing types.

But If s-value and v are checked, I would request that we add the check for chain_Id

All of these things should be checked, they just shouldn't affect the transactions validity.

why not use u8 for v?

We bound v < 2**256-1 everywhere else, it seems weird to do something different here.

```python
assert auth.chain_id < 2**256
assert auth.nonce < 2**64
assert len(auth.address) == 20
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't it be len(auth.address)<=20 ?

Copy link
Member Author

Choose a reason for hiding this comment

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

no, address is a fixed length item.

EIPS/eip-7702.md Outdated Show resolved Hide resolved
Co-authored-by: Mario Vega <[email protected]>
somnathb1 pushed a commit to erigontech/erigon that referenced this pull request Sep 12, 2024
Check (in the txpool and in the main code) that an EIP-7702 transaction
is
[valid](https://eips.ethereum.org/EIPS/eip-7702#set-code-transaction),
namely that:

- `to != nil`
- `len(authorization_list) != 0`
- `authorization.chain_id` is `uint256`
- `authorization.nonce` is `uint64`
- `authorization.address` is `bytes20`
- `authorization.y_parity == 0 || authorization.y_parity == 1`
- `authorization.r` is `uint256`
- `authorization.s` is `uint256` and `authorization.s <= secp256k1n/2`

This PR doesn't implement ethereum/EIPs#8865 or
ethereum/EIPs#8845
somnathb1 pushed a commit to erigontech/erigon that referenced this pull request Sep 12, 2024
Check (in the txpool and in the main code) that an EIP-7702 transaction
is
[valid](https://eips.ethereum.org/EIPS/eip-7702#set-code-transaction),
namely that:

- `to != nil`
- `len(authorization_list) != 0`
- `authorization.chain_id` is `uint256`
- `authorization.nonce` is `uint64`
- `authorization.address` is `bytes20`
- `authorization.y_parity == 0 || authorization.y_parity == 1`
- `authorization.r` is `uint256`
- `authorization.s` is `uint256` and `authorization.s <= secp256k1n/2`

This PR doesn't implement ethereum/EIPs#8865 or
ethereum/EIPs#8845
@lightclient
Copy link
Member Author

Seems like there was good support for this in ACDE 196. Still need to look more into constraining the v value, but this PR can be merged in the meantime.

@lightclient lightclient marked this pull request as ready for review September 12, 2024 21:37
@lightclient lightclient merged commit 223985b into ethereum:master Sep 12, 2024
15 checks passed

```python
assert auth.chain_id < 2**256
assert auth.nonce < 2**64
Copy link
Member

Choose a reason for hiding this comment

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

Have a slight nit about this. (Sorry, just noticed after-merge). By https://eips.ethereum.org/EIPS/eip-2681 should this not be 2**64 - 1? Or is this checkout outside tx validity, but instead inside EVM?

Copy link
Member

Choose a reason for hiding this comment

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

It is, but specific to the tx sender. The idea here is to only give numeric boundaries here and leave interpretation to other subsystems.

Copy link
Member

Choose a reason for hiding this comment

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

It is, but specific to the tx sender.

The nonce of authority is also incremented during delegation setting, so it is important to check nonce < 2**64 - 1 here.

I've made this change in #8905

@ethereum ethereum deleted a comment from GIgako19929 Oct 11, 2024
@ethereum ethereum deleted a comment from GIgako19929 Oct 11, 2024
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-review This EIP is in Review t-core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants