banksyweb3
Posts
Solana Technology Overview [3,513 words]

Solana Technology Overview [3,513 words]

You might not be able to learn everything about Solana from Mert’s twitter, but you can from Helius’ blogs.

December 12, 2024

Intro

This blog will provide an introduction to Solana’s technology and an overview of recent implementations, from the lens of most of Helius’ blogs. This was done to see how much technical detail you need to know for a BD role on Solana?

Founding team

Solana was founded in 2018 by Anatoly Yakovenko, with co-founders Raj Gokal, Greg Fitzegerald and Stephen Akridge [15]. Solana’s genesis block was on the 16th of March 2020 [5].

Solana Technology

Solana is a decentralised Layer 1 blockchain, with a focus on speed and user experience [1]. Solana’s blockchain is monolithic and integrated, so apps build and interact directly on Solana. This is in contrast to other blockchains, which may form a layered (i.e. Ethereum) or modular approach (i.e Cosmos). Solana is a network of thousands of nodes that work together to keep the single ledger updated. A client refers to the open source software, ran by nodes on high-performing machines.

Transactions per second (TPS) – currently averages 400 user generated TPS and 4,000 raw TPS (including validators votes) [3].
Block time (slots) – 400 milliseconds. Epoch - ~2 days (around 432,000 slots per epoch).
Fees – non-voting transaction fees can be less than $0.001 USD (0.000005 SOL).

The Solana Virtual Machine (SVM) is where smart contracts are executed. This is not to be misinterpreted for the Sealevel Virtual Machine (also SVM). Solana’s runtime environment is called Sealevel, which processes transaction in parallel for simultaneous processing.

In Solana, there are program accounts (only storing code/logic) and data accounts (only storing data/state). By having separate accounts for data, low latency and throughput are achieved. When running a Solana program, the state of the data accounts are modified, but the program account is unchanged. This differs from other blockchains, such as Ethereum, where smart contracts combine both logic/code and data/state, requiring more computation power and resulting in longer latency.

Software not getting in the way of hardware, is a core principle of Solana. But, what does it mean? It allows Solana to receive performance benefits, in line with developments in hardware (e.g. GPUs), even if the Solana protocol remains unchanged. When Solana does make changes, they use Solana Improvement Documents (SIMDs), which the network then votes on.

Proof of History

Proof of History (PoH) provides an order of network events, as a timestamp. The next PoH hash is the current PoH hash combined with a hash of all new transaction entries. This means only one round of voting for block commitment is needed by validators, which saves time by avoiding node-to-node communication. A chain of hashes is created as the previous hash’s output forms the input the next hash [1]. Therefore, the future hashes are unknown as hashing is done in sequence. This is the same as a verifiable delay function (VDF) and validators cannot produce blocks before their turn. Leader rotation uses PoH and VDF to slightly reduce validator centralisation.

SHA256 is Solana’s hashing algorithm. It is deterministic, fixed size, fast, pre-image resistant, has the Avalanche Effect and is Collision Resistant. A blockhash is the latest PoH hash for a slot, a transactions recent blockhash is a timestamp. This prevents duplicates and ensure transactions are executed within a timeline of 150 blocks/~79 seconds (the maximum blockhash).

Solana uses Tower BFT (TBFT), a customised use of the Practical Byzantine Fault Tolerance (PBFT) algorithm, which uses the PoH clock. Note, PoH is not a consensus algorithm like Proof of Stake (PoS).

Proof of Stake

Solana uses a Proof of Stake (PoS) consensus mechanism, with network validators having the responsibility to create new blocks and confirm transactions [8]. Validators are rewarded with SOL tokens and malicious actors have their stake slashed.

Solana Tokenomics

Token - $SOL. Initial supply - 500 million SOL. Total circulating supply - 587 million SOL [17]. Maximum supply - Infinite.

Solana’s inflation schedule started at 8% (16/03/2022) and has reduced by 15% every 180 epochs (~1 year) [5]. Estimations for inflation as of June 2024 was at 5.23%, with the 1.5% inflation target being achieved around 2035. The reducing inflation and fee burns will have a net deflationary impact on SOL’s total supply.

