Section I: Architecture and Execution
Solana represents a fundamentally different approach to blockchain scaling. While Ethereum (Chapter II) and Bitcoin (Chapter I) are also Layer 1 (L1) blockchains, meaning they are base-layer networks that operate independently and settle their own transactions, Solana makes radically different engineering tradeoffs. It prioritizes raw speed and throughput over keeping hardware requirements low, betting that powerful computers will become cheaper faster than blockchain demand will grow.
Most blockchains execute transactions one at a time within blocks. When you send a transaction on Ethereum, it waits in line behind every other transaction, processed sequentially to avoid conflicts. Scaling typically happens by adding Layer 2 networks on top, as described in Chapter II. This approach keeps validator requirements modest and maximizes decentralization, but it introduces fragmentation. Users must navigate between different networks with different fee tokens, bridging experiences, and compatibility layers.
Solana takes a different path. The critical innovation is that every transaction must declare upfront which accounts it will read from or write to. This simple requirement unlocks something powerful: the network can identify transactions that don't overlap and run them simultaneously across multiple CPU cores. While Ethereum processes transactions one after another like a single checkout lane, Solana operates more like a supermarket with dozens of lanes open at once. This creates a direct relationship between hardware resources and network capacity. More CPU cores translate to higher transaction throughput.
This parallel execution model shapes Solana's data architecture. State is organized around an account model that cleanly separates program code from user data. Programs live in executable accounts whose code is effectively immutable. User-level state lives in separate data accounts owned by those programs. Composability, the ability for programs to interact with each other, is straightforward. Programs call into one another via cross-program invocations (CPIs), essentially one program asking another to perform an operation, passing accounts as inputs. The runtime can verify that all necessary accounts are included before execution begins.
Address Types and Account Management
Within this account architecture, Solana introduces a novel address type that solves a fundamental problem in decentralized systems. The network uses two distinct types of addresses that serve different purposes in the ecosystem.
Regular addresses function like traditional crypto wallets. Users control these addresses with private keys, just like Bitcoin or Ethereum wallets.
Program Derived Addresses (PDAs) represent a departure from this model. These addresses have no private keys at all. Instead, programs generate them mathematically using a combination of inputs that produce an address no one can control directly. The result is an address that only the program itself can authorize transactions from.
PDAs solve the fundamental custody problem that plagues traditional escrow systems. Traditional escrow requires someone to hold private keys, introducing inherent trust issues and potential points of failure. With PDAs, the escrow program itself controls the funds directly. No human can steal them because there is no private key to compromise.
Accounts must hold a minimum balance of lamports (Solana's smallest unit, similar to satoshis for Bitcoin) to remain rent-exempt, which prevents state bloat by requiring an economic commitment for persistent storage. In practice, this works like an upfront security deposit for using storage space rather than an ongoing subscription fee.
These execution constraints and the account model shape how users actually transact on Solana. The following section examines the transaction structure, fee mechanics, and the user experience they enable.