Solana: Proof of History and Parallelism

In November 2021, Solana processed 400,000 transactions per second in a stress test - and an hour later went down for 17 hours. A network claiming 65,000 TPS and a slot every 400 milliseconds has suffered more than 10 major outages over two years. How can the same architecture be simultaneously the fastest and the least stable? The answer lies in four innovations, each of which squeezes the maximum out of hardware but creates its own failure points. Today we will break down those four mechanisms: the cryptographic clock, the parallel runtime, BitTorrent for blocks, and forwarding without a mempool.

• **DeFi on Solana** processes ~$2B in daily volume: DEX aggregators (Jupiter), lending (Marginfi, Kamino), perps (Drift) - all at fees of ~$0.001 per transaction, impossible on Ethereum L1
• **Helium** - a decentralized wireless network - migrated from its own blockchain to Solana in 2023: 1 million IoT hotspots generate tens of thousands of transactions daily, and only Solana's throughput made it possible to process them with acceptable latency
• **Visa** launched a USDC settlement pilot on Solana in 2023, choosing the network for its sub-second finality and low fees - for a system processing 65,000 TPS in the real world, every millisecond matters

Предварительные знания

• The Consensus Problem: Why and How

Proof of History: cryptographic clock

The main problem in distributed systems is **time**. When two nodes on different continents create transactions 'simultaneously', which one was first? In Bitcoin this question is resolved by brute force: a block every 10 minutes, order determined by the chain. But 10 minutes is an eternity. Anatoly Yakovenko, an engineer from Qualcomm, reframed the question: what if we could create a **cryptographic proof that time has passed**, without relying on other nodes' clocks?

**Proof of History (PoH)** is a sequential chain of SHA-256 hashes where each next hash is computed from the previous one. This is a **verifiable delay function (VDF)**: you cannot compute hash number 1,000,000 without computing all the preceding 999,999 hashes. But **verification** can be done in parallel - split the chain into segments and verify them simultaneously on different cores.

PoH is **not consensus**. It is a cryptographic clock that gives the entire network a single reference point in time. Consensus in Solana is provided by **Tower BFT** - a modification of PBFT that uses PoH as the time source instead of network timeouts. In classic PBFT, nodes exchange 'I am ready', 'I voted', 'I confirmed' messages - and wait for responses. Tower BFT replaces these timeouts with PoH ticks: a validator's vote 'expires' after a certain number of ticks, not after a wallclock timeout. This reduces message complexity from O(n^2) to O(n).

**Why SHA-256 and not a specialized VDF?** Researchers have proposed VDFs based on RSA or elliptic curves (Boneh et al., 2018), but SHA-256 has two advantages: 1. decades of cryptanalysis confirm its security 2. hardware acceleration of SHA-256 is well-understood - Solana validators use GPUs for parallel verification of the PoH chain.

Sealevel: parallel transaction execution

Ethereum executes transactions **strictly sequentially**: the EVM takes a transaction from the block, changes the global state (balance, storage), takes the next one. Even if Alice is transferring to Bob and Charlie is deploying a contract - they are processed one after another. Why? Because the EVM works with **global state**: any transaction can read or modify any storage slot of any contract. **Sealevel** - Solana's runtime - solves this through a radically different model: **each transaction declares in advance which accounts it will read and write**.

The key difference between Solana and EVM: **programs (smart contracts) are stateless - they don't store data**. All state lives in **accounts**, and programs are pure functions that take accounts as input, process them, and return the modified state. This is like the difference between OOP and functional programming: - **EVM**: a `Contract` object stores its data internally (storage slots), and the `transfer()` method modifies internal state - **Sealevel**: a function `process_transfer(account_a, account_b, amount)` takes accounts as arguments, modifies them, returns the result

