中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC033
An account-based ledger can store a balance and a transaction counter for each account. In the ordinary sender model used here, a transaction must carry the counter value expected in the selected pre-state. Executing it advances that counter. This makes two otherwise authorized instructions distinguishable by their place in one sender’s sequence.
A nonce is therefore useful evidence about ordering, but it is not a receipt, a global queue number or a promise of successful application execution. This guide follows two fictional instructions through an exact account-state worksheet, then tests gaps, repeated submissions and competing candidates. No real funds, keys or transactions are involved.
Choose your reading route
In this guide
- 1. A balance answers a different question from a nonce
- 2. Write down the complete classroom pre-state
- 3. The first instruction consumes nonce 4
- 4. The second instruction depends on the first state change
- 5. A gap is not a reserved place in a global queue
- 6. Repeating the same transaction does not create another turn
- 7. Two candidates can ask for the same position
- 8. Equal numbers from different senders need not conflict
- 9. Ask which state a reported nonce describes
- 10. Keep the ordinary model’s limits visible
- 11. Exercise: diagnose six account-state claims
- 12. Frequently asked questions
- 13. Sources and next reading
Read the account card and the two-step calculation first. Use the failure cases to separate a transaction that cannot execute at the current counter from one a node may retain for later. Finish with the observation checklist and answer key before drawing conclusions from a wallet’s pending display.
The worksheet deliberately covers ordinary sender transactions with a single increasing counter. It is not a complete Ethereum implementation. Delegation authorizations, contract-created accounts, smart-account nonce schemes and actual gas accounting require additional rules. The final sections explain why this scope matters.
Back to contents · Next section
1. A balance answers a different question from a nonce
A balance describes a quantity in the chosen account state. A nonce, in our model, describes which numbered instruction from that sender can execute next. Having enough balance does not make every signed instruction immediately executable.
Imagine an archive classroom account A with 20 invented credits and next nonce 4. The number 20 answers how many credits A currently holds. The number 4 says that the next ordinary instruction must use nonce 4. Neither number identifies a real person, establishes legal ownership or explains why earlier state changes occurred.
The Ethereum transaction documentation describes nonce as a transaction field associated with the sender. We use this basic ordering idea without assuming that every blockchain, account abstraction system or authorization format follows an identical counter scheme.
A transaction nonce is also different from an application record’s revision number. A catalogue entry might be at revision 7 while its sender’s next nonce is 4. One tracks the application object; the other orders the sender’s transactions. A correctly numbered transaction can still request an outdated catalogue revision.
Back to contents · Next section
2. Write down the complete classroom pre-state
Our synthetic ledger starts with these supplied values:
- A holds 20 credits and has next nonce 4.
- B holds 0 credits and has next nonce 0.
- C holds 0 credits and has next nonce 0.
- A separate teaching fee sink holds 0 credits.
All credits are invented integer units. Every successful classroom transfer deducts a fixed fee of 1 from its sender and adds that unit to the fee sink. This fee is a bookkeeping device, not Ethereum’s fee formula or a quoted network price.
For this exercise, a transfer executes only if its authorization is valid, its network context matches, its nonce equals the sender’s current next nonce, and the sender can cover value plus the fixed fee. Its recipient and values must also fit the supplied record format. Successful execution updates the balances and increases the sender’s nonce by one.
We assume valid authorization and matching network context for the two main transactions. Receiving credits alone does not change B’s or C’s next nonce in this model. We exclude application calls and failure-after-inclusion behavior from the arithmetic, so the worksheet has one unambiguous success transition.
Back to contents · Next section
3. The first instruction consumes nonce 4
Transaction T4 says: sender A, nonce 4, recipient B, value 6, fixed fee 1. The label T4 is a classroom identifier; the number in its name is not a cryptographic transaction hash.
Before execution, A expects nonce 4 and can cover 6+1=7 credits. Under the supplied assumptions, T4 therefore passes the worksheet’s checks. A loses 7 credits, B gains 6, and the fee sink gains 1.
The resulting state is A balance 13 with next nonce 5; B balance 6 with next nonce 0; C balance 0 with next nonce 0; fee sink 1. The total remains 13+6+0+1=20.
Notice what advanced: A’s sender counter. B’s counter remains 0 because B has received a transfer rather than executed an outgoing instruction in this model. It would be a mistake to increment every account touched by the transaction simply because its balance changed.
The counter is part of the transition, not an extra annotation added by the user interface afterward. A later validator replaying the same supplied pre-state and rules must use the updated counter when checking A’s next transaction.
Back to contents · Next section
4. The second instruction depends on the first state change
Transaction T5 says: sender A, nonce 5, recipient C, value 5, fixed fee 1. After T4, A expects 5 and has 13 credits, enough to cover 5+1=6.
Executing T5 leaves A with 7 credits and next nonce 6. B still has 6, C now has 5, and the fee sink contains 2. The final accounting identity is 20=7+6+5+2.
The full sequence is therefore T4 followed by T5. This is not just an arbitrary presentation order. T5’s nonce matches the state produced by T4, not the initial state. Attempting T5 first fails the worksheet’s nonce-equality check even though A initially has ample credits.
That distinction matters in diagnosis. “Insufficient balance” and “the preceding nonce has not been consumed” are different explanations. A user-facing display that reduces both to a generic waiting message removes information needed to understand the next valid state transition.
Do not extend the result to a guarantee that T5 will execute. The worked path supplies T4’s successful execution and all other checks. In an actual system, a different preceding transaction, changed state or other validity condition may prevent the later candidate from progressing.
Back to contents · Next section
5. A gap is not a reserved place in a global queue
Suppose a node learns about T5 before it learns about T4. The selected canonical account state still expects nonce 4. Under our ordinary sender rule, that node cannot validly execute T5 as A’s next instruction.
It may nevertheless retain T5 locally according to its transaction-pool policy. Retention means the node has a candidate it might reconsider after state or its available transaction sequence changes. It does not mean the candidate is already in a block, has reserved network capacity or will be kept indefinitely.
The Geth txpool documentation, last edited 16 August 2023, describes non-standard inspection methods with pending and queued groups indexed by account and nonce. This is a client-specific observation interface, not a definition of one global waiting room shared by every node.
For the classroom case, write two separate notes: “canonical A next nonce is 4” and “this node has observed candidate T5 with nonce 5.” Those statements can both be true. Collapsing them into “A’s nonce is 5 now” confuses a signed candidate with accepted state.
A missing earlier candidate is one possible explanation for a gap. It is not proof that someone deleted a transaction, censored a user or lost a private key. Those stronger conclusions need additional evidence beyond this counter comparison.
Back to contents · Next section
6. Repeating the same transaction does not create another turn
After T4 has executed on the selected canonical path, A expects nonce 5. Submitting the same T4 bytes again does not turn their nonce 4 into nonce 5. They cannot pass the same ordinary sender check at that later state.
A transaction identifier helps distinguish byte-level candidates; the sender and nonce identify the position they seek in this simplified sequence. Neither should be replaced with a vague count of how many times a person clicked a button.
This explains a useful separation between repeated communication and repeated execution. A node might hear the same transaction from several peers. Multiple observations do not imply multiple accepted transfers. In the worksheet, only the first valid state transition consumes A’s nonce 4.
The qualification “on the selected canonical path” is important. A chain reorganisation may replace the state history used for a recent observation. One must then inspect the newly selected state and the transaction’s status there. The counter rule is not a statement that a transaction can appear only once across every competing history ever observed.
Back to contents · Next section
7. Two candidates can ask for the same position
Now introduce T4prime: sender A, nonce 4, recipient C, value 6, fixed fee 1. Its supplied authorization is valid. It differs from T4 in recipient, so it is a competing instruction for the same sender position rather than a second step after T4.
If T4 executes first in the initial state, A advances to nonce 5 and T4prime cannot then consume nonce 4 in that same canonical sequence. If T4prime executes instead, A still reaches balance 13 and next nonce 5, but C receives the 6 credits and B receives none.
Thus identical post-transaction sender balance and nonce do not establish which recipient was paid in the classroom ledger. To answer that question, inspect the accepted transaction and resulting recipient state. A counter alone is insufficient evidence of application intent.
The Geth inspection documentation explicitly allows observations of multiple candidates associated with the same account and nonce. Which candidate a node admits, replaces, retains or relays depends on client and pool rules. Our exercise supplies no replacement-price rule and makes no promise that every node will choose the same locally preferred candidate.
A wallet feature labelled “cancel” cannot be understood as erasing an already signed instruction from every possible observer. Read the actual mechanism, transaction state and applicable network rules. This lesson provides no live replacement or cancellation procedure.
Back to contents · Next section
8. Equal numbers from different senders need not conflict
Consider a separate supplied account D with enough credits, valid authorization and next nonce 4. D’s nonce-4 transaction does not compete for A’s nonce-4 position in this model. The sequence is scoped to the sender account and network context, not merely the integer 4.
Likewise, A’s nonce 4 on one network does not automatically have the same meaning on another. A robust evidence record identifies the network and authorization scheme as well as the sender and nonce.
EIP-155, created 14 October 2016 and marked Final, specifies chain-ID-aware signing for its legacy Ethereum transaction format. Its historical replay-protection mechanism illustrates why a sender counter alone is not a complete cross-network authorization boundary.
Do not turn that example into a universal claim that adding a chain ID protects every signed message in every application. The signed fields and verifier’s rules determine the scope. Two branches sharing a context also require more careful reasoning than comparing two different network labels.
Back to contents · Next section
9. Ask which state a reported nonce describes
A report that says “A nonce 6” is incomplete without its observation context. Is it the counter in a particular accepted block’s state, a node’s current selected head, or a pending-state calculation influenced by that node’s local candidates?
Ethereum’s JSON-RPC documentation gives state-query methods block-context parameters, including named contexts such as latest and pending. These contexts should not be treated as interchangeable evidence. Record the method, parameter, responding node and observation time; identify the actual block where available.
For our worksheet, the state after T4 and T5 has A next nonce 6. A node whose accepted state stops before T4 has A next nonce 4. Those reports may reflect different selected states rather than an arithmetic disagreement.
If a report uses a pending view, ask what local sequence it incorporates and whether the client supports the requested semantics. A pending counter is useful for understanding that node’s working view, but it does not independently prove block inclusion or finality.
A reproducible comparison starts by aligning network, block identity and account. Only then compare values. Comparing a finalized historical state with another node’s pending view without labelling the difference creates a misleading contradiction.
Back to contents · Next section
10. Keep the ordinary model’s limits visible
A nonce is not necessarily random. The ordinary transaction counter here increases predictably. Other systems use the word nonce for different protocol roles, with different uniqueness or unpredictability requirements. A mining nonce, an encryption nonce and this account counter should not inherit one another’s rules by name alone.
Nor should a reader assume that an externally owned account’s nonce always equals the number of outgoing transactions a block explorer happens to list. EIP-7702, created 7 May 2024 and marked Final, includes authorization processing that checks and increments an authority account’s nonce. Our transfer-only worksheet excludes those authorization tuples and delegated execution.
Application success is another separate dimension. Real transaction processing can advance a sender nonce even when an included application’s execution fails; the applicable execution rules determine which changes persist. Our synthetic fee-and-transfer success rule must not be used to infer a real failed transaction’s balance, fee or nonce effects.
For the same reason, do not apply this single-counter exercise directly to every smart-account design. Identify its authorization and nonce mechanism first. The transferable skill is to read the state-transition rule and its scope, not to assume every account-shaped interface implements this exact worksheet.
Back to contents · Next section
11. Exercise: diagnose six account-state claims
Use only the supplied classroom rules. State the relevant pre-state before answering each question.
- At the initial state, T5 is correctly authorized and A has 20 credits. Can it execute immediately as A’s next instruction?
- After T4 then T5, what are A’s balance and next nonce, B’s balance, C’s balance and the fee-sink total?
- After T4, someone resends identical T4 bytes. Does this give B another 6 credits?
- At the initial state, T4 and T4prime are both observed. Can both consume A’s nonce 4 consecutively in the same canonical sequence?
- A and D each have next nonce 4. Must one account wait simply because the other uses the same integer?
- A report gives A next nonce 6 without a block or pending-state context. Does this alone prove that C received the intended 5 credits in T5?
Answers and reasoning
- No. A expects nonce 4, whereas T5 carries 5. Adequate balance and authorization do not remove the ordering condition. A node’s possible retention is a separate policy question.
- A has 7 and next nonce 6; B has 6; C has 5; the fee sink has 2. The credits reconcile to 20. B and C still have next nonce 0 under the receiving-only rule.
- No. The selected state after T4 expects A nonce 5. Identical bytes still carry 4 and cannot produce the proposed second transition there.
- No. They are alternative candidates for the same sender position. The first accepted transition advances the counter. Observing both is compatible with executing at most one of them at that position on the selected path.
- No. The counters are account-scoped. Other shared-resource or application conflicts might exist in a richer system, but equality of these integers alone does not create one.
- No. The report lacks state context and transaction evidence. Other instructions could have advanced A’s counter. Check the accepted transaction, its execution result and the relevant recipient state.
Extension: choose the alternative branch
Replace T4 with T4prime, then execute the unchanged T5. A again finishes with 7 credits and next nonce 6. B has 0; C has 11; the fee sink has 2. The identity is 20=7+0+11+2.
This extension is the strongest reason to avoid using a sender’s final balance and counter as a complete audit of recipients. Two different authorized histories can leave those sender fields equal while producing materially different recipient states.
Back to contents · Next section
12. Frequently asked questions
Is the nonce a transaction’s unique identifier?
No. In this model it identifies a sender sequence position within a context. Different competing transaction bytes can carry the same sender nonce. Their transaction identifiers and effects can differ.
Does a higher nonce mean a higher priority?
No. It means a later position in this ordinary sender sequence. The worksheet does not assign fee-based ordering or scheduling priority, and a gap can prevent immediate execution.
Does receiving a transfer increase the recipient nonce?
Not under the classroom receiving-only rule. A balance update and a sender-counter update are different operations. For a real system, inspect the specific execution and authorization path rather than generalising from the account’s involvement.
Can a counter prove that the user intended the result?
No. It helps constrain ordering. Human intent, authorization scope, transaction contents, application execution and finality remain separate questions requiring their own evidence.
Back to contents · Next section
13. Sources and next reading
Technical sources checked on 12 October 2026, Singapore time. Proposal creation dates describe the documents, not an assertion that every network implements their rules.
- Ethereum transactions: transaction fields and the ordinary sender model.
- Geth txpool namespace: client-specific pending and queued inspection; page last edited 16 August 2023.
- EIP-155: Final; created 14 October 2016; historical chain-ID-aware transaction signing.
- Ethereum JSON-RPC: state-query contexts and observation parameters.
- EIP-7702: Final; created 7 May 2024; authority nonce processing beyond the transfer-only example.
Review the UTXO lesson to compare named-output consumption with account-state updates. Continue to mempools to examine how two nodes can retain different candidates, then to gas and failed execution for resource accounting. Keep the account-counter worksheet separate from those additional mechanisms until their rules are specified.