Solana's Architecture

The previous page showed Ethereum trading energy for staked capital — but it still produces blocks every ~12 seconds and executes transactions one at a time. Solana is the chain built around the opposite obsession: raw speed. Sub-second blocks, fees fractions of a cent, throughput orders of magnitude above Bitcoin or Ethereum’s base layer. It gets there with three signature ideas — Proof of History, Sealevel, and Gulf Stream — that are genuinely clever and worth understanding. But this is a first-principles part, so we apply the same discipline as everywhere else: what does that speed cost? The honest answer involves serious hardware requirements and a real, dated history of the network going down. We’ll cover both, balanced.

First: Solana is still Proof of Stake (with a clock bolted on)

A common myth is that “Proof of History” is Solana’s consensus or its Sybil defense. It isn’t. Solana ranks validators by staked SOL — its Sybil resistance is Proof of Stake, like post-Merge Ethereum. What Proof of History adds is a cryptographic clock that lets those validators agree on the order and timing of events without chattering back and forth about timestamps. Keep these two jobs separate:

   Sybil resistance (who gets influence)   :  Proof of STAKE  (stake SOL)
   Ordering / timekeeping (when things happen) :  Proof of HISTORY (a hash clock)
   Final agreement (which fork wins)       :  a PoS BFT vote ("Tower BFT") that uses the PoH clock

Proof of History — a verifiable clock

Proof of History (PoH), introduced by Solana’s founder Anatoly Yakovenko (whitepaper ~2017, mainnet beta launched March 2020), is the idea Solana is most known for. The problem it solves: in a distributed system, agreeing on what time it is — and on the order events happened — normally costs a lot of back-and-forth messaging. PoH removes most of that by creating time that is provable from the data itself.

The mechanism is a long, unbroken SHA-256 hash chain that feeds its own output back in as the next input, over and over, as fast as the hardware can run:

   h0 = hash(seed)
   h1 = hash(h0)
   h2 = hash(h1)
   ...                ← cannot be parallelized: each step needs the previous output
   hN = hash(h_{N-1})

Because each hash must wait for the one before it, the only way to produce hN is to actually run N sequential hashes — which takes a roughly predictable amount of wall-clock time. So the count of hashes becomes a trustworthy stopwatch: if a message is stamped between h1000 and h1001, you have cryptographic proof it existed at that point in the sequence. Crucially, while producing the sequence is strictly sequential, verifying it can be checked in parallel across many cores — the same hard-to-make / easy-to-check asymmetry that powers Proof of Work, repurposed as a clock rather than a lottery.

PoH is a stopwatch, not a vote

Don’t confuse Proof of History with Proof of Work. PoW rations influence by burning energy on a lottery. PoH measures the passage of time so validators don’t have to negotiate timestamps — it decides ordering, not who wins. Solana still needs Proof of Stake to decide whose blocks count. PoH’s payoff is speed: with a shared, verifiable clock baked in, the leader can stream a firehose of ordered transactions and everyone agrees on their sequence without a round of “what time do you have?” messages.

Sealevel — execute transactions in parallel

Recall the deep problem from the account-model page: shared mutable state forces sequential execution, because the result depends on ordering. Ethereum’s base layer runs transactions one at a time for exactly this reason. Sealevel is Solana’s attempt to escape that trap.

The trick: every Solana transaction must declare, up front, exactly which accounts (state) it will read and which it will write. Armed with that list, the runtime can see which transactions overlap and which don’t:

   tx A : writes account X            ┐
   tx B : writes account Y            ├─ X, Y, Z all different  →  run A, B, C in PARALLEL
   tx C : writes account Z            ┘    (across many CPU cores)

   tx D : writes account X            ┐
   tx E : writes account X            ┘  both touch X  →  must run in some defined ORDER

Non-overlapping transactions run simultaneously across all the cores of a multi-core machine; only transactions that touch the same account are forced to serialize. This is Solana recovering, by explicit up-front declaration, the parallelism that Bitcoin’s UTXO model gets almost for free (independent coins) and that Ethereum’s account model threw away. It is a real engineering achievement — and it asks more of developers, who must correctly declare every account a transaction touches.

Gulf Stream — push transactions ahead of time

