test: Regression-test top-level tx execution at sender nonce 2^64-2#1608
Merged
chfast merged 1 commit intoJul 22, 2026
Merged
Conversation
Member
|
Thanks for the report and test. I'm aware of the issue, but it may take some time to fix it (it has lower priority due to unrachability in real networks). |
Contributor
Author
chfast
force-pushed
the
add-regression-test-nonce-max-minus-1-tx
branch
2 times, most recently
from
July 22, 2026 17:44
3596179 to
c55fd60
Compare
Per EIP-2681 only a transaction with nonce >= 2^64-1 is invalid; an account nonce that merely reaches 2^64-1 during an otherwise valid transaction must not abort execution. Before ipsilon#1589 the create-address host path re-checked the sender nonce against MAX_NONCE for every depth-0 message, after transition() had already bumped it, so a top-level CALL or CREATE from a sender at 2^64-2 (ipsilon#1495) -- and a set-code tx whose self-signed authorization bumps the sender to 2^64-1 (ipsilon#1496) -- were wrongly aborted as light failures. ipsilon#1589 dissolved that host path, leaving the EIP-2681 check only in tx validation (pre-bump) and create_impl (nested CREATE), which incidentally fixed both cases. Add regression tests so a future refactor cannot silently reintroduce the abort: top-level CALL and CREATE at sender nonce MAX_NONCE - 1, and an EIP-7702 self-authorization that drives the sender to MAX_NONCE. The 7702 test asserts a storage write by the top-level callee, proving the call executed rather than being skipped. Co-authored-by: Ahmet <mail.a.cavdar@gmail.com>
chfast
force-pushed
the
add-regression-test-nonce-max-minus-1-tx
branch
from
July 22, 2026 18:00
c55fd60 to
d0563c1
Compare
2 tasks
LouisTsai-Csie
pushed a commit
to ethereum/execution-specs
that referenced
this pull request
Jul 24, 2026
Add regression tests verifying that reaching the maximum account nonce (2**64-1) during execution is valid: per EIP-2681 only a transaction whose nonce is 2**64-1 is invalid, not one that merely increments an account to that value. Ported from ipsilon/evmone#1608: * top-level CALL from a sender at nonce 2**64-2 * top-level CREATE from a sender at nonce 2**64-2 (created-account nonce fork-gated per EIP-161) * EIP-7702 self-sponsored set-code tx whose authorization drives the sender to 2**64-1
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1495 (I think — see note below).
A top-level CALL or CREATE transaction from a sender at nonce
2^64-2mustexecute normally; only
nonce == 2^64-1is invalid per EIP-2681. #1495reported that evmone incorrectly aborted such transactions as a "light
failure" after bumping the sender's nonce.
I could not reproduce the bug on current
master. It looks like it wasfixed incidentally by #1589 ("Compute the create address in the VM"),
which moved the EIP-2681 nonce check out of the path shared by all
depth-0 messages and into
create_impl, which only runs for nested,bytecode-triggered
CREATE/CREATE2. That PR doesn't mention #1495 orEIP-2681, so this may be worth double-checking on your end.
Since there was no test covering this scenario, I added two (
CALLandCREATE, both at sender nonce2^64-2) so a future refactor can'tsilently reintroduce the bug.
Tested with
ctest -R "evmone/unittests": 1133/1133 passed.