Lecture 05 · Platform Layer

L05: Ethereum & Smart Contracts

Technical Deep Dive

From Turing-complete vision to live EVM opcodes: how Ethereum extends blockchain into a programmable world computer, why gas exists, what the account model gains over UTXOs, and how EIP-1559 and The Merge reshaped Ethereum’s economics and security model.

Level: BSc Year 2 Prerequisites: L03 Bitcoin, L04 Consensus Slides: 39 full deck Sections: 8 Charts: 22

WHY

The Vision: From Digital Cash to World Computer

Bitcoin proved one thing beyond reasonable doubt: you can transfer value between strangers without any bank or clearinghouse in the middle. That is a significant achievement. But Vitalik Buterin, reading the Bitcoin whitepaper in 2011 at age 17, saw a narrower tool than its reputation suggested. Bitcoin’s scripting language — called Script — is deliberately limited. It can express simple conditions like “release this coin if signature X is provided,” but it cannot loop, cannot store state between transactions, and cannot implement anything resembling a general agreement.

Buterin’s 2013 whitepaper proposed a different question: what if the blockchain were not just a payment ledger, but a general-purpose programmable platform? Any computation expressible as a program should be expressible as a contract on a shared, censorship-resistant, globally replicated virtual machine. The result, launched on 30 July 2015 as the “Frontier” release, was Ethereum.

The Ethereum thesis in one sentence: Replace institutional trust not just for payments, but for any agreement — lending, trading, voting, identity, insurance — by encoding the agreement as self-executing code that runs identically on thousands of nodes worldwide, with no single party able to halt or alter it.

The practical leap from Bitcoin to Ethereum rests on three design decisions. First, Turing completeness: the Ethereum Virtual Machine (EVM) can execute any algorithm, given enough gas. Loops, conditionals, dynamic data structures — all supported. Second, account-based state: the blockchain tracks the current state of every account rather than just a chain of transactions. Third, gas metering: every EVM instruction carries a fixed gas cost, preventing infinite loops and compensating validators for their computational resources.

The result, a decade later, is a platform that hosts over \$100 billion in locked value across DeFi protocols, the vast majority of the world’s NFT activity, hundreds of DAOs governing billions in treasury assets, and thousands of ERC-20 tokens — all running on the same virtual machine without requiring any operator to be trusted.

Fig 5.1 — Ethereum vs Bitcoin across key technical dimensions: purpose, state model, scripting, block time, supply, and consensus

Fig 5.2 — The Ethereum ecosystem: DeFi, NFTs, DAOs, and Layer 2 networks all sharing one execution layer

WHAT

The Account Model: State, Nonces, and Two Account Types

Bitcoin’s UTXO model treats the blockchain as a set of unspent coins: your “balance” is the sum of all output coins locked to your address, and spending means destroying those outputs and creating new ones. It is elegant, stateless, and privacy-friendly (you can use a fresh address per transaction). But it makes complex programming extraordinarily awkward — a contract that needs to remember state between calls has no natural home in a UTXO model.

Ethereum chose the account model instead. The world state is a mapping from 160-bit addresses to account records. Every account — whether controlled by a human or by code — has four fields stored in Ethereum’s global state trie.

Field	Type	EOA (human wallet)	Contract Account
nonce	uint256	Transactions sent from this address (prevents replay)	Number of contracts this contract has created
balance	uint256 (wei)	ETH held; 1 ETH = 10¹⁸ wei	ETH held by the contract (e.g., an escrow)
codeHash	bytes32	Hash of empty string — EOAs have no code	Keccak-256 of the deployed EVM bytecode (immutable)
storageRoot	bytes32	Hash of empty trie — no storage	Root of the per-contract storage trie (all variables)

There are exactly two account types in Ethereum. An Externally Owned Account (EOA) is controlled by a private key — your MetaMask wallet is an EOA. It has balance and nonce, but no code and no storage. Any transaction on Ethereum must be initiated by an EOA. A Contract Account is controlled by its deployed bytecode. It cannot initiate transactions; it only responds to calls. It has all four fields populated, including a storage trie that persists contract variables (token balances, proposal states, lending positions) indefinitely.

