Solana Core Concepts

Solana Core Concepts

Accounts

Accounts within Solana are used to store state. They are an essential building block for developing on Solana.

Facts

1. Accounts are used to store data
2. Each account has a unique address
3. Accounts have a max size of 10MB (10 Mega Bytes)
4. PDA accounts have a max size of 10KB (10 Kilo Bytes)
5. PDA accounts can be used to sign on behalf of a program
6. Accounts size are fixed at creation time, but can be adjusted using realloc
7. Account data storage is paid with rent
8. Default account owner is the System Program

Deep Dive

Account Model

There are 3 kinds of accounts on Solana:

1. Data accounts store data
2. Program accounts store executable programs
3. Native accounts that indicate native programs on Solana such as System, Stake, and Vote

Within data accounts, there are 2 types:

1. System owned accounts
2. PDA (Program Derived Address) accounts

Each account has an address (usually a public key) and an owner (address of a program account).
The full field list an account stores is found below.

Fiels	Description
lamports	The number of lamports owned by this account
owner	The program owner of this account
executable	Whether this account can process instructions
data	The raw data byte array stored by this account
rent_epoch	The next epoch that this account will owe rent

A few important ownership rules:

1. Only a data account’s owner can modify its data and debit lamports
2. Anyone is allowed to credit lamports to a data account
3. The owner of an account may assign a new owner if the account’s data is zeroed out

Program accounts do not store state.

For example, if you have a counter program that lets you increment a counter, you must create two accounts, one account to store the program’s code, and one to store the counter.

To prevent an account from being deleted, you must pay rent.

Rent

Storing data on accounts costs SOL to maintain, and it is funded by what is called rent. If you maintain a minimum balance equivalent to 2 years of rent payments in an account, your account will be exempt from paying rent. You can retrieve rent by closing the account and sending the lamports back to your wallet.

Rent is paid during two different timings:

1. When referenced by a transaction
2. Once an epoch
   A percentage of rent collected by accounts is destroyed, while the rest is distributed to vote accounts at the end of every slot.

If the account does not have enough to pay rent, the account will be deallocated and the data removed.

It is also important to note that new accounts must be rent exempt.

Programs

Any developer can write and deploy programs to the Solana blockchain. Programs (known as smart contracts on other protocols) serve as the foundation for on-chain activity, powering anything from DeFi and NFTs to Social Media and Gaming.

Facts

1. Programs process instructions from both end users and other programs
2. All programs are stateless: any data they interact with is stored in separate accounts that are passed in via instructions
3. Programs themselves are stored in accounts marked as executable
4. All programs are owned by the BPF Loader and executed by the Solana Runtime
5. Developers most commonly write programs in Rust or C++, but can choose any language that targets the LLVM’s BPF backend
6. All programs have a single entry point where instruction processing takes place (i.e. process_instruction); parameters always include:

program_id: pubkey
accounts: array,
instruction_data: byte array

Deep Dive

Unlike most other blockchains, Solana completely separates code from data. All data that programs interact with are stored in separate accounts and passed in as references via instructions. This model allows for a single generic program to operate across various accounts without requiring additional deployments. Common examples of this pattern are seen across the Native and SPL Programs.

Native Programs & The Solana Program Library (SPL)

Solana comes equipped with a number of programs that serve as core building blocks for on-chain interactions. These programs are divided into Native Programs and Solana Program Library (SPL) Programs.

Native Programs provide the base functionality that is required to operate validators. Among these programs, the most well known is the System Program which is responsible for administering new accounts and transferring SOL between two parties.

SPL Programs support a number of on-chain activities, including creating, swapping, and lending tokens, as well as generating stake pools and maintaining an on-chain name service. The SPL Token Program can be invoked directly via the CLI, while others like the Associated Token Account Program are usually composed with custom programs.

Writing Programs

Programs are most commonly developed with Rust or C++, but can be developed with any language that targets the LLVM’s BPF backend. Recent initiatives by Neon Labs and Solang enable EVM compatibility and allow developers to write programs in Solidity.

Most Rust-based programs adhere to the following architecture:

File	Description
lib.rs	Registering modules
entrypoint.rs	Entrypoint to the program
instruction.rs	Program API, (de)serializing instruction data
state.rs	Program objects, (de)serializing state
error.rs	Program-specific errors

Recently, Anchor has emerged as a popular framework for developing programs. Anchor is an opinionated framework, akin to Ruby on Rails, that reduces boilerplate and streamlines the (de)serialization process for Rust-based development.
Programs are usually developed and tested against Localhost and Devnet environments before being deployed to Testnet or Mainnet. Solana supports the following environments:

