Solana School — Lesson 1: Learn Solana Architecture, Proof of History, and Alpenglow

Solana School — Lesson 1: Learn Solana Architecture, Proof of History, and AlpenglowSolana is often praised for its blazing speed and low transaction fees — but what actually powers that performance?
In Lesson 1 of the School of Solana — Season 7 by Ackee, we dive into Solana’s core architecture, Proof of History, and its upcoming runtime upgrade, Alpenglow. Perfect for devs or enthusiast curious about how Solana really works under the hood.Topics Covered :

• Hello Solana: Introduction
• Solana Today : Current state of the network
• Solana Architecture — Explained
• Gulf Stream + SWQoS
• Processing Transactions : Building Blocks
• Proof Of History (PoH), Sealevel & Turbine
• Account-Based Storage Model
• Alpenglow Runtime — A Glimpse Into Solana’s Future

Hello Solana : IntroductionDecentralized, Globally synchronized state machine

• Founded in 2017 by Anatoly Yakovenko, former Qualcomm engineer
• Testnet in 2018, and mainnet-beta went live in March 2020
• Layer 1 blockchain, similar to Ethereum
• Proof-of-Stake (PoS) network

Tools like validators.app and solanabeach.io offer real-time visualizations of Solana’s validator network, including stake distribution, validator performance, and decentralization metrics.

Solana — Today : Current state

• Nakamoto Coefficient - 22 : This means the top 22 validators on Solana collectively hold enough stake to influence consensus, serving as a key measure of the network’s decentralization and resistance to collusion.
• 1000–1300 True TPS : Solana consistently achieves 1,000 to 1,300 true transactions per second (TPS), excluding validator vote transactions — making it one of the fastest operational blockchains.
• Block Time ~400ms : A new block is created every 400ms on Solana, compared to ~10 minutes on Bitcoin.
• Time to Finality ~12s : Transactions typically finalize in about 12 seconds, meaning they become irreversible and confirmed on-chain.
• ~1200 Validators : distributed geographically
• Multiple Validator Clients : Decentralization is strengthened through diverse validator software (e.g., Jito, Firedancer, Agave). If one client has a bug, others remain fully operational, ensuring network continuity.

Solana ArchitechtureIncrease bandwidth, Reduce latencySolana Architecture — Block Creation

Transaction Overview :

Note: This section only provides a brief overview. A more detailed explanation will be covered later in the blog.

• Let a User wants to send some USDC
• The User connects his wallet with the dApp and initiates a transfer of USDC
• User → RPC Node : User signs the transaction with his private key and this signed transaction is sent to the RPC Node.
• RPC Node → Validator : The transaction is then forwarded from RPC to the validators
• Validator → Block Leader (via Gulf Stream) : The validator validates the transaction and forwards the verified transaction to the scheduled block leader using Gulf Stream.
• Block building - Here, The block leader fetch transactions, again verify signatures, and all the valid transactions are moved to the Banking state, where they are executed in parallel giving high throughput.
• The transactions are sequenced using Proof of History (PoH) Service.

PoH Service is a synchronization mechanism, not a consensus mechanism like PoS

• Transactional state changes are written by the bank to the Accounts DB and those transactions which change the blockchain state are added to the Block.

Accounts DB..? Solana smart contracts don’t have built-in memory. Instead, they store state externally in accounts — which are key-value pairs replicated across validators, enabling parallel execution and consistent state management across the network.

• The created Block is then broadcasted across to all validators to vote on the validity of the block.
• This broadcast happens using Turbine protocol, where each validator broadcasts the block to their adjacent neighbours. Thus, eventually all validators will receive your Block
• Block validation / verification — To ensure all validators maintain a synchronized state, each validator re-executes the transactions in the received block in the exact same order. They verify both the resulting state changes and the correct sequencing of transactions using the PoH service.

While PoH sequence creation is sequential, its validation can be done in parallel. Therefore validations are done very fast than creation, leading to efficient performance of Solana