Key rule: Every transaction on Ethereum originates from an EOA, even if it subsequently triggers a cascade of contract-to-contract calls. Contracts cannot schedule their own execution; they are passive until called.

The nonce field deserves special attention. For EOAs, the nonce is a transaction counter that increments with each outgoing transaction. Ethereum nodes reject any transaction whose nonce is not exactly one higher than the account’s current nonce. This prevents replay attacks — an adversary who captures a signed transaction cannot resubmit it because the nonce would already be consumed. It also means transactions from the same account are strictly ordered, unlike Bitcoin UTXOs which can be spent in any order.

Fig 5.3 — EOA vs contract account: fields, control mechanism, and interaction patterns

Account Abstraction (ERC-4337): The strict EOA/contract distinction is being blurred by account abstraction, introduced in 2023. ERC-4337 allows smart contract wallets to sponsor gas for users, implement custom signature schemes (e.g., biometrics), and support social recovery — combining the programmability of contracts with the user-facing simplicity of traditional wallets. Safe (formerly Gnosis Safe) and Argent are leading implementations.

Fig 5.4 — Feature comparison between EOA and contract accounts: security model, gas payment, upgradability, and programmability

HOW

The EVM: Stack Machine, Opcodes, and Gas Metering

The Ethereum Virtual Machine is the runtime environment in which all smart contract code executes. Every full node on the Ethereum network runs an identical copy of the EVM and executes every transaction against it. Because execution is deterministic — the same inputs always produce the same outputs — all honest nodes agree on the resulting state without trusting each other. This is the core technical guarantee that makes smart contracts “trustless.”

The EVM is a stack-based virtual machine with a word size of 256 bits (32 bytes). This unusually large word size was chosen to accommodate 256-bit cryptographic hashes and Ethereum addresses natively without awkward casting. The stack can hold up to 1,024 items; a stack overflow aborts execution and reverts all state changes. Alongside the stack, the EVM provides three memory regions:

Stack: Last-in, first-out; 256-bit words; up to 1,024 items; wiped after each call.
Memory: Byte-addressable, linear; grows on demand; wiped after each call. Expansion cost increases quadratically to prevent unbounded allocation.
Storage: 256-bit key to 256-bit value mapping; persists between calls; most expensive by far. This is where contract state lives.

EVM execution is gas-metered. Every opcode has a fixed gas cost reflecting its computational and storage burden. The two most important cost categories are arithmetic (cheap: ADD costs 3 gas) and storage (expensive: SSTORE to a new slot costs 20,000 gas — 6,600x more expensive than an addition). This steep cost gradient was deliberately designed to discourage state bloat: unnecessary on-chain storage accumulates forever and burdens every future node that must hold the state.

Fig 5.5 — EVM stack-based architecture: opcode execution cycle, memory regions, and gas accounting

Gas formula: Total fee = gasUsed × (baseFee + priorityFee). A simple ETH transfer consumes exactly 21,000 gas (the base transaction cost). A Uniswap token swap typically uses 100,000–200,000 gas. A complex DeFi interaction touching many storage slots can exceed 500,000 gas.

Fig 5.6 — Gas costs for common EVM opcodes grouped by category — storage dominates; arithmetic is essentially free by comparison

Why does the EVM exist at all, rather than running native machine code? Three reasons. First, portability: nodes run on Linux, macOS, Windows, ARM, and x86. The EVM abstracts over all hardware. Second, metering: native execution cannot be metered without OS-level instrumentation; the EVM meters every instruction by definition. Third, isolation: contract code runs in a sandbox with no file system access, no network calls, and no access to external randomness. Any contract that needs external data must call an oracle that posts that data as an on-chain transaction first.

