Revision: The Validator Pipeline

This part is where the ingredients became a machine. Proof of History gave us agreed-upon order without a conversation; the account model gave us knowable footprints; Sealevel turned those footprints into parallel execution across cores. On their own, each was a component on a bench. The overview asked the mechanical question the whole book had been building toward: once those exist, how does a validator physically ingest, order, execute, and propagate a firehose of transactions fast enough to keep sub-second slots?

The answer, page by page, was a single idea worn in two directions — a validator is an assembly line, not a loop. This page walks one transaction from a wallet’s sendTransaction call to a supermajority of validators voting on the block that contains it, naming which stage does the work at every hop and why it is shaped that way.

The full path of one transaction

Follow a single transaction the whole way. Nothing below is new — it is the six pages compressed into one trace.

   wallet / RPC
        │  1. Gulf Stream: forward to the KNOWN upcoming leader (no mempool)
        ▼
   ┌─────────────────── LEADER ───────────────────┐
   │  TPU (the assembly line)                      │
   │    2. fetch     receive UDP packets           │
   │    3. sigverify verify signatures (GPU-bulk)  │
   │    4. banking   PoH stamps order +            │
   │                 Sealevel executes in parallel │
   │    5. broadcast split the block into shreds   │
   └──────────────────────┬────────────────────────┘
                          │  6. Turbine: fan shreds down a stake-weighted tree
                          ▼
   ┌───────────────── EVERY OTHER VALIDATOR ───────┐
   │  TVU (the receiving side)                     │
   │    7. shred fetch + retransmit (help the tree)│
   │    8. replay: re-execute + verify PoH         │
   │    9. vote                                    │
   └───────────────────────────────────────────────┘

1. Gulf Stream forwards it — no mempool

Most chains hold pending transactions in a global mempool: a shared pool every node gossips about, from which the next block producer pulls. Solana deletes the mempool. Because PoH gives a known leader schedule — everyone can compute who leads each upcoming slot — a wallet (or the RPC node in front of it) can push the transaction straight to the expected leader, and to the one after it, before that leader’s slot even begins. Gulf Stream is that forwarding discipline. The payoff is that the leader’s pipeline never starts cold: work is already queued at the front when its slot opens.

This is the first place an earlier idea pays off directly: the leader schedule (from PoH) is the precondition for Gulf Stream. Without a knowable upcoming leader, there is nobody to forward to, and you are back to a mempool.

2–5. The TPU turns packets into a block

When the leader’s slot opens, its TPU — Transaction Processing Unit — runs. It is a four-stage assembly line, each stage a specialist handing off to the next:

Fetch pulls raw UDP packets off the network card and batches them. The firehose arrives here, unordered and unverified.
Sig-verify checks each transaction’s signatures. This is embarrassingly parallel arithmetic, so it is the stage Solana pushes onto a GPU to verify thousands of signatures at once and keep this stage from becoming the bottleneck.
Banking is the heart. Here PoH and Sealevel meet: the PoH recorder stamps order into the stream by hashing entries into its sequential chain, while the Sealevel scheduler reads each transaction’s declared account footprint and executes non-conflicting transactions in parallel across cores. Order and execution happen in the same stage.
Broadcast takes the block the banking stage produced and splits it into shreds — small, individually-signed fragments — to hand to Turbine.

Here the second earlier idea pays off: up-front account declarations (the account model) are what let banking execute in parallel. Because every transaction says which accounts it will read and write before it runs, the scheduler can prove two transactions do not conflict and place them on different cores — without that declaration, banking would collapse back into a serial loop.

6. Turbine broadcasts the shreds down a tree

A leader that tried to send a whole block to thousands of validators directly would melt its own uplink: one machine cannot fan a full block out to the entire cluster at once. Turbine solves this the way BitTorrent-style systems do — the block is already shredded, and those shreds fan out down a stake-weighted tree. The leader sends each shred to a small set of nodes; each of those forwards to the next layer, and so on. No single node’s bandwidth carries the whole block, and the number of hops to reach everyone grows only logarithmically with the cluster size.

7–9. Every follower’s TVU replays and votes

Almost all the time, a validator is not the leader — one leader serves each ~400 ms slot for a rotation of slots, so the overwhelming majority of nodes are following. Following runs the TVU — Transaction Validation Unit, the mirror image of the TPU:

Shred fetch + retransmit receives shreds and, crucially, forwards them onward — every follower is also an interior node of somebody’s Turbine tree, so receiving and relaying are the same job.
Replay reassembles the shreds into a block and re-executes it, checking the PoH chain is valid and that re-running the transactions reproduces the leader’s claimed result. This is where the block is validated, not merely received.
Vote casts the validator’s vote on the block once replay confirms it, feeding consensus.

