Engineering
Solana

Introduction

As a result of its unique architecture, Solana is the fastest, most performant, most scalable and most cost-efficient blockchain. Its architecture is built leveraging a couple of technologies to maximise throughput. By processing read and write (in some cases) in parallel, transactions are propagated in an optimized manner, and tracked using a unique cryptographic clock. The uniqueness of this architecture and massive growth in its developer ecosystem has created the need for more specialized professionals that understand how the working parts of Solana come together to give it its high throughput and low latency.

In this chapter we shall approach Solana from an holistic point of view to grasp how its key components function to order and facilitate transactions at incredibly low cost. At a high level, Solana consist of the following key innovations:

Proof of History (PoH):

Proof of History (PoH) Proof of History is the most fundamental idea behind the trustless property of the network and can be thought of as the basis of all major technical optimizations on the network. It is analogous to a cryptographic clock that orders transactions before they are voted and included in blocks (a process known as consensus). At its core, it is a verifiable delay function implemented as a sequential hash function. Through PoH, Solana minimises the overhead of having a node-to-node communication so multiple rounds of voting is not required to commit to a block. Underlying this trusted quality of PoH is the SHA256 which ensures it is deterministic, preimage resistant and collision resistant. Every node/client running a Solana Client runs a dedicated PoH that constantly executes the SHA256 algorithm which generates recorded sequences on a single CPU core but other validators can verify the correctness of the hashes in parallel.

Tower BFT:

is a customized optimized implementation of PBFT (Practical Byzantine Fault Tolerance) that leverages PoH ledger to ensure the network can reach a state of consensus even when some participants (nodes) fail. By virtue of the ledger being a reliable network clock itself, the PBFT time-outs in the ledger can be encoded so validators can stake their votes based on elapsed time. It works by enforcing “vote-locking” which gives votes weight over an elapsed period. Validators submit a vote to commit a particular block (identified by its blockhash and slot number) and this vote will include the validator’s “staked” weight. If a validator votes for a slot at a given time T, they must wait for 2^n slots before changing their vote (n represents the number of “consecutive” votes) and the more a validator commits to a chain of votes, the longer they must wait before switching to a competing fork (a process known as lockout) therefore preventing them from changing their votes trivially and frequently and reducing the likelihood of creating forks.