DOCSEARCHbyAlgolia
Submit Docs

Solana Blockchain Protocol

repository·master·Indexed 12 days ago

https://github.com/solana-labs/solana

A high-performance blockchain protocol including the core implementation of the validator, SDK, and networking and storage components. Documentation covers validator setup, the Geyser Plugin Interface for custom runtime logic, cluster metrics monitoring via Grafana and InfluxDB, and testnet deployment on GCP and AWS.

Tokens
167.5K
Snippets
446
Records
864
Agent score
94%

What's inside Solana

  1. Overview of Economic Design MVP features

    master

    The Economic Design MVP (Minimum Viable Product) outlines the foundational economic functionalities intended for early pre-testnet and testnet participants. These features serve as a baseline for developing a sustainable Solana economy and are subject to change based on stakeholder engagement during implementation phases (pre-testnet, testnet, and mainnet).

    The core MVP economic features include:

    • Faucet: A mechanism to deliver testnet SOL to validators to support staking and application development.
    • Inflation Rewards: A mechanism by which validators are rewarded through network inflation.
    • Token Delegation: The ability for users to delegate tokens to validator nodes.
    • Validator Commissions: A system allowing validator sets to collect commission fees from the interest generated by delegated tokens.

  2. Overview of the Solana CLI Tool Suite

    master

    The Solana Command Line Interface (CLI) is the primary tool for interacting with the Solana cluster. It is used for core tasks such as:

    • Wallet Management: Creating and managing Solana wallets.
    • Token Transfers: Sending and receiving SOL tokens.
    • Staking: Participating in the cluster by delegating stake.

    Note that the CLI is often the first place new functionality is deployed by the Solana core team, providing the most direct, flexible, and secure access to Solana accounts, even if it has a steeper learning curve than other interfaces.

  4. The SPV Program Service Model

    master

    SPV Programs function as decentralized marketplaces for proofs on Solana.

    Key Characteristics:

    • Multi-instance: There can be multiple SPV Program instances active, with at least one instance per connected external network (e.g., Bitcoin, Litecoin).
    • Extensibility: While the high-level API is consistent, the SPV Engine requires network-specific implementations. Developers can extend the ecosystem by implementing a specific engine and dropping it into a standard SPV program.
    • Flexible Filtering: Clients do not have to request a single specific transaction. They can submit requests with filters for parameters such as:
      • Inputs
      • Outputs
      • Amounts
      • Timeframes (e.g., "any transaction from Address A to Address B with amount X after time T")
    • Monitoring: Clients track the status of their requests by querying the account data of the Proof Request account created by the program.

  6. Use solana-watchtower to monitor cluster health

    master

    The solana-watchtower program monitors the health of a Solana cluster by periodically polling the RPC API. It verifies three key health indicators:

    1. Transaction Count: Confirms that the transaction count is advancing.
    2. Blockhashes: Ensures new blockhashes are available.
    3. Validator Status: Checks that no validators are in a delinquent state.

    Results are reported as InfluxDB metrics. The program can also send optional push notifications when a sanity check fails.

    Configuration Options

    • Target a specific validator: Use --validator-identity to restrict failure notifications to issues that specifically affect a single validator identity.
    • Suppress duplicate alerts: Use --no-duplicate-notifications to prevent sending identical failure notifications (useful for SMS or other high-frequency notification channels).

  7. What is Proof of History (PoH)?

    master

    Proof of History (PoH) is a core innovation in Solana designed to accelerate transaction finalization.

    Key distinction: PoH is not a consensus architecture (like Proof of Stake). Instead, it is a feature that works alongside the Proof of Stake system. It provides a cryptographically repeatable clock that allows validators in the cluster to agree on time, which significantly speeds up the process of block finalization.

  8. What is the Transaction Validation Unit (TVU)?

    master

    The Transaction Validation Unit (TVU) is the core logic component of a Solana validator. It is responsible for two primary functions:

    1. Validating and propagating blocks: Ensuring the integrity of incoming blocks and spreading them across the network.
    2. Processing transactions: Passing the transactions contained within those blocks through the Solana runtime for execution.

    Understanding the TVU is essential for developers working on validator performance, network propagation, or transaction lifecycle management.

  9. What is a Receipt in Solana SPV?

    master

    A Receipt is a minimal cryptographic proof that satisfies three conditions:

    1. A specific transaction has been included in a block.
    2. The block has been voted on by the client's preferred set of validators.
    3. The votes have reached the required confirmation depth.

    A receipt consists of a Transaction Inclusion Proof and an Optimistic Confirmation Proof linked via a chain of PoH (Proof of History) entries.

  10. What is the Epoch Accounts Hash (EAH)?

    master

    The Epoch Accounts Hash (EAH) is a full accounts hash calculation performed once per epoch. The result is hashed into a bank's hash to ensure all validators have a consistent view of all accounts. This mechanism helps identify validators with missing, corrupt, or extra accounts within 1-2 epochs by checking every account at least once per epoch.

    Key Timing and Slots

    To ensure all validators calculate the same hash, the process uses a predetermined start slot and stop slot based on offsets within the epoch:

    • start slot: The first root $\ge$ first slot in epoch + start offset. The start offset is typically set at one-quarter into the epoch (e.g., 108,000 for a 432,000 slot epoch).
    • stop slot: The slot where the EAH is saved into a bank. The stop offset is typically set at three-quarters into the epoch (e.g., 324,000 for a 432,000 slot epoch).

    Implementation Details

    • Background Processing: Because the calculation is time-intensive, it runs in the background using Accounts Background Services (ABS). EAH requests have the highest priority in ABS.
    • Storage: The EAH is stored in a new field in AccountsDb. The bank at the stop slot (or more precisely, banks where bank slot >= stop slot and parent slot < stop slot) reads the EAH from AccountsDb and incorporates it into its own bank hash.
    • Trigger: An EAH calculation is requested via bank_forks::set_root() when root bank slot >= start slot and root parent slot < start slot.

  11. Understand Solana's economic sustainability mechanisms

    master

    Solana's long-term economic sustainability is designed around two primary mechanisms that manage the supply and distribution of tokens:

    1. Token Issuance (Inflation): This provides validator rewards, which are the dominant remittances from the Solana mining pool.
    2. Token Burning (Disinflation): To counter inflation, the protocol implements a disinflationary mechanism. This is a flat, protocol-specified percentage of each transaction fee that is burned, reducing the overall supply.

  12. Optimize Solana BlockStore with FIFO Compaction

    master

    Solana's BlockStore uses RocksDB for storage. For shred data (which accounts for ~99% of storage size), the proposed design replaces standard Level Compaction with FIFO (First-In-First-Out) Compaction.

    Why use FIFO Compaction for Shred Data?

    Shred data write-keys are mostly monotonically increasing. This allows SST files to be naturally sorted from old to new, making FIFO compaction highly efficient for this specific workload:

    • Write Amplification: 1 (Data is written once without background compaction cycles).
    • Read Amplification: < 1.1 (Each read hits mostly one file due to natural sorting).
    • Space Amplification: 1 (No duplicate data or temporary compaction space required).
    • No Write Stalls: Unlike Level Compaction, which stalls writes when background compaction cannot keep up with the write rate, FIFO simply deletes the oldest files when a size threshold is reached.
    • Timely Deletions: Deletions occur immediately when the column family reaches the configured size trigger, preventing disk bloat.

    Column Family Strategy

    • ShredData and ShredCode: Use FIFO Compaction.
    • Metadata (e.g., Index): Continue using Level Compaction with compaction filters, as these contribute only ~1% of the data size.