1. Overview and mental model

Before learning Solana’s performance techniques, learn what the system is doing. In this chapter, you will follow one transfer and attach every new term to that story.

The problem a blockchain solves

Alice and Bob can update a shared spreadsheet, but whoever owns the spreadsheet can rewrite the history. A public blockchain replaces one trusted database operator with a network that follows common verification and consensus rules.

Solana maintains a replicated state. Each validator can independently check the same transaction and compute the same result.

old account state + valid transaction = new account state

A transaction is valid only when the required signatures, balances, account permissions, freshness rules, fees, compute limits, and program rules all pass.

First definition

Solana is a public, programmable state machine replicated by validators. SOL is the native asset used inside that state machine. Solana and SOL are related, but they are not the same thing.

Follow a 0.1 SOL transfer

Suppose Alice wants to send 0.1 SOL to Bob.

Step 1: A client expresses the intent

A wallet or application creates a System Program transfer instruction. The instruction says, in effect:

Program: System Program
From: Alice's account, writable and signer
To: Bob's account, writable
Amount: 100,000,000 lamports

One SOL equals one billion lamports, so 0.1 SOL is represented as 100,000,000 integer lamports.

Step 2: The instruction enters a transaction

The wallet places the instruction inside a transaction message. The message also contains account addresses and a recent blockhash that limits how long the transaction remains usable.

Step 3: Alice authorizes the message

Alice’s wallet signs the exact message. If the destination, amount, or blockhash changes afterwards, the signature no longer verifies.

Step 4: The transaction reaches the network

An RPC endpoint accepts the signed transaction and forwards it. RPC submission is not final settlement. The application must track the transaction signature and confirmation status.

Step 5: The runtime executes it

The scheduled leader loads the named accounts. The runtime verifies Alice’s signature, locks writable accounts, charges the fee, and invokes the System Program. If every rule passes, Alice’s lamports decrease and Bob’s increase.

Step 6: Validators agree on history

Other validators replay the ledger entries and vote. As votes accumulate, the transaction gains stronger commitment.

Meet the seven objects

Account: where state lives

An account stores lamports and bytes. A wallet-controlled system account is only one kind of account. Programs, user profiles, token mints, and token balances also use accounts.

Program: the rules

A program contains executable logic. Solana programs keep mutable application state in separate data accounts. Think program equals rules, account equals data.

Instruction: one requested action

An instruction names one program, the accounts supplied to it, and input data. A transfer, mint, vote, or profile update is represented by one or more instructions.

Transaction: an atomic envelope

A transaction carries one or more instructions and required signatures. Atomic means all instructions succeed together or their state changes are rolled back together.

Wallet: the signing interface

A wallet manages keys and asks the user to approve signatures. A wallet is not the blockchain and is not identical to an on-chain account.

RPC node: the application doorway

RPC lets applications read accounts, simulate transactions, submit signed data, and check status. RPC nodes provide access; voting validators provide consensus participation.

Validator: execution and agreement

Validators execute transactions, maintain the ledger, produce entries when scheduled as leader, and vote on forks.

Ethereum and Solana: translate carefully

If you know Ethereum, use this translation only as a starting point:

Question	Ethereum mental model	Solana mental model
Where is code?	Contract bytecode	Program account
Where is mutable app state?	Contract storage	Separate data accounts
What requests work?	Transaction or contract call	Instruction inside a transaction
How are data dependencies found?	During execution	Accounts declared before execution
Execution resource	Gas	Compute units plus transaction fees
Common application language	Solidity	Rust, often with Anchor

The most important difference is the declared account list. Solana can see which state a transaction intends to read or write before execution. Non-conflicting work can be scheduled concurrently.

Parallelism without magic

Consider two profile updates:

Transaction A writes AliceProfile
Transaction B writes BobProfile

The accounts differ, so the runtime may execute the work concurrently. Now consider two swaps that both write one global pool account. The shared writable account creates contention even if the overall network has spare capacity.

Fast network, slow application

Solana’s architecture enables parallel execution, but an application can remove that advantage by forcing every user through one writable account.

Clusters and commitment

You will encounter four environments:

• Local validator for isolated development.
• Devnet for public testing with test SOL.
• Testnet mainly for validator and network testing.
• Mainnet Beta for production assets and applications.

You will also encounter commitment levels:

• processed means the queried node has processed the transaction.
• confirmed adds stronger cluster vote support.
• finalized gives the strongest commonly requested settlement view.

Choose based on risk. A loading animation and the release of high-value goods should not use the same settlement policy.

Check your understanding

Explain this without looking back:

A wallet signs a transaction. The transaction contains instructions. Each instruction calls a program and supplies accounts. The runtime executes the program, and validators agree on the resulting account state.

If that sentence is clear, continue to Keys, wallets, and addresses. If not, trace the 0.1 SOL transfer once more.