Most blockchains run transactions one after another. Solana was designed to run them at the same time wherever it can. Every other choice in the system, the way state is stored, the way fees are priced, the cryptographic clock that orders the work, follows from that single decision. Picturing Solana as a world computer built for parallel execution is the mental model that makes the rest of the course land.

You already know what a blockchain is. A network of nodes that hold the same data, agree on what gets added next, and chain blocks together with hashes so nothing can be quietly changed. Solana starts from that same architecture and adds one constraint that shapes everything else: the runtime should be able to execute unrelated work in parallel.

The way to picture this: imagine a global computer where the state is broken into millions of small, independently-owned cells. Anyone can read any cell. Writing to a cell requires permission. Every transaction that wants to run on the chain has to declare up front which cells it will read and which it will write. The runtime takes those declarations, sorts the incoming transactions into groups whose cell-sets do not overlap, and runs the groups on different threads at the same time.

That is the picture worth holding. A world computer where every transaction comes with a manifest of what it touches, so the runtime never has to guess.

The cells in the picture above are called accounts. Every account has an address, a balance in lamports, which is Solana's smallest unit at one billionth of a SOL, some bytes of data, and an owner. The owner is what makes the model work. Each account is owned by exactly one program, and only that program is allowed to change the account's data. Reads are open to anyone. Writes go through the owner.

There are no separate categories the way other chains split user accounts from contract accounts. Programs are accounts too. A program is just an account whose data is executable code and whose owner is the special loader program that knows how to run it. A user's wallet is an account owned by the System Program. A token balance is an account owned by the Token Program. Everything is the same kind of object with different ownership.

Storing data on this chain costs a small ongoing fee called rent, scaled to the size of the data. In practice every account pays the rent up front by depositing enough lamports to be permanently exempt, which is what every wallet and program does without anyone thinking about it. The mechanism is there to keep dead state from piling up on the network forever.

Running code on a shared computer costs something. On Solana every transaction pays a small base fee in lamports for each signature it carries, half of which is burned and half of which goes to the validator that produces the block. The base fee is fixed, currently five thousand lamports per signature.

Computation itself is metered in compute units. Each operation a program performs costs a fixed number of compute units, and every transaction comes with a limit on how many it may consume. Hitting the limit causes the transaction to revert. The fee for execution is optional and called a priority fee, paid in micro-lamports per compute unit. Raising the price tells the leader your transaction should be scheduled ahead of competing ones. During congestion the priority fee dominates. When the network is quiet you can set it to zero and your transaction still lands.

SOL is what the fees are paid in. SOL is also what every account's rent-exempt balance is held in, and what stakers post when they help secure the network.

Anything an application can express as a program that operates on accounts. Tokens with custom rules. Decentralized exchanges that hold pools of liquidity in accounts and let traders swap between them. Lending markets, on-chain games, prediction markets, governance systems, identity records. The same surface area as any general-purpose smart-contract chain.

The thing Solana is built to do faster than most chains is to run all of those at the same time. When the runtime can schedule a swap on one DEX in parallel with a vote on a governance proposal in parallel with a token transfer between two wallets, throughput climbs. The price of that design is the rest of the course. You have to think about state differently, you have to declare your access patterns up front, and you have to be careful about what your program assumes when other transactions touched the same accounts a millisecond before yours.

Solana is one specific design for a smart-contract chain. It made one choice, parallel execution as the central goal, and the rest of the system follows. Ethereum made a different choice, a global serial computer with a simpler programming model, and got a different system. Both are valid. Both host real applications worth hundreds of millions of dollars. The patterns you learn here transfer in spirit to other parallel-execution chains like Sui, Aptos, or Sei, with adjustment, but the details will differ. When you finish this track you will be able to read a Solana program and reason about what it does. Everything else builds on that.