Fig 5.7 — EVM stack operations illustrated: how PUSH, ADD, SSTORE, and CALL opcodes manipulate the stack and modify world state

HOW

EIP-1559: The Fee Market Revolution and ETH Burn

Before August 2021, Ethereum used a first-price auction for gas. Users submitted bids (“I will pay up to X gwei per gas unit”) and block producers included the highest bidders. This mechanism had three pathological properties. Users overbid systematically because underbidding meant waiting indefinitely during congestion. Fee volatility was extreme — the same transaction might cost \$0.50 at 2am and \$200 during a popular NFT mint twelve hours later. And the auction mechanism made Maximal Extractable Value (MEV) strategies by miners straightforward, since they could reorder transactions to maximize extracted value.

EIP-1559, activated in the London hard fork on 5 August 2021, replaced this with a two-component model that has become one of Ethereum’s most consequential design decisions.

Base fee (burned): Set algorithmically by the protocol based on previous block utilization. Target is 50% of the 30M gas limit (15M gas per block). If the previous block used more than 15M gas, the base fee increases by up to 12.5%. If it used less, the base fee decreases by up to 12.5%. The base fee is destroyed — it leaves circulation permanently. No validator receives it.

Priority fee / tip (paid to validators): A user-chosen tip that incentivizes validators to include the transaction in the next block rather than a later one. During quiet periods, a 1 gwei tip suffices. During high congestion, users competing for inclusion bid up the tip. This is the only fee component validators receive directly.

Fig 5.8 — EIP-1559 base fee adjustment over time responding to block utilization above and below the 50% target

The economic implications of the base-fee burn are significant. On days of high network activity, more ETH is burned than is issued as staking rewards — making ETH net deflationary. Since the London fork, over 4 million ETH has been burned, representing billions of dollars removed from circulation. This mechanism aligns validator incentives (earn tips) with network health (high usage means more burning, which benefits all ETH holders by increasing scarcity). Critics note that burning does not directly fund protocol development; that resource allocation happens through governance.

Worked example: You want to swap tokens on Uniswap. Base fee = 25 gwei. You set a priority fee of 2 gwei. The swap uses 150,000 gas.
• Total fee: 150,000 × (25 + 2) = 4,050,000 gwei = 0.00405 ETH
• Burned (base fee): 150,000 × 25 = 0.00375 ETH
• Validator tip: 150,000 × 2 = 0.0003 ETH
Of your \$8.10 fee at ETH = \$2,000, \$7.50 is permanently destroyed and \$0.60 goes to the validator.

Fig 5.9 — ETH issuance vs burn over time: the post-Merge, post-EIP-1559 era where net issuance can turn negative during high activity

WHAT

World State: Merkle Patricia Tries and Storage Layout

Ethereum must track the state of hundreds of millions of accounts and thousands of contract storage mappings efficiently. It must also allow light clients — nodes that do not download the entire chain — to verify that a specific account state or storage value is authentic without trusting any server. The data structure that serves both requirements is the Modified Merkle Patricia Trie (MPT).

A Merkle Patricia Trie is a key-value store where the keys are paths through the trie and each internal node is identified by the hash of its children. The root hash commits to the entire trie: changing any leaf changes all hashes on the path to the root, producing a different state root. This means the single 32-byte stateRoot in a block header is a cryptographic fingerprint of all 400 million+ account states at that block height.

Ethereum maintains four separate tries per block:

State trie: Maps address → (nonce, balance, codeHash, storageRoot) for all accounts.
Storage trie (one per contract): Maps 256-bit slot key → 256-bit value for each contract’s variables.
Transaction trie: Ordered list of all transactions in the block.
Receipt trie: Execution receipts (gas used, logs, status) for each transaction.

Light client proofs: To prove that account 0xABCD has balance 5 ETH at block 19,000,000, a light client requests a Merkle proof from a full node. The proof is an O(log n) sequence of hashes from the leaf to the state root. The client verifies the proof locally in microseconds — without trusting the full node and without downloading the entire state.