Solana’s token standard is the Solana Program Library (SPL). Solana tokens have value on the Solana Mainnet-Beta, with the other clusters being Localnet, Testnet and Devnet.

Token Extensions

The next generation of the SPL is in the form of the Token-2022 program, enabling Token Extensions which allow new use cases for token customisation, in addition to, the current burn/mint/freeze capabilities [6,7]. Key applications are: Confidential Transfers which enable privacy of the balance and transfer amount. Metadata Extensions which help with payment reconciliation, for invoicing and tax payments, whilst still being privacy preserving. Transfer Fees are used for automated fee collection on token transfers. Interest-Bearing Tokens enable interest to be paid on onchain bonds or staking. Non-transferable tokens can be used for loyalty programs. Transfer hooks allow onchain royalties for NFTs and KYC/ALM checks. Token-gated transfers can be used for airdrops based on KYC laws. Permanent Delegation enables addresses to have control over tokens or Real World Assets (RWAs). All features are live apart from Confidential Transfers, which is expected by the end of 2024, after the adoption of Agave 2.0.

Solana Transactions

When a user initiates a transaction, it is sent to the leader (the current block producer). The leader compiles the transactions into a block, then executes them, which updates their state. The block is then sent to the network, so other validators can also execute and confirm. For a more detailed overview, please view figure 1 below. After a transaction is signed it is sent to the current and next two leaders.

Solana Transaction Overview [1]

Sending a transaction is the only way to mutate state on Solana. Any write operation is performed through a transaction. Solana’s public-key cryptography uses Ed25519, “an elliptic curve digital signature algorithm” [1]. Ed25519 compliments Solana’s focus on fast speed, by having a “small key size, small signature size, fast computation and immunity to many common attacks”.

Transactions on Solana are known as a transaction message. They have “four sections: a header, a list of account addresses, a recent blockhash and instructions”. All transactions are atomic, meaning that everything the transaction attempts happens or it fails. Failed transactions still incur fees. More than 80% of failed transactions fail due to slippage (error code 0x1771). Most (95%) are caused by bots taking advantage of arbitrage, with only 0.1% of active addresses responsible for the failed transactions. Some transactions fail due to exceeding the compute units (CUs). Solana uses a recent blockhash, which expires after 150 blocks (~1 minute) to prevent duplicate and/or stale transactions. RPCs will stop forwarding transactions after the recent blockhash expires (if not finalised).

Transaction cost = base fee + prioritisation fee.

One SOL is divisible by 100 billion Lamports ($0.00000015 at $150/SOL), named after Leslie Lamport. The base fee is 5000 lamports ($0.00075 at $150/SOL). Priority fees are used to increase the likelihood of a validator including them in the block, they are priced in micro-lamports (million of a lamport). Although optional, they are sometimes necessary. RPC nodes improve the UX by giving priority fee etsimations, using the getRecentPrioritizationFees function or Helius’ improved Priority Fee API. Wallet providers such as Phantom and Solflare handle priority fees, by analysing network congestion and adjusting priorities fees accordingly [2]. Blockspace can be priced using local fee markets which enable fees to adjust to demand specific to that state. This is compared to traditional gas-based blockchains such as Ethereum.

The use of Remote Produce Call (RPC) Nodes is another differentiator of Solana, with over 4,000 RPC nodes on the network. Normally, a blockchain’s validator and RPC node is the same (i.e. Ethereum). RPCs act inbetween the apps and block validator. Applications use JSON-RPC or WebSocket endpoints, to simulate or submit signed transactions and retrieve onchain data. Despite running the same software as normal (full) validators, they have different settings, enabling them to focus on RPC calls, rather than staking (voting or block building). RPC providers, such as Helius operate as a paid B2B service. RPC providers forward a transaction message to the block leader, shown below.

Helius’ RPC node transaction visual [1].

