Chapter 3: Solana

Overview

Solana is a high-performance Layer 1 blockchain that launched its mainnet in 2020, designed from the ground up to be the fastest blockchain in the world. Where Ethereum struggled with scalability — slow throughput and prohibitively high fees — Solana sought to address these limitations through fundamental architectural innovation. What sets Solana apart is not incremental improvement over existing technology, but rather the combination of novel core mechanisms such as Parallel Execution and Proof of History (PoH) to target tens of thousands of transactions per second.

This chapter takes a deep dive into the seven core concepts that make Solana what it is. We begin with the architectural innovations of Parallel Execution and Proof of History (PoH), then move to Program Derived Addresses (PDA), which enhance both security and developer ergonomics. From there, we examine Local Fee Markets, which reimagine how transaction fees are structured, and the network efficiency protocols Gulf Stream and Turbine. Finally, we cover the Alpenglow upgrade — the development that may define Solana's future — giving readers a comprehensive picture of both where Solana stands today and where it is headed.

Solana has earned recognition for its exceptional performance, but it has also faced pointed criticism: network outages, centralization concerns, and real-world reliability issues. This chapter aims to present a balanced assessment of Solana's technical strengths and trade-offs, enabling readers to critically evaluate Solana's particular approach to solving the blockchain scalability problem.

---

Parallel Execution

Definition

Parallel Execution is the mechanism by which Solana processes transactions simultaneously across multiple CPU cores, provided those transactions access different accounts. The key requirement that makes this possible is straightforward: every transaction must declare upfront which accounts it will read from or write to. The runtime uses these declarations to detect conflicts before execution begins — transactions with no overlapping accounts run in parallel, while transactions touching the same account are serialized. Solana implements this through a parallel runtime called Sealevel.

Key Points

• Multiple Checkout Lanes vs. a Single Queue: Ethereum processes transactions against a global state in strict sequential order — think of a single checkout lane at a supermarket. Solana, by contrast, operates like a large store with many checkout lanes open simultaneously. Transactions accessing different accounts are independent of one another and can be processed concurrently, just as customers buying different items don't need to stand in the same line.

• The Importance of Pre-declaration: Every Solana transaction must explicitly specify which accounts it will access before execution begins. This requirement is a prerequisite for Parallel Execution, but it places additional design responsibilities on developers. Logic that dynamically determines its account targets at runtime — common in more flexible smart contract environments — is inherently more complex to implement on Solana.

• Performance Advantages: Parallel Execution is the foundational reason Solana can credibly claim throughput in the tens of thousands of TPS. Modern servers carry dozens of CPU cores, and in theory, Solana's throughput can scale proportionally with core count, assuming transactions are sufficiently independent.

• Sequential Fallback on Conflicts: Transactions that access the same account must still be executed sequentially. When a large number of transactions converge on a single account — as happens during popular NFT mints or high-activity DeFi protocols — the benefits of Parallel Execution diminish and bottlenecks emerge.

• A Fundamental Departure from Ethereum: Ethereum's EVM is built around the concept of a global state transition, inherently optimized for sequential execution. Introducing parallelism to Ethereum requires complex additions like speculative execution or optimistic concurrency control. Solana, by contrast, was architected from day one with parallelism as a foundational design principle.

Related Concepts

Parallel Execution is tightly coupled to every performance-related concept in Solana's stack. Local Fee Markets are designed to complement Parallel Execution: when transactions pile up on a particular account, only the priority fees for that account rise, leaving other parallel execution lanes unaffected. Gulf Stream contributes by delivering transactions to the upcoming leader in advance, allowing account information to be pre-sorted and staged for parallel scheduling. The Alpenglow upgrade is designed to dramatically improve the consensus layer while preserving the Parallel Execution architecture, maximizing the synergy between throughput and finality.

---

Proof of History (PoH)

Definition

Proof of History (PoH) is Solana's cryptographic timekeeping mechanism. By generating a continuous sequence of SHA-256 hashes — where each hash's output serves as the next hash's input — PoH mathematically proves that specific events occurred in a specific order at specific points in time. In a conventional blockchain, nodes must exchange a significant volume of messages to agree on event ordering and timing. PoH replaces this coordination overhead with a cryptographic timestamp, reducing consensus latency and increasing throughput. It is important to note that PoH is not a standalone consensus algorithm; rather, it functions as a timekeeping layer that supports Solana's actual consensus mechanism, Tower BFT, which is built on Proof of Stake (PoS).

Key Points

• Sequential Hash Chain: PoH is implemented as a sequential hashing process in which the output of one hash becomes the input of the next. Because each computation takes real time to perform, the existence of a particular hash value in the chain proves that all preceding hashes were computed first. The ordering of events encoded in the chain is therefore cryptographically unforgeable.