The third idea attacks latency. On Bitcoin and Ethereum, unconfirmed transactions sit in a mempool waiting for whoever mines/proposes next. Solana, because of the PoH clock, knows the leader schedule in advance — which validator will produce blocks in upcoming slots. Gulf Stream uses that to forward transactions to the expected upcoming leaders before it’s even their turn, so the leader can start ordering and executing the moment its slot arrives, instead of first gathering a mempool.

   Bitcoin/Ethereum :  tx → big shared mempool → wait for next miner/proposer to pull it
   Solana (Gulf Stream) :  tx → pushed straight to the KNOWN upcoming leaders, ahead of time

The benefit is lower latency and less memory spent holding a giant pending pool. The cost is subtler and central to this page: it assumes validators are beefy and well-connected enough to receive and process that firehose — which pushes us straight to the trade-off.

The real cost — hardware centralization and outages

Solana’s speed is not magic; it is bought with hardware. To keep up with sub-second slots, parallel execution, and the Gulf Stream firehose, a validator needs a high-core-count CPU, a very large amount of RAM, fast NVMe SSDs, and serious bandwidth. Compare the philosophies:

	Bitcoin	Solana
Run a full node on	A Raspberry Pi / old laptop (deliberately)	A high-end server (many cores, lots of RAM, fast SSD, big bandwidth)
Design priority	Anyone can verify the chain cheaply	Maximum throughput and low latency
Decentralization cost	Throughput is low by design	Far fewer parties can afford to run a validator

Bitcoin treats cheap verifiability as sacred — the whole point of Proof of Work’s asymmetry is that a hobbyist on a Raspberry Pi can check the chain. Solana treats throughput as the priority, accepting that fewer, more powerful machines will run the network. That is a coherent choice — but it is a centralization pressure, and it has a visible track record.

It actually happened — Solana’s outages (2021–2022, dated)

Solana’s headline cost has been liveness: the network has halted or required a coordinated restart multiple times. The clearest, best-documented case:

• 14 September 2021 — a roughly 17-hour outage. A surge of automated transactions (bots contending in a token launch) overwhelmed validators; the flood exhausted memory and the network forked and stalled, ultimately requiring validators to coordinate a restart. The chain does not “stay up no matter what” the way Bitcoin’s has — restarting it depends on enough validators cooperating off-chain.
• Spring 2022 (around late April–May and June 2022) — further multi-hour outages and severe degradation, again largely driven by transaction floods (e.g. NFT-mint bots) that the network couldn’t shed cleanly.

A handful of additional halts and degraded periods occurred into 2023–2024, generally at lower frequency as the team shipped mitigations — among them local fee markets / priority fees (so congestion on one hot program doesn’t have to spike the whole network), a QUIC-based transaction ingress, and stake-weighted quality of service to throttle spam. The pattern is the throughline of this page: a design optimized for raw speed and a no-fee-friction firehose is more exposed to resource-exhaustion failures, and the fix has been ongoing engineering. (Specific durations and dates above are the well-known ones; treat finer details as approximate and check current sources.)

By the numbers — speed claims, dated and hedged

Solana’s marketing figure of “up to 65,000 transactions per second” is a theoretical/lab number; real sustained throughput is much lower and historically a large share of transactions have been validator vote transactions rather than user payments. Useful framing, not gospel:

   target slot time     :  ~400 ms   (vs Bitcoin's ~10 min, Ethereum's ~12 s)
   advertised peak TPS   :  "tens of thousands" (theoretical — hedge heavily)
   realistic sustained user TPS :  far lower, varies by load and over time
   fees                 :  fractions of a cent (as of the mid-2020s)

The honest takeaway isn’t a precise number — it’s the order of magnitude: Solana is built to be dramatically faster and cheaper per transaction than either base layer, and it pays for that with the hardware bar and liveness risks above. Always date and sanity-check any specific TPS or fee figure.

Local fee markets — a genuinely good idea

One Solana innovation deserves credit on its own terms and recurs later in Fees, Throughput & Blockspace. Because Sealevel already knows which accounts each transaction touches, Solana can run localized fee markets: a frenzy of demand for one popular program (say a single NFT mint or token) raises priority fees for that specific hot account, rather than spiking fees for everyone network-wide the way a single shared fee market does. It’s a neat consequence of the up-front account declarations — the same design choice that enables parallel execution also enables localized congestion pricing.

The thread

