Key Takeaways: Ethereum Architecture — The World Computer Concept

Core Concepts

1. The Account Model Is a Fundamental Design Choice

Ethereum uses an account model where each entity (user or contract) has a persistent account with nonce, balance, storage, and code. This contrasts with Bitcoin's UTXO model and was chosen specifically to support stateful computation. The tradeoff: natural support for complex applications at the cost of reduced privacy and unbounded state growth.

2. Two Account Types, One Clear Division

Externally owned accounts (EOAs) are controlled by private keys and can initiate transactions. Contract accounts are controlled by code and can only execute when called. This separation enforces a clear distinction between authorization (who can act) and logic (what actions do). All on-chain activity originates from an EOA.

3. Ethereum Is a State Machine

The global state is a mapping from every address to its account state. Transactions are inputs to the state transition function (the EVM). Each block transforms the state from one valid configuration to the next. The state root — a single 256-bit hash in the block header — cryptographically commits to the entire global state.

4. The Merkle Patricia Trie Enables Verification

The Modified Merkle Patricia Trie stores the global state in a structure that supports efficient lookups, updates, and cryptographic proofs. Any claim about any account's state can be verified with a compact Merkle proof against the state root, enabling light clients to participate without storing the full state.

5. Gas Is an Economic Solution to a Theoretical Problem

The halting problem proves that no algorithm can determine whether an arbitrary program will halt. Gas sidesteps this by pricing every computational step. Infinite loops are not prevented by analysis — they are prevented by running out of gas. This transforms Turing completeness from a security liability into a bounded, priced capability.

6. EIP-1559 Transformed the Fee Market

The London hard fork introduced a base fee (algorithmically adjusted, burned) and a priority fee (paid to validators). This creates predictable pricing, reduces overpayment, and makes ETH potentially deflationary during high-usage periods. The base fee increases when blocks exceed 50% capacity and decreases when they are below 50%.

7. Turing Completeness Enables Everything — and Introduces Everything

Ethereum's Turing-complete EVM can express any computable function, enabling DeFi, DAOs, NFTs, and arbitrary applications. But it also makes it impossible to prove contracts are bug-free, enables new attack vectors (reentrancy, gas manipulation), and complicates security analysis. The expanded capability and expanded risk are inseparable.

8. The Merge Was a Masterclass in Distributed Systems Engineering

Transitioning a live $200B+ network from PoW to PoS without downtime required years of preparation, innovative testing (shadow forks), and extraordinary coordination. The result: 99.95% energy reduction, ~90% issuance reduction, and proof that even fundamental protocol changes can be executed safely on a running network.

9. State Growth Is the Open Challenge

Ethereum's state grows monotonically — every new account and storage slot persists until explicitly removed. With 1.4+ billion state objects and growing, the hardware requirements for full nodes continue to increase. Verkle trees, state expiry, and stateless clients are the primary research directions, but no solution has been deployed yet.

Key Formulas and Numbers

Common Mistakes to Avoid

1. Confusing gas with ETH. Gas is an abstract unit of computation. Gas price (in gwei/ETH) determines the ETH cost. A transaction always costs the same gas regardless of ETH price.

2. Thinking contracts can act autonomously. Contracts are reactive — they only execute when an EOA initiates a transaction. Scheduled or time-based actions require off-chain infrastructure (keepers/automation).

3. Assuming the account model is strictly superior to UTXO. Each model optimizes for different properties. UTXO is better for parallelism and privacy; accounts are better for stateful computation.

4. Forgetting that failed transactions still cost gas. If a transaction reverts (e.g., require statement fails, out of gas), state changes are undone but gas is still charged. The validator performed the computation.

5. Underestimating state growth's impact. State bloat is not a theoretical concern — it is a measurable, ongoing challenge that affects sync times, hardware requirements, and network decentralization today.

Connection Map

• Prerequisites: Chapter 6 (UTXO model comparison), Chapter 3 (distributed systems, consensus)
• This chapter provides foundations for: Chapter 12 (EVM deep dive), Chapter 13 (Solidity and smart contract deployment), Chapter 15 (smart contract patterns including upgradeability), Chapter 18 (account abstraction, keepers), Chapter 20 (MEV and transaction ordering), Chapter 23 (Layer 2 scaling solutions)
• Progressive project: The voting dApp state model designed here will be implemented in Solidity in Chapter 13 and deployed to a testnet in Chapter 14