### Solana Network Interaction and Concepts

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter3/index.md

This documentation outlines key concepts for interacting with the Solana blockchain, including transactions, accounts, and runtime policies. It guides users through understanding transaction lifecycles, anatomy, account structures, security rules, program derived addresses, and inter-program communication.

```APIDOC
Interacting with the Network:
  Description: Learn how to interact with Solana's blockchain using different tools.
  Link: ./interacting-with-the-network.md

Transaction Lifecycle:
  Description: Explore the journey of a transaction on Solana.
  Link: ./transaction-lifecycle.md

Transaction Anatomy:
  Description: Understand what makes up a transaction on Solana.
  Link: ./transaction-anatomy.md

Account Anatomy:
  Description: Learn the structure of accounts as well as their purpose.
  Link: ./account-anatomy.md

Runtime Policy:
  Description: Learn the rules enforced by Solana’s runtime to ensure system security.
  Link: ./runtime-policy.md

Program Derived Address:
  Description: Understand program derived addresses and how they differ from regular pubkeys.
  Link: ./program-derived-address.md

Cross Program Invocation:
  Description: Explore how programs on Solana interact with each other.
  Link: ./cross-program-invocation.md
```

--------------------------------

### Merkle Tree Structure and Terminology

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter4/account-compression-program.md

Explains the fundamental structure of a Merkle tree, including leaf nodes, non-leaf nodes, and the root node. It also defines key tree terminology like root node, non-leaf node, and leaf node with a visual example.

```APIDOC
Merkle Tree:
  Structure:
    - Leaf nodes: Represent a hash of some data.
    - Non-leaf nodes: Represent a hash of their child nodes.
    - Root node: A compact representation of all data stored in the tree.

  Terminology:
    - Root node: The top-most node, with no parent.
    - Non-leaf node: A node with children.
    - Leaf node: A node with no children.

  Example Tree Graph:
             A (root)
            / \
           B   C
          / \
         D   E

  (A is the root of the tree)
  (B is a parent of nodes D and E)
  (D is a child of node B)
```

--------------------------------

### Solana Program Library Navigation

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/index.md

Provides a link to the Solana Program Library chapter, which contains a collection of programs for tasks like token creation and management.

```Markdown
-   :material-library:{ .lg .middle } __Solana Program Library__

    ---

    Collection of programs that simplify tasks like token creation, management, and more.

    [__Solana Program Library__](./chapter4/index.md)
```

--------------------------------

### Solana Programming Model Navigation

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/index.md

Provides a link to the Programming Model chapter, enabling exploration of Solana's programming paradigms.

```Markdown
-   :material-code-brackets:{ .lg .middle } __Programming Model__

    ---

    Explore Solana's programming model.

    [__Programming Model__](./chapter3/index.md)
```

--------------------------------

### Solana Basics Navigation

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/index.md

Provides a link to the Solana Basics chapter, covering the fundamental aspects of the Solana blockchain.

```Markdown
-   :material-book-open-page-variant:{ .lg .middle } __Solana Basics__

    ---

    Learn the basics of Solana blockchain.

    [__Solana Basics__](./chapter1/index.md)
```

--------------------------------

### Solana CLI Keypair Generation

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter3/interacting-with-the-network.md

Shows how to generate a new Solana keypair using the Solana Command-Line Interface.

```bash
solana-keygen new
```

--------------------------------

### Solana Core Concepts Overview

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter2/index.md

This section provides a high-level overview of Solana's core concepts, each with a brief description and a link to a more detailed explanation. These concepts are crucial for understanding Solana's performance and scalability.

```APIDOC
Proof of History:
A cryptographic clock that timestamps transactions.
[__Proof of History__](./proof-of-history.md)

Tower BFT:
A consensus mechanism that ensures finality using PoH as a clock reference.
[__Tower BFT__](./tower-bft.md)

Turbine:
A block propagation protocol that breaks data into smaller packets for faster transmission.
[__Turbine__](./turbine.md)

Gulf Stream:
A mempool system that pushes transactions to validators before confirmation.
[__Gulf Stream__](./gulf-stream.md)

Sealevel:
Solana’s parallel smart contract runtime for simultaneous transaction execution.
[__Sealevel__](./sealevel.md)

Pipelining:
A technique that optimizes transaction processing.
[__Pipelining__](./pipelining.md)

Cloudbreak:
Solana's custom database that enables fast reads and writes.
[__Cloudbreak__](./cloudbreak.md)

Archivers:
Distributed storage systems that hold and serve off-chain data for Solana’s ledger.
[__Archivers__](./archivers.md)
```

--------------------------------

### Solana Core Concepts Navigation

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/index.md