Fig 5.10 — Modified Merkle Patricia Trie structure: branch nodes, extension nodes, and leaf nodes in Ethereum’s state encoding

Within a contract’s storage trie, variables are assigned storage slots numbered from 0. The Solidity compiler assigns fixed-size variables in declaration order. Two uint128 variables occupy one 32-byte slot (slot packing). Dynamic types use derived slot addresses: a mapping balances at slot 3 stores the value for key k at keccak256(k, 3). This deterministic layout is why upgrading a contract via a proxy pattern requires extreme care — if the new implementation has a different variable declaration order, it will read the wrong slot and produce corrupted state.

Fig 5.11 — Solidity storage slot layout: fixed-size packing, dynamic type slot derivation, and the cost implications of cold vs hot access

Fig 5.12 — Merkle Patricia Trie proof path: how O(log n) hashes suffice to verify any account state against the block header’s stateRoot

CASE

Smart Contracts: Lifecycle, Deployment, and Anatomy

A smart contract is a program whose bytecode is stored on-chain and whose execution is triggered by transactions. The word “smart” is a slight misnomer: contracts are not intelligent — they are extremely literal. They execute exactly what their bytecode specifies, nothing more and nothing less. This literalism is both the source of their power (no counterparty can deviate from the agreed terms) and their vulnerability (bugs are exploitable as intended behavior).

The deployment process has five steps. First, a developer writes Solidity (or Vyper) and compiles it to EVM bytecode. The compiler produces two artifacts: init code (constructor logic) and runtime bytecode (the deployed contract). Second, the developer sends a transaction with the to field empty (null) and the init code in the data field. Third, the EVM executes the init code, which runs the constructor and returns the runtime bytecode. Fourth, the EVM stores the runtime bytecode at a newly computed address. Fifth, the address is determined by keccak256(deployer_address, nonce) for CREATE, or keccak256(0xff, deployer, salt, codeHash) for CREATE2 (which enables deterministic, pre-computable addresses).

After deployment, the code is immutable. The codeHash field is set at deployment and cannot change. This is what “code is law” means in practice: once a contract is deployed, its logic is frozen. Upgradability requires the proxy pattern — a minimal proxy contract stores the address of a separate implementation contract; calls are forwarded to the implementation via delegatecall. The proxy can be updated to point to a new implementation, but this reintroduces a trusted administrator who controls the upgrade.

Fig 5.13 — Smart contract lifecycle: from Solidity source to deployed bytecode, calls, state transitions, and optional SELFDESTRUCT

Fig 5.14 — Anatomy of a deployed contract: ABI, selector dispatch, function logic, event emission, and storage interaction

A transaction that calls a deployed contract specifies the function selector in its data field — the first 4 bytes of the Keccak-256 hash of the function signature (e.g., transfer(address,uint256) becomes 0xa9059cbb). The contract’s dispatcher checks this selector and jumps to the matching function’s code. Arguments are ABI-encoded in the remaining bytes. Events emitted by contracts are stored in transaction receipts as logs, accessible to off-chain applications via eth_getLogs but not from within other contracts during execution.

// Minimal ERC-20 transfer in Solidity -- what the EVM actually executes
function transfer(address to, uint256 amount) external returns (bool) {
    // Checks (reads are cheap: SLOAD = 2,100 gas cold, 100 gas warm)
    require(balances[msg.sender] >= amount, "Insufficient balance");
    // Effects (writes are expensive: SSTORE = 5,000 or 20,000 gas)
    balances[msg.sender] -= amount;
    balances[to] += amount;
    // Interactions (emit event: stored in receipt, not state)
    emit Transfer(msg.sender, to, amount);
    return true;
}

The pattern above — Checks, Effects, Interactions (CEI) — is the canonical defense against reentrancy attacks. By updating state (Effects) before making external calls (Interactions), the contract prevents recursive re-entry from draining more than the caller’s balance. The DAO hack of 2016, which drained \$60 million, was caused precisely by violating this ordering.

