Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Solana doesn't have contract storage in the Ethereum sense. Every piece of state is an 'account' — a separate file on-chain that a program reads or writes by reference. Programs declare in advance every account a transaction will touch. This account-model thinking is the single biggest mental flip from EVM-style development, and protocol-engineering on Solana starts here.
Ethereum: contract C has storage; you call C.write() and it updates C's slot. Solana: account A is data; program P reads A in instruction I and produces new bytes for A. Account A's owner is set to P, so only P can write it.
Use these three in order. Each builds on the one before.
In one paragraph, contrast the Ethereum contract-storage model with Solana's account model.
Walk me through what happens when a Solana program reads and writes an account.
Design a Solana program where the same logical entity (e.g., a user) has data split across multiple accounts. What's the access pattern?
use anchor_lang::prelude::*;
#[derive(Accounts)]
pub struct Increment<'info> {
#[account(mut, has_one = owner)]
pub counter: Account<'info, Counter>,
pub owner: Signer<'info>,
}
#[account]
pub struct Counter {
pub owner: Pubkey,
pub count: u64,
}
// The transaction MUST list 'counter' and 'owner' accounts in advance.
// Solana's scheduler reads this list and parallelizes non-conflicting txs.