Provides a link to the Core Concepts chapter, detailing the eight unique concepts that define Solana's speed and functionality.

```Markdown
-   :material-cogs:{ .lg .middle } __Core Concepts__

    ---

    Solana can be described by the eight core concepts that make it unique and fast.

    [__Core Concepts__](./chapter2/index.md)
```

--------------------------------

### Solana CLI Airdrop SOL

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter3/interacting-with-the-network.md

Illustrates how to request SOL tokens to an account address via airdrop on Devnet and Testnet using the Solana CLI.

```bash
solana airdrop 1 <account-address>
```

--------------------------------

### Solana CLI Public Key Retrieval

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter3/interacting-with-the-network.md

Demonstrates how to view the public key associated with your Solana keypair using the Solana CLI.

```bash
solana-keygen pubkey
```

--------------------------------

### Solana SPL Token Program Instructions

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter4/token-program.md

The Solana Program Library (SPL) Token program provides common implementations for fungible and non-fungible tokens. This documentation outlines key instructions for token management.

```APIDOC
MintTo Instruction:
  - Used by the mint_authority to create new tokens.
  - Requires a valid mint_authority on the mint account.

Transfer Instruction:
  - Transfers token balances between accounts.
  - Requires the source account owner as a signer if accounts differ.

Burn Instruction:
  - Decreases an account's token balance.
  - Burnt tokens are permanently removed from circulation.

FreezeAccount Instruction:
  - Makes an account unusable.
  - Requires the freeze_authority on the mint account.

ThawAccount Instruction:
  - Re-enables a frozen account.

SetAuthority Instruction:
  - Changes the authority of an account (e.g., mint_authority, freeze_authority).
```

--------------------------------

### Solana Token Program Overview

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter4/index.md

Provides an overview of the core Solana Token Program, responsible for creating and managing tokens on the Solana blockchain.

```APIDOC
Token Program:
  Purpose: Solana's core program for creating and managing tokens.
  Description: Facilitates the creation and management of fungible and non-fungible tokens on the Solana network.
```

--------------------------------

### Solana Account Compression Overview

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter4/index.md

Details Account Compression on Solana, a feature designed to reduce costs for NFTs and other tokenized assets by compressing data.

```APIDOC
Account Compression:
  Purpose: Enables data compression, lowering costs for NFTs and other tokenized assets.
  Description: Utilizes a Merkle tree structure to efficiently store and manage large numbers of on-chain assets.
```

--------------------------------

### Solana CLI Account Balance Check

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter3/interacting-with-the-network.md

Explains how to check the SOL balance of a specific Solana account address using the Solana CLI.

```bash
solana balance <account-address>
```

--------------------------------

### Cloudbreak Database Design Principles

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter2/cloudbreak.md

Details the core principles of Solana's Cloudbreak database, focusing on its use of memory-mapped files for parallel data access and efficient storage management.

```APIDOC
Cloudbreak Database:
  Type: Custom Solana Database
  Core Technology: Memory-mapped files
  Key Features:
    - Supports parallel reads and writes.
    - Scales with additional disks.
    - Randomly distributed reads across disks.
    - Sequential writes using Copy-on-Write semantics.
    - Garbage collection for space preservation.
  Optimized For:
    - Hardware setups like RAID 0 with fast NVMe SSDs.
  Performance:
    - Benchmarked to achieve nearly 1 million read/write operations per second with 10 million accounts on a single SSD.
```

--------------------------------

### Zero-Knowledge Proofs for Data Compression

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter4/account-compression-program.md

Explains the application of Zero-Knowledge (ZK) proofs in further reducing blockchain data storage requirements. ZK proofs enable verification of calculations or balances without revealing the underlying sensitive data.

```APIDOC
Zero-Knowledge (ZK) Proofs:
  Functionality: Allow a party to prove a statement's truth without revealing information about the statement itself.
  Application in Blockchain: Further reduce data storage by verifying calculations or balances without storing or revealing underlying data.
```

--------------------------------

### Solana Account Anatomy

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter3/account-anatomy.md

Details the components of a Solana account, including lamports (SOL balance), data (byte vector), owner (program ID or loader), executable status, and rent epoch.

```APIDOC
Account Anatomy:
  1. Lamports: Account balance in lamports (1 lamport = 10^-9 SOL).
  2. Data: Vector of bytes (max 10 MB, PDAs max 10 KB initially).
  3. Owner: Program ID or loader for executable accounts. System program owns new accounts for transfers, allocation, and ownership changes.
  4. Executable: One-way switch to load code from data. Makes account read-only.
  5. Rent Epoch: Previously used for rent collection, now inactive.
```