• Once verification successful, now all validators have same synchrozied state changes - Thus, Resulting in Consensus among all validators

More Detailed Explanation :

Now, that we know the transactional overview, Lets understand each process in depth again covering important concepts of each phase -

> Gulf Stream :Solana’s Alternative to Mempools

Most blockchains use mempools — where validators pick unconfirmed transactions based on fees. Solana takes a different approach with Gulf Stream, which eliminates mempools entirely.

• Each ~400ms slot has a designated block leader
• The block leader Schedule is precomputed for the next epoch (~2 days).
• Therefore, once a validator receives and verifies a transaction, it forwards the validated transaction directly to the upcoming block leader using Gulf Stream.

Speed vs Flexibility design trade-off : Since, There’s no shared mempool, so only the pre-scheduled leader receives transactions (via Gulf Stream). If that leader goes offline, no one else can take over immediately, increasing the risk of temporary halts.

> Gulf + Stake-Weighted Quality of Service (SWQoS) :Stake-Powered Spam FilteringStake-Weighted Quality of Service (SWQoS)

In Solana, user transactions flow from RPCs to validators, then to scheduled block leaders.
To prevent spam and ensure network reliability, Stake-Weighted Quality of Service (SWQoS) is used:

• Stake-Based Priority: Validators with higher stake — are considered more trustworthy —receive prioritized dedicated connections to leaders.
• Connection Allocation: ~80% of a leader’s inbound slots go to these trusted validators, while only ~20% remain open to public or low-stake RPCs.
• Delegated Access: Trusted validators can assign their connection priority to specific RPCs for direct transaction forwarding to the leader

> QUIC (Quick UDP Internet Connections)

Solana uses QUIC, a transport-layer protocol built on UDP but with key performance enhancements. Its faster handshake and connection reuse help reduce latency — offering a significant speed advantage over traditional, sequential TCP.

> Processing Transactions: Building Blocks

Now, that the transaction are received by the Block leader. Lets look into the Transaction processing unit (TPU), which process transactions and adds it to the block.

(-) Fetch Stage:
The block leader’s TPU fetches incoming transactions packets from the network. These are the transactions sent by validators (via Gulf Stream) to the leader’s network interface.

(-) Signature Verification Stage:
This stage verifies the signatures of fetched transactions to ensure they’re valid and not tampered with. Only valid, untampered transactions proceed to the next stage. Malicious or malformed ones are dropped.

(-) Banking Stage:
This is where actual state changes occur — instructions in transactions are executed. Solana’s runtime execute transactions in parallel, thanks to its account-based-model and Sealevel — The parallel execution engine
How it works:
 — Each transaction instruction declares which accounts it reads / writes, and whether they must be mutable.
— If two transactions access independent sets of accounts, they can be processed parallel at the same time.
 — If two instructions conflict (e.g., both modify the same account), they are serialized.
 — The Sealevel analyzes these access patterns and schedules execution safely

(-) Proof of History (PoH) Service:

Proof Of History (PoH)

Solana’s PoH service is a cryptographic timekeeping mechanism that provides a verifiable sequence of events — before consensus is even reached. It acts as a synchronization mechanism, not a consensus protocol.

Think of it like a photo in a newspaper: the image must have been taken before the newspaper was printed. Similarly, PoH proves that events happened in a specific order before block production.

How It Works:

• The block leader runs a PoH generator — a continuous, high-speed hashing process (using SHA-256).
• Each hash output becomes the input for the next, forming a PoH hash chain.
• Transactions are inserted into the chain, producing a new PoH hash and binding them to a unique point in time.
• Anyone can verify the order and spacing of events by checking the position in the hash sequence — without needing to trust the leader.
• The PoH creation is sequential, while the validation can be done in parallel

