Walkthrough — Tracing One Transaction End to End

You now have every piece: the account model, ed25519 signing, transactions and instructions, Proof of History, Tower BFT consensus, Sealevel’s parallel execution, the runtime, and the validator pipeline itself. This page spends them all at once. We follow one transaction — Alice invoking a program that transfers tokens and updates an account — from her wallet’s signature to the moment the cluster agrees it happened. Nothing here is new; it is the whole machine, wired together around a single object.

The journey on one page

   Alice's wallet
      │  ① build tx: instructions + account list (r/w + signer flags) + recent blockhash; sign (ed25519)
      ▼
   signed tx ──② Gulf Stream──▶ forwarded straight to the CURRENT + UPCOMING leaders (no global mempool)
                                     │
                          ┌──────────┴─── the leader's TPU (an assembly line) ───────────┐
                          │  ③ fetch (QUIC) → ④ sigverify (parallel) → ⑤ banking + PoH   │
                          └──────────┬───────────────────────────────────────────────────┘
                                     │  ⑤a Sealevel runs non-conflicting txs in PARALLEL (account locks)
                                     │  ⑤b PoH stamps ordering into the hash stream
                                     ▼
                              entries → shreds ──⑥ Turbine──▶ propagated down a stake-weighted tree
                                     │
                                     ▼
                              ⑦ validators replay + VOTE (Tower BFT) → optimistic confirmation → rooted

① Build and sign

Alice’s wallet assembles a transaction: an ordered list of instructions (each naming a program plus the accounts it will touch), a flat account list where every account is flagged read/write and signer-or-not, a recent blockhash, and the fee payer. She may also add a compute-budget instruction to raise her limit or attach a priority fee. The wallet then signs the message with her ed25519 key.

Two design choices here decide everything downstream. The recent blockhash both proves the transaction is fresh (it expires after ~150 blocks) and prevents replay — there is no per-account nonce. And the account list with read/write flags is a promise: Alice is declaring, up front, exactly which accounts this transaction will read and write. That declaration is what makes step ⑤a possible.

② Gulf Stream — no mempool

Solana has no global mempool. Because the leader schedule is known in advance, Gulf Stream lets clients and RPC nodes push a signed transaction directly to the current leader and the few upcoming leaders. The transaction skips the “shared waiting room” entirely and arrives at the one validator that can actually include it. This is why Solana has no mempool to gossip and no public pending-transaction pool in the Ethereum sense — the trade-off being a different, leader-local MEV surface rather than a global one.

③–④ The leader’s TPU: fetch and verify

The chosen leader runs the Transaction Processing Unit (TPU) — a pipeline, so different stages of different transactions run at once. The fetch stage receives packets over QUIC (chosen after the 2021–2022 congestion episodes let UDP floods overwhelm nodes — see reliability), with connections prioritized by stake (stake-weighted QoS). The sigverify stage checks every ed25519 signature, a massively parallel job often offloaded to the GPU. Invalid signatures are dropped here, before any execution.

⑤ Banking + PoH: parallel execution, stamped in order

Verified transactions reach the banking stage, where the real work happens — and where Solana’s central bet pays off. Because every transaction already declared the accounts it reads and writes, the scheduler applies the conflict rule: two transactions conflict only if one writes an account the other touches. Non-conflicting transactions have no way to affect each other, so Sealevel runs them in parallel across CPU cores.

   pending: T1(write A), T2(write B), T3(read A, write C), T4(write A)
   locks:   A ← T1        B ← T2       A is taken → T3 waits   A is taken → T4 waits
   ┌─ batch 1 (parallel) ─┐
   │  T1 on core 0        │      T3 and T4 both want account A, which T1 holds,
   │  T2 on core 1        │      so they run in a LATER batch — never alongside T1.
   └──────────────────────┘

