Engineering
Solana

Introduction

Solana is not a blockchain in the traditional sense — it is a distributed state machine optimized for throughput at the hardware level. Understanding Solana requires shifting the frame from "how does this blockchain work" to "how does this distributed system achieve consensus at network speeds?"

This chapter establishes the systems-level mental model you'll need throughout this book. We will examine the core architectural decisions that define Solana's design, the tradeoffs those decisions introduce, and why those tradeoffs are deliberately chosen.

The Eight Innovations

Solana's architecture is built on eight core innovations. Of these, Proof of History (PoH) is the most fundamental and most misunderstood. PoH is not a consensus mechanism — it is a cryptographic clock. It provides a verifiable sequence of events that allows validators to agree on the ordering of transactions without coordinating timestamps through the network.

Tower BFT

Tower BFT is Solana's optimized implementation of Practical Byzantine Fault Tolerance (PBFT). It leverages the PoH clock to reduce the messaging overhead inherent in traditional BFT protocols. Validators maintain a tower of votes, with each successive vote locked to an exponentially increasing timeout, disincentivizing rollbacks.

Turbine — Block Propagation

Transmitting block data to thousands of validators simultaneously is a bandwidth problem, not a consensus problem. Turbine solves this by breaking blocks into shreds — small packets of approximately 1,232 bytes — and distributing them through a tree-shaped fanout structure. Each validator receives a subset of shreds and is responsible for forwarding them downstream.

// Shred structure (simplified)
pub struct Shred {
    pub common_header: ShredCommonHeader,
    pub data_header:   DataShredHeader,
    pub payload:       Vec<u8>,   // up to ~1,228 bytes
}

// Each shred is signed by the leader
// and contains a FEC (Forward Error Correction) set index

The Validator Pipeline

A Solana validator is a pipelined system. Transactions enter through the QUIC-based ingestion layer, are deduplicated and prioritized in the banking stage, executed in parallel across Sealevel, and committed to the ledger through the PoH stream. Understanding this pipeline is essential for diagnosing performance bottlenecks.

This is the systems view. In the next chapter, we follow a single transaction through every stage of this pipeline — from the moment it leaves a client's wallet to the moment it achieves finality.