Example —(based on the above block diagram) :
 — Let, The Signed Tx(0x0deb10b) is included in the PoH hash chain at a specific point mapped to PoH hash(0xdeadc0de).
 — During the the next PoH Hash generation, both the previous hash and this transaction hash are used as input.
 — This new PoS hash cryptographically proves the transaction’s exact position in time, making its order verifiable and immutable.

(-) Broadcast Stage (Turbine Tree):
As discussed before, Once the block is created, the block leader broadcasts the finalized block using Solana’s Turbine protocol — a tree-based, decentralized propagation system. The leader sends the block to a few nearby validators, who then relay it further, enabling fast and bandwidth-efficient distribution across the network.

> Block-Verification and Consensus:

Validators re-execute transactions in the order defined by the PoH sequence to ensure consistent state updates. If the state transitions and order are valid, they vote on the block. Once a supermajority (≈66% of stake) approves, the block is finalized and all validators reach consensus with a synchronized state.

Solana Storage Account Model— Overview:

• Key-Value Structure:
   — Key: A public key (e.g., wallet address)
   — Value: Binary data (bytes) that holds the account’s state.
• No Built-in Storage in Programs:
  Solana smart contracts (called programs) do not store data internally.
  Instead, they read from and write to external accounts passed to them.
• Explicit Account Access:
  When writing a program, you must declare upfront which accounts your instruction will access, and whether it needs read or write access.
• Example — SPL Token Account:
  Holds data like:
   — Token mint address (e.g., USDC pubkey)
   — Owner’s public key
   — Token balance (as bytes)
• Design Benefit:
  This separation of code (programs) and state (accounts) allows parallel transaction execution and better scalability.

Alpenglow — A Glimpse Into Solana’s Future

Alpenglow is the next big upgrade coming to Solana in 2026. It aims to make the network faster, lighter, and easier to maintain — setting the stage for a smoother and more scalable future. Think of it as Solana’s future engine, built for long-term growth and reliability.

• Time to Finality reduced to ~150ms (currently ~12s)
• No more voted transactions: Removes the need for onchain vote transactions, reducing validator costs and improving overall efficiency — since consensus no longer waits on validator votes to be recorded.
• No more PoH (at least in consensus)
• New concepts : Rotor & Voltor

Rotor :A Smarter Way to Pick Block ProducersAlpenglow-Rotor

• Rotor replaces the older Turbine (tree-based block propagation) with a faster, flatter distribution model.
• It introduces Relayers — a selected group of trusted nodes responsible for broadcasting blocks across the network.
• Once the block is created, the leader sends it to a group of relayers.
   — These relayers quickly forward the block to all validators, ensuring fast and efficient propagation with minimal delay.

Voltor :

In Alpenglow’s Voltor consensus, validators use BLS (Boneh–Lynn–Shacham) signatures to collectively sign and certify blocks.

• No more vote transactions: Voltor removes the need for on-chain vote transactions by moving voting off-chain. Validators sign blocks, and an aggregator collects these signatures.
• BLS Certificate: The Individual validator signatures are aggregated into a single compact signature — called a BLS certificate — proving quorum agreement.
• 80% Stake Certificate — Fast Finalization :
  When validators representing 80% of total stake sign a block,
  A Fast Finalization certificate is produced & The block is immediately finalized with a single round of voting.
• 60% Stake Certificate — Slow Finalization :
  If only 60% stake signs in the first round,, a second round of voting is required. If 60% signs again, the block is finalized — this is called 2-round finalization.

Learn More about Alpenglow: https://www.helius.dev/blog/alpenglow

Conclusion

If you’ve made it this far — congrats, you’ve achieved finality! ⚡️
I hope this gave you a clearer understanding of how Solana really works under the hood.

This blog is part of my personal notes from Solana School Season 7 — Lecture 1, where I’m learning and summarizing key concepts as I go.

Stay tuned for upcoming blogs where we’ll dive into hands-on programming and real Solana examples.

Thanks for reading, and let’s keep exploring the chain!