Solana

How it works Users

Gulf
Stream
Block
Building

An executive overview of the Solana protocol Consensus

Block
Turbine
Verification
 RPCs
3,000 +
Global Base of
Apps & Users
Validators
Validators
1,500 +

Solana
How it works
 Users Gulf Stream Block Building
RPCs Validators
Proof of History (PoH) Service
Wallet dApp 1.5% stake

Connect 2% stake Banking

$420 3% stake
Entry

Broadcast
Send

Sig Verify
Entry

Fetch
1% stake Entry
Sign Build
Entry
0.5% stake

Non paired RPCs Bank >> Accounts DB

slot 0 slot 1 slot 2 slot 3 slot 4 slot 5 Gossip Downstream

Service Validators L Leader
Block 5
Empty

0 Root Node
Block 3
Empty

rooted Shred 1 2 3
Retra- Verify Shred
Block 0

Block 1

Block 4

Replay
nsmit Leader Fetch
Sig
Block 2

4 5 6 7 8 9 10 11 12
pruned
13 14
pruned Bank >> AccountsDB Solana
How it works
Consensus Block Verification Turbine
 Solana – Executive Overview

Table of Contents
I. Introduction 5
II. Users 9
III. Gulf Stream 17
IV. Block Building 23
V. Proof of History 28
VI. Accounts Model 33
VII. Turbine 39
VIII. Consensus 43
IX. Gossip & Archive 49
X. Economics & Jito 53

The opinions and interpretations presented in this report are solely those of the author and do not represent the views of Turbin3,
Helius, the Solana Foundation, Solana Labs, or any other entity. The author conducted this research through a review of
Disclaimers documentation, literature analysis, code examination, interviews with ecosystem participants, and independent research. Nothing in
this document should be misconstrued as an endorsement or recommendation to purchase the SOL token. This content is for
informational purposes only and does not constitute investment advice.
 Solana – Executive Overview

Author’s Note
This document aims to offer a holistic overview of the core Solana protocol that
balances accessibility and depth. That is, this report aims to provide a resource
that does not assume extensive industry knowledge while also not shying away
from the complexities of the Solana protocol. Something easier said than done!

I hope this work can become a valuable reference to a wide range of professionals
in industries adjacent to crypto, such as payments, finance, and e-commerce, for
whom Solana is now appearing on their radar. While Solana is indeed more
complex than traditional blockchains, it is by no means impenetrable, as this
report aims to demonstrate.
Lostin
My sincere thanks to 0xIchigo, dubbelosix, Jacob Creech, Maël Bomane, Solana enthusiast,
Nagaprasad Vr, and Rex St. John for reading earlier versions of this report and Technical writer, Helius
providing invaluable feedback. Lastly, I’d like to acknowledge the support and
guidance of Jeff (@japarjam), Jack Sturt, and Mert in bringing this project Twitter: @__lostin__
together.

4
Lostin
I
Solana – Executive Overview

“We knew smaller, faster, cheaper better than

anybody else in the world, and now we're
applying those concepts to blockchain.”

— Greg Fitzgerald, Solana co-founder

Global State Machine Synchronized at the Speed of Light

Introduction
Gulf Block
Users
Stream Building

Block
Consensus Turbine
Verification

Key concepts: integrated, composability, the leader

 Solana – Executive Overview

Solana is a high- of 400 milliseconds and to its capabilities. Solana hardware. This means that
performance, low-latency transaction fees that are takes an integrated approach software exploits whatever
blockchain renowned for fractions of a cent, it delivers to blockchain development, hardware it runs on to the
its speed, efficiency and on both speed and cost- that leverages the founding fullest and scales with it.
focus on user experience. effectiveness. team's decades of experience
Its unique integrated in building distributed As a unified ecosystem, all
architecture enables This report delves into the systems. applications built on this
thousands of transactions intricacies of Solana's design single blockchain inherit

6
per second across a and operation, exploring the One of Solana's core composability, enabling them
globally decentralized key components and principles is that software to interact and build upon
network. With a block time mechanisms that contribute should never get in the way of each other.
 Solana – Executive Overview

This architecture also ensures a Transaction Lifecycle - This block of transactions is then
straightforward and intuitive user propagated throughout the network for
experience with no need for bridging, Our primary lens for understanding other validators to execute and confirm.
separate chain IDs, or fragmentation of Solana throughout this report will be the
liquidity. lifecycle of a typical transaction. The subsequent sections of this report
will expand out this model and delve into
Solana is evolving rapidly, with recent To construct a basic model for this process in much greater detail,
developments such as SVM rollups understanding Solana transactions, we beginning with the key participants—the
and ZK Compression as important can outline the process as follows: users.
scaling solutions. While these projects
may one day come to shape our future - Users initiate transactions, all of which
perception of Solana, they are currently are sent to the current lead block
in the very early stages of development producer (known as the leader). The
or adoption and will not be covered in leader compiles these transactions into
this report. a block, executing them and thereby
updating the blockchain's state.

Substantial changes to the core Solana protocol go through a formal, transparent process of submitting a Solana
Improvement Document (SIMD) which community members and core engineering will publicly critique. SIMDs are then
voted on by the network.
 Solana – Executive Overview

Gulf Block
Users
Stream Building

Block Turbine
Consensus
Verification

Six stages Earlier chapters are arranged This overlap is unavoidable

according to these six stages. The because the six-stage framework
We will reference the six-stage final chapters—Gossip, Archive, has its limitations. In reality,
visual shown above throughout Economics, and Jito—tie up any Solana is a complex distributed
this report, as it offers us a loose ends. However, it’s important system with many interdependent

8
consistent framework for to note that some chapters will span elements.
understanding the relationships multiple stages, and some stages
between Solana's core elements. will appear in multiple chapters.
II
Solana – Executive Overview