Fig 5.15 — Ethereum transaction types: legacy (Type 0), access list (Type 1, EIP-2930), and EIP-1559 (Type 2) — Type 2 is now the default

RISK

Vulnerabilities: What the EVM Cannot Protect You From

Ethereum’s EVM guarantees that contracts execute exactly as written. This guarantee cuts both ways: correct code runs correctly, and buggy code runs buggily, with no possibility of a patch after deployment. The immutability that makes smart contracts trustworthy is the same property that makes smart contract bugs catastrophic. Understanding the most common vulnerability classes is not optional for anyone writing or auditing contracts.

The DAO Hack (June 2016) — The Canonical Case Study: The DAO raised \$150 million from 11,000 investors. An attacker discovered that its withdraw function sent ETH to the caller before updating the balance. The attacker deployed a malicious contract whose fallback function recursively called withdraw again before the balance was decremented — draining \$60 million in a reentrancy loop. The Ethereum community hard-forked the chain to reverse the theft, creating Ethereum Classic (ETC) as the dissenting minority. Every withdraw function written since uses Checks-Effects-Interactions or a reentrancy guard to prevent this class of attack.

🔄

Reentrancy

External call re-enters the contract before state is updated. Drain: send ETH, re-enter, repeat. Fix: update state before external calls (CEI pattern) or use a mutex lock.

📈

Oracle Manipulation

Price oracles based on spot DEX prices can be manipulated within one block using flash loans. A \$1B flash loan can move a thin market, manipulate the oracle, and profit, all atomically. Fix: use time-weighted average price (TWAP) oracles.

⚡

Integer Overflow

Solidity prior to 0.8.0 did not revert on arithmetic overflow. Adding 1 to the maximum uint256 wrapped to zero. Fix: Solidity 0.8+ has built-in overflow protection; older code used SafeMath libraries.

🔑

Access Control

Functions that should only be callable by the owner or governance are left public by mistake. Accounted for a large fraction of 2022 DeFi hacks. Fix: onlyOwner modifiers, role-based access control.

📋

Flash Loan Attacks

Uncollateralized loans of any size within one atomic transaction. Used to amplify oracle manipulation, governance attacks, and liquidity exploits. Flash loans are not inherently malicious but weaponize previously impractical attack scales.

🔒

Proxy Storage Collision

When an upgradeable proxy and its implementation use the same storage slots for different purposes, writes collide and corrupt state. Fix: EIP-1967 standardized proxy storage slots at specific hash-derived positions.

Mitigation strategies form a defense-in-depth stack: automated static analysis (Slither, MythX) catches common patterns; manual audits by specialist firms (Trail of Bits, OpenZeppelin) catch logical flaws; formal verification (Certora Prover) mathematically proves invariants; economic audits assess incentive structures; bug bounties crowdsource ongoing monitoring. Even with all of these, DeFi lost over \$3.8 billion to exploits in 2022 alone — demonstrating that smart contract security remains an unsolved engineering problem rather than a checklist exercise.

Fig 5.16 — Post-Merge Ethereum block structure: execution payload, beacon chain integration, withdrawals, and the four state roots committed in each header

WHERE

The Merge and Roadmap: PoS, Surge, Verge, Purge

On 15 September 2022 at 06:42:42 UTC, Ethereum’s consensus mechanism switched from Proof of Work to Proof of Stake in an event called The Merge. The execution layer (the EVM, transactions, smart contracts) continued running unchanged. The consensus layer (block proposal, finality, slashing) switched from mining to a validator set of over 900,000 accounts each staking 32 ETH. From the outside, the only observable differences were: block time became a fixed 12 seconds (vs Bitcoin’s variable ~10 minutes), energy consumption dropped by 99.95%, and ETH issuance fell by roughly 88%.