How does Solana let untrusting strangers agree on one ledger — and what did the bargain cost? It keeps the foundations: Proof of Stake rations influence by scarce staked capital, so identities still can’t be faked, and Proof of History gives every validator the same verifiable clock so they agree on order without trusting anyone’s timestamp. On top of that it layers Sealevel and Gulf Stream to push throughput far past the base layers. The bargain is paid in the resource this whole book treats as sacred — cheap, universal verifiability. When a node must be a high-end server, fewer strangers can independently check the ledger, and when the network is tuned to swallow a firehose, it has repeatedly proven easier to knock over. Solana isn’t “wrong”; it sits at a different point on the same spectrum — buying speed and cheapness with the very decentralization and bulletproof liveness that Bitcoin spends everything to protect. Which trade is worth it is exactly the question Why Three Chains Exist closes the part on.

The architect’s lens

Solana’s three signature ideas are a deliberate throughput-first bet — interrogate the bargain:

• Why does it exist? Proof of History (a verifiable hash-chain clock), Sealevel (parallel execution), and Gulf Stream (mempool-less forwarding to known upcoming leaders) exist to push raw throughput far past Bitcoin’s or Ethereum’s base layer — sub-second slots, sub-cent fees.
• What problem does it solve? Coordination cost and latency: PoH lets validators agree on order/timing without chattering about timestamps; Sealevel reclaims the parallelism the account model threw away by making each tx declare the accounts it touches; Gulf Stream removes the waiting mempool.
• What are the trade-offs? Speed is bought with hardware — a validator needs a high-core CPU, lots of RAM, fast NVMe, big bandwidth — a real centralization pressure, and the firehose design has a dated record of liveness failures (the ~17-hour 14 Sept 2021 halt; spring-2022 outages).
• When should I avoid it? This monolithic, throughput-first design is the wrong bet where cheap, universal verifiability and bulletproof liveness are sacred — Bitcoin spends everything so a Raspberry Pi can verify the chain, and hasn’t had an unplanned network-wide halt since 2013.
• What breaks if I remove it? Strip PoH and Gulf Stream’s known-leader-schedule forwarding can’t work — validators fall back to negotiating timestamps and the latency edge that justifies the whole architecture evaporates. (Note: PoH is ordering, not Sybil resistance — that’s still Proof of Stake.)

Check your understanding

1. Proof of History is often misdescribed as Solana’s consensus. What does it actually provide, and what mechanism gives Solana its Sybil resistance?
2. Explain how a sequential SHA-256 hash chain functions as a trustworthy clock — and why it’s sequential to build but parallel to verify.
3. What must every Solana transaction declare up front, and how does Sealevel use that to run transactions in parallel?
4. What does Gulf Stream do differently from a traditional mempool, and what does it assume about validators?
5. State the central trade-off Solana makes versus Bitcoin, and give one concrete, dated example of the cost showing up.

Show answers

1. Proof of History provides a verifiable cryptographic clock — agreement on the order and timing of events without back-and-forth messaging — not consensus or Sybil defense. Solana’s Sybil resistance is Proof of Stake (validators ranked by staked SOL); final fork choice is a PoS BFT vote (“Tower BFT”) that uses the PoH clock.
2. Each hash takes the previous hash as input (h_{n} = hash(h_{n-1})), so producing hN requires running N hashes one after another — a roughly fixed amount of wall-clock time, making the hash count a trustworthy stopwatch (anything stamped between two hashes provably existed at that point). It’s sequential to build (each step needs the prior output) but can be verified in parallel across many cores — the same hard-to-make / easy-to-check asymmetry as Proof of Work, used as a clock instead of a lottery.
3. Every transaction must declare exactly which accounts it will read and write. Sealevel uses those lists to see which transactions don’t overlap and runs those simultaneously across CPU cores, forcing only transactions that touch the same account to serialize — recovering the parallelism that the account model otherwise loses.
4. A traditional mempool holds unconfirmed transactions until the next miner/proposer pulls them. Gulf Stream instead forwards transactions to the known upcoming leaders ahead of their slot (possible because the PoH-based leader schedule is known in advance), cutting latency and memory. It assumes validators are powerful and well-connected enough to ingest and process that firehose.
5. Solana trades cheap, universal verifiability / decentralization for raw throughput and low fees: a validator needs a high-end server (many cores, lots of RAM, fast SSD, big bandwidth) where Bitcoin runs on a Raspberry Pi. The cost has shown up as liveness failures — e.g. the ~17-hour outage on 14 September 2021 (bot transaction flood exhausted validators, forcing a coordinated restart), plus further multi-hour outages in spring 2022.