“Solana has the potential to be

the Apple of crypto,”

— Raj Gokal, Solana co-founder

Global State Machine Synchronized at the Speed of Light

Gulf Block

Users
Users
Stream Building

Block
Consensus Verification Turbine

Key concepts: transactions, keypairs, Ed25519

 Solana – Executive Overview

A user's journey A user’s account on the password or

typically begins by Solana can be thought access key that grants Public Key (Base58 string)
setting up and funding of as a data structure permission to access
a wallet application. that holds information and modify the FDKJvWcJNae6wecbgDYDFPCfgs1
Multiple popular wallet and state related to their account. 4aJnVsUfWQRYWLn4Tn
applications are interactions with the
available for Solana, Solana blockchain. In Signing with private Keypair (Base58 string)
either as native mobile this way, a public key is keys is how
applications or browser similar to a filename: blockchains handle 3j15jr41S9KmdfughusutvvqBjAeEDb
extensions. just as a filename authorization. U5sDQp8EbwQ3Hify2pfM1hiEsuFFA
uniquely identifies a file Knowledge of the Vq8bwGywnZpswrbDzPENbBZbd5nj
Wallets within a file system, a private key gives
cryptographically Solana public key absolute authority over Keypair (integer array)
generate user keypairs, uniquely identifies an the account.
consisting of public and account on the Solana [63,107,47,255,141,135,58,142,191,2
private keys. The public blockchain. Public keys Solana private keys are 45,78,18,90,162,107,197,8,33,211,15,
key acts as the unique on Solana are also 32-bytes in length. 228,235,250,30,185,122,105,23,147,1
identifier for their represented as 32-byte Keypairs are the 64- 15,115,86,8,155,67,155,110,51,117,0,
account and is known Base58-encoded strings. byte combinations of 19,150,143,217,132,205,122,91,167,6
by all participants in the public (first half) and 1,6,246,107,39,51,110,185,81,13,81,1
network. A private key — also private (second half) 6,182,30,71]
known as a secret key — keys.
can be considered as
 Solana – Executive Overview

The user signs transactions with

their private key. This signature
is included with the transaction
data and can be verified by other
participants using the sender's
public key. This process ensures
the transaction has not been
tampered with and is authorized
by the owner of the
corresponding private key. The
signature also acts as a unique
identifier for the transaction.

Sending a transaction is the only

way to mutate state on Solana.
Private keys can also be derived Solana uses Ed25519, a widely-used
Any write operation is performed
from mnemonic seed phrases, elliptic curve, for its public-key
through a transaction, and
usually consisting of 12 or 24 words. cryptography needs. Ed25519 is
transactions are atomic—either
This format is often used by wallets favored for its small key size, small
everything the transaction
for easier backup and recovery. signature size, fast computation, and
attempts to do happens or the
Multiple keys can be derived immunity to many common attacks.
transaction fails.
deterministically from a single seed Each Solana wallet address represents
phrase. a point on the Ed25519 elliptic curve.
 Solana – Executive Overview

A Solana Transaction

Colored text = Size in bytes

 Solana – Executive Overview

A transaction, more However, knowing in after 151 blocks (about 1 Each instruction specifies the
formally known as a advance which pieces of minute). By default, RPCs program to execute, the
"transaction message," state a transaction will attempt to forward accounts required, and the
comprises four sections: a interact with enables transactions every 2 data needed for the
header, a list of account optimizations not seconds until the instruction's execution.
addresses, a recent possible on many other transaction is either
blockhash, and blockchains. finalized or the recent The number of instructions in
instructions. blockhash expires, at a transaction is limited first
Header: The header which point the by its size, which can be up
Account Addresses: This contains references to the transaction is dropped. to 1,232 bytes. There are also
list includes all the account address list, limits around the number of
accounts that will be read indicating which accounts Instructions: These are accounts that can be
from or written to during must sign the transaction. the core of the referenced. Lastly, there are
the transaction. Building transaction. Each limits to a transaction’s
such a list for every Recent Blockhash: This is instruction represents a complexity measured in
transaction is a used to prevent duplicate specific operation (e.g., compute units (CUs). CUs
requirement unique to and stale transactions. A transfer, mint, burn, quantify the computational
Solana and can be recent blockhash expires create account, close resources expended in
challenging for developers. account). processing transactions.

13
 Solana – Executive Overview

total fee = prioritization fee + base fee

prioritization fee = compute unit price (micro-lamports) x compute unit limit

The cost in SOL to execute a optional, but during periods of high Currently, 50% of all transaction-
transaction is separated into 2 parts demand for blockspace become related fees are burnt, permanently
- a base fee and a prioritization fee. necessary. These fees are priced in removing this SOL from circulation
The base fee is a fixed 5000 micro-lamports (millionth of a with the remaining 50% going to the
lamports per signature cost lamport) per compute unit. block producer. A new change (SIMD
irrespective of the transaction’s 96) is soon to be introduced allowing
complexity, usually there is 1 Their purpose is to act as a price for 100% of prioritization fees to go to
signature per transaction. signal, making transactions more the block producer. Base fees remain
Prioritization fees are technically economically compelling for validator unchanged.
nodes to include in their blocks.

The smallest unit of SOL is known as a "lamport," equivalent to one billionth of a SOL, similar to a satoshi in Bitcoin. The
lamport is named after Leslie Lamport, a computer scientist and mathematician whose research established many
theoretical foundations of modern distributed systems.
 Solana – Executive Overview

A user connects their wallet to the message parameters based on the Once the transaction message is ready,
application, allowing the app to read user’s interactions. For example, if a it is sent to the wallet to be signed with
the user’s public key which remains user wanted to swap two tokens, they the user’s private key. The user is
encrypted and securely sandboxed in would specify the amount of tokens to prompted with a popup to confirm their
a separate environment. buy, the corresponding tokens to sell, willingness to transact. This popup may
and an acceptable slippage rate. include a simulation of the transaction’s
The application builds the transaction results.
 Solana – Executive Overview

