Walkthrough — Tracing One Transaction End to End

You now have every piece: accounts and state, signatures, transactions, the EVM, gas and EIP-1559, proof-of-stake consensus, and the Merkle-Patricia tries that commit all of it. This page spends those pieces at once. We follow one transaction — Alice sending 1 ETH to a contract that also updates a storage slot — from the moment her wallet builds it to the moment it can never be reverted. Nothing here is new; it is the whole book, wired together around a single object.

The journey on one page

   Alice's wallet
      │  ① build + sign (ECDSA over secp256k1, chainId in the signature)
      ▼
   raw signed tx ──② broadcast──▶ mempool (gossiped peer-to-peer, validity-checked)
                                      │
                                      │  ③ a proposer for this slot picks it (orders by tip)
                                      ▼
                                 block being built
                                      │  ④ EVM executes the tx: opcodes, gas metered per step
                                      │  ⑤ fees settle: base fee BURNED, priority tip → proposer
                                      ▼
                                 new world state ──⑥──▶ new stateRoot in the block header
                                      │              new receiptsRoot (status, gasUsed, logs)
                                      ▼
                                 block gossiped ──⑦──▶ committees ATTEST (LMD-GHOST)
                                      │
                                      ▼
                                 ⑧ two justified checkpoints later → FINALIZED (Casper FFG)

① Build and sign

Alice’s wallet assembles the transaction fields: her account’s next nonce, the to address (the contract), value = 1 ETH, the data (the ABI-encoded function call), a gas limit, and the EIP-1559 fee fields maxFeePerGas and maxPriorityFeePerGas. It then signs the RLP-encoded transaction with her private key, producing (v, r, s). Two facts make this signature load-bearing:

• The signature covers the chainId (EIP-155 replay protection), so a transaction valid on mainnet can’t be replayed on another chain.
• Ethereum stores no public keys. The network recovers Alice’s address from the signature itself — the signature is the authorization, and it doubles as proof of who is paying.

The wallet never sends the private key anywhere. It sends only the signed bytes.

② Broadcast into the mempool

The signed transaction is handed to a node, which gossips it to peers so it floods the mempool — the shared waiting room of pending transactions. Before any node relays or keeps it, it runs cheap validity checks: the signature recovers to a real account, the nonce is the account’s next expected value, and the balance covers the worst case value + gasLimit × maxFeePerGas. A transaction that fails these never propagates — junk dies at the edge, not in a block.

At this point the transaction is pending: real, signed, and visible, but not yet in the ledger. It has changed nothing.

③ A proposer picks it up

Under proof of stake, time is sliced into 12-second slots, and one validator is pseudo-randomly chosen as the proposer for each slot. When Alice’s slot comes, that proposer builds a block from the mempool. Because the priority fee (the tip) is the proposer’s to keep, they order transactions by tip — so Alice’s tip is her bid for when she is included. (In practice, as of 2024 most proposers outsource block-building to specialized builders via MEV-Boost — see MEV — but the incentive is identical.)

④ The EVM executes the transaction

Now the transaction runs. The EVM sets up an execution context and steps through the contract’s bytecode. Every opcode costs gas; the running total is checked against Alice’s gas limit on each step. The call transfers her 1 ETH into the contract and executes its code, which writes a new value into a storage slot (an SSTORE, one of the most expensive opcodes precisely because it grows state).

   start: gasLimit = 90,000
   ┌───────────────────────────────────────────────┐
   │ intrinsic cost         21,000  (base tx cost)  │
   │ CALL + value transfer   ...                    │
   │ SSTORE (new slot)      ~20,000                 │
   │ ...opcodes...           ...                    │
   └───────────────────────────────────────────────┘
   if the total ever exceeds gasLimit → OUT OF GAS:
      all state changes REVERT, but the gas is still spent.

Two outcomes are possible, and both are deterministic (determinism is why every node computes the same result): success, or a revert. On a revert — out of gas, a failed require, an exception — every state change rolls back as if the call never ran, except the nonce increment and the gas already burned. You pay for the computation whether or not it succeeded; that is what makes spamming the world computer expensive.

⑤ Fees settle

