Day 26 · The Throughput Problem

Project 5 and Project 6 each built a chain by asking “what should this be for?” Bitcoin’s answer was sound, censorship-resistant money; Ethereum’s was a programmable world computer. Both, by design, are slow — Bitcoin settles a handful of transactions per second, Ethereum’s base layer a few dozen. Before we write a line of solmini, this page answers the question that drove every Solana design decision: what if you optimized a single chain almost entirely for throughput and cost? Everything that looks weird about Solana — the clock, the parallel scheduler, the beefy validators — falls out of taking that one goal seriously.

What Solana optimized for

Pick any system and you can usually find the one number its designers refused to compromise. For Solana that number is transactions per second per dollar of fees. The thesis, from the project’s origins around 2017–2018, was that a blockchain should feel like the internet: cheap enough that a transaction costs a rounding error, and fast enough that confirmation feels instant. That goal is the lens for the whole project.

Crucially, “make it fast” is not one problem — it’s several, and Solana attacked each with a named mechanism. Two of them are what you’ll build:

• Agreeing on order is expensive. If validators must message each other to agree on when each transaction happened, that conversation becomes the bottleneck. Proof of History (Day 27) removes the conversation: a hash chain that is the clock, which every validator verifies independently.
• Executing transactions one-at-a-time wastes a 64-core machine. Ethereum runs transactions serially because it can’t know what state a contract call will touch. Sealevel (Day 29) requires every transaction to declare its accounts up front, so the runtime runs the non-conflicting ones in parallel.

PoH is a clock, not a consensus mechanism

A common misconception: Proof of History is not how Solana decides who’s right. Sybil resistance and consensus come from Proof of Stake plus Tower BFT (a PoH-anchored variant of practical Byzantine fault tolerance). PoH is a verifiable clock that makes that consensus cheaper — it lets validators agree on the order and rough timing of events without round-trips. Keep the two ideas separate: PoH orders, PoS+BFT decides. We model only the clock and the scheduler in solmini; the staking and voting are out of scope and we say so honestly.

The three chains at a glance

                 Bitcoin (p5)        Ethereum (p6)         Solana (p7)
   ───────────   ─────────────────   ───────────────────   ──────────────────────
   model         UTXO coin set       account world-state   accounts + stateless programs
   execution     fixed script        EVM, sequential       Sealevel, parallel
   ordering      PoW + longest chain  PoW→PoS, slots        PoH clock + Tower BFT
   sybil resist. Proof of Work        Proof of Stake        Proof of Stake
   optimized for decentralization /   programmability       throughput / low cost
                 security             (a shared computer)   (a fast global machine)
   scaling path  layer 2 (Lightning)  layer 2 (rollups)     scale the single L1 up

The bottom two rows are the heart of it. Bitcoin and Ethereum both increasingly scale out — push activity onto layer-2 systems and keep the base layer conservative. Solana made the opposite bet: keep one monolithic, synchronous, very fast layer-1, and pay for the speed with hardware. There’s no universally “right” choice here; they’re different points on the same trade-off surface.

By the numbers — the throughput gap

Order-of-magnitude figures, all as of ~2025 and deliberately rounded — treat them as “which power of ten,” not benchmarks:

   chain      practical TPS (simple transfers)     fee per simple tx
   ────────   ──────────────────────────────────   ─────────────────
   Bitcoin    ~7                                    dollars (varies wildly)
   Ethereum   ~15–30 on L1                          cents to dollars (varies)
   Solana     thousands of non-vote tx/s            small fractions of a cent

Solana is often quoted at a theoretical ~65,000 TPS; sustained real-world non-vote throughput is far lower (commonly low-thousands, with bursts higher). Even the conservative number is two to three orders of magnitude past Bitcoin:

   ~2,000 TPS / ~7 TPS  ≈  ~285×        (Solana vs Bitcoin, conservative)

The exact multiplier drifts with network conditions and client upgrades — the shape (two-plus orders of magnitude, at a tiny fraction of the fee) is the durable fact.

The bill for that speed: the trilemma trade-off

There’s a popular heuristic — the blockchain trilemma, framed by Ethereum co-founder Vitalik Buterin — that a chain struggles to maximize decentralization, security, and scalability all at once; push hard on one and you tend to pay in another. It’s a rule of thumb, not a theorem, but it’s a useful lens. Solana pushed scalability hard, and the bill came due mostly in decentralization pressure:

• Validators need serious hardware. As of ~2024–2025, running a Solana validator realistically wants a 12-or-more-core CPU, on the order of 256 GB of RAM (256–512 GB is commonly cited), multiple fast NVMe SSDs, and high-bandwidth networking. Compare a Bitcoin full node, which runs comfortably on a Raspberry-Pi-class machine. Heavier hardware means fewer people can afford to validate, which is real centralization pressure — an honest cost of the throughput bet, not a free lunch.
• A single fast layer is harder to keep live. Squeezing maximum performance from one synchronous chain leaves less slack; the network has historically been more prone to halting under load than the slower chains (more on that below).