The term “failed transaction” on Solana is misleading and has caused considerable confusion. These
transactions incur fees and are executed successfully by the runtime exactly as the signer intended. They
“fail” due to the transaction’s own logic requiring them to do so. +80% of “failed” transactions come from error
code 0x1771, the code for exceeding slippage amount. Notably, 95% of these transactions are submitted by
only 0.1% of active Solana addresses, primarily automated bots attempting to take advantage of time-
sensitive price arbitrage opportunities.

Once signed, the message and They are an essential service that
the signature are returned to the enables applications to submit or
app, which forwards the simulate signed transactions and
transaction to an RPC provider. efficiently retrieve on-chain data.
RPC (Remote Procedure Call) Applications who wish to interact
providers act as intermediaries with the network do so via a JSON-
between applications and the RPC or a WebSocket endpoint.
validators that build blocks.
III
Solana – Executive Overview

“Literally the goal of Solana is to carry

transactions as fast as news travels around
the world — so speed of light through fiber.
Who we’re competing with is NASDAQ and
the New York Stock Exchange.”

— Anatoly Yakovenko, Solana co-founder

Global State Machine Synchronized at the Speed of Light

Gulf Stream
Gulf Block
Users
Stream Building

Block
Consensus Turbine
Verification

Key concepts: RPCs, SW QoS, QUIC

 Solana – Executive Overview

RPCs (Remote Procedure Calls) refer to Unlike full validator nodes, RPC nodes paid service for developers. Solana
RPC nodes. These nodes can be thought do not hold any stake in the network. stands out because it was designed
of as gateways to interact with and read Without stake, they cannot vote or build from the outset to operate without a
data from the network. They run the blocks. This setup differs from most mempool. Unlike traditional
same software as full validators but with other blockchains, where validator and blockchains that use gossip protocols
different settings, allowing them to RPC nodes are typically the same. Since to randomly and broadly propagate
accurately simulate transactions and RPC nodes do not receive staking transactions across the network,
maintain an up-to-date view of the rewards, the economics of running RPC Solana forwards all transactions to a
current state. As of this writing, there are nodes are distinct from those of predetermined lead validator, known
over 4,000 RPC nodes on Solana. validators with many operating as a as the leader, for each slot.
 Solana – Executive Overview

Solana operates four clusters: Localnet, Testnet, Devnet, and Mainnet-beta. When people refer to Solana or the Solana
network, they almost always refer to Mainnet-Beta. Mainnet-Beta is the only cluster where tokens hold real value, while the
other clusters are used solely for testing purposes.

Once an RPC receives a transaction are forwarded to the leader, who has This system enables leaders to
message to be included in a block, it the opportunity to produce a block. prioritize transaction messages that
must be forwarded to the leader. A When it is a validator’s turn, they are proxied through other staked
leader schedule is produced before switch to "leader mode," begin actively validators. Here, validators with a
every epoch (approximately every processing transactions and higher stake are granted a
two days). The upcoming epoch is broadcast them to the rest of the proportionally higher capacity to
divided into slots, each fixed at 400 network. transmit transaction message packets
milliseconds, and a leader is chosen to the leader. This approach effectively
for each slot. Validators with more In early 2024, Solana introduced a new mitigates Sybil attacks from non-
stake have a higher chance of being mechanism aimed at preventing spam staked nodes across the network.
chosen as leaders. During each slot, and enhancing Sybil resistance, known
transaction messages as "Stake-Weighted Quality of Service"
(SWQoS).
Solana – Executive Overview
 Solana – Executive Overview

Under this model, validators highways, where drivers A QUIC Note It facilitates rapid,
can also engage in pay a toll to avoid traffic. asynchronous
agreements to lease their In late 2022, Solana communication similar to
stake-weighted capacity to SWQoS has impacted the adopted the QUIC UDP, but with the secure
RPC nodes. In return, RPC Solana ecosystem by networking protocol to sessions and advanced flow
nodes gain increased raising the requirements to manage transaction control strategies of TCP.
bandwidth, allowing them forward transactions to the message transmission to This allows for limits to be
to achieve greater leader and reducing the the leader. This transition placed on individual sources
transaction inclusion rates effectiveness of spam was prompted by network of traffic so that the network
in blocks. Notably, 80% of a attacks. The change has disruptions caused by bots can focus on processing
leader’s capacity (2,000 incentivized high-traffic spamming on-chain NFT genuine transactions. It also
connections) is reserved for applications to vertically mints. QUIC facilitates has a concept of separate
SWQoS, while the integrate their operations. rapid, asynchronous streams; so if one transaction
remaining 20% (500 By running their own communication. is dropped, it doesn’t need to
connections) is allocated validator nodes, or by block the remaining ones. In
for transaction messages having access to staked Initially developed by short, QUIC can be thought of
from non-staked nodes. connections, applications Google in 2012, QUIC as attempting to combine the
This allocation strategy can ensure privileged attempts to offer the best best characteristics of TCP
mirrors priority lanes on access to the leader, of both worlds. and UDP.
enhancing their transaction
processing capabilities.
 Solana – Executive Overview

Stake-weighting is a recurring principle found throughout Solana's core systems, encompassing voting rewards, turbine
trees, leader schedules, gulf stream and the gossip network. Validators with greater stake are accorded higher trust and
prioritized roles in the network.
IV
Solana – Executive Overview

“We consider SVM (Solana Virtual

Machine) the best in terms of virtual
machine technology currently.”

— Andre Cronje, Fantom Foundation

Global State Machine Synchronized at the Speed of Light