Transaction drop off can be caused when transactions use the ‘recentBlockhash’ function and timing is different to the more recent blockhash, resulting in the transaction not being included. This is mitigated by preflight checks using the sendTransaction function. Similar issues occur when a validator is slow to process blocks and a temporary network fork occurs. The client references a recentBlockhash on the minority fork, which is then not included.

Solana has no mempool. Mempools (i.e. Ethereum’s) normally use gossip networks to randomly broadcast transactions to a global transaction queue, which is a decentralised pool of validators. Solana instead uses Gulf Stream to forward transactions to that slot’s leader (lead validator). Some validators use the Jito validator client to order transactions using a “pseudo-mempool” [2].

Visual of Solana’s Gulf Stream + Leader Schedule [1].

Validators & Staking

Solana’s inflation is used to give new SOL to validators who have staked SOL, as a reward for securing the network. The new (inflationary) SOL is distributed to validators after every epoch, based on the number of vote credits and adjusted for proportional stake. Validator vote costs are ~1 SOL a day [1]. An accepted block (canonical block) must receive votes from 66% of the stake.

Until SIMD-0096 (June 2024), the lead validator received 50% of the base fee and 50% of the priority fees of all block transactions, the rest were burned [13]. After the passing of SIMD-0096 and implementation of Agave 2.0, the lead validator will receive 100% of priority fees. Users can delegate tokens to validators they trust and receive interest on their SOL. Liquid Staking Tokens (LSTs) and Liquid Staking Derivatives (LSDs) are not novel to Solana. But, still enables users to stake their SOL by buying a token which represents (multiple) validator pools. The tokens can also be used and traded, rather than being ‘locked’. As of October 2024 there was 397 million SOL ($66.79bn) staked with validators [12]. The cost of running a validator are; hardware (~$470/month for Latitude’s c3 large), operational expenditure (space, internet, staff), voting costs (~1 SOL/day) and the opportunity cost of capital invested [14]. The Solana Foundation Delegation Program (SFDP) helps to lower the barrier to entry for new validators, by covering voting costs and matching stakes (up to 100,000 SOL). This improves decentralisation and resilience.

A leader schedule is generated every epoch (~2 days), with a leader for each slot (400 milliseconds). A leader is assigned for four consecutive slots (1.6 seconds). The leader schedule uses a random number generator, in addition to PoH and VDF to avoid validator centralisation. All transaction in a block need to be valid and reproducible. Solana uses continuous block building, to construct them during each slot (dynamically). This is done to reduce latency and instead of discrete block building (i.e. Ethereum), where blocks are constructed before broadcasting them. Blocks are built in the banking stage.

The banking stage is when blocks are built. The transactions which flow into entries, are then sent to the PoH stream and timestamped. After block finalisation, validators flush account updates from memory (the bank) to the disk, becoming permanent. Once the blocks bank is updated, Turbine can start. Turbine is where the leader broadcasts their block to the rest of the network. “Shredding” of transaction data into “shreds” (<1280 bytes), sends validators a replay of the block using User Datagram Protocol (UDP) and “erasure coding to handle packet loss or malicious dropping of packets” [1]. Erasure coding allows for block reconstruction even after losing shreds. The leader broadcasts to a single root node, which sends the shreds to validators, predominantly those sat at the top of the “Turbine Tree”, where heavier staked validators sit. This raises centralisation concerns.

Regular timeslots permit a routine of activity, with each new epoch allowing new staking and unstaking. At the end, validator rewards are paid. Also, Solana RPCs and validators only store 1 or 2 epochs (2-4 days) of transaction history. Archives store the transaction history and are managed by warehouse nodes.

Earlier in 2024 Solana introduced Stake-Weighted Quality of Service (SWQoS), to reduce spam and improve Sybil resistance (against non-staked nodes). This form of motorway ‘toll’ enables leaders “to prioritise transaction messages that are proxied through other staked validators” [1]. Validators with a higher stake, have extra capacity to send transactions messages to the leader. This is why Helius can provide best in class RPC services, due to having the most SOL staked, with 3.26% of SOL [17]. Validators can rent out their stake-weighted capacity, giving increase bandwidth to RPC node providers, for extra transaction inclusion. Leader’s reserve 80% of capacity for SWQoS, with 20% from non-staked nodes. Also, validators with a higher stake have a higher chance of becoming a leader. As with Turbine, SWQoS raises centralisation concerns too.

