Section I: Core Concepts
Chapter I introduced Bitcoin's breakthrough: digital scarcity without centralized control. Ethereum extends this concept by making computation itself programmable and decentralized.
This shift unlocked possibilities that didn't exist before. Decentralized exchanges let people trade tokens without intermediaries. Lending protocols let users earn interest or borrow money using only programs called smart contracts. NFT marketplaces create new forms of digital ownership. Notably, these applications work together seamlessly. A lending protocol can automatically interact with an exchange, creating financial products that emerge organically from the platform itself.
But power requires complexity. Bitcoin prioritized simplicity and security above all else. Ethereum chose a different path. It replaced Bitcoin's straightforward transaction model with an account system that tracks complex application state. It developed a dynamic fee system to manage computational resources. It underwent a technical transition from proof-of-work to proof-of-stake. And it spawned an entire ecosystem of scaling solutions to handle real-world usage.
Understanding Ethereum means grasping how these pieces fit together: how the fee system incentivizes efficient resource use, how proof-of-stake secures the network, and how Layer 2 solutions make the platform practical for everyday applications. This chapter will guide readers through these core mechanics, showing the engineering decisions that power today's significant experiment in decentralized computation.
The Ethereum Virtual Machine
At Ethereum's core lies the Ethereum Virtual Machine (EVM), a computational engine that executes code across thousands of computers (called nodes) simultaneously. Unlike Bitcoin, which primarily transfers value, Ethereum runs smart contracts, transforming the network from a simple payment system into a programmable "world computer."
The EVM operates as a stack-based virtual machine, processing instructions like a stack of plates where you can only add or remove from the top. It uses low-level instructions called opcodes. These include operations like ADD, MULTIPLY, STORE, and CALL. When developers write smart contracts in high-level languages like Solidity or Vyper, compilers translate that code into EVM bytecode (a series of opcodes) that every Ethereum node can execute. This standardization ensures contracts behave identically whether running in New York, Singapore, or Dubai.
What distinguishes the EVM is its combination of deterministic execution with persistent state management. Every smart contract maintains its own storage space where it saves data between transactions. When someone interacts with a contract, like swapping tokens on Uniswap or borrowing from Aave, the EVM executes the relevant bytecode, reads and writes to storage, and updates account balances. Every node independently performs these same computations and verifies they reach identical final states. This process creates decentralized consensus: Ethereum becomes trustworthy without requiring trust in any single party, since thousands of independently run nodes all verify the same results.
Each operation consumes gas, a fee measured in computational work. Gas serves two critical purposes: it compensates node operators for executing computations and prevents spam by making every operation cost something. More complex operations require more gas, which explains why simple transfers cost less than deploying intricate smart contracts. This metering ensures no transaction runs indefinitely, mitigating resource-exhaustion attacks.
The gas mechanism aims to price operations roughly in line with their actual resource usage. Early attacks exploited underpriced operations, prompting Ethereum to adjust opcode costs over time. These adjustments increased prices for operations that proved too cheap relative to their computational demands, reducing opportunities for denial-of-service attacks and better reflecting underlying resource costs.
The EVM has evolved into a de facto standard extending far beyond Ethereum itself. Most rollups (Arbitrum, Optimism, Base) and many alternative L1s have adopted EVM compatibility, meaning they execute the same bytecode. This compatibility creates enormous value: applications like Uniswap and Aave deploy to these networks with minimal changes, while the entire infrastructure ecosystem (wallets like MetaMask, block explorers, developer tools, indexers) functions almost identically across EVM chains. New blockchains can bootstrap activity by inheriting Ethereum's mature tooling and attracting existing users and developers without requiring them to learn new paradigms. These network effects reinforce Ethereum's dominance.
This computational model explains Ethereum's scaling challenges. Since every full node replays every transaction in order, Ethereum functions as a globally replicated computer. Protocol parameters like gas limits and block times must remain conservative enough for ordinary machines to keep up. Pushing more computation on-chain risks raising hardware requirements and eroding the decentralization that makes the network secure.
Rollups and other scaling solutions address this constraint by moving most execution off Ethereum while using the base layer primarily for data availability and final settlement. They batch many off-chain transactions together, posting only compressed data and (in some designs) validity proofs back to Ethereum. This allows many users to share the gas cost of a single L1 transaction, dramatically lowering fees and increasing effective throughput while still inheriting Ethereum's security.
Understanding the EVM reveals both Ethereum's power (arbitrary programmable logic secured by neutral consensus) and its limitations. The base layer remains a fully replicated machine where every computation is verified everywhere, making raw throughput fundamentally scarce. Higher scale must therefore come from layering and smarter use of that scarce resource.
Ethereum's Fee System
We've seen how the EVM measures computational work in gas. Now let's examine how Ethereum's fee system actually prices that gas and how it evolved to become more user-friendly.
Gas powers Ethereum's computational engine like fuel powers a car. Every operation, from sending ETH to a friend to executing a complex smart contract, consumes a specific amount of this computational fuel. A simple ETH transfer between regular wallets burns through 21,000 units of gas, while interacting with smart contracts requires proportionally more. Swapping tokens on Uniswap might use 150,000 gas, while deploying a new smart contract could consume millions.
When discussing fees, Ethereum users work with specific denominations (unit sizes). While wei represents the smallest possible unit of ether (1 ETH equals 1,000,000,000,000,000,000 wei), fee discussions typically happen in gwei (1 gwei equals 1,000,000,000 wei, or one billionth of an ether). This makes gas prices easier to discuss. Instead of saying "the gas price is 50,000,000,000 wei," people say "50 gwei."
A key development came with EIP-1559, which radically transformed Ethereum's protocol-level fee market. Before this August 2021 upgrade, users participated in a chaotic auction system, constantly trying to outbid each other for block space: you guessed a single gas price and hoped it was neither too low nor unnecessarily high. EIP-1559 introduced a new, more predictable default fee mechanism with two components: a dynamically adjusting base fee and a user-set tip. Most modern wallets use this mechanism by default. Legacy type-0 "gasPrice" transactions are still supported and behave more like the old auction, so the extra predictability is available but not strictly mandatory for all transactions.
Users set maxFeePerGas (the absolute maximum they'll pay per unit of gas) and maxPriorityFeePerGas (an optional tip to validators for faster inclusion) when submitting transactions. The actual gas price paid is calculated as the minimum of either your maximum fee or the sum of the base fee plus your priority fee. The total transaction cost equals the gas used multiplied by this effective gas price.
Each Ethereum block has a gas limit that defines its capacity: a maximum amount of gas that all transactions in that block can collectively consume. Since EIP-1559, the protocol targets using about half of that limit in each block and treats this target as “100% full” for pricing purposes. When demand spikes, blocks can temporarily expand up to roughly twice the target (up to the gas limit itself), creating so-called elastic blocks.
Historically, Ethereum used a 30 million gas limit (with a 15 million gas target). Since 2024-2025, validators have gradually raised this to around 45 million, and Fusaka’s EIP-7935 standardizes a 60 million default gas limit per block in client configs. The important rule remains the same: the target gas usage is always half the current gas limit, and blocks can stretch up to roughly twice that target during congestion.
The base fee is set algorithmically based on network congestion. When blocks use more than the target amount of gas (more than half the gas limit), the base fee rises by up to 12.5% in the next block. When they use less than the target, it falls by up to the same amount. High demand automatically increases prices; low demand decreases them through this self-balancing mechanism.
The most significant innovation is what happens to fees. Of the total fee paid, the portion covering the base fee (gas used multiplied by the base fee) gets burned, meaning it is destroyed forever and removed from circulation, introducing deflationary pressure on ETH's supply. Only the priority fee (the tip above the base fee) goes to validators. Any unused portion of your maxFeePerGas is refunded, not paid out. This gives users a way to incentivize faster inclusion during busy periods by offering higher tips without permanently overpaying for gas.
During periods of sustained demand, the base fee burn can exceed new ETH issuance from staking rewards, making the overall supply net deflationary (shrinking rather than growing). Higher network usage increases the burn rate, tightening supply and potentially supporting ETH's value. Since The Merge in September 2022, there have been extended periods where ETH supply has been deflationary. However, upgrades like Dencun and EIP-4844 also made L1 gas cheaper, which in turn reduced fee burn. Since 2024 there have been periods where ETH supply has turned net inflationary again despite the burn mechanism.
EIP-1559 reduced fee volatility and dramatically improved user experience by making fees more predictable. Users can set reasonable max fees without worrying about overpaying, and wallets can estimate costs more accurately. Importantly, this change modified how fees work without altering Ethereum's consensus mechanism (the system went through this upgrade during proof-of-work and kept it after transitioning to proof-of-stake). The upgrade introduced new validation rules that all nodes must enforce, including the base fee calculation algorithm and the burning mechanism. However, it didn't address all fee market concerns. Issues like transaction censorship (validators choosing to exclude certain transactions) remain active areas of research, with proposals like inclusion lists (rules forcing validators to include certain transactions) still being developed.
How Ethereum Identifies Accounts and Assets
While understanding gas helps users manage transaction costs, knowing how Ethereum identifies accounts and assets is equally important for navigating the ecosystem effectively.
Ethereum's account model differs fundamentally from Bitcoin's UTXO model (explained in Chapter I). Bitcoin tracks ownership through chains of unspent transaction outputs that must be consumed and recreated with each transfer. Ethereum maintains persistent accounts with balances that get updated directly. Think of it like the difference between using cash (UTXOs that get exchanged) versus a bank account (a balance that increases and decreases). This architectural choice enables the complex state management that smart contracts require, allowing contracts to store data and maintain balances across multiple transactions without the complexity of tracking individual UTXOs.
Ethereum has two types of accounts. Externally Owned Accounts (EOAs) are regular user wallets controlled by private keys (like hot wallets or hardware wallets). Smart contract accounts are programmable accounts that execute code when triggered. Every participant in Ethereum (whether a person or a smart contract) has a unique address that serves as their public identifier.
These addresses look like cryptographic gibberish: a 40 character string of numbers and letters such as 0x742d35Cc6634C0532925a3b844Bc454e4438f44e. Behind this seemingly random sequence lies mathematics. For EOAs, the address represents the last 20 bytes of a cryptographic hash (a one-way mathematical function) of the account's public key. The public key is derived from your private key, so your address is mathematically linked to your key without revealing it.
The Ethereum Name Service (ENS) addresses this usability challenge by allowing users to register human-readable names like alice.eth that resolve to these hexadecimal addresses. This naming system works similarly to DNS for websites, making it easier to send funds and interact with accounts without copying and pasting long strings of characters.
Smart contracts also receive addresses when they're deployed, generated deterministically from the deployer's address and other parameters.
This distinction between EOAs and smart contracts is beginning to blur. Account abstraction proposals like EIP-7702 (introduced in Pectra) allow EOAs to temporarily delegate control to smart contract code, enabling features like sponsored transactions, batch operations, and improved key recovery without requiring users to migrate to entirely new account types.
With accounts and addresses established, Ethereum's next key development was creating standards that allowed different applications to work together effectively. The most important example is the ERC-20 token standard, which created a universal language for digital assets.
Before ERC-20, every new token was essentially a unique snowflake, requiring custom code for wallets and exchanges to support it. ERC-20 changed this by establishing a common blueprint: every compliant token must implement the same basic functions like transfer(), approve(), and balanceOf(). This seemingly simple standardization unleashed what many call the "Cambrian explosion" of DeFi.
Suddenly, developers could build applications that worked with thousands of different tokens without writing custom code for each one. A decentralized exchange could list any ERC-20 token, a lending protocol could accept any ERC-20 as collateral, and users could seamlessly move assets between different applications. This composability (the ability for different protocols to work together like Lego blocks) became one of Ethereum's defining characteristics, enabling complex multi-step operations that either complete entirely or revert with no partial execution. Chapter VII explores these DeFi applications in detail.
The ecosystem continued to evolve with additional standards: ERC-721 and ERC-1155 for NFTs (which Chapter XI explores), and various other token standards that extended Ethereum's capabilities. But all of this (the EVM, the fee market, the account system, the token standards) depends on thousands of validators agreeing on the state of the network. Ethereum's approach to achieving that agreement transformed fundamentally in 2022.