Block Building
Gulf Block
Users
Stream Building

Block
Consensus Turbine
Verification

Key concepts: TPU, the bank, entries, SVM

 Solana – Executive Overview

Many blockchain networks to gain acceptance, all Unit (TPU), the validator's described as the block-building
construct entire blocks transactions within it core logic responsible for stage. It is the most important
before broadcasting them, must be valid and block production. stage of the TPU, which gets
known as discrete block reproducible. its name from the “bank“. A
building. Solana, in Here, the transaction bank is just the state at a given
contrast, employs Two slots prior to processing sequence block. For every block, Solana
continuous block building assuming leadership, a begins with the Fetch has a bank that is used to
which involves assembling validator halts transaction Stage, where transactions access state at that block.
and streaming blocks forwarding to prepare for are received via QUIC. When a block becomes
dynamically as they are its upcoming workload. Subsequently, transactions finalized after enough
created during an allocated During this interval, progress to the SigVerify validators vote on it, they will
time slot, significantly inbound traffic spikes, Stage, undergoing rigorous flush account updates from
reducing latency. reaching over a gigabyte validation checks. Here the the bank to disk, making them
per second as the entire validator verifies the validity permanent. The final state of
Each slot lasts 400 network directs packets of signatures, checks for the chain is the result of all
milliseconds, and each to the incoming leader. the correct number of confirmed transactions. This
leader is assigned four signatures, and eliminates state can always be recreated
consecutive slots (1.6 Upon receipt, transaction duplicate transactions. from the blockchain history
seconds) before rotation to messages enter the deterministically.
the next leader. For a block Transaction Processing The banking stage can be
 Solana – Executive Overview

Transactions are processed made easy because each conditions by easily from and the other writes to
in parallel and packaged transaction must include selecting only non- the same account (read +
into ledger “entries,” which a complete list of all the conflicting transactions for write). Thus conflicting
are batches of 64 non- accounts it will read and execution within each entry. transactions go into different
conflicting transactions. write to. This design Transactions conflict if they entries and are executed
Parallel transaction choice places burden on both attempt to write to the sequentially, while non-
processing on Solana is developers but allows the same account (two writes) conflicting transactions are
validator to avoid race or if one attempts to read executed in parallel.
 Solana – Executive Overview

The term SVM can be ambiguous, as it may refer to either the "Solana Virtual Machine" or theIt"Sealevel Virtual Machine."
Both terms describe the same concept, with Sealevel being the name of Solana's runtime environment. The term SVM
continues to be loosely thrown around despite recent efforts to precisely define its boundaries.

There are six threads Once transactions have is executed, updating the machine built using the
processing transactions in been grouped into entries account states. A hash of Solana fork of rBPF, a library
parallel, with four dedicated they are ready to be the entry will be sent to the for working with JIT
to normal transactions and executed by the Solana Proof of History service to compilation and virtual
two exclusively handling Virtual Machine (SVM). be recorded (more on this machines for eBPF programs.
vote transactions which are in the next section). If the
integral to Solana’s The accounts necessary recording process is Note Solana does not
consensus mechanism. All for the transaction are successful, all changes will mandate how validators
parallelization of locked; checks are run to be committed to the bank, choose to order transactions
processing is achieved confirm the transaction is and the locks on each within a block. This flexibility
through multiple CPU cores; recent but hasn’t already account placed in the first is a crucial point that we will
validators have no GPU been processed. The step are lifted. Execution is return to later in the
requirements. accounts are loaded, and done by the SVM, a virtual Economics + Jito section of
the transaction logic this report.
 Solana – Executive Overview

Clients software known as a “client”. Firedancer is a complete

Solana launched with a single ground-up rewrite of the
Solana is a network validator client software — original client in the C
comprising thousands of originally the Solana Labs programming language. Built
independently operated nodes client, now known as the by an experienced team
collaborating to maintain a Agave client — written in Rust. from high-frequency trading
single unified ledger. Each Expanding client diversity has firm Jump, it promises to be
node constitutes a high- been a priority ever since and the most performant
performance machine running one that will truly come to validator client on any
the same open source fruition with the launch of the blockchain.
Firedancer client.
V
Solana – Executive Overview

“I had two coffees and a beer, and I was up

until 4:00 AM. I had this eureka moment that
puzzle [sic] similar to proof of work using
the same SHA-256 preimage-resistant hash
function… I knew that I had this arrow of time.”

— Anatoly Yakovenko, Solana co-founder

Global State Machine Synchronized at the Speed of Light

Proof of History
Gulf Block
Users
Stream Building

Block
Consensus Turbine
Verification

Key concepts: SHA256, PoH Service

 Solana – Executive Overview

Proof of History (PoH) is between nodes typically submitting their block. •Preimage Resistance:
Solana's secret sauce, increases as networks Finding the original input
functioning like a special expand, and coordination Underlying PoH are the from the hash output is
clock in every validator that becomes increasingly unique properties of hashing computationally infeasible.
facilitates synchronization complicated. Solana algorithms, specifically
across the network. PoH mitigates this by replacing SHA256: •Avalanche Effect: A small
establishes a reliable source node-to-node change in the input (even a
of truth for the order of communication with a PoH •Deterministic: The same single bit) results in a
events and the passage of local computation. This input will always produce the significantly different hash, a
time. Most critically it means validators can same hash. property known as the
ensures adherence to the commit to a block with just avalanche effect.
leader schedule. Despite a single round of voting. •Fixed Size: Regardless of
similar names, Proof of Trusted timestamps in input size, the output hash is •Collision Resistance: It is
History is not a consensus messages ensure that always 256 bits. infeasible to find two
algorithm such as Proof of validators cannot start their different inputs that produce
Work. blocks prematurely and •Efficient: It is relatively fast the same hash output.
must wait a minimum to compute the hash for any
Communication overhead amount of time before given input.
 Solana – Executive Overview

