Solana Cookbook

The Solana Cookbook is organized into three primary sections to help developers navigate different types of information:

• Core Concepts: Explains the fundamental building blocks of Solana necessary for development.
• Guides: Provides small, focused guides regarding various development tools.
• References: Contains frequently used code snippets and technical references.

Standard Solana transactions rely on a RecentBlockhash, which expires after approximately 150 blocks. If a transaction is not broadcast within this window, it will be rejected.

A Durable Nonce provides a way to use a 'never expiring' recent blockhash. To use this mechanism, your transaction must satisfy two requirements:

1. Use a nonce stored in a nonce account as the recent blockhash.
2. Include a nonce advance operation as the first instruction in the transaction.

A Program Derived Address (PDA) differs from a standard address in two ways:

1. It is off the ed25519 curve.
2. Programs use the program itself to sign for the account instead of a private key.

Note: While the address is derived from a Program ID, it does not automatically mean the PDA is owned by that program. You can initialize a PDA as a Token Account owned by the Token Program.

To generate a PDA, use findProgramAddress. This function appends an extra byte (starting from 255 down to 0) to your seeds until it finds a public key that falls off the ed25519 curve. Providing the same Program ID and seeds will always yield the same result.

// Refer to @/code/accounts/program-derived-address/derived-a-pda/find-program-address.en.ts for implementation

The dataSlice parameter does not reduce the number of accounts returned, but it limits the amount of data returned for each account. This is useful when you need to find accounts (e.g., counting holders) but do not need to read their full state.

Parameters:

• offset (number): The number of bytes into the account data to begin returning.
• length (number): The number of bytes of account data to return.

In Solana, Programs (often called smart contracts) are the foundation for on-chain activity. Unlike many other blockchains, Solana strictly separates code from data.

Key characteristics:

• Statelessness: Programs themselves do not store state. All data used by a program is stored in separate Accounts.
• Execution: Programs are owned by a BPF Loader and executed by the Solana Runtime.
• Storage: A program exists within an Account marked as executable.
• Entry Point: Every program has a single entry point (typically process_instruction) that receives three mandatory parameters:
  • program_id: The pubkey of the program.
  • accounts: An array of accounts involved in the instruction.
  • instruction_data: A byte array containing the instruction parameters.

Every transaction must reference a recent blockhash before being sent to the cluster. The blockhash serves two primary purposes:

1. Preventing Duplication: It helps prevent replay attacks.
2. Expiration: It allows the network to discard old transactions. A transaction is considered valid for a maximum of approximately 150 blocks or roughly 1 minute and 19 seconds.

An alternative to PDAs is to store a data structure like a BTreeMap within a single account. The account address itself can be either a PDA or a standard Keypair public key.

Limitations

• Initialization: You must explicitly initialize the account before inserting key-value pairs.
• Address Management: You must store the address of this mapping account somewhere to reference it for future updates.
• Size Constraints: Solana accounts have a maximum size of 10MB, which limits the number of key-value pairs a single BTreeMap can hold.

Solana programs are categorized into two main types:

1. Native Programs: These provide fundamental infrastructure required to run validators. The most prominent example is the System Program, which manages account creation and SOL transfers between accounts.
2. Solana Program Library (SPL) Programs: These support a wide range of on-chain activities such as token creation, swapping, lending, stake pools, and on-chain name services.
   • The SPL Token Program can be invoked directly via the CLI.
   • Other programs, like the Associated Token Account Program, are typically used as part of custom program logic.