• A Trustless Global Clock: Time synchronization between nodes is a notoriously difficult problem in distributed systems. PoH provides a blockchain-native cryptographic clock, allowing all participants to verify the relative ordering of events without relying on external timestamp servers or trusting any single party's clock.

• Relationship with Tower BFT: PoH does not achieve consensus on its own. Tower BFT handles actual consensus, while PoH supplies the temporal foundation on which Tower BFT operates. Validators cast votes within the slot and epoch structure that PoH defines.

• Integration with the Leader Schedule: Solana pre-assigns a leader validator to produce each block slot. The passage of time tracked by PoH is synchronized with this leader schedule, ensuring each leader processes transactions within its designated slot before cleanly handing off to the next.

• Deprecation in Alpenglow: Despite being one of Solana's most distinctive innovations, PoH is slated for complete removal in the Alpenglow upgrade. Fixed slot scheduling will replace PoH, enabling a simpler and faster consensus process. The timekeeping role that PoH has served will be fulfilled in a new way under the redesigned architecture.

Related Concepts

PoH is woven into Solana's consensus architecture at every level. Parallel Execution operates on top of the temporal structure and leader schedule that PoH establishes. Gulf Stream leverages PoH's leader schedule information to forward transactions directly to the appropriate upcoming leaders. Most critically, Alpenglow is defined precisely by its replacement of PoH — understanding what PoH does and why it was introduced is therefore the key to understanding exactly what Alpenglow improves upon.

---

Program Derived Address (PDA)

Definition

A Program Derived Address (PDA) is a special type of address in Solana that is deterministically generated by a program (smart contract) and has no corresponding private key. Ordinary Solana wallet addresses are derived from public-private key pairs, meaning the holder of the private key controls the assets at that address. PDAs, by contrast, are derived mathematically from a combination of a program's ID and one or more seed values, producing a point that lies off the elliptic curve. Because they are off-curve, no valid private key corresponds to a PDA. Only the program that owns the PDA can authorize actions on it — a property Solana refers to as program signing.

Key Points

• Solving the Escrow Custody Problem: Escrow functionality in DeFi requires a neutral party to temporarily hold funds on behalf of others. In traditional setups, someone — or a multisig group — must hold the keys to the escrow account, introducing risks of insider theft or key compromise. Because PDAs have no private key, no individual can arbitrarily withdraw funds held at a PDA. Assets can only move when the owning program's logic explicitly permits it, enforcing custody rules in code rather than in trust.

• Program Signing: Solana's runtime allows a program to sign on behalf of its own PDAs. This mechanism — known as program signing or cross-program invocation (CPI) with signer — is what enables a program to transfer assets or modify state stored in a PDA account. Without this capability, a keyless address would be completely inaccessible.

• Deterministic Address Generation: Given the same program ID and seed values, a PDA always resolves to the same address. This determinism means any participant can independently compute and verify a PDA's address in advance, providing transparency and predictability across the ecosystem.

• Broad Range of Use Cases: Beyond escrow, PDAs serve as the foundational pattern for a wide range of Solana application architecture: liquidity pool accounts in AMMs (Automated Market Makers), NFT metadata storage accounts, per-user state accounts, on-chain configuration data, and much more. PDAs are arguably the central building block of Solana DApp development.

• Comparison with Ethereum: Ethereum smart contracts also hold assets at their own addresses and can enforce custody through code. However, Solana's account model and program ownership structure make PDA-based custody more explicit and fine-grained, with clearer delineation between the program's logic and the accounts it controls.

Related Concepts

PDAs connect to the broader Solana programming model at every level. In the context of Parallel Execution, transactions involving PDAs must declare those PDA accounts upfront, making them part of the conflict-detection and parallel scheduling process. In the context of Local Fee Markets, high-demand PDAs — such as the liquidity pool accounts of a popular DEX — become focal points for priority fee competition. PDAs will remain central to Solana's programming model well beyond the Alpenglow upgrade, as they are a feature of the account model rather than the consensus layer.

---

Local Fee Markets

Definition

Local Fee Markets are Solana's approach to transaction fee pricing, where fees are determined at the individual account level rather than by network-wide congestion. In Ethereum, the base fee responds to aggregate demand across the entire network — congestion caused by one application drives up fees for every other transaction, regardless of whether it interacts with the congested application at all. In Solana's Local Fee Markets, when demand surges for a particular account, only the priority fees for transactions touching that account increase. Transactions operating on unrelated accounts are completely unaffected.

Key Points

• Account-Level Fee Pricing: Every Solana transaction carries a mandatory base fee and an optional priority fee. When many transactions compete for access to the same account, a localized bidding war for priority fees emerges around that account. This effect is most visible during events like popular NFT mints or DeFi liquidation cascades, where demand concentrates sharply on specific accounts.

