Scale Up, Not Out — Solana's Thesis

The previous page showed the wall every blockchain hits: a chain is a state machine that many untrusting parties must agree on, and the cheapest way to guarantee they agree is to run one transaction after another, in a single agreed order. That serialization is the ceiling. Every design decision after it is really an answer to one question: given that ceiling, how do you get more throughput out of the machine?

There are only two shapes of answer. You can scale out — keep the base layer slow and conservative, and push activity onto other layers that settle back to it. Or you can scale up — keep a single global state machine and make that one machine faster, by throwing bandwidth, cores, and pipelining at it. Bitcoin and Ethereum chose scale-out. Solana chose scale-up, and that one choice explains almost everything strange about it. This page states the thesis plainly, shows why a single synchronous machine is worth fighting for, and — because this book keeps itself honest — names exactly what the bet costs.

Two ways to scale a chain

Say demand for blockspace doubles. You have two levers.

Scale out. Leave the base layer roughly as slow as it was. Absorb the extra demand on other systems — payment channels, rollups, sidechains — that do their work off the main chain and periodically settle a compressed summary back to it. The base layer stays small enough that a hobbyist can verify the whole thing on a cheap machine; the throughput lives one layer up.

Scale up. Keep everything on one layer, and make that layer eat the extra demand directly: faster networking to move transactions, more CPU cores to execute them, a cheaper way to agree on their order. The base layer is the fast layer. There is no “up one level” — there is just a bigger, better-engineered single machine.

   SCALE OUT (Bitcoin, Ethereum)         SCALE UP (Solana)
   ─────────────────────────────         ─────────────────

        user tx                                user tx
          │                                      │
          ▼                                      ▼
   ┌──────────────┐  rollups / channels    ┌──────────────────────┐
   │  L2 / L3     │  do the volume         │  ONE L1              │
   │  (fast, many)│                        │  parallel execution, │
   └──────┬───────┘                        │  pipelined validator │
          │ settle a summary               │  (does the volume    │
          ▼                                │   itself)            │
   ┌──────────────┐  slow, conservative    └──────────────────────┘
   │  base L1     │  base layer that a
   │  (secure,    │  cheap node can verify
   │   verifiable)│
   └──────────────┘

Neither lever is “correct.” They are different points on the same trade-off surface, chosen by teams optimizing for different things. But they lead to radically different systems, so it is worth understanding each on its own terms.

Scale-out: the L2 school

Bitcoin’s base layer settles a handful of transactions per second, and its culture treats base-layer changes as near-irreversible and therefore rare. So Bitcoin scales off the chain: Lightning moves ordinary payments into two-party channels that settle to the base layer only when they open or close. The main chain stays a slow, maximally-verifiable backstop; the speed lives in the channel network.

Ethereum made the same choice explicit as official strategy: don’t scale execution on L1 — scale it on rollups. A rollup executes transactions off-chain in bulk, then posts compressed data (and a fraud or validity proof) back to Ethereum, which acts as the settlement and data-availability layer. Ethereum even changed its base layer specifically to make rollups cheaper — the Dencun upgrade (13 March 2024) added “blob” data priced for exactly this. The base layer’s job became hosting other layers well.

The unifying idea: keep verification cheap on L1, push execution off it. A cheap node can still check the base layer, decentralization is protected, and the volume happens somewhere that doesn’t burden every validator. The cost is fragmentation — value and liquidity end up spread across many L2s that don’t share one state, and bridging between them is where a great deal of real-world risk lives.

Scale-up: the monolithic school

Solana rejects the premise. Its wager is that with enough engineering you can do everything on one fast base layer — no rollups, no channels, no sidechains for normal activity. “Scaling” means making the single L1 itself faster. When bandwidth and core counts grow — as they do every hardware generation — the chain gets faster for free, because it was built to ride the hardware curve rather than route around it.

That is the thesis in one line:

Don’t shard. Keep a single global state machine, and scale it up as bandwidth and compute grow.

Everything you will learn later in this book — the eight core innovations, the verifiable clock, the parallel scheduler, the pipelined validator — is machinery in service of that one sentence. Solana is not a pile of clever tricks; it is a single bet, executed relentlessly.

Why one synchronous machine is worth fighting for

Scaling up is hard. So why not just shard and be done? Because a single synchronous state machine buys three properties that a sharded system has to work to fake, and often can’t.

Atomic composability

On one machine, any transaction can touch any state atomically. A single transaction can read from a lending protocol, swap on a DEX, and deposit into a vault — three different programs — and if any step fails, the whole thing reverts as a unit. No program had to know the others existed. This is composability, and it is the reason “money legos” is a real phrase in this ecosystem: programs snap together because they all live in, and mutate, one shared state under one clock.