Within each validator have calculated each surprisingly narrow, with serves as a timestamp that
client, a dedicated Proof of hash sequentially — this only small differences inserts the entry into the
History service continually can be thought of as a among the fastest chain of hashes, proving
runs the SHA256 hash “micro proof of work.” Yet, machines. A common the sequence that
algorithm creating a chain other validators can verify upper limit has already transactions were
of hashes. Each hash’s the correctness of the been reached, despite processed. This process
input is the previous thousand hashes in significant time and effort not only confirms the
hash's output. This chain parallel at a much faster being invested in optimizing passage of time but also
acts the same as a rate than they were this function, largely due to serves as a cryptographic
verifiable delay function, produced since the input Bitcoin's reliance on it. record of the transactions.
given that the hashing and output of each hash
work must be done in have been broadcast to During a leader’s slot, the In a single block, there are
sequence and the results the network. Therefore, PoH service will receive 800,000 hashes. The PoH
of future hashes cannot be PoH is difficult to produce newly processed entries stream also includes "ticks,“
known ahead of time. If but easy to verify. from the banking stage. which are empty entries
the PoH service creates a The current PoH hash plus indicating the leader's
chain of a thousand The range of performance a hash of all transactions in liveness and the passage of
hashes, we know time has in computing SHA-256 the entry are combined into time.
passed for it to across different CPUs is the next PoH hash. This

30
 Solana – Executive Overview

31
 Solana – Executive Overview

The key benefit of PoH is that it ensures the correct leader schedule must be adhered to, even if a block producer is offline
— a state known as being “delinquent”. PoH prevents a malicious validator from producing blocks before their turn.

A tick occurs every 6.25 milliseconds,

resulting in 64 ticks per block and a
total block time of 400 milliseconds.

Validators continually run the PoH clock

even when they are not the leader. It
plays a pivotal role in the process of
synchronization between nodes.

32
VI
Solana – Executive Overview

“Separating code and state in SVM was

the best design decision. Blessed are the
embedded system devs that religiously
drilled this concept into my brain.”

— Anatoly Yakovenko, Solana co-founder

Global State Machine Synchronized at the Speed of Light

Gulf Block

Accounts Model
Users
Stream Building

Block
Consensus Turbine
Verification

Key concepts: AccountsDB, rent, ownership, PDAs

 Solana – Executive Overview

Within a Solana validator, the The primary data structure in As of writing, the number of
global state is maintained in the account index is a Solana accounts is easily in
the accounts database hashmap, making the hundreds of millions. This
known as AccountsDB. This AccountsDB essentially a vast large number is partly

34
database is responsible for key-value store. Here, the key because, as Solana developers
storing all accounts, both in is the account address, and often say, "Everything on
memory and on disk. the value is the account data. Solana is an account!"
 Solana – Executive Overview

Solana accounts
•Program accounts: These Field Format Description
An account is a container are larger accounts that
that persistently holds data, contain executable bytecode, The owner of the account. By
Public key
similar to a file on a somewhat equivalent to a Owner default this is the System
address
computer. They come in .exe file on Windows or a Program.
various forms: .app file on Mac.
The amount of SOL held by the
•Native program accounts: Lamports u64 account, measured in
•User accounts: These
These are special pre- Lamports (1 billionth of a SOL)
accounts have a private key
and are typically generated deployed program accounts
that perform various core Bytes,
by a wallet software for a This is the most important field,
functionalities of the Data variable
user. akin to the contents of a file.
network. Examples include length
•Data accounts: These the Vote Program and the
Legacy field for backward
accounts store state BPF Loader.
Rent Epoch u64 compatibility. More on rent
information, such as the later.
number of a specific token All accounts have the
a user holds. following fields: (see table) Boolean Marked ‘true’ if the account
Executable
flag holds an executable program.
 Solana – Executive Overview

Solana program accounts in TypeScript and Python Rent is a mechanism returned to the account
contain only executable are available to facilitate designed to incentivize users owner. For example, if a user
logic. This means when a the creation of application to close accounts and holds a dollar-denominated
program is run it mutates front-ends and enable reduce state bloat. stablecoin, this state is stored
the state of other accounts programmatic interaction in a token account. Currently,
but remains unchanged with the network. To create a new account, a the rent-exempt amount for a
itself. This separation of minimum balance of SOL, token account is 0.002 SOL. If
code and state Many common known as the "rent-exempt" the user transfers their entire
differentiates Solana from functionalities are amount, must be held by the stablecoin balance to a
other blockchains and provided out-of-the-box by account. This can be friend, the token account can
supports many of its native programs. For considered a storage cost be closed, and the user will
optimizations. example, Solana does not incurred to keep the account receive back their 0.002 SOL.
require developers to alive in a validator's memory. Programs often handle
Developers primarily write deploy code to create a If the size of the account's account closures
these programs in Rust, a token. Instead instructions data increases, the minimum automatically for users.
general-purpose are sent to a pre-deployed balance rent requirement Several applications are
programming language native program that will increases proportionally. available to help users clean
known for its strong focus set an account to store the When an account is no up old, unused accounts and
on safety and performance. token’s metadata, longer needed, it can be reclaim the small amounts of
Additionally, multiple SDKs effectively creating a new closed, and the rent is SOL stored in them.

36
token.
 Solana – Executive Overview

Ownership Storage of State