Sealevel uses **read/write locks** at the account level - analogous to databases: - Multiple transactions can **read** one account simultaneously (shared read lock) - Only one transaction can **write** to an account (exclusive write lock) - If a transaction declared `isWritable: true` for an account, other transactions with the same account wait In practice this gives significant parallelism: in a typical Solana block ~70-80% of transactions work with different accounts and run in parallel on different CPU cores.

**Why can't Ethereum just add parallelism?** Projects like **Sei** and **Monad** implement **optimistic parallel execution**: they run transactions in parallel, and if a conflict is detected - they roll back and re-execute sequentially. This works, but is less efficient than Solana's approach where conflicts are known **before** execution. The price of Solana's parallelism - the developer must enumerate all accounts in advance, which complicates some patterns (e.g., composability between DeFi protocols).

Turbine: block propagation like BitTorrent

Solana produces blocks every ~400 ms. At throughput of thousands of transactions, a block can weigh **hundreds of kilobytes**. If the leader sends a block directly to **every** validator - with 2,000+ validators that's gigabytes of outbound traffic per second. In Ethereum this is not a problem: a block every 12 seconds, ~100 KB. In Solana with 400 ms per block and 2,000 validators - direct broadcasting is physically impossible. **Turbine** solves this by splitting the block into small packets and propagating them hierarchically - on the BitTorrent principle.

Turbine works in three stages: 1. **Shredding** - the leader splits the block into **shreds** (fragments of ~1280 bytes, a UDP packet size) 2. **Erasure coding** - adds redundant shreds through Reed-Solomon codes: from 32 data shreds, 32 parity shreds are created, and any **32 of 64** are sufficient to reconstruct the block 3. **Tree propagation** - validators are organized into a tree (turbine tree): the leader sends shreds to the first layer, they forward to the second, and so on

**Why is erasure coding critical for the turbine tree?** If a node on layer 1 crashes or is malicious - all 200 nodes in layer 2 that depend on it won't receive shreds. Reed-Solomon codes allow reconstructing the full block from **any 50%** of packets. Even if half the nodes along the path are silent - the block is recovered. For comparison: Ethereum's gossip protocol forwards **the entire block** to each peer. This is reliable but slow and costly in bandwidth. Turbine sacrifices simplicity for throughput - and this is critical at 400 ms per block.

**Turbine tree is an attack vector.** A malicious validator in layer 1 can deliberately not forward shreds, creating a 'shadow' for all nodes below in the tree. Solana mitigates this through: 1. randomizing positions in the tree each slot 2. erasure coding for loss recovery 3. repair protocol - nodes request missing shreds from neighbors. Nevertheless, attacks on the turbine tree were a real vector during Solana's outages in 2022.

Gulf Stream: forwarding without a mempool

In Bitcoin and Ethereum, transactions go into the **mempool** - a queue of unconfirmed transactions. Each node keeps its own copy of the mempool, and when it's time to create a block, the leader (miner/validator) picks transactions from it. The problem: the mempool spans **10,000+ nodes**, each storing and relaying the same transactions. During peak load, Ethereum's mempool can contain 100,000+ transactions, consuming gigabytes of RAM. Solana abandons the mempool entirely. **Gulf Stream** forwards transactions **directly to the expected leader** - before they even start producing a block.

This is possible thanks to the **Leader Schedule** from PoH: the leader schedule is known for the entire epoch (~2 days ahead). Every validator knows who will be the leader in 2-3 slots. So instead of broadcasting to a mempool, the client (wallet) sends the transaction **to the current leader and several upcoming ones**.

**Trade-off**: Gulf Stream places more trust in the leader schedule. If the leader is malicious - they see incoming transactions before anyone else and can extract MEV (Maximal Extractable Value). Ethereum has **PBS (Proposer-Builder Separation)** and **MEV-Boost** for role separation. Solana has **Jito** playing an analogous role - a protocol-aware MEV infrastructure: - **Jito Block Engine** - external builder that assembles transaction bundles - **Jito-Solana** - a modified client that accepts bundles from the block engine - **Tips** instead of priority fees - MEV-searchers pay tips for bundle inclusion The Jito MEV protocol processes ~50-60% of Solana mainnet transactions, making it a de facto standard.