Under the hood — speed comes from a pipeline, not magic

Solana doesn’t get its throughput from one trick but from treating a validator like a CPU: a pipeline of stages that each specialize and run concurrently. Transactions stream in (Gulf Stream forwards them to the expected leader without a global mempool), signatures are verified in bulk (often on a GPU), the leader stamps them into the PoH stream and executes them in parallel (Sealevel), and blocks are propagated in small shreds through a tree (Turbine). The two stages you’ll build — the PoH clock and the parallel scheduler — are the ones that make the ordering and execution stages fast. The lesson worth internalizing: high throughput is a systems-engineering result (pipelining + parallelism + a cheap clock), the same instincts you’d bring to making any server fast, applied to a blockchain.

It actually happened — the September 2021 halt, and the pattern since

On 14 September 2021, the Solana mainnet stopped producing blocks for roughly 17 hours. The trigger, per the post-mortem, was a flood of transactions (bot traffic around a token sale on Grape Protocol) that overwhelmed validators and forked the network; operators had to coordinate a restart from a known slot. It was the first of several: a multi-hour outage during an NFT-mint bot storm around 30 April – 1 May 2022, an outage of roughly a day in February 2023, and a roughly five-hour outage in February 2024 later traced to a bug in a legacy program loader.

Two things matter for accuracy. First, dates and durations above are the widely-reported figures; treat the hour counts as approximate. Second, and more important: these were overwhelmingly liveness failures — the chain halted and was restarted — not safety failures. There’s no widely-reported case of the protocol itself confirming-then-reversing transactions or minting funds from thin air during these events. Network reliability has also improved markedly since 2021 as the client matured (congestion control, local fee markets, priority fees). The clean takeaway: optimizing a single chain that hard for throughput traded away some robustness to load, and the team spent years buying it back.

Where this leaves the build

solmini won’t reproduce a validator — no signatures, no staking, no networking. It models the two ideas that make Solana Solana: the verifiable clock (Day 27) and the declare-then-parallelize execution model (Days 28–29). The crate skeleton mirrors that:

   rust/solmini/
     src/poh.rs        Day 27 — the verifiable SHA-256 clock
     src/account.rs    Day 28 — typed account buffers + keys
     src/program.rs    Day 28 — stateless programs (transfer, counter)
     src/runtime.rs    Day 29 — the conflict scheduler + parallel executor
     src/main.rs       the narrated demo you saw on the overview

Hold both threads as you go. The project’s own question — what did Solana optimize for? — you can now answer in one breath: throughput and cost, on a single synchronous chain, paid for with hardware. And the playbook’s recurring question — what is the compiler protecting you from? — is about to get its sharpest answer yet, because in two days you’ll be handing live transactions to a pool of threads, and the only reason that isn’t terrifying is that Rust makes the data race unrepresentable.

→ Next: Day 27 · Proof of History · Back to the Project 7 overview

Check your understanding

1. In one sentence, what single quantity did Solana optimize for, and what two execution-level bottlenecks did it have to beat to get there?
2. Why is it inaccurate to call Proof of History a consensus mechanism? What actually provides Solana’s sybil resistance and consensus?
3. State the blockchain trilemma. Which corner did Solana push hardest, and in which corner did it mostly pay for that?
4. Contrast Solana’s scaling strategy with Ethereum’s. What does “scale the single L1 up” mean versus “scale out”?
5. Solana’s historical outages were mostly liveness failures, not safety failures. Explain the difference and why it matters for judging the trade-off.

Show answers

1. It optimized for transactions per second at the lowest possible cost (throughput per dollar of fees). To get there it had to beat the cost of validators agreeing on order (solved with Proof of History, a clock) and the waste of executing transactions serially (solved with Sealevel, parallel execution).
2. PoH only establishes the order and rough timing of events — it’s a verifiable clock. Sybil resistance and consensus come from Proof of Stake plus Tower BFT; PoH makes that consensus cheaper but doesn’t decide who is correct.
3. The trilemma is the heuristic that a chain struggles to maximize decentralization, security, and scalability simultaneously. Solana pushed scalability hardest and paid mostly in decentralization (heavy validator hardware → fewer validators), with some robustness-to-load cost.
4. Ethereum increasingly scales out — keep a conservative base layer and push activity to layer-2 rollups. Solana scales up — keep one monolithic, synchronous, very fast layer-1 and pay for the speed with better hardware and parallelism rather than extra layers.
5. A liveness failure means the chain stopped making progress (it halted and had to be restarted); a safety failure would mean it produced incorrect results (e.g. reversing a confirmed transaction or minting funds). Solana’s outages halted the network but didn’t corrupt the ledger — so the bet cost uptime under load, not the integrity of the money, which is a far less severe failure mode.