Transactions & the Mempool

In the Accounts & State part we built the noun of Ethereum: the world state is a map from address to a mutable account record — a balance, a nonce, and (for contracts) storage and code. In State & the Merkle-Patricia Trie we saw how that entire map is committed by a single 32-byte stateRoot, so that untrusting strangers can agree not just on a list of events but on the exact world those events produce.

This part introduces the verb. A stateRoot describes a world at rest; something has to move it. That something is a transaction: the one and only thing that can change Ethereum’s world state. Nothing else moves the map. Blocks, validators, gossip, forks — all of it exists to order and apply transactions. Get the transaction right and everything downstream is bookkeeping.

A transaction is the only thing that can change state

Here is the claim in full, because the rest of the book leans on it: the address→account map only ever changes when a valid transaction is applied to it. There is no other write path. A validator cannot mint itself a balance; a contract cannot spontaneously run; time passing does not touch a single wei. State transitions happen when — and only when — a signed transaction from an externally-owned account (EOA) is applied.

An EOA is an account controlled by a private key, with no code of its own. It is the only kind of account that can originate a transaction, because originating one requires a signature, and only a key can sign. Contracts have code but no keys, so a contract can never start a transaction on its own; it only acts when an EOA’s transaction reaches it and its code runs as a consequence. That asymmetry is why we say a transaction is self-authorizing: it carries, inside itself, the cryptographic proof of who is allowed to spend from the sender’s account. You do not log in to Ethereum. You sign a message, and the signature is the authorization.

   world state (a map)                      world state'
   ┌────────────────────┐   transaction     ┌────────────────────┐
   │ 0xAli → {nonce:7,   │  (signed by Ali)  │ 0xAli → {nonce:8,   │
   │          bal: 5.0}  │  ───────────────► │          bal: 4.0}  │
   │ 0xBob → {nonce:2,   │                   │ 0xBob → {nonce:2,   │
   │          bal: 1.0}  │                   │          bal: 2.0}  │
   └────────────────────┘                   └────────────────────┘
        stateRoot: 0x9f…                          stateRoot: 0x3c…

   apply(state, tx) = state'      ← the state-transition function

Read that as an equation: apply(state, tx) = state'. The whole “world computer” is just this function, run over and over, on a state everyone agrees to. A transaction is the input; the new stateRoot is the checkable output.

Connecting back: a transaction mutates the account map through the nonce

Recall the nonce field on every account — a per-account counter that increments once per transaction sent from that account. It is not decoration. It is the hinge that ties a transaction to this account at this point in its history. Our companion crate ethmini shows the mechanism in miniature: a transaction names a from, a nonce, and what it wants to do.

/// A transaction: who sent it, the nonce it claims, and what it does.
///
/// The `nonce` must equal the sender account's *current* nonce; applying the
/// transaction bumps that nonce by one. Re-broadcasting the same bytes replays a
/// stale nonce and is rejected. (`ethmini` doesn't model signatures — `from`
/// stands in for "the address a valid signature recovered to".)
pub struct Transaction {
    pub from: Address,
    pub nonce: u64,
    pub kind: TxKind,   // Transfer, Deploy, or Call
}

When WorldState::apply runs, it checks sender.nonce == tx.nonce, does the work, then bumps the sender’s nonce by one. That single line is what makes each transaction usable exactly once, in exactly one order. It is replay protection within one chain. The next part of the story — how a signed transaction is protected against replay across different chains — is the subject of a whole page below.

Real Ethereum adds the piece ethmini deliberately omits: the from address is not a field you get to write. It is recovered from the signature. You sign the transaction with your private key; anyone verifying it runs the recovery algorithm on the signature and the transaction bytes and derives the sender address. There is no “from” to forge, because there is no “from” to write — only a signature that mathematically resolves to exactly one address.

Every transaction buys scarce blockspace — the cost question

If a transaction is the only thing that can change the world, then changing the world must be rationed, or the world computer is trivially free to spam into uselessness. This is the part’s second thread, and the book’s throughline made concrete: what does it cost to run one?

Every transaction consumes two scarce resources:

Blockspace — a block can hold only so many bytes and only so much execution. Transactions compete to be included at all.
Computation and state access — running contract code, reading storage, writing storage. Each operation has a price.

Ethereum meters both with a single unit: gas. Every operation the network performs on your behalf costs a fixed amount of gas; you attach a gasLimit (how much you’ll allow) and a price you’ll pay per unit. The total you pay is gas_used × price, and it goes to the network for the privilege of moving the shared state. We will only name gas in this part — the full mechanism (base fee, priority fee, EIP-1559) gets its own part in Gas & Fees. But keep the frame from here on: a transaction is a bid for scarce blockspace, and gas is how the bid is priced and the work is metered. No transaction is free, because no state change is free to the strangers who must all recompute it.

The journey a transaction takes

A transaction is not applied the instant you create it. It takes a path from your wallet to a block, and each stop on that path is a page in this part.

  construct ─► sign ─► broadcast ─► mempool ─► included in a block ─► executed
   (fields)   (key)   (to a node)  (waiting    (a validator picks    (state
                                    room of      it into a block)      changes)
                                    pending
                                    txs)

