Solana Ledger

Solana eliminates the traditional mempool. Transactions are forwarded to validators known to be leaders in upcoming slots. This allows validators to execute transactions ahead of time and reduces confirmation times and memory pressure. The network's predictable leader schedule, enabled by PoH, makes this forward-aware transaction routing possible.

A CPU optimization technique where the transaction processing pipeline is broken into four sequential stages: 1) Fetching signatures, 2) Banking (signature verification & accounting), 3) Execution (smart contract runtime), and 4) Write (committing to ledger). Each stage handles a different batch of transactions simultaneously, similar to an assembly line, maximizing hardware efficiency.

Solana separates consensus from data storage. Validators only store recent ledger data. Historical data is erasure-coded, split into pieces, and stored by a decentralized network of nodes called Archivers. This design keeps validator hardware requirements manageable while ensuring the full ledger history remains available and verifiable.

The signature is the primary identifier for any transaction on Solana. It is a cryptographic proof of authorization, generated by signing the transaction details with the sender's private key. Every transaction must include at least one valid signature to be executed and recorded on the ledger.

The ledger stores the complete state of every account, including its lamport balance (1 lamport = 0.000000001 SOL) and associated data. This includes:

• Native SOL balances for wallets and programs.
• Data fields for SPL Token accounts (mint, owner, amount).
• Executable flag and owner for smart contract programs.

Each transaction contains a list of instructions to be processed by on-chain programs (smart contracts). The ledger records:

• The program ID being invoked.
• The serialized instruction data passed to the program.
• The accounts required for the instruction, with their read/write permissions.
• Execution results and any program-generated log messages.

Each block header contains metadata crucial for network consensus and validation, including:

• Blockhash: The unique hash of the block's contents.
• Previous Blockhash: Links to the prior block, forming the chain.
• Leader Identity: The validator (identified by its vote account) that produced the block.
• Rewards: The distribution of staking rewards and transaction fees to validators and the protocol treasury.

Validators submit vote transactions to participate in Solana's Proof-of-History consensus. These ledger entries are critical for confirming the validity of the blockchain's history and include:

• The validator's vote on a specific blockhash.
• A cryptographic proof linking the vote to the leader's PoH sequence.
• A slashing proof if the validator votes maliciously.

The ledger maintains special Sysvar accounts that provide global, on-chain context to programs. Key examples recorded in the state include:

• Clock Sysvar: The network's timestamp, epoch, and slot number.
• Rewards Sysvar: Calculated validator rewards for the epoch.
• Stake History: A record of stake activations and deactivations.
• Rent Sysvar: The current rent-exemption thresholds.

End-users interact with the ledger indirectly through wallet interfaces (e.g., Phantom, Solflare). Wallets rely on the ledger to:

• Derive accurate account balances and token holdings (SPL tokens).
• Broadcast signed transactions and confirm their inclusion.
• Display a verifiable history of all user interactions with on-chain programs.

Security experts perform smart contract audits and on-chain forensic analysis. They rely on the immutable ledger to:

• Trace the flow of funds before and after an exploit or hack.
• Verify the bytecode and upgrade history of deployed programs.
• Reconstruct transaction sequences to identify vulnerabilities or malicious patterns.

Centralized exchanges (CEXs) and institutional custodians rely on the ledger for accurate deposit and withdrawal processing. They operate off-chain accounting systems that must be precisely synchronized with the canonical on-chain state to ensure:

• Correct crediting of user deposits.
• Validated proof of withdrawal completions.
• Real-time settlement finality for asset transfers.

A parallel smart contract execution engine that allows transactions to run concurrently across multiple cores. It can process non-overlapping transactions (those affecting different state accounts) simultaneously. This is a key architectural difference from single-threaded blockchains, enabling horizontal scaling of validator hardware.

A mempool-less transaction forwarding protocol. Instead of holding unconfirmed transactions in a public pool, validators push transactions forward to the expected leader of future blocks. This reduces confirmation times, minimizes memory pressure on validators, and allows clients to know their transaction's confirmation slot well in advance.

A block propagation protocol inspired by BitTorrent that breaks data into small packets and disperses them through the network via a tree-like structure. This solves the data scaling problem in blockchains, allowing the ledger's state to be transmitted quickly even as block sizes grow, ensuring low latency across a global validator set.

In Solana, all data is stored in accounts, which are addressable slices of the ledger's state. There are two primary types:

• Executable Accounts: Hold program (smart contract) code.
• Data Accounts: Hold state or data associated with a program or user. Every account stores a lamport balance (fractional SOL) and is owned by a specific program that governs its modification.

Solana uses a rotating leader model based on Proof of Stake voting weight. The network operates in fixed-duration epochs (approximately 2-3 days). At the start of each epoch, a deterministic schedule is produced, assigning specific time slots to validators to act as the leader responsible for producing blocks. This predictable schedule is crucial for Gulf Stream and overall network coordination.