Solana’s highly performant blockchain is built using the eight innovations:

1. Proof of History: A clock before consensus
2. Tower BFT: A PoH-optimized version of PBFT
3. Turbine: A block propagation protocol
4. Gulfstream: Mempool-less transaction forwarding protocol
5. Sealevel: World’s first parallel smart contracts run-time
6. Pipelining: Transaction processing unit for validation
7. Cloudbreak: Horizontally-scaled accounts database
8. Archivers: Distributed ledger storage

Proof of History: A clock before consensus The biggest challenge in distributed networks is agreeing on the time and sequence in which events occurred as nodes within the network can’t trust the timestamp on messages received from other nodes. Solana attempts to solve this with Proof of History (PoH) by creating a cryptographically secure source of time across the network. Proof of History is a high-frequency Verifiable Delay Function (VDF), which requires a specific number of sequential steps to evaluate but produces a unique output that can be publicly verified. This means that nodes can create the next block without having to coordinate with the entire network first because they can trust the timestamp and ordering of the messages that they’ve received. The result is a reduction in consensus overhead.

Tower BFT: A PoH-optimized version of PBFT On top of Proof of History, Solana runs its consensus mechanism called Tower BFT, which is a PBFT-like algorithm that leverages the synchronized clock enabled by PoH to achieve consensus on network transactions. At a high level, each time a node on the network votes on a particular fork, they commit to a certain amount of time where they are locked out from voting on an opposing fork. This period where they are locked out grows exponentially as they continue to vote on the same fork until they achieve a maximum lockout at 32 votes for the same fork. Nodes on the network will only receive inflation rewards when they reach this maximum vote lockout; therefore, it is in their interest to continue voting on the fork they believe the supermajority of the network is voting for.

Turbine: A block propagation protocol Solana transmits blocks (communicates blocks between validators) independently of consensus, using a separate but connected protocol called Turbine. Turbine borrows heavily from BitTorrent and is optimized for streaming. As a block is streamed, it is broken up into small packets along with erasure codes, and then fanned out across a large set of random peers.

Gulf Stream: Mempool-less transaction forwarding protocol In a high-performance network, mempool management presents a new class of problems when it comes to the cost of filtering and maintaining a rising number of unconfirmed transactions. Gulf Stream functions by pushing transaction caching and forwarding to the edge of the network. Since every validator knows the order of upcoming leaders (block producers) in Solana architecture, clients and validators forward transactions to the expected leader ahead of time. This allows validators to execute transactions ahead of time, reduce confirmation times, switch leaders faster, and reduce the memory pressure on validators from the unconfirmed transaction pool. One consequence of knowing leaders ahead of time is an increased risk of validator collusion since the network allows more time for them to coordinate. Solana's fast block times might mitigate the opportunity for collusion because it limits the time allowed to plan an attack.

Sealevel: Parallel smart contracts run-time Solana built Sealevel, a hyper parallelized transaction processing engine designed to scale horizontally across GPUs and SSDs. Most other blockchains are single-threaded computers. In contrast, Solana can support parallel transaction execution (in addition to signature verification) in a single shard. The solution to this problem borrows heavily from an operating system driver technique called scatter-gather. Transactions specify upfront what state they will read and write while executing. Sealevel is able to find the non-overlapping transactions occurring in a block and execute them in parallel (called parallel execution) while optimizing how read and writes to the state are scheduled across an array of RAID 0 SSDs. Sealevel is a VM that schedules transactions, but it doesn’t actually execute transactions in the VM. Instead, Sealevel hands off transactions to be executed on hardware natively using bytecode called the Berkeley Packet Filter (BPF).

Pipeline: A Transaction Processing Unit for validation optimization The process of transaction validation on the Solana network makes extensive use of an optimization common in CPU design called pipelining. Pipelining is an appropriate process when there’s a stream of input data that needs to be processed by a sequence of steps and there’s different hardware responsible for each step. On the Solana network, the pipeline mechanism, the Transaction Processing Unit (TPU), progresses through Data Fetching at the kernel level, Signature Verification at the GPU level, Banking at the CPU level, and Writing at the kernel space. By the time the TPU starts to send blocks out to the validators, it’s already fetched in the next set of packets, verified their signatures, and begun crediting tokens. The GPU parallelization in this four-stage pipeline allows the Solana TPU to operate at a high performance.

Cloudbreak: Horizontally-scaled accounts database Methods to scale computation using these other innovations could result in memory bottlenecks. Memory is used to keep track of accounts and can struggle to maintain performance due to a lack of memory size and limited access speeds. Cloudbreak was designed to optimize for concurrent reads and writes spread across a RAID 0 configuration of SSDs. Each additional disk adds storage capacity available to on-chain programs, while also increasing the number of concurrent reads and writes programs can perform when executing. This goes hand in hand with Solana’s transaction design, allowing for pre-fetching accounts from disk and preparing the runtime for execution, also enabling nodes on the network to begin executing transactions before they are encoded into a block. All of this aims to help reduces block times and confirmation latency on the network.

Archivers: Distributed ledger storage Storing and maintaining data on a high-performance network is likely to become a primary centralization vector. If storage costs are very high, only well-funded entities will be able to act as validators and participate in consensus. On Solana, data storage is offloaded from validators to a network of nodes called Archivers. Archivers do not participate in consensus. The history of the state is broken into many pieces and erasure codes. Archivers store small parts of the state. Every so often, the network will ask the Archivers to prove that they’re storing the data they are supposed to. Solana leverages Proofs of Replication (PoRep), which are borrowed heavily from Filecoin. Archivers are not currently implemented and are on the long term roadmap. They will be rolled out based on network data demands.