# Solana Development

## Solana Playground
[Solana Playground](https://beta.solpg.io/) is browser-based application that will
let you write, build, and deploy onchain Solana programs. All from your browser. No
installation needed.

Normally with [local development](https://solana.com/docs/intro/installation), you

will need to create a file system wallet for use with the Solana CLI. But with the
Solana Playground, you only need to click a few buttons to create a browser-based
wallet.

> Your Playground Wallet will be saved in your browser's local storage. Clearing
your browser cache will remove your saved wallet. When creating a new wallet, you
will have the option to save a local copy of your wallet's keypair file.

Commands you can try:

```
solana address
solana account <wallet-address>
solana balance
solana airdrop <address> <amount>
```

## Local development
1. [Solana CLI](https://docs.solanalabs.com/cli/install)
- `solana --version`
- to install new updates `agave-install update`
3. Nodejs (typescript). Installed using [fnm](https://github.com/Schniz/fnm)
- `fnm ls-remote`
- `fnm install v22`
- `fnm use v22`
- `node --version`
- `npm install --global yarn`
- `yarn --version`
5. [Rust](https://www.rust-lang.org/tools/install)
- `rustc --version`
- `rustup update`
6. an IDE, probably visual studio code using `brew`
7. [Anchor](https://www.anchor-lang.com/docs/installation), Solana Smart Contract
framework
- Using the Anchor version manager AVM
- `cargo install --git https://github.com/coral-xyz/anchor avm --force`
- `avm --version`
- Install the latest version of Anchor CLI using AVM:
- `avm install latest`
- `avm use latest`
- `anchor --version`

## Solana CLI
get info about current connected cluster: devnet, mainnet, etc.
```sh
solana config get
solana config set --url mainnet-beta
solana config set --url devnet
solana config set --url localhost
solana config set --url testnet
```
- connected cluster: a set of network nodes that work together to maintain a
synchronized copy of the blockchain. These clusters are essential for providing a
decentralized, distributed ledger and powering the Solana network by validating
transactions, securing the chain, and executing programs (smart contracts).

The `RPC URL` and `Websocket URL` specify the Solana cluster the CLI will make
requests to.
The `Keypair Path` specifies the location of the default wallet used by the Solana
CLI (to pay transaction fees and deploy programs).

### Create a Wallet

To interact with the Solana network using the Solana CLI, you need a Solana wallet
funded with SOL. You can generate a vanity address using the Solana CLI:
```sh
solana-keygen new #To generate a keypair at the default Keypair Path
solana-keygen grind --starts-with prefix:count
solana-keygen grind --starts-with SoD:1
solana config set --keypair /Users/federico/.config/solana/0xsolodev.json
solana address
solana balance
solana airdrop 5
```

### Getting SOL

From a developer's perspective, SOL is required for two main use cases:
- To create accounts where we can store data or deploy programs
- To pay for transaction fees when we interact with the network
```sh
solana airdrop 5
```
or using the [Web Faucet](https://faucet.solana.com/).
A `Lamport` is the smallest unit of `SOL`, the native cryptocurrency of the Solana
blockchain. It’s named after [Leslie
Lamport](https://en.wikipedia.org/wiki/Leslie_Lamport)
```
1 SOL = 1,000,000,000 Lamports (1 billion Lamports)
```
Use Cases of Lamports
- Transaction Fees: Gas fees on Solana are measured in Lamports.
- Program Interactions: When working with Solana smart contracts (programs), you
often deal with `Lamports` instead of `SOL`.
- Splitting Payments: Since `SOL` is divisible, using Lamports allows for precise
micro-transactions.

## Intro to Development
Development on Solana can be broken down into two main parts:
- Onchain Program Development: This is where you create and deploy custom programs
directly to the blockchain. You can write these programs in Rust, C, or C++
- Client Development: This is where you write software (called decentralized
applications, or dApps) that communicates with onchain programs. Client development
can be written in any programming language.

The "glue" between the client side and the onchain side is the [Solana JSON RPC
API](https://solana.com/docs/rpc). The client-side sends RPC requests to the Solana
network to interact with onchain programs. This means that anyone can interact with
your onchain program without the need of issuing API keys or any other form of
permission.

![clients-solana-blockchain](https://gist.github.com/user-attachments/assets/
2d44fa5c-5e2d-4283-982d-27aa6773b16d)
you'll be working with a blockchain and have to think about how users potentially
interact with your application onchain instead of just on the frontend.

### Client-side Development

SDK for client side development in typescript:
[solana-web3.js](https://github.com/anza-xyz/solana-web3.js)
There are others SDK for different programming languages:
- [Go](https://github.com/gagliardetto/solana-go)
- [Rust](https://docs.rs/solana-sdk/latest/solana_sdk/)
- [Python](https://github.com/kevinheavey/solders)

Just run one simple command to generate a new project! The scaffold will include
both an example frontend and an onchain program template
```sh
npx create-solana-dapp <project-name>
```
You can read more about create-solana-dapp [here](https://github.com/solana-
developers/create-solana-dapp)

### Onchain Program Development

Onchain program development consists of either writing programs in `Rust`, C, or C+
+.
When building onchain programs, you have a choice to either build with native Rust
(ie, without a framework) or use the [Anchor framework](https://www.anchor-
lang.com/)

There are a few different ways to test your program based on your language
preference:
-
[solana-program-test](https://docs.rs/solana-program-test/latest/solana_program_tes
t/) - Testing framework built in Rust
- [solana-bankrun](https://kevinheavey.github.io/solana-bankrun/) - Testing
framework built for writing Typescript tests

For local development using `localhost` you need a [local

validator](https://solana.com/developers/cookbook/development/start-local-
validator):
```
solana-test-validator
```
## Solana Wallet Guide
A crypto wallet is a device or application that stores a collection of keys and can
be used to send, receive, and track ownership of cryptocurrencies.
A wallet might be:
- a directory or file in your computer's file system, A file system wallet is the
most convenient and least secure form of wallet,
- a piece of paper is a collection of seed phrases written on paper,
- smartphone app: [phantom](https://phantom.com/), [jupiter
mobile](https://jup.ag/mobile)
- browser extension: [phantom](https://phantom.com/),
[backpack](https://backpack.app/), [solflare](https://solflare.com/)
- computer program,
- or a specialized device called a hardware wallet:
[ledger](https://shop.ledger.com/), [trezor](https://trezor.io/)

A keypair is a securely generated secret key and its cryptographically-derived

public key. A secret key and its corresponding public key are together known as a
keypair. A wallet contains a collection of one or more keypairs
- The public key (commonly shortened to pubkey) is known as the wallet's receiving
address or simply its address.
- The secret key (also referred to as private key) is required to digitally sign
any transactions to send cryptocurrencies to another address or to make any changes
to the wallet. The secret key must never be shared.

## Core Concepts

### Solana Account Model

On Solana, all data is contained in what we call `accounts`. You can think of data
on Solana as a public database with a single `Accounts` table (key-value store),
where each entry in this table is an individual `account`.

Accounts on Solana:
- can store "state" or "executable" programs.
- State: This is data that's meant to be read from and persisted.
- Executable Programs: These are accounts that contain the actual code of Solana
`programs`.
- Accounts can store up to 10MB of data and the data stored on every account on
Solana has the following structure known as the AccountInfo.
- Data: Bytes (state of the account: data or executable code)
- Executable: Boolean
- Lamports: Number
- Owner: Program Address
- Accounts require a rent deposit in SOL, proportional to the amount of data
stored, which is fully refundable when the account is closed.
- Each one has an `address` (epresented as 32 bytes in the format of an [Ed25519]
(https://ed25519.cr.yp.to/) PublicKey) that serves as its unique ID used to locate
its corresponding on-chain data.
- All `wallet` accouns are ownwed by the `System Program` with the address
`11111111111111111111111111111111`
- All executable accounts are owned by the `Upgradable BPF Loader` with the address
`BPFLoaderUpgradeab1e11111111111111111111111`
- Only the program designated as the owner of an `account` can modify the data
stored on the `account` or deduct the lamport balance.
- Sysvar accounts are special accounts that store network cluster state. Full list
[here](https://docs.anza.xyz/runtime/sysvars)

#### Native Programs

Solana contains a small handful of native programs that are part of the validator
implementation and provide various core functionalities for the network. You can
find the full list of native programs
[here](https://docs.anza.xyz/runtime/programs).
- System program
- new account creation
- space allocation
- assign program ownership
- BPFLoader Program
- Owner of all other programs on the network, except native programs
- responsible for deploying, upgrading, and executing custom programs.
- Custom programs (smart contracts)
- When new programs are deployed on Solana, technically three separate
accounts are created:
- Program Account: This account stores the address of an executable data
account (which stores the compiled program code) and the update authority for the
program (address authorized to make changes to the program).
- Program Executable Data Account: An account that contains the executable
byte code of the program.
- Buffer Account: A temporary account that stores byte code while a
program is being actively deployed or upgraded. Once the process is complete, the
data is transferred to the Program Executable Data Account and the buffer account
is closed.
- Solana programs are "stateless", meaning that program accounts only contain
the program's executable byte code. To store and modify additional data, new
accounts must be created. These accounts are commonly referred to as “data
accounts”.

### Transactions and Instructions

On Solana, we send transactions to interact with the network. Transactions include
one or more instructions, each representing a specific operation to be processed.
The execution logic for instructions is stored on programs deployed to the Solana
network, where each program stores its own set of instructions.
- Atomicity: If any instruction within the transaction fails, none of the
instructions are executed.
- Execution Order: instructions (interaction with a program) are processed in
the order they are added to the transaction.
Each instruction specifies the program to execute the instruction, the accounts
required by the instruction, and the data required for the instruction's execution.

The maximum size of a transaction is 1232 bytes.

#### Transaction
A Solana transaction consists of:
- Signatures: An array of signatures included on the transaction.
- Message: List of instructions to be processed atomically.

The structure of a transaction message comprises of:

- Message Header: Specifies the number of signer and read-only account.
- Account Addresses: An array of account addresses required by the instructions
on the transaction.
- Recent Blockhash: Acts as a timestamp for the transaction. The blockhash is
used to prevent duplications and eliminate stale transactions. The maximum age of a
transaction's blockhash is 150 blocks (~1 minute assuming 400ms block times).
- Instructions: An array of instructions to be executed.

#### Instruction
An instruction is a request to process a specific action on-chain and is the
smallest contiguous unit of execution logic in a program. Each instruction in the
array specifies the following information:
- Program ID: Identifies an on-chain program that will process the
instruction.
- Compact array of account address indexes: Accouns required by the
instruction
- Compact array of opaque u8 data: This data specifies the instruction to
invoke on the program along with any additional data that the instruction requires.

For every account required by an instruction, the following info must be specified:
- pubkey: The on-chain address of an account
- is_signer: Specify if the account is required as a signer on the transaction
- is_writable: Specify if the account data will be modified

### Fees on Solana