Skip to content

Update EIP-7702: Do not allow authorization nonce equal to 2**64 - 1#8905

Closed
gumb0 wants to merge 3 commits intoethereum:masterfrom
ipsilon:eip7702-nonce-overflow
Closed

Update EIP-7702: Do not allow authorization nonce equal to 2**64 - 1#8905
gumb0 wants to merge 3 commits intoethereum:masterfrom
ipsilon:eip7702-nonce-overflow

Conversation

@gumb0
Copy link
Copy Markdown
Member

@gumb0 gumb0 commented Sep 25, 2024

It is important to not allow authorization.nonce == 2**64 - 1, because in this case incrementing authority nonce will result in nonce overflowing 64 bit, which is not allowed since EIP-2681

Alternative to adding this to the transaction validity rules could be additional check during delegation setting, but it is simpler this way (fewer checks) and more aligned with existing transaction types validity. It is checked at authorization list processing now.

@gumb0 gumb0 requested a review from eth-bot as a code owner September 25, 2024 10:15
@github-actions github-actions bot added c-update Modifies an existing proposal s-review This EIP is in Review t-core labels Sep 25, 2024
@eth-bot
Copy link
Copy Markdown
Collaborator

eth-bot commented Sep 25, 2024

File EIPS/eip-7702.md

Requires 1 more reviewers from @adietrichs, @lightclient, @SamWilsn, @vbuterin

@lightclient
Copy link
Copy Markdown
Member

but it is simpler this way (fewer checks) and more aligned with existing transaction types validity.

Is this true? I feel like add bounds outside of basic type widths might add more complexity since it isn't natively part of decoding (e.g. value too big for type!).

@gumb0
Copy link
Copy Markdown
Member Author

gumb0 commented Sep 26, 2024

but it is simpler this way (fewer checks) and more aligned with existing transaction types validity.

Is this true? I feel like add bounds outside of basic type widths might add more complexity since it isn't natively part of decoding (e.g. value too big for type!).

I guess you're right, it's probably the same number of checks, so either extra check at transaction validity, or one at processing authorizations. I don't mind it either way.

@gumb0
Copy link
Copy Markdown
Member Author

gumb0 commented Sep 26, 2024

I changed it now to be checked at authorization list processing.

@lightclient
Copy link
Copy Markdown
Member

LGTM. Needs a rebase - I just did in in #8938. Closing

@lightclient lightclient closed this Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

a-review Waiting on author to review 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.

4 participants