◎
Storage Model
Solana
Flat Account Model — No Global State Trie!

Solana throws away the state trie entirely. Just pubkey → bytes in RocksDB.Programs are accounts. Data is in accounts. Parallel execution via Sealevel because transactions pre-declare which accounts they touch.

🚫

No Merkle Patricia Trie. No IAVL. No State Trie At All.

Ethereum/Cosmos: every state read/write → traverse a deep tree → many DB lookups
Solana: pubkey → bytes — 1 DB lookup. Done.

📦

Everything is an Account

Wallets, tokens, programs, config — everything is an account. Each account = lamports (SOL) + bytes (data) + owner program.

📜

Programs are Stateless

A program (smart contract) only stores bytecode. All mutable state lives in separate "data accounts" owned by the program. This enables parallelism.

⚡

Parallel via Account Declarations

Transactions must declare all accounts upfront. The scheduler sees which txs share accounts and runs independent ones in parallel via Sealevel.

Account Types — Everything in Solana

Click any account to explore its structure.

👛EOA (Wallet)
4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy
🪙Token Account
7nZ3GwrJTe...
📜Program Account
executable
TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
📦Data Account
8QvjH3b...

Account Structure

account-model.rsrust
1// Solana Account Model — NO GLOBAL STATE TRIE
2// Every account is just a blob of bytes in RocksDB
3
4Account {
5  lamports:   u64,      // SOL balance (1 SOL = 1e9 lamports)
6  data:       Vec<u8>,  // arbitrary data (up to 10MB)
7  owner:      Pubkey,   // which program owns this account
8  executable: bool,     // is this account a program?
9  rent_epoch: u64,      // when rent was last collected
10}
11
12// Storage key: just the pubkey (32 bytes)
13DB[alice_pubkey] = serialize(alice_account)
14DB[program_pubkey] = serialize(program_account)  // program is also an account!
15
16// NO global state trie
17// NO keccak256(address) → nibbles → trie traversal
18// JUST: pubkey → bytes
program-account.rsrust
1// Programs (Smart Contracts) = Just Accounts
2// The code lives in a "program account" with executable=true
3
4// Program account:
5{
6  owner:      BPF_LOADER_PUBKEY,
7  executable: true,
8  data:       [compiled BPF bytecode...]  // the actual program
9}
10
11// State accounts (owned by programs):
12{
13  owner:      spl_token_program,  // this program controls the data
14  data:       serialize(TokenAccount {
15    mint:    usdc_mint_pubkey,
16    owner:   alice_pubkey,
17    amount:  1000000,  // 1 USDC (6 decimals)
18    ...
19  })
20}
21
22// KEY INSIGHT: Programs are stateless!
23// A program's code never changes its own data
24// Instead, it updates "data accounts" that it owns
25// This is why Solana can parallelize transactions

Sealevel — Parallel Execution Engine

sealevel.rsrust
1// Sealevel — Solana's Parallel Execution Engine
2// Why it works: transactions declare ALL accounts they'll touch
3
4// Transaction must declare:
5tx.accounts = [
6  { pubkey: alice,  is_writable: true,  is_signer: true  },
7  { pubkey: bob,    is_writable: true,  is_signer: false },
8  { pubkey: usdc,   is_writable: false, is_signer: false },
9]
10
11// Scheduler can see:
12// Tx1 reads/writes: [alice, bob]
13// Tx2 reads/writes: [carol, dave]
14// Tx3 reads/writes: [alice, carol]  // conflicts with Tx1 and Tx2!
15
16// Tx1 and Tx2 → PARALLEL (no shared accounts)
17// Tx3 → must wait for Tx1 and Tx2 to finish
18
19// Compare to Ethereum:
20// Txs can read/write any account → must run sequentially

Visual: Parallel vs Sequential Execution

Ethereum (Sequential)
Tx1: Alice→Bob
[waits for Tx1] Tx2: Carol→Dave
[waits for Tx2] Tx3: Eve→Frank
Total: 3 time slots
Solana Sealevel (Parallel)
Tx1: Alice→Bob
Tx3: Eve→Frank
Tx2: Carol→Dave
Total: 1 time slot!

AccountsDB — Append-Only Storage

accounts-db.rsrust
1// Solana AccountsDB — How accounts are stored
2// Uses an append-only write structure for performance
3
4// Old accounts are NOT modified in place
5// Instead, new versions are APPENDED and old ones marked as dead
6
7AccountsDB {
8  // Append-only storage files
9  append_file_1: [account_v1_data, account_v2_data, ...]
10  append_file_2: [new_account_data, ...]
11  
12  // Index: pubkey → (file_id, offset, size)
13  index: {
14    alice: (file_2, offset_100, 128),  // latest version
15    bob:   (file_1, offset_500, 96),
16  }
17}
18
19// Merkle hash for verification:
20// Not a full trie! Uses account-hash for each account
21// Then a separate "bank hash" combines all changed accounts
22// Much simpler than Ethereum's per-account trie
23
24bank_hash = hash(
25  prev_bank_hash,
26  hash_of_all_account_changes_in_block  // simple XOR of account hashes
27)

Rent — Preventing State Bloat

rent.rsrust
1// Solana Rent — Paying for Storage
2// Accounts must maintain minimum balance or get deleted
3
4// Minimum balance = (account_size bytes) × rent_per_byte
5// At current rates: ~0.00089 SOL per KB per year
6
7// Rent-exempt: if balance > rent_minimum, never deleted
8alice_min_lamports = RENT_EXEMPTION_THRESHOLD(account_size)
9// ≈ 2 years of rent (about 0.002 SOL for a basic account)
10
11// If balance falls below minimum:
12// → account is garbage collected → data DELETED from DB
13// This keeps the DB clean — no state bloat!
14
15// Ethereum comparison:
16// Ethereum has state bloat — old contract storage stays forever
17// Solana's rent forces cleanup of unused state

How Flat Storage → Capabilities

✅
No state trie — direct pubkey lookup

Reading account state = 1 RocksDB lookup. Ethereum = O(64) trie node reads. Solana is dramatically faster for reads.

✅
Pre-declared account access + stateless programs

Sealevel can run thousands of transactions in parallel. ~65,000 TPS theoretical. No sequential bottleneck.

⚠️
No global state Merkle proof

Can't prove account state to a light client like Ethereum can. Solana needs validators to trust each other more.

✅
Rent mechanism

Forces accounts to hold minimum SOL. Prevents state bloat. But unfamiliar to Ethereum developers.

✅
Programs are fixed code accounts

Programs can't be upgraded unless they use special upgrade authority pattern. More secure but less flexible.