Construct — a wallet fills in the fields: nonce, recipient, value, data, gas parameters, chain id.
Sign — the private key signs the transaction’s bytes, producing the signature that will recover to the sender.
Broadcast — the signed transaction is handed to an Ethereum node, which validates it cheaply and gossips it to peers.
Mempool — the transaction waits in the mempool (memory pool): the network’s shared, unordered waiting room of valid but not-yet-included transactions. This is where fee markets happen and where much of the interesting — and adversarial — behavior lives.
Included — a validator building the next block selects transactions from its mempool (usually highest-paying first) and orders them into the block.
Executed — the block’s transactions are applied in order; the world state moves; a new stateRoot is committed.

Everything before step 5 is reversible and off-chain: a transaction sitting in the mempool has changed nothing. Only inclusion in a block, followed by execution, moves the world. That distinction — submitted is not the same as confirmed — is the single most important thing to internalize from this part, and the last page makes it precise.

Roadmap for this part

Read these in order. Each page uses only ideas from the pages above it, and each one forces a specific idea about how a signed request becomes a state change.

#	Page	What it builds	The idea it forces
2	Anatomy of a Transaction	Every field of a transaction — nonce, to, value, data, gasLimit, fees, chainId — and what each one means.	A transaction is a precise data structure, and every field is load-bearing.
3	Signing & Replay Protection (EIP-155)	How ECDSA signing produces `(v, r, s)`, how the sender is recovered not stored, and how EIP-155 folds the chain id into the signature.	The signature is the authorization — and it must bind to one chain.
4	Transaction Types: Legacy to Blob	The typed-transaction envelope (EIP-2718) and the evolution from legacy → access-list → EIP-1559 → blob-carrying transactions.	The transaction format is versioned, because the fee market and data model changed.
5	The Mempool & Propagation	How a valid transaction gossips across the p2p network, how nodes keep a mempool, and how MEV and reordering enter the picture.	Between broadcast and inclusion, a transaction lives in an adversarial, unordered waiting room.
6	Lifecycle: Submission to Inclusion	The full path end to end — pending, included, confirmed, dropped, replaced — and what “confirmed” actually means.	Submitted is not confirmed; only execution in a block moves state.
900	Revision · Transactions & the Mempool	A one-page recap of the whole part, ready for self-testing.	—

The thread

Tie it back to the book’s one question — how do untrusting strangers agree on the state of a shared world computer, and what does it cost to run one? This part is where the two halves of that question meet in a single object. The agreement half: a transaction is self-authorizing, so a stranger can verify who is allowed to make a change without trusting anyone — the signature recovers to exactly one address, and the nonce pins it to one moment in that account’s history. The cost half: a transaction is a bid for scarce blockspace, metered in gas, so that a world everyone must recompute cannot be spammed for free. Every later part — consensus, the EVM, gas, scaling — is ultimately about ordering, executing, or cheapening these signed requests. The transaction is the atom of the whole system.

Start with Anatomy of a Transaction →

Check your understanding

Ethereum’s world state is a map from address to account. What is the only thing that can change that map, and why can a contract never originate that change on its own?
We call a transaction “self-authorizing.” What does that mean concretely, and where does the sender’s address actually come from — is it a field the sender writes?
The nonce ties a transaction to one account at one point in its history. Explain how checking and then bumping the nonce makes a transaction usable exactly once, in exactly one order.
State the part’s cost question in your own words. What two scarce resources does every transaction consume, and what single unit meters both?
Trace the six stops a transaction takes from a wallet to executed state. At which stop does the world state actually change, and why is “submitted” not the same as “confirmed”?

Show answers

The only thing that can change the world-state map is a valid transaction applied to it — there is no other write path (validators, contracts, and the passage of time cannot mutate it directly). A contract can never originate a transaction because originating one requires a signature, and only a private key can sign; contracts have code but no keys, so they only act as a consequence of an EOA’s transaction reaching them.
Self-authorizing means the transaction carries, inside itself, the cryptographic proof of who is allowed to spend from the sender’s account — you do not log in, you sign, and the signature is the authorization. The sender’s address is not a field the sender writes: it is recovered from the signature and the transaction bytes, so there is nothing to forge — only a signature that resolves to exactly one address.
Applying a transaction requires that its claimed nonce equals the sender account’s current nonce; on success the nonce is bumped by one. So a transaction with nonce n is valid only when the account is exactly at n, and afterward the account is at n+1 — the same bytes can never apply again (stale nonce), and transactions must apply in ascending nonce order, giving each account a strict, replay-proof sequence.
The cost question is: what does it cost to run a shared world computer? Every transaction consumes blockspace (a block holds finite bytes and execution, so transactions compete to be included) and computation/state access (running code, reading and writing storage). Both are metered in a single unit, gas, and the sender pays gas_used × price.
Construct → sign → broadcast → mempool → included in a block → executed. The world state changes only at the last stop, when the block’s transactions are applied in order and a new stateRoot is committed. “Submitted” only means the transaction is broadcast or waiting in the mempool, where it has changed nothing and can still be dropped or replaced; only inclusion-and-execution in a block confirms it.