Solana's ownership model Solana programs, being read- PDA addresses exist "off-curve,"
enhances security by restricting only executable files, must store meaning they are not on the
who can modify an account's state using “Program Derived Ed25519 curve like normal
data. This concept is crucial for Addresses” (PDAs). PDAs are addresses. Only the program
enforcing rules and permissions special types of accounts that owns the PDA can
on the Solana blockchain. associated with and owned by a programmatically generate
program rather than a specific signatures for it, ensuring that
Every account has a program user. it’s the only one that can modify
"owner". The owner of an account the PDA's state.
is responsible for governing it, While normal Solana user
ensuring that only authorized addresses are derived from the
programs can make changes to public key of an Ed25519 key
the account's data. pair, PDAs do not have a private
key. Instead, their public key is
A notable exception to this rule is derived from a combination of
the transfer of lamports (the parameters—often keywords or
smallest unit of SOL)—increasing other account addresses—along
an account's lamports balance is with the program ID (address) of
universally permitted, regardless the owning program.

37
of ownership.
 Solana – Executive Overview

38
Above: Solana token accounts are specific examples of Program Derived Addresses (PDAs). They are used to
hold tokens and live “off-curve.” The Associated Token Account (ATA) program ensures that each wallet can
only have one associated token account for each token type, providing a standardized way to manage token
accounts.
VII
Solana – Executive Overview

“The most interesting part about Solana is

not parallelization, the SVM, or Toly's
tweets. It is something you probably
haven't heard of: Turbine.”

— Mert Mumtaz, Helius

Global State Machine Synchronized at the Speed of Light

Turbine
Gulf Block
Users
Stream Building

Block
Consensus Turbine
Verification

Key concepts: erasure coding, shreds, turbine tree

 Solana – Executive Overview

overhead and minimizing handle packet loss or shreds). Data recovery