Gulf Stream also affects **confirmation latency**. Since the transaction reaches the leader almost instantly (1-2 network hops instead of gossip across the whole network), confirmation arrives in ~400 ms (one slot). For comparison: - **Bitcoin**: ~60 minutes (6 confirmations) - **Ethereum**: ~12 seconds (1 slot) + ~13 minutes for finality (2 epochs) - **Solana**: ~400 ms (optimistic confirmation), ~12-13 seconds (rooted finality - when 2/3+ of validators have confirmed)

**QUIC instead of UDP.** Originally Solana used raw UDP for Gulf Stream. This led to spam attacks in 2022: bots flooded the leader with millions of transactions. In 2023 Solana switched to **QUIC** (HTTP/3 transport) - this provided transport-level rate limiting, TLS authentication, and flow control. The switch to QUIC significantly reduced the effectiveness of spam attacks.

Key ideas

• **Proof of History** - a sequential SHA-256 hash chain acting as a cryptographic clock: generation is strictly sequential (O(N)), while verification is parallel (O(N/k)). PoH is not consensus, but a **time source** that Tower BFT uses instead of network timeouts, reducing message complexity to O(n)
• **Sealevel** executes transactions **in parallel** because each transaction declares its accounts (read/write) in advance. Programs are stateless, state lives in accounts - read/write locks allow Sealevel to distribute independent transactions across CPU cores without speculative execution
• **Turbine** solves the bandwidth problem at 400 ms per block: shredding (fragmentation into ~1.2 KB pieces), erasure coding (recovery from 50% of packets), and tree propagation (hierarchical broadcast with ~200 fanout) - inspired by BitTorrent
• **Gulf Stream** eliminates the mempool: transactions are forwarded directly to the expected leader, made possible by the deterministic leader schedule from PoH. The cost is greater trust in the leader (MEV via Jito), but the gain is confirmation in ~400 ms
• Remember the question from the start: how can the same architecture be the fastest and the least stable? Each of the four innovations (PoH, Sealevel, Turbine, Gulf Stream) optimizes its own bottleneck but creates tight dependencies - a failure in one component cascades to the others. This is the fundamental trade-off: maximum optimization vs. resilience to failures

Related topics

Solana builds on ideas from consensus, distributed systems, and parallel computing:

• The consensus problem: why and how — Tower BFT is built on PBFT ideas but replaces network timeouts with PoH ticks - this reduces message complexity and speeds up finality
• DAG-based consensus: Avalanche, Narwhal — Solana and DAG-protocols solve the same problem (parallelism) in different ways: Sealevel parallelizes execution within a single node, Narwhal parallelizes data dissemination across nodes
• Move-based blockchains: Sui and Aptos — Sui uses an object-centric model (similar to Solana accounts) for parallel execution, but with DAG-consensus (Narwhal/Bullshark) instead of leader-based Tower BFT
• P2P networks and gossip protocols — Turbine replaces classic gossip protocol with hierarchical tree propagation - a trade-off between latency, bandwidth, and fault tolerance

Вопросы для размышления

• Solana requires validators to have 256 GB RAM and a 10 Gbps connection. Ethereum runs on 8 GB RAM and a home internet connection. Which approach is better for decentralization in the long run - and does the answer change as hardware gets cheaper?
• Gulf Stream forwards transactions directly to the leader, giving them an early access advantage (MEV). How would you design a system that preserves Gulf Stream's low latency but reduces the leader's MEV opportunities?
• Solana has suffered multiple outages, while Bitcoin has run without interruption since 2009. Does this mean Solana's approach (maximum optimization of every layer) is fundamentally less reliable than Bitcoin's (simplicity + large time margins)? Or are the outages 'growing pains' of a new architecture?

Связанные уроки

• dist-12-consistency