Amount of Solana staked by validators as of October 2024 [17].

Maximal Extracted Value

Validators earn income from new token inflation, block rewards and Maximal Extractable Value (MEV). MEV “refers to any value derived from adding, removing, or reordering the transactions within a given block” [15]. Opportunities arise with NFT mints, loan liquidations, and exchange token pricing arbitrage. Solana’s low fees and latency enable arbitrage, but this wastes 58% of all compute and results in 98% of arbitrage failing.

Jito

The Jito Validator Client was created in August 2022, as a fork of the original Solana Labs (Agave) client, enabling validators to receive tips for ordering transactions [1,10]. Around 65% of validators run the Jito-Solana client [15]. It is optimised for MEV. Jito tips are received for guaranteeing transaction bundles, which are done in sequence and atomically. Although bundles are still live, the pseduo-mempool has now been deprecated. When Jito’s mempool was live, transactions were auctioned when the Jito-Relayer held transactions for 200 milliseconds, before sending them to the leader.

Firedancer

One of Solana’s main weaknesses in terms of centralisation has been that they only had one validator client. The Agave client is the original Solana Labs client, written in the programming language, Rust. So, if there was a bug, then there would be an issue with the whole blockchain. The Firedancer Client is a new validator client, built by the team at Jump (trading firm), which is written in the programming language C and requires lower hardware requirements, improving decentralisation and resilience. The Firedancer client is capable of processing 1.2million raw TPS and 600k after deduplication in testing.

“In an ideal future, Solana would have at least four independent validator clients. Different teams would build these clients in different programming languages. No single implementation would have more than 33% of the stake, as each client would hold ~25%. This idealized setup would lack a single point of failure in the entire validator stack.“ [10]

1.18 upgrade

The 1.18 upgrade introduces a new scheduler to “streamline transaction handling and ensure more accurate and efficient priority calculations” [1]. Scheduler Jitter was caused by “priority fees only work on intra-thread (within its own lane), not inter-thread (between lanes)” [1]. The 1.18 update eliminates jitter by processing transactions in a consistent priority order. Simple transfers without priority fees are also prioritised due to the low compute units (CUs). QUIC now sees those with a very low stake as unstaked in the SWQoS service.

Solana Accounts

The two types of Solana accounts are mint accounts (contains information about a token) and token accounts. Each Solana token and NFT is held in its own account, which requires rent. The more accounts you have, the more rent you need to pay. Solana account holders can close accounts, to have rent returned on SOL incinerator [18]. This helps incentivise users to reduce state bloat. Rent is effectively a storage cost which is incurred when opening the account with a minimum amount of SOL (“rent-exempt” amount is 0.002 SOL).

State Compression

Solana’s state is a snapshot of its everchanging ledger. On Solana, compute is cheap but storage is expensive. State compression reduces onchain storage by storing hashes of data sets onchain, using Concurrent Merkle Trees [3]. The Solana onchain account stores the digital fingerprint of the accounts data that is in the Solana ledger. However, as Solana scales, the number of accounts, size of the snapshots and indexes grows too.

Compression - Only the state roots (small fingerprints of all compressed accounts) are stored in onchain accounts. The underlying data is stored on the cheaper Solana ledger. Decompression prevents lock in and enables interoperability between normal and compressed accounts. Decompression can be used in web3 gaming to all rapid state changes after decompressing cards and items. State growth is addressed by "moving cold state into compressed storage".

Blinks

Compressed NFTs

A Compressed Non Fungible Token (cNFT) allows (millions of) NFTs metadata to be stored on the Solana Ledger, using a Merkle tree, storing only the root of the tree in the Solana accounts [18]. cNFTs can be de-compressed but ‘normal’ NFTs cannot become compressed. Minting 1 billion NFTs on Polygon would cost $50 million, but only $11,000 on Solana using cNFTs [19].

Zero Knowledge Compression