the amount of data a malicious dropping of occurs per FEC batch,
leader needs to send. packets. meaning that up to half the
During the banking stage, packets in a batch can be
transactions are organized Turbine achieves this by Erasure coding, a lost or corrupted, and all
into entries and sent to the breaking down polynomial-based error the data can still be
Proof of History stream for transaction data into detection and correction recovered. Each 64 shred
timestamping. The block's "shreds'' through a scheme, ensures data batch is merkelized with
bank is updated, and the process called integrity. Even if some the root being signed by the
entries are now ready for "shredding." Shreds are shreds are lost, the block leader, and chained to the
the next phase—Turbine. small packets of data, can still be reconstructed. previous batch. This
similar to individual process ensures that
frames in a video stream. Shreds are grouped into shreds can be securely
Turbine is the process batches known as
through which the leader When reassembled, these obtained from any node in
shreds allow validators to forward error correction the network that possesses
propagates their block to (FEC) batches.
the rest of the network. replay the entire block. them, as the chain of
Inspired by BitTorrent, it is The shreds are sent over Merkle roots provides a
the internet between By default, these batches verifiable path of
designed to be fast and consist of 64 shreds (32
efficient, reducing validators using UDP and authenticity and integrity.

40
utilize erasure coding to data shreds + 32 recovery
communication
 Solana – Executive Overview

The leader initially For security reasons, the

broadcasts to a single root order of the tree is
node, which disseminates rotated for each new
the shreds to all other batch of shreds.
validator nodes. This root
node changes with each The primary goal of
shred. Validators are such a system is to
organized into layers, alleviate the outbound
forming the "Turbine Tree.“ data egress pressure on
the leader and root
Validators with a larger node. By utilizing a
stake amount are typically system of transmit and
positioned toward the top retransmit, the load is
of the tree, while those with distributed between the
lower stakes are placed leader and the
toward the bottom. retransmitters, reducing
the strain on any single
The tree (see next slide) node.
usually spans two or three
hops, depending on the

41
number of active validators.
 Solana – Executive Overview

Above: For visual simplicity, a fanout of 3 is depicted, but Solana’s actual fanout value is currently set to 200.
VIII
Solana – Executive Overview

“Some smart people tell me there is an earnest

smart developer community in Solana… I hope the
community gets its fair chance to thrive”

— Vitalik Buterin, Ethereum co-founder

Global State Machine Synchronized at the Speed of Light

Consensus
Gulf Block
Users
Stream Building

Block
Consensus Turbine
Verification

Key concepts: Tower BFT, forks, TVU

 Solana – Executive Overview

Once a validator receives a new in the sequence dictated by PoH, and for processing shreds and block
block from the leader via Turbine, it updating its local bank. This process validation. Like the TPU, the TVU flow
must validate all transactions within is handled by the Transaction is broken down into several stages,
each entry. This involves replaying Validation Unit (TVU), which is starting with the Shred Fetch Stage

44
the entire block, validating the PoH analogous to the leader’s where shreds are received over
hashes in parallel, recreating the Transaction Processing Unit (TPU), Turbine.
transactions serving as the core logic responsible
 Solana – Executive Overview

Original visual: Justin Starry, Anza In the subsequent Shred Verify Leader
Signature Stage, the shreds undergo
multiple sanity checks, most notably the
verification of the leader’s signature,
which ensures that the received shreds
originated from the leader.

The Retransmit stage, is where the

validator forwards the shreds to the
appropriate downstream validators.

In the Replay Stage, the validator

recreates each transaction exactly and in
the correct order while updating its local
version of the bank. The Replay Stage is
analogous to the banking stage in the
TPU; it is the most important stage and
can be more directly described as the
block validation stage. Replay is a single
threaded process loop that orchestrates
many key operations, including voting,
Above: the replay stage is responsible for switching the validator into resetting the PoH clock, and switching
leader mode and beginning block production. banks.
 Solana – Executive Overview

Tower BFT differentiates they believe are valid (i.e., This mechanism
itself from other chains by free of issues like double incentivizes validators to
leveraging the spends or incorrect vote on the fork they
To achieve consensus, synchronized clock signatures) and should be believe has the best chance
Solana uses Tower BFT provided by Proof of considered canonical. of being included, i.e., the
(TBFT), a custom History. While traditional Validators pay a “heaviest” fork.
implementation of the well- PBFT requires multiple transaction fee for these
known Practical Byzantine rounds of communication votes, which are Forks
Fault Tolerance (PBFT) to agree on the processed by the leader
transaction order, Solana and included in a block Part of Solana’s design,
algorithm, commonly used which makes it so fast, is
by most blockchains to nodes utilize the pre- along with regular user
established order of transactions. that the network doesn’t
agree on the state of the wait for all validators to
chain. Like all blockchains, events, significantly
reducing the messaging This is why Solana agree on a newly produced
Solana assumes the block before producing the
presence of malicious overhead. transactions are often
categorized into vote and next one. As a result, it's
nodes in the network, so not uncommon for two
the system must withstand To participate in non-vote transactions.
consensus and earn When validators submit a different blocks to be linked
not only node failures but to the same parent block,
also certain levels of rewards, validators correct and successful
submit votes for blocks vote, they earn a credit. creating forks.
attacks.
 Solana – Executive Overview

Solana validators must vote on

these forks and use a
consensus algorithm to
determine which one to adopt.
When competing forks exist,
only one fork will ultimately be
finalized by the network, while
blocks in discarded forks are
abandoned.

Each slot has a predetermined

leader, and only that leader's
block will be accepted for the
slot; there cannot be two
proposed blocks for a single
slot. Therefore the number of
potential forks is limited to a
"there/not-there" skip list of
forks that can emerge at the
boundaries of leader rotation
Above: once a block becomes rooted, account updates from earlier banks slots.
that are not ancestors of the finalized bank are pruned
 Solana – Executive Overview

Once a validator chooses a fork, it is reason for these skipped slots. bank is finalized, the account updates
committed to that fork until a lockout from that bank and its ancestors are
time expires, meaning they must stick Other possible reasons for skipped slots flushed to disk.
with their choice for a minimum period. include the start of a new epoch, a
leader being offline or the production of Additionally, any account updates from
The Solana "skip rate"—the percentage an invalid block. earlier banks that are not ancestors of
of slots in which a block was not the finalized bank are pruned. This
produced—varies typically from 2% to For every block, Solana uses a bank to process allows Solana to maintain
10%, with forks being the primary access the state at that block. When a multiple potential states efficiently.

The status of a transaction on Solana varies depending on its current stage in the consensus process:

- Processed: The transaction has been included in a block.

- Confirmed: The transaction’s block has been voted on by a two-thirds supermajority.
- Finalized: More than 31 blocks have been built on top of the transaction’s block.

To date, there has never been an instance in Solana's history where an (optimistically) confirmed block did not become
finalized.
IX
Solana – Executive Overview

“A blockchain requires a clever combination

of cryptography, distributed systems,
operating systems and programming
languages. Solana’s superpower was the
willingness to run away screaming from the
most interesting problems in each discipline.”

— Greg Fitzgerald, Solana co-founder

Global State Machine Synchronized at the Speed of Light

Gossip & Archive

Gulf Block
Users
Stream Building

Block
Consensus Turbine
Verification

Key concepts: CrdsTable, warehouse nodes

 Solana – Executive Overview

Without gossip, validators relying on any central of 1280 bytes, referred to as

and RPCs wouldn't know source. the "packet struct" in the
which addresses and ports codebase.
The gossip network can be are open for Gossip operates
thought of as the control communication across somewhat as an isolated
Gossip records are the
plane for the Solana various services. New system, independent from
actual data objects shared
network. Unlike the data nodes also rely on gossip most other validator
between nodes. There are
plane, which handles to join the network. components. Validators
approximately 10 different
transaction flows, the and RPCs share signed
types of records, each
control plane disseminates Solana's gossip protocol data objects every 0.1
serving different purposes.
crucial metadata about the uses informal, peer-to-peer seconds over UDP via
Gossip records are signed,
blockchain’s state, such as communication with a tree gossip, ensuring
versioned, and timestamped
contact information, ledger broadcast approach information availability
to ensure integrity and
height, and vote inspired by a modified across the network. All
currency.
information. PlumTree algorithm. This gossip messages must be
method efficiently less than or equal to the
propagates information maximum transmission
without unit (MTU)

50
 Solana – Executive Overview

There are four types of gossip Archive

messages:
Solana stands out from other
•Push: The most common messages, blockchains by not requiring
sharing information with a subset of the entire history to determine
"push peers.“ the current state of an account.
Solana's account model
•Pull & Pull Response: Periodically ensures that the state at any
checks for missed messages, with given slot is known, allowing
pull responses sending back the validators to store the current
information that nodes don't have. state of each account without
processing all historical blocks.
•Prune: Allows nodes to selectively RPCs and validators, by design,
reduce the number of connections do not retain the entire
they maintain. historical ledger. Instead, they
typically store only 1 or 2
Gossip data is stored in a Cluster •Ping & Pong: Health checks for epochs' (2-4 days) worth of
Replicated Data Store (CrdsTable). nodes—if a ping is sent, a pong is transaction data, which is
This data structure can grow very large expected back, indicating the peer sufficient to validate the tip of
and needs to be periodically pruned. node is still active. the chain.

51
 Solana – Executive Overview

Archives are currently managed by - Ledger Archive: Uploads raw ledger

"warehouse nodes," operated by and AccountsDB snapshots suitable
professional RPC service providers, the for replaying from scratch.
Solana Foundation, and other ecosystem
participants interested in ensuring - Google Bigtable Instance: Stores
transaction history is available. block data from the genesis block
onward, formatted to serve RPC
Warehouse nodes usually maintain one requests.
or both of the following:

52
X
Solana – Executive Overview

“People are realizing that Solana is the only

chain available today that will support
mainstream consumer apps.”

— Ted Livingston, founder Code

Global State Machine Synchronized at the Speed of Light

Gulf Block
Users
Stream

Economics & Jito

Building

Block
Consensus Turbine
Verification

Key concepts: staking, mem-pool, bundles, tips

 Solana – Executive Overview

Solana employs inflation to

distribute staking rewards
by generating new SOL
tokens each epoch. This
process causes non-
stakers' network share to
decrease relative to stakers,
leading to a wealth transfer
from non-stakers to
stakers. Inflation started in
early 2021 at an initial rate
of 8% which decreases by
15% annually until it
stabilizes at a long-term
rate of 1.5%. Any SOL token
holder can earn rewards
and help secure the
network by staking tokens Assigning tokens to a validator is give the validator ownership or control
to one or more validators. known as delegating. Delegating over the tokens. All staking, unstaking,

54
tokens to a validator indicates trust and delegation actions are executed at
in the validator. However, it does not the beginning of the next new epoch.
 Solana – Executive Overview

When a validator submits The top-performing credits) determines their Another factor is the
a vote they earn a credit validators successfully proportionate reward. This commission rate
if the vote is accurate vote on approximately 90% is further weighted by charged by validators,
and successful. Voting of slots. Note that the stake. which is a percentage of
transactions cost percentage of slots without the total inflation
0.000005 SOL and are blocks (skipped slot rate) Therefore, a validator with rewards directed to their
exempt from priority ranges from 2% to over 1% of the total stake validator. Additionally, a
fees. Voting expenses 10%, and these slots should earn roughly 1% of validator being offline or
amount to roughly 1 SOL cannot be voted on. The the total inflation if they out of sync with the
per day per validator, average validator votes have an average number of blockchain (known as
making it the main successfully on about 80% credits. If they have above delinquency)
operational cost of of slots, earning 345,600 or below the average significantly impacts
running a validator. credits in an epoch of number of credits, their returns.
Throughout an epoch, 432,000 slots. rewards will fluctuate
validators accumulate accordingly. Validators designated as
credits from voting, The total inflation pot is the leader for a specific
which they can exchange first divided based on Differences in voting block receive additional
for a share of the credits earned for the performance is one reason block rewards.
inflation at the end of the epoch. A validator's share why the returns (measured
epoch. of the total credits (their in APY) that validators offer

