Back to Blog

Understanding Solana’s Architecture Through Its Core Design Innovations

·10 min read
blockchainsolanaweb3architecture

In financial systems, how to make sure that "Transaction A" has happened before "Transaction B"?

Nodes in traditional blockchain networks (Bitcoin and Ethereum) constantly talk with each other for this. This back-and-forth wastes a significant amount of network time and creates a bottleneck. Solana addresses this issue by treating time as a data structure rather than a network consensus.

Here are the eight innovations that make it a significant shift in the web3 ecosystem:

1. Proof of History (PoH): The Cryptographic Clock

Let's understand how Solana solved the time problem. They introduced something called Proof of History, which is not, in fact, a consensus mechanism. It's a Verifiable Delay Function (VDF), a cryptographic clock that tells network nodes when time has elapsed without requiring them to communicate with each other.

It utilizes sequential hash generation, a continuous iteration of SHA256 hashes where the output of the previous hash serves as the input for the next. This process of hash generation is slow, but verifying these hash values is significantly faster. Validator nodes break the stream into batches. From there, every single core on the CPU grabs a batch and processes it independently.

Proof of History Diagram

Figure 1: Proof of History - Sequential Hash Generation

2. Tower BFT: The Game of Commitment

Now we have a clock that all nodes in the network can trust. What we need is a way to reach consensus. Tower BFT is Solana's specialized version of pBFT (Practical Byzantine Fault Tolerance).

Think of it like a game of commitment. For every vote a validator casts on a block, the validators promise not to vote for a conflicting block for 'N' slots (a Lockout). If the network continues to produce successful blocks on that path, the lockout period doubles.

  • The Lava Pit Analogy: Think of voting like walking forward on a bridge over lava. After each step, turning back becomes harder. In Solana, every time a validator votes for the same chain, it commits to a lockout period during which it cannot vote for a conflicting chain. This lockout doubles with each consecutive vote. After 10 votes, the validator would need to wait roughly 2^10 (about 1,024) time units before switching. After around 22 consecutive votes, the lockout grows to decades, approximately 54 years. At that point, reversing the vote is no longer practical, and the block can be treated as final.

3. Turbine: The Pyramid Scheme for Data

Traditional blockchains utilize a protocol known as the Gossip protocol to transmit block data to other nodes within the network. When a validator or minor creates a block, they send the entire block to a select group of peers. Those peers then send it to their own peers, and the process continues. This is known as Gossip or Flooding.

The issue with this mechanism is - the leader has to send the entire block to its immediate peers. As the block size increases, the leader’s upload bandwidth becomes a significant bottleneck. Nodes repeat work (sending the same block data to multiple nodes), causing the network to become congested quickly.

Transferring a large amount of block data to 1000+ nodes (validators in this case) in milliseconds is a bandwidth nightmare. Solana solves this problem using Turbine. Turbine breaks blocks of data into small "shreds" and propagates them via a pyramid scheme. Instead of sending the whole block to everyone, the leader sends each shred to a different validator in a neighborhood. The validators then pass the shreds to the next layer of nodes. Because of this pyramid-like tree structure, the leader only communicates with a small part of the network. The data spreads quickly, reaching thousands of nodes in just a few hops.

Ethereum Gossip Protocol

Figure 2: Standard Gossip (Traditional P2P)

Solana Turbine Protocol

Figure 3: Turbine: Overcoming the Gossip Bottleneck through Structured Fan-out

4. Gulf Stream: No More Waiting Rooms

Solana has no mempool. Because the leader schedule is known in advance, transactions are sent directly to the current leader and the next few scheduled leaders. This "mempool-less forwarding" pushes transaction caching to the edge of the network.

5. Sealevel: Parallel Processing

Most blockchains are considered "single-lane roads" because they process transactions one at a time. Sealevel allows Solana to run thousands of smart contracts in parallel. Before executing, every transaction declares exactly which "Accounts" it will touch. If two transactions aren’t touching the same writable account, they run at the exact same time on different CPU cores.

6. Pipelining: The Assembly Line

To maximize efficiency, Solana uses Pipelining, a process from CPU design where tasks are divided among specialized "executors".

  1. Data Fetching: Getting packets from the internet.

  2. SigVerify: Checking digital signatures (GPU intensive).

  3. Banking Stage: Executing smart contract logic.

  4. Write Stage: Saving the results to the ledger.

    As soon as the "SigVerify" member finishes a batch, they hand it to the "Execution" member and immediately start on the next batch.

7. Cloudbreak: The 100-Lane Highway

As a network grows, the account database usually becomes a massive bottleneck. Cloudbreak turns that single-lane road into a 100-lane highway. It uses memory mapping, telling the OS to treat the account file on the SSD as if it were part of computer RAM. This enables the CPU to access data directly and scales horizontally by utilizing multiple SSDs simultaneously.

Standard Blockchain Database Bottleneck

Figure 4: Standard Database (Single-Lane Bottleneck)

Cloudbreak Multi-Lane Highway

Figure 5: Cloudbreak (100-Lane Highway)

8. Archivers: Decentralizing the "Forever"

Solana generates approximately 4 petabytes of data per year.

This number is a rough upper limit based on how much data the network could handle at full speed. It is meant to explain the design choice, not describe current network usage.

It’s impossible for every validator to store that history. Archivers solve this by separating processing from storage. The ledger is broken into ton of tiny fragments and stored by different nodes. These nodes are lightweight and they don't participate in consensus.

Archivers must periodically pass a cryptographic challenge to prove they are actually storing their piece of data and haven't deleted it.

References & Further Reading