What changed in The Merge:
• Consensus: Proof of Work → Proof of Stake
• Block time: variable → fixed 12 seconds
• Energy: ~100 TWh/yr → ~0.01 TWh/yr (comparable to a large office building)
• Issuance: ~13,000 ETH/day → ~1,700 ETH/day
• Block proposer: mining pool → randomly selected validator

What did NOT change in The Merge:
• EVM execution model (all contracts run unchanged)
• Transaction format (EIP-1559 still applies)
• Smart contract compatibility (no migration required)
• Account model and storage layout
• Base fee burn mechanism

Fig 5.17 — Ethereum development roadmap: The Merge, The Surge, The Verge, The Purge, and The Splurge — a multi-year scaling and simplification plan

Ethereum’s roadmap beyond The Merge comprises four phases, each named with characteristic alliteration. The Surge targets 100,000+ TPS by combining data availability sampling (EIP-4844 “proto-danksharding,” already live) with full danksharding, which distributes large blobs of rollup data across the validator set. EIP-4844, activated in March 2024, immediately reduced Layer 2 transaction costs by 10–100x by introducing a separate, cheaper data lane for rollups. The Verge replaces Merkle Patricia Tries with Verkle trees — a cryptographic data structure with much smaller proofs (a few kilobytes vs tens of kilobytes) that enables stateless clients to validate blocks without storing the entire state. The Purge removes historical data obligations from nodes, allowing nodes to prune data older than one year, dramatically reducing node storage requirements. The Splurge is the catch-all for improvements that do not fit the other categories, including EVM Object Format (EOF), which reorganises the bytecode structure for better performance and security.

The Layer 2 thesis: Ethereum’s base layer is not trying to be the cheapest or fastest execution environment — it is trying to be the most secure and decentralized settlement layer. Rollups (Optimism, Arbitrum, Base, zkSync, Scroll) execute transactions off-chain and post compressed proofs or data to Ethereum’s base layer, inheriting its security at a fraction of the cost. This modular architecture separates execution from settlement, and it is already processing over 10x the transaction volume of Ethereum’s base layer at 10–100x lower fees.

Fig 5.18 — Ethereum network statistics: validator count, ETH staked, total ETH burned, Layer 2 TVL, and daily transaction volume over time

Roadmap Phase	Key Upgrade	Primary Benefit	Status (2024)
The Merge	PoS consensus via Beacon Chain	99.95% energy reduction; fixed 12s blocks	Complete (Sep 2022)
The Surge	EIP-4844 proto-danksharding	L2 data costs reduced 10–100x	EIP-4844 live (Mar 2024)
The Surge	Full danksharding	100,000+ TPS with L2s; data availability sampling	In research
The Verge	Verkle trees replacing MPT	Stateless clients; smaller proofs	In development
The Purge	History expiry (EIP-4444)	Nodes can prune old data; lower hardware requirements	In research
The Splurge	EVM Object Format (EOF)	Safer, more analysable bytecode structure	Scheduled

Fig 5.19 — The Ethereum ecosystem in 2024: a layered architecture from Beacon Chain consensus through the EVM execution layer to L2 rollups and application protocols

The central lesson of Ethereum’s evolution is that the design choices made at launch — account model, Turing completeness, gas metering, the state trie — were not arbitrary. They reflect a coherent philosophy about what a programmable blockchain requires. The ongoing roadmap is not abandoning that philosophy; it is engineering around its inherent scaling constraints by separating the functions of execution, consensus, and data availability into distinct layers. Understanding that layered architecture — EVM on top, Beacon Chain below, rollups alongside — is the prerequisite for understanding every subsequent lecture in this course, from DeFi protocols to token standards to governance systems.

Download Slides & Resources

📄 5-Slide Teaser Executive summary 📄 10-Slide Standalone Self-contained overview 📄 Full Lecture (39 slides) Complete lecture deck 📄 Core Slides 10-slide summary 📄 Extended Slides Full detail version

Take the Quiz → View Slide Gallery Back to Course Overview