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.

Sign up for GitHub

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

Jump to bottom

Update EIP-7702: 7702 validity #8845

Merged
merged 3 commits into from
Sep 12, 2024
Merged

Update EIP-7702: 7702 validity #8845

merged 3 commits into from
Sep 12, 2024
+12 −9

Conversation

lightclient
Copy link
Member

@lightclient lightclient commented Aug 30, 2024 •
edited
Loading

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 •
edited
Loading

✅ All reviewers have approved.

@lightclient lightclient mentioned this pull request Aug 30, 2024
Merged
@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.

drortirosh
drortirosh reviewed Sep 3, 2024
View reviewed changes
EIPS/eip-7702.md
```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.

Copy link

Choose a reason for hiding this comment

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

bc1qgllxt924vznatgz7n4y8tj6g84umjtjusgrrc5

Copy link

Choose a reason for hiding this comment

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

bc1qgllxt924vznatgz7n4y8tj6g84umjtjusgrrc5

marioevz
marioevz reviewed Sep 6, 2024
View reviewed changes
EIPS/eip-7702.md Outdated Show resolved Hide resolved
@lightclient @marioevz
typo
e4dd6f7 
Co-authored-by: Mario Vega <[email protected]>
@lightclient lightclient mentioned this pull request Sep 9, 2024
Closed
@yperbasis yperbasis mentioned this pull request Sep 11, 2024
Merged
somnathb1 pushed a commit to erigontech/erigon that referenced this pull request Sep 12, 2024
@yperbasis
Stricter validation of EIP-7702 transactions (#11885)
60675ae 
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
@yperbasis @somnathb1
Stricter validation of EIP-7702 transactions (#11885)
6230069 
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
@petertdavies petertdavies mentioned this pull request Sep 12, 2024
Merged
@gumb0 gumb0 mentioned this pull request Sep 12, 2024
Open
@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
jochem-brouwer
jochem-brouwer reviewed Sep 13, 2024
View reviewed changes
EIPS/eip-7702.md

```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

@buddh0 buddh0 mentioned this pull request Sep 18, 2024
Draft
@onbjerg onbjerg mentioned this pull request Sep 23, 2024
Open
@marioevz marioevz mentioned this pull request Sep 25, 2024
Draft
23 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@chfast chfast chfast left review comments

@gumb0 gumb0 gumb0 left review comments

@marioevz marioevz marioevz left review comments

@jochem-brouwer jochem-brouwer jochem-brouwer left review comments

@drortirosh drortirosh drortirosh left review comments

@GIgako19929 GIgako19929 GIgako19929 left review comments

@eth-bot eth-bot Awaiting requested review from eth-bot eth-bot is a code owner

Assignees
No one assigned
Labels
c-update Modifies an existing proposal s-review This EIP is in Review t-core
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
9 participants
@lightclient @eth-bot @rakita @chfast @gumb0 @marioevz @jochem-brouwer @drortirosh @GIgako19929