中文版 · Blockchain learning guide
Blockchain learning · Extension BCX019
An application call can fail after an authorization list has already changed account nonces and code delegation. To reconstruct the result, first process the ordered list against the evolving account state. Only then apply the separate execution outcome.
This lesson gives you a complete fictional dossier: five accounts, seven ordered authorization rows, supplied signature outcomes and an unrelated catalogue call that reverts. The task is to calculate which rows apply, which skip, the state at execution entry, and the final projected state. A failure label by itself cannot answer those questions.
All addresses, code targets and stored values are symbolic. No signatures are generated or verified, no bytecode runs, and no wallet, key, asset or real transaction is involved. Nineteen finite cases and three early-gate probes check the teaching model; they are not client-conformance tests or a claim that every network supports this mechanism.
Choose your reading route
In this guide
- 1. Separate the sender, each authority and the execution destination
- 2. Establish the phase order before processing row one
- 3. Give every row an ordered set of gates
- 4. Process the seven-row dossier
- 5. Compare execution entry with the final failed result
- 6. Repeated authorities require sequential evaluation
- 7. Self-sponsorship uses the post-sender-increment nonce
- 8. Clearing code preserves the separately tracked storage
- 9. Distinguish envelope rejection from a skipped tuple
- 10. All-skipped lists can still reach application execution
- 11. Reproduce the nineteen cases and three early-gate probes
- 12. Exercises and model answers
- Sources and version notes
- For the main seven-row calculation, follow sections 1–5.
- For repeated authorities, reordered lists and self-sponsorship, read sections 6–7.
- For clearing and the important nonce boundaries, read sections 8–9.
- For reproducibility and a self-check, continue through sections 10–12.
The prerequisite account-state and transaction-nonce lesson covers ordinary sender sequencing. Diagnosing failed transactions covers rejection and execution failure. Both leave this authorization-list calculation outside their worked scope.
Back to contents · Next section
1. Separate the sender, each authority and the execution destination
The selected fictional chain has identifier 71. Sender P begins with nonce 7 and empty code. Authority A begins with nonce 3, an existing delegation to D0 and one stored value 5. B begins with nonce 9, empty code and stored value 2. C begins with nonce 2 and ordinary code; its stored value is 4.
The independent application T has ordinary code, nonce 1 and stored value 5. The outer type-4 transaction calls T, not A or B. D0, D1, D2 and D3 are symbolic code-pointer targets, not actual addresses or programs we execute.
An authorization row names a proposed target and nonce and supplies a cryptographic outcome. When that outcome succeeds, the dossier specifies the recovered authority. A failed-signature row can have a filing label associated with B, but that label is not evidence that B was recovered as its authority.
P is the outer sender; A or B can be an authority in individual rows; T is the application destination. Those roles need not coincide. Later we deliberately make P a listed authority to test what changes when they do coincide.
All omitted envelope, sender-eligibility, destination, resource and fork-support conditions are supplied valid, except where a control explicitly rejects the envelope. The model tracks nonce, code kind or pointer, one stored value per account and symbolic application logs. Gas, refunds and access warming are outside its projection.
Back to contents · Next section
2. Establish the phase order before processing row one
For an admitted outer transaction, increment the sender nonce first. P therefore moves from 7 to 8 before any authorization row is evaluated. That is a sender update, not a successful authorization for P.
Next, process authorization rows one at a time in their supplied order. Each row sees the state left by all earlier applied rows. Do not compare every row with the original account snapshot, and do not merge repeated authority entries into a single record.
Only after list processing does the application call to T begin. The execution-entry snapshot already contains the accepted authorization changes. In the main case, T writes its stored value from 5 to 99, emits T.changed, then reverts. The application effects are restored to that execution-entry snapshot.
This ordering follows the pinned Geth v1.16.5 state transition and its call snapshot boundary. It does not require inventing a separate transaction for each authorization row.
Your worksheet should have three checkpoints: initial state, execution-entry state and final state. If you keep only initial and final values, the application rollback may be mistaken for a rollback of preprocessing that happened before the call snapshot.
Back to contents · Next section
3. Give every row an ordered set of gates
The finite model first checks whether the row’s chain value is 0 or the selected chain 71. It then checks whether the tuple nonce is below the usable ceiling, and then uses the supplied signature outcome. Only a successful recovery allows the worksheet to look up the authority account.
After recovery, check that the authority’s code is empty or already a delegation. Ordinary code fails this eligibility condition. Next compare the tuple nonce with that authority’s current nonce. A matching eligible row updates the code pointer, or clears code for the special zero target, and advances the authority nonce by one.
A row that fails stops there and the list continues with the next row. In this projection, a skipped row does not change the tracked authority nonce or code. That is not a claim of zero gas, zero access warming or no other protocol processing. Late failure can occur after authority access is warmed, and included tuples still affect intrinsic charging.
Keep recovered-authority and account-before/account-after fields empty until recovery succeeds. For wrong-chain, unusable-nonce and failed-signature rows, the correct trace has no recovered authority or account snapshot. Filling those columns from a filing label would fabricate a processing step that was never reached.
The precise usable-nonce versus envelope-width distinction is developed in section 9. It is intentionally not collapsed into a single “bad nonce” category.
Back to contents · Next section
4. Process the seven-row dossier
Row 1 supplies A, nonce 3 and target D1, with the selected chain and successful recovery. A currently has an eligible delegation and nonce 3. The row applies: A becomes nonce 4 with pointer D1; its stored value remains 5.
Row 2 again supplies A nonce 3, now targeting D2. Recovery succeeds and A’s delegation remains eligible, but its current nonce is already 4. The row skips at nonce mismatch. A stays nonce 4 with D1. The later row did not automatically win merely because it was later.
Row 3 is filed with B nonce 9 and target D1, but uses chain value 72. It skips at the chain gate before signature recovery. The trace must not report B as a recovered authority. B’s tracked account remains nonce 9 with empty code.
Row 4 supplies A nonce 4 and target D2 on the selected chain. Its recovery succeeds; A’s current nonce is 4, so it applies. A becomes nonce 5 with pointer D2 and stored value 5.
Row 5 supplies a successful recovery of C, nonce 2 and target D1. C has ordinary code, so it fails code eligibility. It does not reach a successful nonce/code update. C remains nonce 2 with ordinary code and stored value 4.
Row 6 has a B-associated dossier label, nonce 9 and target D3, but its supplied signature result fails. No authority is recovered, and there is no account-before/account-after trace for this row. It cannot be described as a valid B authorization that merely failed to execute.
Row 7 successfully recovers B with nonce 9 and target D1 on the selected chain. B still has empty code and nonce 9, so the row applies. B becomes nonce 10 with pointer D1 and stored value 2.
The ordered outcomes are apply, nonce mismatch, wrong chain, apply, ordinary-code rejection, failed signature and apply. Three rows apply. A advances twice; B advances once; C does not advance. P has independently already advanced once as sender.
Back to contents · Next section
5. Compare execution entry with the final failed result
At execution entry, P has nonce 8. A has nonce 5, pointer D2 and stored value 5. B has nonce 10, pointer D1 and stored value 2. C is unchanged. T still has stored value 5.
Installing these delegation indicators did not automatically call D1 or D2 for every row. The supplied outer destination is T. Our exercise does not make an application call through A or B and does not simulate the code at any delegation target.
T now performs its stipulated write to 99 and symbolic emission T.changed, then reverts. Its final stored value returns to 5, its log does not survive, and the modeled receipt status is 0. The accepted preprocessing state remains: P nonce 8, A nonce 5/D2 and B nonce 10/D1.
Run a control with the identical list but successful T execution. The preprocessing result is identical. T instead ends at 99, T.changed survives and the modeled status is 1. In the tracked projection, changing this execution outcome changes only T’s effect and the application log/status result.
Thus a status-0 result is not enough to conclude that every account still has its initial nonce and code. Conversely, the persisted delegation is not proof that T’s intended application action succeeded. The worksheet deliberately reports these facts separately.
Persistence here means survival of this accepted transaction’s application failure. It does not mean immunity to later valid updates, chain reorganizations or every other possible state transition.
Back to contents · Next section
6. Repeated authorities require sequential evaluation
Reset A to nonce 3 and D0. Process A nonce 3 to D1, followed by A nonce 3 to D2. The first applies and advances A to 4; the second skips. The final pointer is D1, not D2. “Last valid occurrence” does not mean “last listed occurrence.”
Reset again and instead use consecutive nonces: A nonce 3 to D1, then A nonce 4 to D2. Both apply, producing nonce 5 and D2. The second row is valid because the first row established the nonce it needs.
Reverse that consecutive list while keeping the same initial snapshot. A nonce 4 to D2 comes first and skips because A is still at 3. Then A nonce 3 to D1 applies. The result is nonce 4 and D1. The skipped first row is not revisited after the nonce changes.
This is an ordered pass, not a sort, retry queue or search for a globally compatible subset. Deduplicating by authority, choosing the final target in advance or sorting by nonce would change the supplied procedure.
For a later-transaction control, start from the main case’s final state and submit the old A nonce-3 tuple in another otherwise admitted transaction from P. P advances from 8 to 9, while A remains nonce 5 with D2 because the old tuple is stale. Reusing an old authority tuple and repeating an entire outer transaction are distinct questions.
Back to contents · Next section
7. Self-sponsorship uses the post-sender-increment nonce
Reset P to nonce 7 with empty code and use P both as sender and as a listed authority. The admitted outer transaction first advances P to nonce 8. A row for P nonce 7 therefore skips at nonce mismatch.
A following row for P nonce 8 targeting D2 can apply, advancing P again to 9 and setting its pointer to D2. If the application call then reverts, the model still ends with P nonce 9 and D2.
If the list contained only the old nonce-7 row, P would end at nonce 8 with empty code. The sender increment still happened, but no P authorization applied. Counting rows instead of successful updates would predict the wrong final nonce.
This example gives two roles to one account without merging the phases. One increment comes from being the outer sender; another comes from the accepted authorization row. In the main case those increments affected different accounts, which made the distinction less obvious.
The arithmetic is supplied educational state processing, not a request to prepare or sign a self-sponsored transaction. No fee or sponsorship service is modeled.
Back to contents · Next section
8. Clearing code preserves the separately tracked storage
Reset A to nonce 3, pointer D0 and stored value 5. An eligible matching row with the special ZERO target clears A’s code and advances its nonce to 4. It does not replace the stored value 5 with zero.
Use a no-op application control: the final code is empty, nonce is 4 and stored value remains 5, with successful status. Use the unrelated T-revert control instead: the same clearing and nonce update survive, while T’s application write and log do not.
In another reset, clear A at nonce 3 and then apply a nonce-4 row delegating to D2. Both rows pass. A finishes at nonce 5 with pointer D2 and the same stored value 5.
These controls explain why the initial B account can have empty code and a nonzero stored value. Empty code is not a claim that every historical storage field has been erased. However, this lesson does not infer whether a later delegated program will interpret retained storage safely; that requires a separate program and layout analysis.
Clearing is still subject to the row’s earlier gates. Merely naming ZERO in a stale or invalid row does not guarantee any code change.
Back to contents · Next section
9. Distinguish envelope rejection from a skipped tuple
The model computes two selected envelope gates: a type-4 authorization list must not be empty, and each tuple nonce must fit within its field width. An empty list or tuple nonce equal to 2 to the power of 64 causes outer rejection in these controls.
For a rejected outer transaction, no sender increment or authorization processing occurs in the model. Its result has no receipt status rather than status 0. A separate supplied outer-invalid control produces the same lack of preprocessing. These are not a complete implementation of all transaction-validity rules.
Now define MAX as 2 to the power of 64 minus 1. A tuple nonce equal to MAX fits the field, but it is unusable for an authorization update that must advance the nonce. The outer transaction can be admitted while that row skips at the early nonce-limit gate. The sender still advances, and the application still reaches its supplied outcome.
For a sharper boundary, initialize A at MAX minus 1. A matching row can advance it to MAX and install D1. A following tuple at MAX skips and cannot replace D1 with D2. The last usable update is preserved even when the application later reverts.
The selected chain-zero control is also narrow: a row with chain value 0 passes that gate in the supplied chain context, subject to the remaining checks. This is not a claim that all networks implement the mechanism or that any real signature is valid.
Back to contents · Next section
10. All-skipped lists can still reach application execution
Reset the main initial state and use three rows: a wrong-chain row, a failed-signature row and an ordinary-code C row. Every row skips. The outer transaction nevertheless has a nonempty list and is otherwise supplied valid.
P advances to 8; A remains nonce 3 with D0. If T’s supplied execution succeeds, T becomes 99, its symbolic log survives and status is 1. No accepted authorization is necessary for this particular application’s supplied successful behavior.
This separates three categories: rejected outer transaction, admitted transaction with skipped authorization rows, and application execution failure. They are not interchangeable failure labels. A useful dossier records the category before drawing any conclusion about final nonce or code.
Likewise, a row-level skip is not a statement that processing was free. Our results intentionally omit gas, refund counters and warm-access state, so they cannot answer billing or full resource-accounting questions.
Back to contents · Next section
11. Reproduce the nineteen cases and three early-gate probes
The finite checker tracks a fresh account map, increments the admitted sender, processes each row once and snapshots the resulting state before T’s execution. It records row outcome, recovered authority and available account snapshots. An independent formulation reconstructs all full states, traces, statuses and log lists.
The nineteen cases cover the main failed and successful executions, repeated and consecutive nonces, reversed order, two self-sponsorship cases, three clearing cases, an all-skipped list, two selected envelope failures, two nonce-ceiling controls, chain zero, ordinary-code rejection, a separately rejected outer transaction and later stale-tuple reuse.
Three additional probes use an unknown fixture-account label with, respectively, a wrong chain, unusable maximum nonce and failed signature. They test that both models stop at the early gate before trying to read that account. Across the reviewed cases, all eight early-failure rows keep recovery and account-state trace fields null.
These are local symbolic checks. Per-row cryptographic outcomes are premises, not a signature-verification implementation. The upstream tests were inspected as source evidence, not executed. Neither model establishes full Geth conformance, finality or deployed-wallet safety.
To audit an answer, preserve the initial map, ordered rows, first failed gate, each successful nonce/code update, execution-entry checkpoint and final application result. The final pointer alone cannot explain why an earlier or later row was skipped.
Back to contents · Next section
12. Exercises and model answers
- What is P’s nonce before main row 1?
- Why does main row 2 not replace D1 with D2?
- Can main row 6 truthfully name B as a recovered authority?
- Why can A retain D2 when T ends with status 0?
- What happens if consecutive A nonce-3 and nonce-4 rows are reversed?
- Does clearing code prove the stored value was erased?
Answers: 1. It is 8 after the sender increment. 2. A already has nonce 4, so the nonce-3 row skips. 3. No; its failed-signature outcome supplies no recovered authority. 4. Accepted preprocessing precedes the application snapshot restored by T’s failure. 5. The nonce-4 row skips first; the nonce-3 row then applies, leaving nonce 4 and D1. 6. No; the control preserves stored value 5.
For an extension, explain the difference between tuple nonce 2 to the power of 64 and MAX. The former is outside the field width in the selected envelope check; the latter fits but is skipped by the authorization’s incrementability gate. Their effects on sender processing and receipt status are therefore different.
Back to contents · Next section
Sources and version notes
Checked on 13 October 2026. EIP-7702 is marked Final and was created on 7 May 2024. Its status does not establish support on every chain.
Implementation references are pinned Geth v1.16.5 state transition and call handling. Upstream authorization tests are fixed to the stated commit and were read for nonce ordering, self-sponsorship, failed-execution persistence and retained-storage controls. No newest-release claim follows from these pins.
The useful conclusion is procedural: calculate the authorization phase first, preserving its ordered state changes, and then interpret the application outcome against the correct execution-entry snapshot.