• Contrast with Ethereum's Global Fee Market: When a viral NFT mint launches on Ethereum, gas prices spike network-wide, making even simple token transfers unexpectedly expensive for users with no interest in the mint. Solana's Local Fee Markets are designed to prevent this spillover effect, confining the impact of congestion to the accounts that are actually congested.

• Synergy with Parallel Execution: Local Fee Markets achieve their greatest effect in combination with Parallel Execution. While transactions competing over a congested account pay elevated priority fees, transactions on unrelated accounts continue processing in separate parallel lanes at normal cost — the two mechanisms reinforce each other.

• Real-World Limitations — Spam Vulnerability: Elegant in theory, Local Fee Markets have faced criticism for performing imperfectly under extreme spam attacks or bot-driven traffic floods. When malicious transactions are distributed across many accounts simultaneously, or when raw network-layer saturation occurs, the local fee mechanism alone cannot guarantee network quality. This dynamic has been a contributing factor in several historical Solana performance degradation incidents.

• Complementary Measures — QUIC and Stake-Weighted QoS: Recognizing that Local Fee Markets alone are insufficient, Solana has implemented additional protections: replacing UDP with QUIC as the transaction transport protocol and introducing stake-weighted Quality of Service (QoS), which prioritizes traffic from validators with more stake. These measures represent a pragmatic acknowledgment that the fee mechanism requires network-level support.

Related Concepts

Local Fee Markets are designed on top of the architectural foundation that Parallel Execution provides. PDA accounts are fully subject to Local Fee Markets — PDAs associated with popular programs naturally become hotspots for priority fee competition. Gulf Stream forwards transactions — along with their priority fee information — directly to upcoming leaders, enabling leaders to rank and select transactions by profitability before block production begins. Alpenglow's dramatically faster consensus is expected to reduce the time pressure that drives fee competition, offering an indirect benefit to the fee market dynamics.

---

Gulf Stream

Definition

Gulf Stream is Solana's transaction forwarding protocol. In most blockchains — Bitcoin, Ethereum, and others — transactions are broadcast to a public mempool where every node stores and monitors them until a leader (miner or validator) selects them for inclusion. Gulf Stream takes a fundamentally different approach: rather than broadcasting to a global mempool, transactions are forwarded directly to the current leader and to the validators scheduled to lead upcoming slots. This is only possible because Solana's PoH-based leader schedule makes future leaders known in advance to every node on the network.

Key Points

• A Mempool-Free Architecture: Solana does not operate a public mempool. Through Gulf Stream, transactions are not broadcast network-wide; instead, they are delivered directly to the validators who will need them. This eliminates the network overhead and propagation latency associated with global broadcast, reducing the time between transaction submission and processing.

• Leveraging the Leader Schedule: Because PoH produces a deterministic leader schedule, every Solana node knows who will lead each upcoming slot well in advance. Gulf Stream exploits this knowledge by forwarding transactions not just to the current leader, but to multiple future leaders as well, ensuring that by the time a validator's slot begins, it already holds a queue of transactions ready to process.

• Latency Reduction: In a conventional mempool-based system, a transaction must propagate across the entire network before the leader picks it up. Gulf Stream shortens this path significantly, routing transactions more directly and reducing confirmation times as a result.

• MEV Implications: The absence of a public mempool makes traditional front-running MEV strategies — which rely on observing pending transactions — far more difficult on Solana than on Ethereum. However, MEV has not been eliminated: leaders can still reorder the transactions forwarded to them for personal gain, and this form of MEV is an active area of discussion in the Solana ecosystem.

• Centralization Concerns: Routing transactions directly to a small set of scheduled leaders creates a structural opportunity for those leaders to censor specific transactions or manipulate ordering in ways that are harder to detect. This is one of the recurring centralization-related criticisms leveled at Solana's architecture.

Related Concepts

Gulf Stream cannot function without the leader schedule that Proof of History (PoH) produces. When Alpenglow removes PoH, the leader scheduling mechanism will change accordingly, and Gulf Stream's forwarding logic will need to adapt. In the context of Local Fee Markets, priority fee information travels with transactions through Gulf Stream, giving leaders the data they need to order transactions by fee priority before producing a block. Turbine is Gulf Stream's natural counterpart: while Gulf Stream aggregates incoming transactions at the leader, Turbine distributes the resulting block outward to the rest of the validator set.

---

Turbine

Definition

Turbine is Solana's block propagation protocol. Once a leader produces a block, that block must be delivered to every validator on the network — potentially thousands of them. Sending a large block directly to thousands of validators simultaneously would demand enormous network bandwidth. Turbine addresses this by breaking blocks into small fragments called shreds and distributing them through a multi-layered tree structure of validator neighborhoods, dramatically reducing the bandwidth burden on any single node.

Key Points