The account model pays off a second time here: the same up-front footprints that let the leader execute in parallel let every follower replay in parallel. Validation is not a slow serial re-check; it is Sealevel running again on the receiving side, which is what lets thousands of nodes keep pace with a leader producing blocks every 400 ms.

Why the pipeline beats a loop

Strip away the names and the whole part is one claim about shape. The naive design is a single loop: take a transaction, receive it, verify it, execute it, broadcast it, then start the next one. While that loop verifies a signature, the network card, the executor, and the broadcaster all sit idle. Its throughput is the sum of every step’s time.

Pipelining breaks the work into stages that all run at once, each on a different transaction. Fetch is pulling in transaction #40 while sig-verify checks #39, banking executes #38, and broadcast ships #37. Every specialist is busy every moment.

   loop  (throughput = sum of stages)
     [fetch][verify][bank][cast]  ── then start over
       one tx traverses all four before the next begins

   pipeline  (throughput = slowest stage)
     fetch  : [40][41][42][43] …
     verify :    [39][40][41][42] …
     bank   :       [38][39][40][41] …
     cast   :          [37][38][39][40] …
       every stage busy on a DIFFERENT tx, same instant

This is the single fact to retain from the whole part:

Once a pipeline is full, its throughput is set by its slowest stage, not by the sum of all stages.

That is why the TPU obsesses over balancing stages and offloading the slow ones — bulk signature verification onto a GPU, for instance. You do not speed up a pipeline by making it shorter; you speed it up by widening its narrowest stage. Adding a stage only lengthens the latency one transaction takes to traverse the line; it does not lower throughput unless the new stage becomes the bottleneck. Stall one stage and the whole machine backs up behind it.

And pipelining is only one of the two axes. Sealevel is parallelism across data — many independent transactions at once, inside the banking stage. Pipelining is parallelism across stages — every phase at once, each on a different transaction. Together they are the last hinge of the book’s throughline: pipelining plus parallelism is how a single global state machine runs at hardware speed, with no core ever waiting on another.

How the earlier ideas snap together

The satisfying part of this recap is watching three earlier chapters turn out to be load-bearing for the pipeline, not merely adjacent to it:

PoH → the leader schedule → Gulf Stream. Because order comes from a verifiable clock rather than a conversation, everyone can compute who leads next. That knowable schedule is precisely what lets wallets forward transactions to the upcoming leader and delete the mempool.
The account model → parallel banking and parallel replay. Because every transaction declares its account footprint up front, the leader can execute non-conflicting transactions in parallel — and every follower can replay them in parallel by exactly the same reasoning. One declaration, two payoffs, on both sides of Turbine.
Sealevel → the widest possible banking stage. Parallel execution is what keeps the pipeline’s heaviest stage from becoming the permanent bottleneck; it widens the narrowest point.

None of the pipeline’s tricks would work if these were missing. A validator that had PoH, accounts, and Sealevel but ran them in a single loop would still crawl; a validator that pipelined them but lacked a knowable leader would need a mempool again. The components and their arrangement are one design.

The honest cost

This design is a firehose aimed at powerful hardware, and it is fair only if we name what that costs. Every stage assumes a well-provisioned, well-connected validator: sig-verify wants a GPU, banking wants many cores, Turbine wants real bandwidth and low latency to relay shreds onward. This raises the floor to run a node and is a real centralizing pressure on who can validate — a trade-off the reliability part examines head-on.

It is also exposed to resource exhaustion. Because there is no mempool to absorb and price a surge, a flood of cheap or spammy transactions lands directly on the leader’s fetch and sig-verify stages. If an attacker can make the narrowest stage the bottleneck, the whole pipeline backs up — which is the mechanism behind several of Solana’s historical liveness incidents, where the network stalled under transaction load rather than being cryptographically broken. The pipeline is fast because it holds nothing back; that same lack of a shock absorber is its sharpest edge.

Where this plugs in

The pipeline produces two things every 400 ms: a block, and a vote from every validator that replayed it. This part deliberately stopped at “vote.” What that vote means — how votes accumulate into agreement, how forks are chosen between, and how a block goes from replayed to finalized — is consensus, the next part. The TVU’s replay-then-vote step is the seam where the pipeline hands off to it.

From here the book widens out: consensus turns the pipeline’s per-validator votes into a single agreed chain; later parts examine the economics that pay validators to run this expensive machine and the reliability work that keeps the firehose from drowning the node. But the mechanical core is now complete. You can trace a transaction from sendTransaction to a supermajority vote and name, at every hop — Gulf Stream, the TPU’s four stages, Turbine’s tree, the TVU’s replay — which stage is doing the work, which earlier idea makes it possible, and what breaks if that stage stalls. That trace is the answer to this part’s question: a validator ingests, orders, executes, and propagates at hardware speed because it is a pipeline whose stages never wait on each other, fed by parallelism at its widest point.