Since its conception, Solana's development has evidenced its compromise to optimise the capabilities offered by a Layer-1 blockchain. Built upon pre-established concepts like Delegated Proof of Stake (dPoS) and Smart Contracts, Solana has contributed unique features to its field. While the solutions introduced by Solana are aimed to address the blockchain trilemma—scalability, security, and decentralisation, its development is mainly focused on scalability, with a modified dPoS protocol that leverages the Proof of History (PoH) algorithm. This design enables Solana to achieve a transactions-per-second (TPS) rate that surpasses industry standards while maintaining robust security.
Solana is a high-performance platform that implements a permissionless and high-speed layer-1 blockchain. While it employs a dPoS consensus mechanism on the surface, it has been adjusted to align with the network's objective of delivering a scalable and fast ecosystem. Therefore, Solana is a blockchain that prioritises liveness over consistency. In simple terms, this means that Solana places a greater emphasis on continuous functionality within the blockchain—processing transactions and generating blocks—rather than uniform consistency across all nodes, where each node sees the same information simultaneously.[1]
To comprehend how Solana accomplishes its purposes, mainly through developing concepts such as PoH and a particular approach to processing transactions and creating smart contracts, it becomes imperative to deconstruct its architecture.
Solana's Architecture can be analysed in three distinct but inextricably linked aspects, each contributing notable features to this Layer-1 blockchain. These facets are critical to achieving remarkable performance metrics related to transactions processed per second, costs and scalability. Solana Architecture's three primary aspects can be summarised as follows:
Solana achieves its Consensus through a customised dPoS mechanism complemented by the PoH algorithm. This dPoS consensus features a tailored protocol for replicating information between network nodes. Meanwhile, the PoH algorithm consists of a verifiable delay function that allows transactions to be ordered chronologically, reducing consensus time and improving the overall network efficiency.
This approach enables Solana to process thousands of TPS, which positions itself among the fastest blockchain networks. Let's delve into the three main components contributing to Solana's consensus achievement.
Establishing a reliable and trusted time source in decentralised networks can be challenging, as nodes cannot trust external timestamps. In this context, Solana's PoH provides a verifiable historical record that proves when a specific event occurred.
The PoH algorithm operates as a high-frequency Verifiable Delay Function. In simple terms, this means that PoH is a cryptographic function that executes a defined number of sequential steps, after which it produces a unique and publicly verifiable output. Solana's PoH is implemented through a sequential hash continuously running over itself, with each result as the subsequent input.
Periodically, the system records both the count and the current output. This process ensures that real-time has passed between each counter generation, and the recorded order of each counter aligns with the chronological sequence of events in real time.
While the generation of the recorded sequence is restricted to one Validator each time, the output can be simultaneously verified, providing a secure and transparent means to establish a consistent historical timeline. With the development of PoH, Solana not only addresses the challenge of decentralised time agreements but also enhances its speed and efficiency by reducing the time it takes to reach a consensus on the chronological order of events recorded on the blockchain.
Solana achieves network state consensus thanks to the Tower BFT's mechanism, which, as mentioned above, integrates the PoH algorithm to improve network efficiency and minimise transaction processing delays. Unlike traditional PBFT approaches, where network nodes exchange messages to agree on the order of transactions and the system's state, Solana's PoH acts as a global time source, encoding times directly into the blockchain and eliminating constant messaging between validators for time consensus, facilitating synchronisation through a shared ledger.
Solana's Validators are organised into Clusters, proposing and voting on transaction blocks to maintain the blockchain's functionality. Clusters operate in units of time called slots, each with a designated leader overseeing block production, critical transaction and block parameters, and their propagation. When Validators achieve a supermajority consensus, meaning two-thirds of the staked weight of a Cluster, they communicate the outcome to the Cluster's leader, who finalises the block.
Solana's dPoS consensus architecture allows token holders to participate in the Consensus by staking SOL with validators and obtaining SOL as rewards from network emissions. While there's no minimum staked SOL requirement, Validators need a sufficient balance to cover transaction fees for ongoing participation in Consensus.
Solana tackles the scalability challenge of the blockchain trilemma with the Turbine protocol, a block propagation solution. While traditional blockchains face latency as the number of nodes increases, making it difficult to propagate data efficiently. Turbine optimises data propagation by breaking large blocks into 64KB packets, which are then sent to different Validators. Each Validator then relays the packet to a "neighbourhood" composed of other Validators, forming a tree-like network structure. With a stake-weighted selection algorithm, higher-stakes validators are strategically positioned closer to the Cluster leader in the tree, prioritising efficient data transmission.
Nodes refusing to broadcast information or spreading incorrect data are security concerns addressed by allowing validators to reconstruct entire blocks even if a portion of the packets is dropped. Cluster leaders dynamically observe packet drop rates, ensuring that Validators can address these types of behaviour. Despite not being exempt from potential challenges, this protocol offers a scalable and secure solution to the blockchain scalability issue.
While Solana's consensus mechanism establishes the foundation for achieving high TPS, additional developments concerning how to process transactions contribute to its performance metrics. Solana employs a unique process for validating and replicating transactions. Additionally, the handling of pending transactions is optimised through its mempool-less transaction forwarding protocol, known as Gulf-Stream.
Solana employs a process known as the Pipeline to validate and replicate transactions, achieving confirmation times of under a second. This mechanism leverages pipelining, a CPU design optimisation, to process a continuous flow of transaction data through different stages.
To begin with, the Transaction Processing Unit (TPU), the core component responsible for efficiently processing transactions, undergoes a four-phase sequence: Data Fetching, Signature Verification, Banking, and Writing. Each phase is executed by specific sections of the hardware infrastructure provided by a Validator, enabling the concurrent processing of four transactions. Simultaneously, the Validator nodes manage the Transaction Validation Unit (TVU), a component that validates transactions. With this parallelisation mechanism, the Solana TPU can handle 50,000 transactions simultaneously.
As mentioned, Solana employs the Turbine protocol to mitigate network congestion during block propagation. Paired with Pipeline, it accelerates transaction processing and streamlines block propagation, effectively addressing blockchain scalability challenges.
A mempool, a repository of unconfirmed transactions waiting to be processed on a blockchain, serves as a critical component of network efficiency. Unlike blockchains such as Bitcoin or Ethereum, which may contend with mempools of thousands of pending transactions, Solana implements a mempool-less protocol. In this context, its Validators can efficiently handle 100,000 transactions within seconds without increasing its network throughput.
This mechanism, known as Gulf Stream, involves Validators forwarding transactions to their expected Cluster leaders in advance, enabling transactions to be executed ahead of time, reducing confirmation times, and alleviating memory pressure on Validators.
This approach is effective due to the deterministic nature of Solana's Cluster leader selection, which allows for optimised transaction handling. Interfaces used by users, such as wallets, sign transactions referencing a specific block hash, ensuring its validity within a defined time frame. Then, Validators forward transactions to their upcoming Cluster leader, enabling users to receive timely confirmations. This architecture enhances transaction processing efficiency and, by supporting prioritisation based on Validator staked amounts, fosters network resilience in the face of potential denial-of-service attacks.
As a layer-1 blockchain capable of supporting smart contracts, Solana has a unique approach to handling the development of decentralised applications (dApps). To fully understand how dApps are created and how users interact with them, two concepts are essential: accounts and programs, each designed by Solana Labs. Additionally, aiming for scalability, Solana employs a particular method for processing state modifications in dApps, which enables parallel runtime.
Accounts within the Solana ecosystem are the means to store and organise the wide range of data in the network, covering tokens, program variables and even entire programs. Each account occupies memory space provided by Solana Validators and subsequently incurs mandatory rent. This rent, paid in SOL, can be exempted if the account holds sufficient SOL to cover two years of renting. Conversely, insufficient SOL to pay rent may result in immediate account removal. Accounts have associated metadata, including SOL balance, ownership details, executable status, stored data, and the rent epoch.
Solana features two account types: executable and non-executable. Executable accounts contain the code that governs Solana programs' logic. This code is executed through transactions initiated by users or other programs. On the other hand, non-executable accounts are responsible for recording changes to programs or, in other words, storing the state of executable accounts.
Solana Programs are executable code stored in accounts and can be triggered through transactions. One feature differentiating Solana from other smart contract blockchains, such as Ethereum, is that their programs are stateless. In simple terms, while programs are stored in executable accounts, their state is stored separately in non-executable accounts, enhancing runtime efficiency.
In this context, Solana features two types of programs: native and on-chain programs. Native programs, developed by Solana Labs, are integral to the blockchain's core functionality. Examples include the System Program, managing account creation and token transfers; the BPF Loader Program, handling on-chain program deployment and execution; and the Staking program, overseeing SOL staking management.
On the other hand, on-chain programs are user-written programs directly deployed on the blockchain. These programs leverage the infrastructure provided by Native programs, enabling the development of diverse applications and services on Solana. For instance, by leveraging the infrastructure supplied by Native programs, such as the Solana Program Library—which consists of a collection of pre-written, modular programs— developers can create diverse applications and services on the Solana blockchain. This library supports tasks like token creation, swapping, lending, stake pool generation, and on-chain name services maintenance.
Lastly, unlike on other blockchains, Solana's on-chain programs can be updated by their owner after they have been deployed on the network. In contrast, native programs are updated as new versions of the network software are released.
Sealevel is Solana's parallel smart contracts runtime, a system that improves the efficiency of the network by making it capable of concurrently processing thousands of contracts. Unlike the single-threaded execution times of platforms such as Ethereum, Solana achieves simultaneous contract processing thanks to Sealevel's unique transaction structuring. Each transaction in Solana must specify the states it will read or write during its execution, leveraging a database of accounts known as Cloudbreak and the BPF loader program for executing executable accounts.
Since Solana does not rely on a single shared state across the network, as long as there are no conflicts with the state to be read or modified, Solana can simultaneously process transactions involving the same program. In this context, Sealevel optimises transaction processing by sorting and scheduling transactions in parallel, using instructions for concurrent execution across multiple Validators. This system allows Solana to provide high throughput and usability.
Solana, whose mainnet remains in beta, faced significant challenges in preventing past halting instances, which occurred multiple times in 2022 and 2023, making some users cautious about engaging with the network. Additionally, claims were made that Solana TPS is less than the presented numbers, as they count validators' messaging as transactions. On another front, throughout 2023, Solana actively worked to disassociate itself from being linked with controversial participants in the industry.
Although some of the problems that caused the downtime have reappeared, the previously achieved stability has generated attention and proven Solana to be a reliable system, healing some wounds on Solana's track record. Moreover, its unique technological approach to solving blockchain constraints has received support from influential figures like Rune Christensen, the founder of MakerDAO. This public display of support, coupled with the tangible confidence vote reflected in the recent surge of applications developed on the network and the announcements of applications transitioning to a Solana Virtual Machine compatible infrastructure, has restored Solana to the forefront. It once again positions itself as one of the networks that capture widespread attention.
[1] Solana Foundation, “Solana Blog - Tower BFT: Solana’s High Performance Implementation of PBFT” (Solana Blog, July 16 2019)<https://solana.com/news/tower-bft--solana-s-high-performance-implementation-of-pbft> accessed February 12, 2024
[2] Anatoly Yakovenko, “Proof of History: A Clock for Blockchain” (Medium, April 19, 2018) <https://solana.com/news/proof-of-history> accessed February 12, 2024
[3] “Solana Documentation - Implemented Proposals - Tower BFT” <https://docs.solanalabs.com/implemented-proposals/tower-bft> accessed February 12, 2024
[4] “Solana Labs Documentation - Consensus - Turbine Block Propagation” <https://docs.solanalabs.com/consensus/turbine-block-propagation> accessed February 12, 2024
[5] Andrew Hyde, “Pipelining in Solana: The Transaction Processing Unit” (Solana Medium, September 23, 2019) <https://medium.com/solana-labs/pipelining-in-solana-the-transaction-processing-unit-2bb01dbd2d8f> accessed February 12, 2024
[6] Anatoly Yakovenko, “Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol” (Solana Medium, June 20, 2019) <https://solana.com/news/proof-of-history> accessed February 12, 2024
[7] “Solana Documentation - Core - Accounts” <https://solana.com/docs/core/accounts> accessed February 12, 2024
[8] “Solana Documentation - Core - Programs” <https://solana.com/it/docs/core/programs> accessed February 12, 2024
[9] “Solana Program Library Documentation - Token” <https://spl.solana.com/token> accessed February 12, 2024
[10] Anatoly Yakovenko, “Sealevel — Parallel Processing Thousands of Smart Contracts” (Solana Medium, September 9, 2019) <https://medium.com/solana-labs/sealevel-parallel-processing-thousands-of-smart-contracts-d814b378192> accessed February 12, 2024