Solana Core Concept

2024, Sep 19

Solana Account Model #
- Account info
  - Structure
  - Details
- 7 commandments of Solana Accounts
Programs on Solana #
Transactions and Instructions #
- 5 commandments of Solana Transactions
Fees on Solana #
Cross Program Invocation #

This article is an introduction to the core concept around the blockchain Solana, notably:

Solana Account Model
Accounts and programs on Solana
Transactions and Instructions
Program Derived Address (PDA)
Cross Program Invocation (CPI)

Solana’s ecosystem is centered on speed, scalability, and efficient smart contract development, using Rust as a primary programming languages. Additionally, Solana supports Solana Program Library (SPL), a set of community-maintained on-chain programs providing standards for functions like token management and governance.

This article is mainly based on several video by Ackee Blockchain Security: Solana programming model I, Solana Programming Model 2, SPL Tokens on Solana ◎ Bonus Lecture

[TOC]

Solana Account Model #

On Solana, all data is stored in what are referred to as “accounts”. The way data is organized on the Solana blockchain resembles a key-value store, where each entry in the database is called an “account”. Learn more about Accounts here.

There are three main type of accounts in Solana

Data Accounts: These are created by Programs and used for storing data.
Program Accounts: These accounts store executable programs. This is the equivalent of smart contracts on Solana.
Native Accounts: These refer to native programs on Solana, such as System, Stake, and Vote. They are built-in programs included with the Solana runtime.

Account info

The data stored on every account on Solana has the following structure known as the AccountInfo.

account

Structure

Here the full structure

pub struct AccountInfo<'a> {
    pub key: &'a Pubkey,
    pub lamports: Rc<RefCell<&'a mut u64>>,
    pub data: Rc<RefCell<&'a mut [u8]>>,
    pub owner: &'a Pubkey,
    pub rent_epoch: Epoch,
    pub is_signer: bool,
    pub is_writable: bool,
    pub executable: bool,
}

Details

The AccountInfo for each account includes the following fields:

key
- Use to identify an account
- 256-bit long
- Usually a public key of ed25519 keypair
data: A byte array that stores the state of an account. If the account is a program (smart contract), this stores executable program code. This field is often referred to as the “account data”.
executable: A boolean flag that indicates if the account is a program.
lamports:
- the number of lamports owned by this account, in the smallest unit of SOL (1 SOL = 1 billion lamports).
- Only the owner of an account may substract its lamport
- Runtime assets
```
total_lamports_before == total_lamports_after
```
is_signer
- Flag indicating if an account has signed a transaction
- It is not actually stored in the account
- It’s just runtime metadata
data
- The raw data byte array stored by this account
- Up to 10 MB of mutable storage
- Can only be written by the owner account
- Can not be resized (currently)
owner:
- Specifies the public key (program ID) of the program that owns the account.Only the program designated as the owner of an account can
  - modify the data stored on the account
  - deduct the lamport balance.
- Only the owner of an account
  - may assign a new owner
  - write to the data
- The owner can only be changed if the data is zero
executable
- Accounts are marked as executable during a successful progroam deployment process
- Executable accounts are fully immutable once they are marked as final
- Owned by the bpf loader program
rent_epoche
- Accounts are helds in validator memory and pay “rent” to stay there
- Charged every epoch(~2 days) and are determined by account size
- Accounts with sufficient balance to cover 2 years of rent are exempt from fees

Reference: Solana - accounts

7 commandments of Solana Accounts

Each account has an unique address and an owner(some program)
Owner has fully autonomy over the owned accounts
Only a data account’s owner can modify its data and debit lamports
Program accounts don’t store state
Account must pay rent to stay alive, otherwise they will be deleted at the end of the transaction
Anyone is allowed to credit lamports to a data account
The owner of an account may assign a new owner if the account’s data is zeroed out

Programs on Solana #

In the Solana ecosystem, “smart contracts” are called programs. Each program is an on-chain account that stores executable logic, organized into specific functions referred to as instructions.

In summary:

Programs are piece of code that runs by Solana Blockchain
Programs are stateless. Meaning you can’t store any data in them
Solana uses Accounts to store both program’s code and “Data” - We can imagine them as files
Program can be upgraded on-chain if the authorized authority has not bee revoked.

Solana Program Library