55
credits divided by the sum to stakers vary.
of all validators'
 Solana – Executive Overview

These rewards comprise Liquid staking These tokens can be traded back
50% of the base fees and and forth, or used across
50% of the priority fees of all Solana’s defi ecosystem, while
transactions within the Liquid staking has become a still earning staking rewards,
block, with the remaining popular alternative to native significantly enhancing capital
fees being burned. staking. Participants receive a efficiency.
token, known as a Liquid
Only the validator who Staking Token (LST) or Liquid With traditional native staking,
produced the block receives Staking Derivative (LSD), in over time, the staker will directly
these rewards. Unlike return for staking their SOL, accrue more SOL. Whereas with
staking rewards, which are usually in a stake pool that liquid staking, rewards are
distributed per epoch, block delegates their tokens across reinvested back into the pool
rewards are instantly multiple validators. increasing the fair value of the
credited to the validator’s LST. As long as there is a
identity account when the The newly received LST tokens mechanism to redeem LSTs for
block is produced. represent the user’s share of the underlying staked SOL,
the staked SOL. arbitrage traders will ensure that
the token price remains rational.

56
Price of LST = (total staked SOL in pool * price of SOL) / total LST minted
 Solana – Executive Overview

Jito

As of writing, over 80% of the

stake on Solana utilizes the
Jito client validator software.
This client, a fork of the
original Agave client,
introduces an out-of-protocol
blockspace auction that
provides validators with
additional economic incentives
through tips. This extra
incentive is a major factor in
the widespread adoption of the
Jito client among validators.

When leaders use the Jito

client validator, their
transactions are initially
directed to the Jito-Relayer.

57
 Solana – Executive Overview

This open-source software After 200 milliseconds, the relayer Tips operate entirely out-of-
functions as a transaction proxy optimistically releases the protocol, separate from in-
router. Other network nodes transactions regardless of the protocol priority and base fees.
remain unaware of the Jito- auction results. Previously, Jito operated a
Relayer's existence, as they canonical out-of-protocol mem-
simply send transactions to the Blockspace auctions occur off- pool service, which has now been
address and port configuration chain via the Jito Block Engine, deprecated.
the leader has advertised over allowing searchers and
the gossip network as their applications to submit groups of
ingress_socket, assuming it to be atomically executed transactions
the leader’s. known as bundles. These bundles
typically contain time-sensitive
The relayer holds all transactions transactions such as arbitrages or
for 200 milliseconds before liquidations. Jito charges a 5% fee
forwarding them to the leader. on all tips, with a minimum tip of
This "speed bump" mechanism 10,000 lamports.
delays incoming transaction
messages, providing a brief
window for conducting auctions.

58
 Solana – Executive Overview

Turbin3 is the Solana arm of the Web3 Builders Alliance, an education, research, and development organization serving
the Solana Ecosystem. The program is designed to enhance developer onboarding and retention within the Solana
ecosystem by providing comprehensive training, resources, and hands-on project experience. Turbin3 offers structured
courses, mentorship, and community support to help developers navigate the complexities of Solana development.

[Link]

Helius is the ultimate developer platform for building on Solana. Effortlessly navigate on-chain data with our powerful
APIs, webhooks, and RPCs. Enhance your apps with speedy Solana RPC nodes optimized for reliability and backed by
24/7 support. Stream Solana transactions and account changes with low latencies and robust fault tolerance—query all
tokens and NFTs through a single interface indexed for performance.

59
[Link]
Solana
How it works Users
Gulf
Stream
Block
Building

An executive overview of the Solana protocol Consensus

Block
Turbine
Verification