To understand the importance of Zero Knowledge (ZK) compression on Solana, the Solana transaction cycle is shown below. Onchain storage costs can be saved from the 3rd part, by including account data as part of the payload. However, this creates trust assumptions and the token amounts can be lied about, as the full nodes do not have the offchain data. Merkle proofs solve this issue, by using a small amount of onchain storage to commit to data and provide a verifiable cryptographic proof that all nodes store. Despite being worked on, Solana transactions cannot exceed 1232 bytes and a proof for ten accounts with a merkle tree containing 100,000 accounts would use up 4.5x this (5440 bytes). ZK Compression solves this issue with a 256 byte proof that only takes up 128 bytes of storage, due to Solana’s accounts being on an eliptic curve points. Proof verification is done onchain, using “Groth16 and it, in turn, relies on the alt_bn128 syscall, which is currently feature-gated in mainnet and is under testing” [9]. ZK compression uses zk-SNARKs (Succinct Non-Interactive Argument of Knowledge).

Solana transaction cycle [9].

Without ZK compression Solana’s onchain state (storage) is expensive, with 100 accounts costing 0.2 SOL [20]. With ZK compression that costs 0.00004 SOL (5000x saving).

Note, ZK compressions is different to ZK rollups. On Ethereum, the ZK rollup state is “a single root in the base layer (Ethereum)”, but “100 transactions are verified… and one single proof is generated” [9]. The state root then changes to the new state. Whereas, with ZK compression on Solana, “each of the 100 transactions contain one proof that simply tells you that the account data is correct, but the state transitions (generated by transactions) are actually executed on-chain as part of the SVM itself” [9]. For ZK rollups “the trust assumptions are for the complete state transition function (from the view of the base layer”, whereas ZK compression is only asking “is the account data correct?” [9].

Blinks

Blinks are blockchain links which enable users to pay and vote on twitter, using their crypto wallet.

Solana downtime

Since the the introduction of QUIC [9], there has been no downtime related to spam, like that seen on: ”The Grape IDO Spam on Sept 14 2021 DDoS Attacks that occurred from Jan 6-12 and the 2022 NFT Mint Spam that occurred from Apr 30 - May 1 2022” [9].

Solana was down in February 2023 for 18 hours due to “Several services on the network running custom block-forwarding software inadvertently transmitted a huge amount of data, several order of magnitude larger than a normal block” [21].

Solana was down in February 2024 for 5 hours due to “a bug associated with how the network compuled and cached a program’s code for execution, specifically affecting older version of program loaders.” [10].

Solana industries

Enterprise adoption is one part of achieving mass adoption and Solana allows enterprises to “run their own instance of Solana in a dedicated environment… tailored to their specific needs” [3]. This enables permissioned blockchains, with specific privacy and verifiability options. This has been demonstrated by Paypal and their $PYUSD on Solana.

Solana Climate

The energy use of a non-vote transaction on Solana is similar to a few Google searches [4].

Solana Energy Use Chart [4]

Solana’s ESG ranking compared to peers is shown below.

Solana ESG [25]

Solana Decentralisation

Sometime to compete with data centres (NASDAC etc.), you need to have data centres. This Helius blog covers Solana decentralisation in more detail, but some graphics are shown below.

Solana validators grouped by stake.

Solana validators grouped by stake [25]

Nakamoto Coefficient

Nakamoto Coefficient [25]

Geographical Stake Distribution

Geographical Stake Distribution [25]

Validator Hosting Providers

Validator Hosting Providers [25]

Solana Technology Overview [3,513 words]

You might not be able to learn everything about Solana from Mert’s twitter, but you can from Helius’ blogs.

Intro

Founding team

Solana Technology

Proof of History

Proof of Stake

Solana Tokenomics

Token Extensions

Solana Transactions

Validators & Staking

Maximal Extracted Value

Jito

Firedancer

1.18 upgrade

Solana Accounts

State Compression

Blinks

Compressed NFTs

Zero Knowledge Compression

Blinks

Solana downtime

Solana industries

Solana Climate

Solana Decentralisation

References