Core Concepts

Solana Architecture

How Solana achieves high throughput through Proof of History, Sealevel, and Tower BFT.

Updated March 202515 min read

Overview

Solana's performance stems from eight key innovations working in concert. Understanding these mechanisms helps developers make informed decisions about application architecture, transaction design, and infrastructure choices.

Proof of History (PoH)

Proof of History is Solana's most distinctive innovation. It is a cryptographic clock that creates a verifiable record of time passing between events. PoH uses a sequential hash function (SHA-256) where the output of each hash becomes the input of the next, creating an immutable sequence that proves the ordering of events without requiring validators to communicate about timestamps.

This eliminates the need for validators to exchange timestamps when agreeing on transaction ordering, reducing the communication overhead that limits throughput in other blockchains. The PoH sequence runs on the leader — the validator currently responsible for producing blocks — and other validators can verify the sequence in parallel.

Tower BFT

Tower BFT is Solana's consensus mechanism, optimized to leverage PoH as a global clock. It is a variant of Practical Byzantine Fault Tolerance (PBFT) that uses PoH to reduce messaging complexity. Validators vote on the validity of PoH sequences, and votes are weighted by stake. The network achieves finality when a supermajority (2/3+) of stake has voted on a block.

Sealevel — Parallel Execution

Sealevel is Solana's parallel smart contract runtime. Unlike Ethereum's EVM, which processes transactions sequentially, Sealevel can execute thousands of transactions in parallel. This is possible because Solana transactions declare upfront which accounts they will read and write. The runtime can identify non-overlapping transactions and execute them simultaneously across multiple CPU cores and GPUs.

Gulf Stream — Mempool-less Transaction Forwarding

Gulf Stream eliminates the traditional mempool by pushing transaction caching and forwarding to the edge of the network. Clients send transactions directly to the expected leader for the next few slots, rather than broadcasting to all nodes. This reduces memory pressure on validators and allows leaders to execute transactions ahead of time, contributing to Solana's low latency.

Turbine — Block Propagation

Turbine is Solana's block propagation protocol, inspired by BitTorrent. Blocks are broken into small packets called shreds and distributed through a tree of validators. Each validator only needs to receive and retransmit a fraction of the total data, making propagation efficient even at high throughput. This is the foundation for Shredstream, which allows applications to receive shreds directly.

Cloudbreak — Horizontal Scaling

Cloudbreak is Solana's memory-mapped file system for accounts. It enables concurrent reads and writes to accounts across multiple SSDs, allowing the validator to handle the high I/O demands of parallel transaction processing.

Pipelining

Solana uses a Transaction Processing Unit (TPU) that pipelines transaction processing across four stages: data fetch, signature verification, banking, and writing. Each stage runs on dedicated hardware (GPU for signature verification, CPU for banking), maximizing hardware utilization.

Accounts Model Deep Dive

Understanding Solana's account model is essential for building efficient applications. Every piece of data on Solana — including program code, token balances, and user data — is stored in an account. Accounts have the following properties:

  • Address: A 32-byte public key (Ed25519)
  • Lamports: The account's SOL balance (1 SOL = 10⁹ lamports)
  • Data: Arbitrary byte array up to 10MB
  • Owner: The program that controls this account
  • Executable: Whether the account contains program code
  • Rent epoch: When the account will next owe rent
ℹ️
Accounts must maintain a minimum balance (rent-exempt threshold) proportional to their data size. For a 0-byte account, this is approximately 0.00089 SOL. Accounts below this threshold are garbage collected.

Program Derived Addresses (PDAs)

PDAs are deterministically derived account addresses that are not on the Ed25519 curve, meaning no private key can sign for them. Programs can sign for PDAs using their program ID and seeds, enabling programs to own and control accounts without a traditional keypair. PDAs are fundamental to DeFi protocols, NFT metadata, and any application requiring program-controlled state.