Shard the state across many chains or rollups and this evaporates. Now a “swap then deposit” that crosses a shard boundary is two operations on two machines, and you must either build a cross-shard messaging protocol (slow, and a new failure surface) or accept that the two steps are no longer atomic — one can succeed while the other fails, which in finance is exactly the situation you least want.

   ONE MACHINE                        SHARDED
   ───────────                        ───────

   tx { swap; deposit } ── atomic     shard A: swap  ─┐
        all-or-nothing                                │ cross-shard
        one state, one clock          shard B: deposit┘ message
                                       (async, can half-complete)

One consistent global state — no cross-shard messaging

A sharded world has no single “now.” Each shard has its own head, and reconciling them means passing messages, waiting for the other shard’s finality, and reasoning about states that briefly disagree. Every one of those is latency, complexity, and a place for bugs to hide. On a single synchronous machine there is exactly one global state and one order of events; a program never has to ask “which version of the world am I looking at?” The whole category of cross-shard coordination bugs simply does not exist, because there is nothing to coordinate.

One place to find liquidity and users

Fragmentation has an economic cost as well as a technical one. Spread activity across fifty L2s and you spread liquidity across fifty pools, users across fifty bridges, and developers across fifty deployment targets. A single global machine concentrates all of it in one place — which is why the scale-up bet is as much about network effects as about transactions per second.

The through-line of this whole book — how do you build a single global state machine that runs at hardware speed without falling apart? — is really a promise to preserve these three properties while going fast. That “without falling apart” clause is where the hard part, and the honesty, lives.

The trilemma, and where Solana plants its flag

There is a popular heuristic, framed by Ethereum co-founder Vitalik Buterin, called the blockchain trilemma: a chain struggles to maximize decentralization, security, and scalability all at once. Push hard on one corner and you tend to pay in another. It is a rule of thumb, not a theorem — but it is a genuinely useful lens for reading design choices, because it forces the question “if this chain is winning at X, what is it quietly paying?”

                    Decentralization
                         /\
                        /  \
                       /    \
                      /      \
                     /        \
          Security  /__________\  Scalability  ◄── Solana pushes here

Solana plants its flag firmly on the scalability corner. It optimizes almost single- mindedly for throughput at low cost, on one synchronous layer. By the trilemma’s logic, that choice has to be paid for somewhere — and it is, mostly in the decentralization corner. Which brings us to the honest part.

The cost of the bet — stated honestly

A first-principles book does not sell you a corner of the triangle as if it were free. Here is the bill for scaling up, in plain terms.

Less slack under load. Squeezing maximum performance out of one synchronous chain leaves little headroom. A scale-out chain that gets overwhelmed can lean on its conservative base layer and its L2s; a scale-up chain that gets overwhelmed has nowhere to offload, so heavy load has historically pushed the network toward liveness failures — the chain halts and has to be restarted — rather than gracefully degrading. This is the “without falling apart” clause failing in practice, and it is the exact problem the rest of this book is about engineering around.

Centralization pressure from hardware. If the single machine must be fast, every validator must run fast hardware. As of roughly 2024–2025 a realistic Solana validator wants a 12-plus-core CPU, on the order of 256 GB of RAM, fast NVMe SSDs, and high-bandwidth networking — where a Bitcoin full node runs comfortably on a Raspberry-Pi-class machine. Heavier hardware means fewer people can afford to validate, and fewer validators is real centralization pressure. It is the trilemma’s bill, paid in the decentralization corner.

It actually happened — the September 2021 halt

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

Two points, both important. First, treat the hour counts as the widely-reported approximations they are. Second, and more telling: these were overwhelmingly liveness failures — the chain halted and was restarted — not safety failures. There is no widely-reported case of the protocol confirming-then-reversing transactions or minting funds from nothing during these events. The scale-up bet cost uptime under load, not the integrity of the ledger — a far less severe failure mode, and one the team has spent years buying back with congestion control, local fee markets, and priority fees.

By the numbers — the two bills, side by side

Order-of-magnitude figures, deliberately rounded — read them as “which power of ten,” not as benchmarks:

                       Bitcoin (scale-out)      Solana (scale-up)
   ─────────────────   ──────────────────────   ─────────────────────────
   node hardware       Raspberry-Pi-class        12+ cores, ~256 GB RAM,
                                                  NVMe, fast networking
   base-layer TPS      ~7                         thousands of non-vote tx/s
   who can validate    almost anyone              well-funded operators
   failure under load  base layer just stays      has historically halted
                       slow; L2s absorb it        (liveness, then restart)