Cluster Environment	RPC Connection URL
Mainnet-beta	https://api.mainnet-beta.solana.com
Testnet	https://api.testnet.solana.com
Devnet	https://api.devnet.solana.com
Localhost	Default port: 8899 (e.g. http://localhost:8899, http://192.168.1.88:8899)

Once deployed to an environment, clients can interact with on-chain programs via RPC connections to the respective cluster.

Deploying Programs

Developers can deploy their programs via the CLI:

solana program deploy <PROGRAM_FILEPATH>

When a program is deployed, it is compiled to an ELF shared object (containing BPF bytecode) and uploaded to the Solana cluster. Programs live in accounts (much like everything else on Solana), except these accounts are marked as executable and assigned to the BPF Loader. The address of this account is referred to as the program_id and is used to reference the program in all future transactions.

Solana supports multiple BPF Loaders, with the latest being the Upgradable BPF Loader. The BPF Loader is responsible for administering the program’s account and making it available to clients via the program_id. All programs have a single entry point where instruction processing takes place (i.e. process_instruction) and parameters always include:

program_id: pubkey
accounts: array,
instruction_data: byte array

Once invoked, programs are executed by the Solana Runtime.

what is BPF byte code?

BPF (Berkeley Packet Filter) bytecode is a low-level, platform-independent instruction set used primarily for network packet filtering and more recently for various other types of kernel-level instrumentation and monitoring tasks.
Key Points about BPF Bytecode:
Origins in Networking:

Originally designed for filtering network packets in the Unix kernel.
Allows user-space programs to specify rules for which packets to capture or discard, useful in tools like tcpdump and Wireshark.
Extended BPF (eBPF):

Modern versions of BPF, known as eBPF, have expanded beyond networking.
eBPF can be used for tracing, monitoring, security, and performance analysis within the Linux kernel.
Execution:

BPF bytecode runs in a restricted virtual machine environment inside the kernel.
Ensures safety and security by validating the bytecode before execution, preventing crashes or malicious behavior.
Instruction Set:

The BPF instruction set includes a variety of operations such as load, store, arithmetic, jumps, and function calls.
It is designed to be efficient and to run with minimal overhead.
User Applications:

Users write BPF programs in C or a similar high-level language.
These programs are then compiled into BPF bytecode and loaded into the kernel for execution.
Use Cases:

Networking: Packet filtering, load balancing, and firewalling.
Observability: System monitoring, tracing, profiling, and debugging.
Security: Implementing security policies and detecting anomalies.
Example BPF Bytecode
A simple example of BPF bytecode might look like this in its assembly-like form:

assembly
Copy code

ldh [12]               ; Load 2 bytes from offset 12
jne #0x800, drop       ; If not IPv4 (0x800), drop packet
ldh [23]               ; Load protocol field
jeq #0x6, pass         ; If TCP (0x6), pass packet
drop: ret #0           ; Drop packet
pass: ret #0xffff      ; Pass packet
In this example, the BPF program filters IPv4 TCP packets, dropping others.

Conclusion
BPF bytecode plays a crucial role in high-performance packet filtering and more general-purpose kernel instrumentation. Its flexibility and efficiency make it a powerful tool for developers working on low-level system tasks.

Transactions

Clients can invoke programs by submitting a transaction to a cluster. A single transaction can include multiple instructions, each targeting its own program. When a transaction is submitted, the Solana Runtime will process its instructions in order and atomically. If any part of an instruction fails, the entire transaction will fail.

Facts

1. Instructions are the most basic operational unit on Solana
2. Each instruction contains:

The program_id of the intended program
An array of all accounts it intends to read from or write to
An instruction_data byte array that is specific to the intended program

3. Multiple instructions can be bundled into a single transaction
4. Each transaction contains:

An array of all accounts it intends to read from or write to
One or more instructions
A recent blockhash
One or more signatures

5. Instructions are processed in order and atomically
6. If any part of an instruction fails, the entire transaction fails.
7. Transactions are limited to 1232 bytes

Deep Dive

The Solana Runtime requires both instructions and transactions to specify a list of all accounts they intended to read from or write to. By requiring these accounts in advance, the runtime is able to parallelize execution across all transactions.

When a transaction is submitted to a cluster, the runtime will process its instructions in order and atomically. For each instruction, the receiving program will interpret its data array and operate on its specified accounts. The program will either return successfully or with an error code. If an error is returned, the entire transaction will fail immediately.

Any transaction that aims to debit an account or modify its data requires the signature of its account holder. Any account that will be modified is marked as writable. An account can be credited without the holder’s permission so long as the transaction fee payer covers the necessary rent and transaction fees.
Before submission, all transactions must reference a recent blockhash. The blockhash is used to prevent duplications and eliminate stale transactions. The max age of a transaction’s blockhash is 150 blocks, or about ~1 minute 19 seconds as of the time of this writing.

Fees

The Solana network collects two types of fees:

1. Transaction fees for propagating transactions (aka “gas fees”)
2. Rent fees for storing data on-chain

In Solana, transaction fees are deterministic: there is no concept of a fee market in which users can pay higher fees to increase their chances of being included in the next block. At the time of this writing, transaction fees are determined only by the number of signatures required (i.e. lamports_per_signature), not by the amount of resources used. This is because there is currently a hard cap of 1232 bytes on all transactions.

All transactions require at least one writable account to sign the transaction. Once submitted, the writable signer account that is serialized first will be the fee payer. This account will pay for the cost of the transaction regardless of whether the transaction succeeds or fails. If the fee payer does not have a sufficient balance to pay the transaction fee, the transaction will be dropped.

At the time of this writing, 50% of all transaction fees are collected by the validator that produces the block, while the remaining 50% are burned. This structure works to incentivize validators to process as many transactions as possible during their slots in the leader schedule.

Solana Accounts

Definition:

1. An account in Solana is a data structure that holds state information and can store arbitrary data.
2. Every transaction in Solana must reference at least one account.

Types of Accounts:

1. System Accounts: Used to store SOL tokens and are created when a user creates a new wallet or public key.
2. Program Accounts: These are accounts associated with a smart contract or program. They contain executable code and can be invoked by transactions.
3. Data Accounts: Used to store data related to a program. They are created and managed by the programs themselves.

Key Features:

1. Ownership: Each account has an owner, which is typically a program that can modify the account’s data.
2. Balance: Accounts can hold SOL tokens, and the balance can be used to pay for transaction fees and other costs.
3. Rent: Solana employs a rent mechanism to encourage users to keep only necessary accounts open. If an account’s balance drops below a certain threshold, it may be deleted to free up space.
4. Executable Flag: Indicates whether the account is a program (executable) or just a regular account holding data or tokens.

Accessing and Using Accounts:

1. When executing a transaction, accounts need to be referenced and passed as inputs to the programs.
2. Programs can read from and write to the accounts they own or have been given access to.
3. Accounts must be pre-allocated with the appropriate amount of SOL to cover the rent and any potential transaction fees.

Example

If you have a voting DApp using Solana, you’ll likely deal with several types of accounts:

1. Voter Accounts: Each voter might have an account storing their voting status or specific choices.
2. Voting Program Account: The smart contract (or program) handling the voting logic.
3. Poll Accounts: These might hold the details of each poll, such as the options and results.

Wallets

Definition:

1. A wallet in Solana (and other blockchain networks) is essentially a digital tool that allows users to manage their private and public keys.
2. It provides an interface to interact with the blockchain, send and receive tokens, and manage accounts.

Functionality:

1. Key Management: Wallets manage the private keys that are necessary to sign transactions and access funds.
2. Account Management: Wallets can create, view, and manage multiple accounts, each associated with a public key.
3. Transaction Handling: Wallets can initiate transactions, such as transferring SOL tokens or interacting with smart contracts.

Accounts

Definition:

1. An account in Solana is a data structure on the blockchain that stores state information and SOL tokens.
2. Accounts are referenced by their public key, and they hold data used by programs.

Functionality:

1. State Storage: Accounts store data and state information relevant to various applications and programs.
2. Token Holding: Accounts can hold SOL tokens and other SPL (Solana Program Library) tokens.
3. Program Interaction: Accounts are used by smart contracts (programs) to read and write data during transactions.

Relationship Between Accounts and Wallets

Public and Private Keys:

1. A wallet generates and manages pairs of public and private keys.
2. The public key is used to create and reference accounts on the blockchain.
3. The private key is used to sign transactions, proving ownership and authorization to interact with an account.

Account Ownership:

1. The wallet does not directly store SOL or tokens; instead, it manages the private keys that give access to the accounts where tokens are stored.
2. When a user wants to perform an action, such as transferring SOL, the wallet signs the transaction with the private key corresponding to the account’s public key.

Multiple Accounts:

1. A single wallet can manage multiple accounts, each with a unique public key.
2. Users can use different accounts for different purposes, such as holding funds, interacting with specific programs, or managing application data.