• Shred-Based Fragmentation: Rather than transmitting a complete block to every validator, Turbine splits the block into small units called shreds. Each validator receives only a subset of shreds directly, then passes those shreds to other validators in its neighborhood. This cascading distribution means the leader's outbound bandwidth requirement scales with the number of shreds it must originate, not with the total number of validators.

• Hierarchical Neighborhood Structure: Turbine organizes validators into a tree of neighborhoods. The leader sends shreds to a set of top-level validators, each of which retransmits to the next layer, and so on. This tree structure allows block data to reach the entire validator set in logarithmic time relative to network size, rather than requiring direct point-to-point connections.

• Erasure Coding for Resilience: To handle packet loss and validator failures, Turbine applies erasure coding to shreds. This means a validator can reconstruct the full block even if a fraction of the shreds it expected to receive are missing — similar in principle to how RAID storage or video streaming systems handle partial data loss.

• Bandwidth Efficiency: By distributing propagation work across the entire validator tree rather than concentrating it at the leader, Turbine allows Solana to propagate large blocks to a large validator set without requiring every node to maintain extremely high-bandwidth connections.

• Trade-offs and Failure Modes: Turbine's tree structure introduces dependencies between nodes. If a validator high in the tree fails to retransmit its shreds, downstream validators in its subtree may not receive the data they need, potentially disrupting block confirmation for that segment of the network.

Related Concepts

Turbine is the outbound complement to Gulf Stream's inbound aggregation: Gulf Stream routes transactions to the leader before block production; Turbine distributes the resulting block to the rest of the network afterward. The protocol's efficiency directly supports Parallel Execution and Solana's high-throughput ambitions by ensuring that the large volumes of transaction data encoded in blocks can actually be propagated quickly across a large validator set. Alpenglow redesigns Solana's consensus layer in ways that interact with block propagation timing, and Turbine's role will evolve accordingly within that new architecture.

---

Alpenglow

Definition

Alpenglow is Solana's forthcoming consensus upgrade, representing the most significant architectural change to Solana since its mainnet launch. Alpenglow replaces both Proof of History (PoH) and Tower BFT — the two mechanisms that have defined Solana's consensus layer — with an entirely new design composed of two sub-protocols: Votor and Rotor. Votor handles voting and block finalization, while Rotor manages block data dissemination. Together, they are designed to reduce block finalization time from Solana's current range of several seconds down to approximately 100–150 milliseconds, while also simplifying the consensus architecture and improving network resilience.

Key Points

• Replacing PoH: Alpenglow eliminates PoH entirely. The sequential hash chain that served as Solana's cryptographic clock and timekeeping foundation is replaced by fixed slot scheduling, which achieves equivalent ordering guarantees through a simpler mechanism. This removes a significant source of architectural complexity without sacrificing the orderly slot-based block production that Solana's throughput depends on.

• Votor — Fast Block Finalization: Votor is the voting protocol at the heart of Alpenglow. It is designed to achieve finality in a single round of voting under normal network conditions, with a fallback second round available when conditions degrade. This represents a fundamental departure from Tower BFT, which required multiple rounds of voting locked behind PoH's slot timing — a process that, while secure, introduced latency measured in seconds.

• Rotor — Redesigned Block Propagation: Rotor replaces or significantly augments Turbine's role in block data dissemination. Like Turbine, Rotor distributes block data efficiently across the validator set, but is redesigned to align with Votor's aggressive finality timeline and to reduce the propagation latency that would otherwise bottleneck the faster consensus process.

• Implications for Finality: With finality dropping to the 100–150 millisecond range, Solana would achieve confirmation speeds competitive with traditional financial infrastructure. This would unlock use cases that are currently impractical on-chain, such as high-frequency trading, real-time settlement, and latency-sensitive consumer applications.

• Preserving the Existing Programming Model: Alpenglow is a consensus-layer upgrade. Solana's account model, Parallel Execution via Sealevel, PDAs, Local Fee Markets, and the overall programming model remain intact. Applications and smart contracts built on Solana will continue to operate without modification.

• Network Resilience: Beyond raw speed, the Alpenglow design aims to improve Solana's tolerance for network partitions and validator failures — conditions that have historically contributed to Solana's network outages. A simpler consensus mechanism with fewer dependencies is inherently easier to reason about and recover from under adversarial conditions.

Related Concepts

Alpenglow touches every other concept in this chapter. It directly replaces Proof of History (PoH), making PoH the essential predecessor to understand before Alpenglow's changes become meaningful. Gulf Stream will need to adapt its transaction forwarding logic as the leader schedule mechanism changes. Turbine may be partially or fully superseded by Rotor in block propagation. Parallel Execution and Local Fee Markets are preserved and stand to benefit indirectly from dramatically faster finality. PDAs and the broader programming model are unaffected, ensuring continuity for developers building on Solana through the upgrade.