--------------------------------

### Solana Virtual Machine: Berkeley Packet Filter (BPF)

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter2/sealevel.md

Details Solana's choice of a virtual machine for executing smart contract code, focusing on the Berkeley Packet Filter (BPF) and its extended version (eBPF).

```APIDOC
Solana Virtual Machine (VM):
  - Executes smart contract code compiled into bytecode.
  - Solana uses a variant of the Berkeley Packet Filter (BPF).
  - BPF and eBPF are in-kernel VMs originally for high-performance packet filtering.
  - Sealevel hands off transactions to the VM for execution as BPF bytecode.

Solana's Specific Implementation:
  - Uses Rust Berkeley Packet Filter (rBPF).
  - rBPF is a modified version of eBPF optimized for Solana's architecture.
```

--------------------------------

### Solana Token-2022 Program Overview

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter4/index.md

Introduces the Token-2022 program, an updated standard for Solana tokens offering enhanced features and flexibility.

```APIDOC
Token-2022 Program:
  Purpose: An updated token standard with additional features.
  Description: Offers advanced functionalities beyond the original Token Program, such as transfer hooks and metadata extensions.
```

--------------------------------

### Solana Virtual Machine (SVM)

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter1/smart-contract.md

The Solana Virtual Machine (SVM) is the execution environment for the Solana blockchain. It is written in Rust and is designed to process thousands of transactions per second, enabling efficient smart contract execution.

```APIDOC
Solana Virtual Machine (SVM):
  Description: The execution environment for the Solana blockchain.
  Implementation: Written in Rust.
  Performance: Enables handling thousands of transactions per second.
  Usage: Processes transactions involving smart contract execution.
```

--------------------------------

### Solana Account Types

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter3/account-anatomy.md

Categorizes Solana accounts into three main types: data accounts for storing data, program accounts for executable bytecode, and native accounts for built-in programs.

```APIDOC
Account Types:
  1. Data Accounts: Store and retrieve data.
  2. Program Accounts: Store user-deployed executable bytecode.
  3. Native Accounts: Hold Solana's built-in programs (e.g., System program, BPF Loader).
```

--------------------------------

### Solana Development Languages

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter1/introduction.md

Details the primary programming languages used for developing on the Solana blockchain, including smart contract development and interaction libraries.

```Rust
Rust is the primary language for smart contract development on Solana.
```

```C
C is also supported for smart contract development on Solana.
```

```C++
C++ is also supported for smart contract development on Solana.
```

```JavaScript
Libraries and tools are available for JavaScript developers to interact with the Solana blockchain.
```

```TypeScript
Libraries and tools are available for TypeScript developers to interact with the Solana blockchain.
```

--------------------------------

### Solana Account Compression Program

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter4/account-compression-program.md

Details Solana's Account Compression program, designed to mitigate high on-chain storage costs for assets like NFTs. It achieves this by storing a compressed hash of asset data on-chain, with the actual data stored off-chain, utilizing Merkle trees.

```APIDOC
Account Compression Program:
  Purpose: Addresses rising on-chain storage costs on Solana.
  Mechanism: Stores a compressed hash of asset data on-chain; actual data stored off-chain.
  Implementation: Data is split, a Merkle tree is built, and only the Merkle root is stored on-chain.
  Type of Merkle Tree Used: Concurrent Merkle tree (allows simultaneous data changes while maintaining integrity).
```

--------------------------------

### Solana Compute Budget

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter3/runtime-policy.md

Explains that each transaction has a compute budget to prevent resource abuse. Exceeding this budget or specific bounds halts instructions and returns an error.

```APIDOC
Compute Budget:
  - Each transaction is allocated a compute budget to prevent abuse of node resources.
  - When a program consumes its entire compute budget or exceeds certain bounds, the runtime halts the currently running instructions and returns an error.
```

--------------------------------

### Arweave Storage Fees for NFTs

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/appendices/appendixB/metadata-off-chain.md

Explains the cost structure for storing NFT assets on Arweave, including the asset file, metadata file, and manifest. Fees are calculated based on the cumulative size of these files.

```APIDOC
NFT Storage Files:
  - Asset (image, video, audio, etc.)
  - Metadata file (attributes etc.)
  - Manifest (logical grouping of files)

Storage Fee Calculation:
  - Based on the cumulative size (in bytes) of the three NFT files.
  - Estimated fee is returned in winstons by the Arweave storage cost estimation service.
  - Winstons are converted to SOL for payment.
```

--------------------------------

### Solana Cross Program Invocation (CPI) Methods

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter3/cross-program-invocation.md