The Solana Program Library (SPL) is a collection of on-chain programs targeting the Sealevel parallel runtime. These programs are tested against Solana’s implementation of Sealevel, solana-runtime, and deployed to its mainnet.

There are several different program

Stake pool to create different staking pool
Token-Lending program to create lending protocol
Token Swap Program: A Uniswap-like exchange for the Token program on the Solana blockchain, implementing multiple automated market maker (AMM) curves.

Tokens on Solana

Tokens on Solana can be created through the Token Program, which defines a common implementation for Fungible and Non Fungible tokens.

There are two others accounts which are crucial:

A Mint Account represents a specific type of token and stores global metadata about the token such as the total supply and mint authority, which is the address authorized to create new units of a token.
A Token Account keeps track of individual ownership of how many units of a specific type of token (mint account) are owned by a specific address.

Reference: solana.com/docs/core/tokens

Tokens programs: to create different SPL token

Ethereum / ERC-20	Solana / SPL token
Fungible tokens use the ERC-20 standard, a general interface that an ERC-20 token must respect	Integrated program No general interface
Smart contract template to create a new token	There is a single token program (spl-token-progran)
To create a new token, you deploy ERC smart contract on-chain	You deploy and interact with SPL program via Solana CLI, see my article

Example

solana-token-program.drawio

We have our Token Program and our System Program

The user Alice owns the private key of the System Account (wallet)
First, we ask our Token program to create our Mint account
1. This mint account is owned by Token Program
2. The mint_authority can burn and mint tokens. It can be our user Alice
3. The Token Program contains several different fields related to fungible tokens: supply, decimal
Alice with its wallet can ask the Mint account to burn and mint tokens from the Token Account to the Alice wallet

Program Derived Address #

Program Derived Addresses (PDAs) provide developers on Solana with two main use cases:

Deterministic Account Addresses: PDAs provide a mechanism to deterministically derive an address using a combination of optional “seeds” (predefined inputs) and a specific program ID.
Enable Program Signing: The Solana runtime enables programs to “sign” for PDAs which are derived from its program ID.

You can think of PDAs as a way to create hashmap-like structures on-chain from a predefined set of inputs (e.g. strings, numbers, and other account addresses).

Learn more about Program Derived Address here.

Reference: RareSkills - PDA (Program Derived Address) vs Keypair Account in Solana

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.

5 commandments of Solana Transactions

All program input are potentially malicious
- User composes an instructions/transactions
- User provides all the accounts
Check the signers
Check the owner
Beware of unexpected order of instructions within transaction
Think of compute budget

See also my article Solana Programs - Basic Security with Anchor

Learn more about Transactions and Instructions here.

Fees on Solana #

The Solana blockchain has a few different types of fees and costs that are incurred to use the permissionless network. These can be segmented into a few specific types:

Transaction Fees - A fee to have validators process transactions/instructions
Prioritization Fees - An optional fee to boost transactions processing order
Rent - A withheld balance to keep data stored on-chain

Rent is the fee deposited into every Solana Account to keep its associated data available on-chain.

This fee is withheld in the normal lamport balance on every account
When an account’s owner no longer desires to keep this data on-chain and available in the global state, the owner can close the account and reclaim the rent deposit.

Learn more about Fees on Solana here.

Cross Program Invocation #

A Cross Program Invocation (CPI) refers to when one program invokes the instructions of another program. This mechanism allows for the composability of Solana programs.

Each CPI instruction must specify the following information:

Program address: Specifies the program being invoked
Accounts: Lists every account the instruction reads from or writes to, including other programs
Instruction Data: Specifies which instruction on the program to invoke, plus any additional data required by the instruction (function arguments).

Programs can execute CPIs using either invoke or invoke_signed within their instructions

invoke is used when all required signatures are accessible prior to invocation, without the need for PDAs to act as signers. This is the case when you use the original transaction signature that was passed into your program.
invoke_signed is used when PDAs from the calling program are required as signers in the CPI

// Used when there are not signatures for PDAs needed
pub fn invoke(
    instruction: &Instruction,
    account_infos: &[AccountInfo<'_>]
) -> ProgramResult
 
// Used when a program must provide a 'signature' for a PDA, hence the signer_seeds parameter
pub fn invoke_signed(
    instruction: &Instruction,
    account_infos: &[AccountInfo<'_>],
    signers_seeds: &[&[&[u8]]]
) -> ProgramResult