10 - WTF is Solana
Introduction
Solana is a blockchain platform created in 2017 by Anatoly Yakovenko and officially launched in March 2020. In contrast to Ethereum’s architecture covered in previous tutorials, Solana takes a fundamentally different approach to solving the blockchain trilemma – achieving scalability, security, and decentralization simultaneously.
Solana’s architecture targets throughput of up to 65,000 transactions per second (theoretical maximum; practical sustained throughput ~4,000-5,000 TPS) with current finality of ~12.8 seconds and low transaction costs.
Key Architectural Differences from Ethereum
EVM vs SVM: Single-threaded vs Multi-threaded Execution
From Tutorial 4, Ethereum can be conceptualized as a single-core processor:
- EVM = "single-core processor & RAM" – processes transactions sequentially
- Only signature verification can be parallelized
- Mempool stores pending transactions waiting for sequential processing
Solana fundamentally differs with its Solana Virtual Machine (SVM):
- Multi-threaded global state machine – processes transactions in parallel across all available CPU cores
- Sealevel runtime – analyzes transaction dependencies and executes non-overlapping transactions simultaneously
- Gulf Stream – mempool-less architecture where transactions are forwarded directly to upcoming leaders
Account Model: Unified vs Separated State and Logic
In Ethereum (Tutorial 4):
- EOA (Externally Owned Accounts): User accounts with no code
- Contract Accounts: Contain both code and state (storage)
- Smart contracts store their own state internally
In Solana:
- Everything is an account (similar to UNIX "everything is a file")
- Programs (Solana’s smart contracts) are stateless – they contain only executable code
- Data accounts store all state separately from program logic
- Programs own accounts and control write access
- This separation enables parallel execution since programs can process multiple independent accounts simultaneously
Important:
Program is granted write access only if the owner matches its ID (program owns the account).
Transaction Structure
Ethereum transactions (Tutorial 4):
- Contain calldata specifying function selector (4 bytes) and encoded arguments
- Implicitly reference accounts through contract execution
- Processed sequentially by EVM
Solana transactions:
- Explicitly declare all accounts the transaction will read from or write to
- Contain one or more instructions (similar to Ethereum’s internal calls)
- Sealevel analyzes these declarations to schedule parallel execution
- Transactions touching disjoint account sets execute simultaneously
Programming Languages and Bytecode
Ethereum:
- Solidity compiles to EVM bytecode
- EVM is a stack-based virtual machine
- Bytecode executes in a sandboxed environment with gas metering
Solana:
- Rust is the primary language
- Compiles to rBPF (Rust Berkeley Packet Filter) bytecode
- rBPF is a modified version of eBPF optimized for Solana’s architecture
- Anchor framework provides higher-level abstractions for Rust development
- JavaScript/TypeScript libraries (e.g., @solana/web3.js) for client-side interaction
Gas and Transaction Costs
Ethereum:
- Complex gas model with dynamic base fees (EIP-1559)
- Gas costs vary significantly based on network congestion
Solana:
- Simpler fee structure based on signatures and compute units
- Fees remain consistently low (typically $0.00025 per transaction)
Solana’s Eight Core Innovations
Solana’s performance derives from eight core innovations working together:
Proof of History (PoH)
Achieving agreement on time in distributed systems has always been problematic. Solana uses a timekeeping protocol called Proof of History (PoH) to synchronize local virtual clocks on all nodes. PoH ensures that the timestamp in any message can be trusted and that any timeouts in the consensus protocol can be avoided because every node knows the current time and when to begin a new consensus round.
Important:
Proof of History minimizes block time by eliminating waiting overhead. Thanks to synchronized clocks, communication can be replaced by local computation.
PoH is based on a Verifiable Delay Function (VDF). Solana uses a recursive, pre-image-resistant SHA-256 VDF, where the output of one SHA-256 iteration is recursively used as the input for the next. This creates a cryptographic clock that provides a historical record of events.
Warning:
Proof of History is neither a consensus mechanism nor a Sybil resistance mechanism!
Tower BFT
Solana uses Tower Byzantine Fault Tolerance (TBFT) as its consensus algorithm, which is a custom implementation of the Practical Byzantine Fault Tolerance (PBFT) algorithm published in 1999 by Miguel Castro and Barbara Liskov.
The goals of PBFT are to ensure:
- Safety: Results are valid and identical across all non-faulty nodes.
- Liveness: Nodes that don’t fail will always produce a result.
TBFT is a variation of PBFT, with one key difference. Proof of History provides a global source of time before consensus is reached and can therefore be used to enforce the exponentially increasing timeouts introduced in the original PBFT algorithm. No additional messages are needed because PoH itself enforces the timeouts, thereby reducing communication overhead.
Turbine
Turbine is a block propagation protocol designed to reduce both time needed for block propagation as well as the overall message complexity, reducing the communication overhead of a node.
Nodes in the network are divided into small partitions called neighborhoods. Nodes within a particular neighborhood are responsible for sharing received data with other nodes in the same neighborhood and propagating the data to a small number of nodes in other neighborhoods.
The data unit shared is called a shred, and each block is composed of many shreds. To handle adversarial environments, Turbine uses:
- Erasure Codes – broadcasting a block with more shreds than necessary to reconstruct the entire block without errors, even if some shreds are lost along the way.
- Stake-weighted selection algorithm – creating a tree where validators with the highest stake are positioned closer to the current leader, minimizing the risk of faulty or malicious nodes.
Gulf Stream
Gulf Stream is Solana’s mempool-less solution for transaction forwarding. Instead of a single shared mempool, transactions are pushed directly to the next expected leader, enabling immediate processing upon leader rotation.
For this to work, the next leader must always be known in advance. In Solana, leader rotation is scheduled one full epoch ahead of time.
Sealevel
Sealevel is a runtime enabling parallel smart contract execution. It processes as many transactions as available CPU cores, making Solana a multi-threaded global state machine.
Important:
A high-level overview of how Sealevel works:
- Sort pending transactions.
- Schedule non-overlapping transactions to run in parallel.
This is possible because each transaction explicitly declares all states it will read from and write to. Sealevel schedules non-overlapping instructions for parallel execution. Read-only transactions can also execute in parallel.
Pipelining
Beyond consensus and block propagation, nodes must validate and execute all transactions before the next block arrives. The Transaction Processing Unit (TPU) addresses this through extensive pipelining.
Pipelining is a CPU optimization technique that splits instruction execution into stages, allowing hardware components to work in parallel and reducing idle time.
Stages of the TPU pipeline:
- Data fetch: Incoming data is fetched in the kernel space via network card.
- Signature verification: The GPU handles signature verification.
- Banking: Update of the state using the CPU.
- Write: The processed transactions are written to the disk in the kernel space and broadcast via network card to the network.
Cloudbreak
As computation speed increases, memory access becomes the bottleneck. LevelDB, the industry-standard database for blockchain data, does not support parallel reads and writes – acceptable for sequential systems like Bitcoin or Ethereum, but inadequate for Solana’s massively parallel architecture.
Cloudbreak is Solana’s custom database. It makes use of memory-mapped files to store data in a way that allows for independent access to each file.
- Reads are randomly distributed among available disks, as the data is stored evenly.
- Writes use Copy-on-Write semantics, appending new data sequentially to random disks.
Archivers
The Solana blockchain’s growth rate presents storage challenges for maintaining complete transaction history on each node. The proposed distributed ledger storage solution addresses this through decentralized data distribution.
At 1 Gbps network speed, the Solana blockchain generates approximately 4 petabytes of data annually.
To address the impracticality of full history storage on every validator, the design proposes offloading data to specialized lightweight nodes called Archivers. Data is partitioned and replicated to enable full state reconstruction.
Time Model: Slots, Epochs and Leaders
Solana’s deterministic time model differs significantly from Ethereum’s probabilistic block production:
Slots
A slot is a 400 milliseconds time interval during which a designated validator (the leader) proposes a block. Other validators verify and confirm the block’s validity.
If a leader fails to propose a block during their slot, the network proceeds to the next scheduled validator without delay.
Epochs
An epoch spans approximately 432,000 slots (~2 days). At each epoch boundary:
- Validator stakes are recalculated
- Leader schedule for the entire next epoch is determined
- Stake activations/deactivations take effect
Leader selection probability is proportional to validator stake (Proof-of-Stake mechanism).
Account Structure Details
Each account contains:
- Lamports – Account balance (1 lamport = 10-9 SOL)
- Data – Byte array (max 10 MB; PDAs limited to 10 KB at creation, resizable to 10 MB)
- Owner – Program ID that owns this account (grants write access)
- Executable – Boolean flag (one-way: non-executable → executable)
- Rent Epoch – Legacy field (rent mechanism deprecated)
Account Types
- Data accounts – Store state (analogous to Ethereum contract storage)
- Program accounts – Store executable rBPF bytecode (analogous to Ethereum contract code)
- Native accounts – Built-in programs (System program, BPF Loader, etc.)
Program Derived Addresses (PDAs)
Solana uses Program Derived Addresses (analogous to Ethereum’s CREATE2):
- Addresses derived from program ID and seeds (no corresponding private key)
- Programs can "sign" for PDAs they derive
- Enables programs to own and control accounts
- Critical for cross-program invocation patterns
Solana Program Library (SPL)
The SPL provides standard on-chain programs, analogous to Ethereum’s token standards but with fundamental architectural differences:
Token Program
Important:
Key difference from ERC-20/ERC-721:
- Ethereum: Each token requires deploying a new smart contract containing both code and state
- Solana: Single Token Program handles all tokens; each token type creates a mint account, and each holder has a token account
Token architecture:
- Mint account – Defines token properties (supply, decimals, authorities)
- Token accounts – Store individual balances (separate from mint)
- Associated Token Accounts – Deterministic token account addresses per user/mint pair
This design is more efficient and enables the Token Program to handle millions of token types without code redeployment.
Token-2022 (Token Extensions)
Extended Token Program with additional features:
- Transfer fees
- Confidential transfers (zero-knowledge proofs)
- Interest-bearing tokens
- Non-transferable tokens
- Permanent delegates
Account Compression
Reduces storage costs using Merkle trees:
- Stores only Merkle root on-chain
- Full data stored off-chain (via Arweave or similar)
- Enables "compressed NFTs" (cNFTs) at fraction of normal cost
- Critical for large-scale NFT projects (e.g., 1 million NFTs)
Security: BFT Thresholds
Solana uses Proof-of-Stake for Sybil resistance (like Ethereum post-Merge) combined with Tower BFT consensus. It inherits PBFT security assumptions:
- 1/3 Attack – Controls >33% stake → can halt consensus (liveness failure)
- 2/3 Attack – Controls >66% stake → can violate safety (rewrite history)