This is the opposite of the EVM’s strictly serial one-transaction-at-a-time model, and it is the whole reason Solana scales with core count. As transactions execute against the bank (the working copy of account state), the Proof of History service is simultaneously grinding its sequential SHA-256 chain and stamping transactions into it — recording their order as a cryptographic fact, so the rest of the cluster doesn’t have to negotiate ordering later. Fees settle here too: a base fee per signature (half burned) plus any priority fee, with local fee markets pricing contention on hot accounts.

⑥ Turbine — propagating the block

The leader packages executed transactions into entries, splits them into small packets called shreds, and sends them out via Turbine. Rather than the leader uploading the whole block to everyone (which would cap throughput at the leader’s uplink), Turbine arranges validators into a stake-weighted tree: the leader sends shreds to a small set of peers, who forward to the next layer, and so on. Bandwidth cost is spread across the cluster, so block size isn’t bottlenecked by one machine’s connection.

⑦ Replay, vote, and confirmation

On the receiving side, every validator’s TVU reassembles the shreds and replays the transactions — re-executing them to reach the same bank state the leader did (determinism means they must match). Satisfied, validators cast votes under Tower BFT, Solana’s PoH-clocked consensus: each vote carries an exponentially growing lockout, so a validator that votes for a fork is economically committed to it and can’t cheaply flip.

The result is two levels of assurance, mirroring the pattern from optimistic confirmation vs finality: a transaction is optimistically confirmed within a second or two once a supermajority of stake has voted for the block, and later rooted (finalized) once enough subsequent blocks are locked in on top of it. At that point Alice’s token transfer is permanent.

The recurring thread, one last time

Trace what each stage bought against the book’s throughline — how do you build a single global state machine that runs at hardware speed without falling apart? Gulf Stream removed the mempool so transactions arrive where they’re needed. QUIC and stake-weighted QoS keep the fetch stage upright under load — a lesson paid for in real outages. Declaring account access up front is what let Sealevel use all the cores instead of one. PoH turned “what order did these happen in?” from a consensus negotiation into a hash anyone can verify. Turbine kept block propagation from bottlenecking on one uplink. Each is a deliberate answer to “where would a single global state machine fall apart under speed?” — visible in the life of one transaction.

Check your understanding

1. Solana has no global mempool. What replaces it, and what makes that replacement possible?
2. Alice’s transaction lists every account it will read and write, with flags. Which specific downstream stage depends on that list, and what would break without it?
3. Proof of History is running alongside execution in the banking stage. What problem does it solve that would otherwise require validators to talk to each other?
4. Turbine sends the block as shreds down a stake-weighted tree instead of the leader broadcasting to everyone. What bottleneck does that avoid?
5. Alice sees “confirmed” in about a second but the transfer is “rooted” only later. What is the difference, and what makes a validator’s vote costly to reverse?

Show answers

1. Gulf Stream replaces it: because the leader schedule is known ahead of time, clients forward signed transactions directly to the current and upcoming leaders instead of gossiping them into a shared pool. It’s possible precisely because Solana knows who the next leaders are in advance.
2. Sealevel’s parallel execution (in the banking stage) depends on it. The scheduler uses the declared read/write sets to detect conflicts and run non-overlapping transactions in parallel. Without the up-front declaration it couldn’t know which transactions are independent, and would have to fall back to serial execution — losing Solana’s core throughput advantage.
3. Ordering. PoH’s sequential hash chain stamps transactions with a verifiable before/after relationship, so the cluster agrees on order by checking a hash rather than by exchanging messages to negotiate it. It turns time into a cryptographic fact and takes the ordering problem off consensus’s plate.
4. The leader’s uplink bandwidth. If the leader had to send the whole block to every validator directly, block size would be capped by one machine’s outbound connection. Turbine’s tree spreads the forwarding cost across the cluster so no single link is the bottleneck.
5. Optimistic confirmation (~1–2s) means a supermajority of stake has voted for the block; rooted/finalized means enough later blocks are locked in on top that reversal is effectively impossible. A vote is costly to reverse because Tower BFT lockouts grow exponentially — voting for a fork commits the validator to it, and abandoning it means forfeiting rewards/stake.