Gas used is now priced. Under EIP-1559 each unit costs baseFee + priorityFee. The base fee is burned — destroyed, paid to no one — which ties ETH issuance to demand for blockspace. The priority fee goes to the proposer. Any gas Alice reserved but didn’t use is refunded at the end, so over-estimating the gas limit is safe; under-estimating is what triggers the out-of-gas revert above.

⑥ The state transition and the new root

The execution produced a set of changes: Alice’s balance down (value + fees), her nonce up by one, the contract’s balance up, and one storage slot rewritten. Applying them is the state transition s' = f(s, tx). But a change isn’t real until it’s committed: the contract’s storage trie is re-hashed to a new storage root, which changes the contract’s account record, which changes a leaf in the global state trie, which bubbles up to a brand-new stateRoot. That 32-byte root goes in the block header — a single hash that commits to the entire post-transaction world (the four tries).

In parallel, a receipt is emitted — success/failure status, cumulative gas used, and the event logs the contract fired (indexed into a bloom filter) — and hashed into the block’s receiptsRoot. This is what a light client later uses to prove “your transaction succeeded and emitted this event” without re-executing anything.

⑦ Attestation, and ⑧ finality

The proposer gossips the block. In the same slot, a committee of validators attests — votes — for the head of the chain they see, and the fork-choice rule (LMD-GHOST) follows the branch with the most accumulated stake behind it. After a couple of slots with a supermajority behind it, Alice’s block is confirmed — extremely unlikely to be reorged.

Confirmed is not final. Finality comes from Casper FFG’s checkpoint voting: once two consecutive epoch-boundary checkpoints are justified — about two epochs, ~12.8 minutes — the block between them is finalized. Reverting it would now require an attacker to burn at least one-third of all staked ETH to slashing. At that point Alice’s 1 ETH transfer and the contract’s storage write are, economically, permanent.

The recurring thread, one last time

Trace what each stage bought. The signature answered who authorized this without a trusted account database. The mempool answered is it even valid before wasting a block on it. Gas answered how do we stop an infinite loop on a computer no one can reboot. The stateRoot answered how does everyone agree the state is identical in 32 bytes. Finality answered when can I stop worrying it reverts. Every one of those is the book’s throughline — how do untrusting strangers agree on the state of a shared world computer, and what does it cost to run one — made concrete in the life of a single transaction.

Check your understanding

1. Ethereum stores no public keys, yet every node knows which account paid for a transaction. How?
2. A transaction runs out of gas halfway through an SSTORE. What happens to (a) the storage write, (b) the nonce, and (c) the gas?
3. Under EIP-1559, the base fee and the priority fee have very different destinations. Name each destination and why the split exists.
4. Applying the state changes is only half of step ⑥ — the other half is producing a new stateRoot. Why is the root, not the raw state changes, what actually goes in the block header?
5. Alice sees her transaction “confirmed” one slot later but the book says it isn’t final for ~12.8 minutes. What is the difference, and what would reverting a finalized block cost an attacker?

Show answers

1. The signature (v, r, s) allows public-key recovery: from the signed transaction hash and the signature, nodes recover the signer’s public key and hence the 20-byte address. The signature is the authorization and simultaneously identifies (and bills) the sender — no key database needed.
2. (a) The storage write — and every other state change in the call — reverts as if it never happened. (b) The nonce still increments (the transaction was included). (c) The gas is still spent and paid; running out of gas does not refund the work already done. You pay for computation whether or not it succeeds.
3. The base fee is burned (destroyed), which prices blockspace by demand and removes it from supply; the priority fee (tip) goes to the block proposer as the incentive to include the transaction. Splitting them lets the protocol set a predictable, non-gameable base price while still letting users bid for ordering.
4. Because consensus needs every node to agree the resulting state is identical in a fixed, tiny amount of data. The stateRoot is a single 32-byte hash committing to the entire post-transaction state; two nodes with the same root provably have the same state, and light clients can verify any account against it without the raw changes.
5. Confirmed means the block is the head under LMD-GHOST fork choice and unlikely to be reorged; finalized means two epoch-boundary checkpoints have been justified (~two epochs, ~12.8 min) so the block is economically irreversible. Reverting a finalized block would require an attacker to get at least one-third of all staked ETH slashed — an intentionally ruinous cost.