The shape is the durable fact: Solana buys two-plus orders of magnitude more throughput on one layer, and pays with a heavier hardware floor and less slack under load. The exact numbers drift with client upgrades — the trade shape does not.

Under the hood — why “scale up” can even work

Naïvely, “one machine, faster” sounds like it just means “wait for a faster CPU.” It does not. Solana’s scale-up works because it treats a validator like a CPU pipeline: a chain of specialized stages that run concurrently rather than one big serial loop. Transactions stream in and are forwarded to the expected leader; signatures are verified in bulk (often on a GPU); the leader stamps them into a verifiable clock and executes the non-conflicting ones in parallel; blocks propagate through a tree in small pieces. Each stage scales with a different hardware resource — network, GPU, cores, disk — so throwing more of each kind of hardware at the machine raises throughput without breaking the single global state.

That is the deep reason the bet is coherent: high throughput here is a systems- engineering result — pipelining plus parallelism plus a cheap way to agree on order — not a consensus trick. It is the same instinct you would bring to making any server fast, applied to a state machine that thousands of untrusting parties must agree on. The eight core innovations are the names of those stages, and what “hardware speed” means makes the “rides the hardware curve” claim precise.

The architect’s lens

The single-monolithic-L1 model is the master decision of this whole book — interrogate it before you fall in love with the throughput numbers.

• Why does it exist? Because sharding a blockchain to scale it out breaks composability and forces cross-shard messaging; a single synchronous L1 keeps one global state and one order of events, and bets that hardware and pipelining can make that one machine fast enough to not need L2s.
• What problem does it solve? Fragmentation. It gives every program atomic composability over one shared state, one consistent “now,” and one place for liquidity and users to gather — none of which a sharded, scale-out system gets for free.
• What are the trade-offs? The trilemma bill, paid in decentralization: a fast single machine demands heavy validator hardware (fewer validators) and leaves little slack, so it is more exposed to load-driven liveness failures than a conservative scale-out chain.
• When should I avoid it? When you value maximal decentralization and base-layer conservatism above raw throughput — if a Raspberry-Pi-class node verifying everything and a chain that degrades gently rather than halting matter more to you, the scale-out (Bitcoin/Ethereum) model is the better fit.
• What breaks if I remove it? Drop the single-machine premise and you inherit the L2 world’s problems: state splits across shards, atomic multi-program transactions become cross-shard messages that can half-complete, and liquidity fragments — exactly the costs Solana is spending decentralization to avoid.

Check your understanding

1. In one sentence each, contrast “scale out” and “scale up” as strategies for handling a doubling of demand for blockspace.
2. State Solana’s thesis in a single sentence, and name the three properties a single synchronous state machine buys that a sharded system has to fake.
3. What is “atomic composability,” and why does sharding the state across chains break it?
4. State the blockchain trilemma. Which corner does Solana push hardest, and in which corner does it mostly pay?
5. Name the two honest costs of the scale-up bet, and explain why Solana’s historical outages being liveness failures rather than safety failures softens (but does not erase) the first cost.

Show answers

1. Scale out: leave the base layer slow and conservative and absorb the extra demand on other layers (channels, rollups, sidechains) that settle summaries back to it. Scale up: keep everything on one layer and make that single machine eat the demand directly, with more bandwidth, cores, and pipelining.
2. Thesis: don’t shard — keep a single global state machine and scale it up as bandwidth and compute grow. The three properties: atomic composability, one consistent global state (no cross-shard messaging), and one place for liquidity and users to concentrate.
3. It means any transaction can touch any state all-or-nothing — read a lending protocol, swap on a DEX, and deposit into a vault in one transaction that reverts as a unit if any step fails. Sharding splits that across machines, so a cross-boundary sequence becomes async cross-shard messages that can half-complete, destroying the atomic guarantee.
4. The trilemma is the heuristic that a chain struggles to maximize decentralization, security, and scalability at once. Solana pushes scalability hardest and pays mostly in decentralization (heavy validator hardware → fewer validators), with some robustness-to-load cost.
5. The two costs: less slack under load (more exposure to load-driven liveness failures) and centralization pressure from hardware (a fast single machine needs expensive validators, so fewer people can run one). A liveness failure means the chain stopped and was restarted; a safety failure would mean it produced incorrect results (reversing a confirmed tx, minting funds). Solana’s halts cost uptime, not ledger integrity — a much less severe failure mode — but the exposure to halting under load is still a real cost of the bet.