Demonstrates the core methods used for Cross Program Invocation (CPI) in Solana programs. 'invoke' is used when all signatures are available, while 'invoke_signed' is for when the calling program needs PDAs to act as signers.

```rust
use solana_program::program::invoke;
use solana_program::program::invoke_signed;

// Example usage of invoke:
// invoke(&instruction, &[account1, account2])?;

// Example usage of invoke_signed:
// invoke_signed(&instruction, &[account1, account2], &[&[pda_signer_seeds]]?;
```

```APIDOC
Solana Program Invocation:

invoke(instruction: &Instruction, account_metas: &[AccountMeta]) -> ProgramResult
  - Invokes another program with pre-existing signatures.
  - instruction: The instruction to be executed by the called program.
  - account_metas: A slice of AccountMeta specifying accounts required by the instruction.
  - Returns: Ok(()) on success, or an error.

invoke_signed(instruction: &Instruction, account_metas: &[AccountMeta], signer_seeds: &[&[u8]]) -> ProgramResult
  - Invokes another program, allowing the calling program to sign using PDAs.
  - instruction: The instruction to be executed by the called program.
  - account_metas: A slice of AccountMeta specifying accounts required by the instruction.
  - signer_seeds: A slice of byte slices representing the seeds for the PDA signer.
  - Returns: Ok(()) on success, or an error.

CPI Depth:
  - The maximum chain of CPI calls is 4.
```

--------------------------------

### Solana Token Creation and Management

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter4/token-program.md

Tokens on Solana are managed through the SPL Token program. Creating a token involves initializing a mint account, which holds token information. The mint authority can then mint new tokens.

```APIDOC
Token Creation:
  - Initialize a new [mint account](./mint-account.md).
  - The mint account stores token information.
  - Mint new tokens using the MintTo instruction via the mint_authority.

Token Accounts:
  - Store token balances.
  - Associated with a mint account.

Wrapped SOL:
  - SOL can be wrapped to interact with Token program interfaces.
  - Associated with the Native Mint.
  - Has unique behaviors detailed in the SPL Token documentation.
```

--------------------------------

### TBFT vs PBFT: Proof of History Integration

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter2/tower-bft.md

Highlights the key difference between TBFT and PBFT, focusing on how Solana's Proof of History (PoH) provides a global source of time before consensus. This integration allows PoH to enforce the exponentially increasing timeouts from the original PBFT algorithm without requiring additional messages, thereby reducing communication overhead.

```APIDOC
TBFT vs PBFT:
  - Key Difference: Integration of Proof of History (PoH).
  - PoH Functionality:
    - Provides a global source of time before consensus is reached.
    - Enforces exponentially increasing timeouts (as in original PBFT).
  - Benefits:
    - Reduces communication overhead by eliminating the need for additional messages to enforce timeouts.
    - PoH itself enforces the timeouts.
```

--------------------------------

### Solana TPU Pipeline Stages

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter2/pipelining.md

Details the sequential stages involved in Solana's Transaction Processing Unit (TPU) pipeline for validating and executing transactions.

```APIDOC
TPU Pipeline Stages:

1. Data Fetch:
   - Description: Incoming transaction data is fetched from the network card into the kernel space.

2. Signature Verification:
   - Description: Verifies the digital signatures of the transactions.
   - Handler: GPU

3. Banking:
   - Description: Updates the blockchain state based on the validated transactions.
   - Handler: CPU

4. Write:
   - Description: Processed transactions are written to disk (in kernel space) and broadcast to the network via the network card.
```

--------------------------------

### Metaplex Candy Machine Features

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/appendices/appendixB/metaplex.md

Details the features of Metaplex's Candy Machine program, a minting and distribution system for NFT launches on Solana. It supports various payment methods, launch restrictions, bot protection, and customizable minting groups.

```APIDOC
Metaplex Candy Machine Features:
  - Payment Methods: SOL, NFTs, or any Solana token.
  - Launch Restrictions: Configurable via start/end dates, mint limits, third-party signers.
  - Bot Protection: Includes configurable bot taxes and gatekeepers (e.g., captchas).
  - Access Control: Restrict minting to specific NFT/Token holders or curated wallet lists.
  - Minting Groups: Support for multiple groups with different rule sets.
```

--------------------------------

### Solana Mint Account Details

Source: https://github.com/ackee-blockchain/solana-handbook/blob/master/docs/chapter4/index.md

Explains the role of a Mint Account in Solana, which represents a specific token type and stores its global metadata.

```APIDOC
Mint Account:
  Purpose: Represents a specific type of token and stores global metadata.
  Description: Holds information such as the token's supply, decimals, and authority.
```