Exercises: Ethereum Architecture

Exercises: Ethereum Architecture

Conceptual Questions

Exercise 11.1 — Account Model vs. UTXO Model

Consider the following scenario: Alice has 10 ETH and wants to send 3 ETH to Bob and 4 ETH to Carol in two separate transactions.

(a) Describe how these two transactions would be processed under Ethereum's account model. Show Alice's nonce and balance after each transaction (assume a gas cost of 0.001 ETH per transaction for simplicity).

(b) Describe how the equivalent scenario would work under Bitcoin's UTXO model (substituting BTC for ETH). Alice has a single UTXO worth 10 BTC. How many UTXOs exist after both transactions?

(c) Now suppose both transactions are submitted simultaneously. Explain why nonce ordering matters in the account model and why the UTXO model handles simultaneous submissions differently.

(d) Which model provides better privacy in this scenario? Explain your reasoning.

Exercise 11.2 — EOA vs. Contract Account Identification

Given only the four fields of an Ethereum account state (nonce, balance, storageHash, codeHash), explain how you can determine whether an account is an EOA or a contract account. What are the specific values that distinguish them?

Exercise 11.3 — State Transitions

Consider the following initial state:

Account A (EOA): nonce=3, balance=5.0 ETH
Account B (Contract): nonce=1, balance=2.0 ETH, code=transfer_code
Account C (EOA): nonce=0, balance=0.0 ETH

Account A sends a transaction calling Account B's transfer(C, 1.5 ETH) function, which transfers 1.5 ETH from B's balance to C. The transaction uses 50,000 gas at a base fee of 20 gwei and a priority fee of 2 gwei.

(a) Calculate the total gas cost in ETH.

(b) Write out the complete state of all three accounts after the transaction succeeds.

(c) What would the state look like if the transaction reverted (e.g., Account B's code has a bug)? Would Account A still pay gas?

Exercise 11.4 — Gas Calculations

A smart contract function performs the following operations: - 3 storage reads (SLOAD): 2,100 gas each - 1 new storage write (SSTORE to empty slot): 20,000 gas - 1 storage update (SSTORE to existing slot): 5,000 gas - 15 arithmetic operations (ADD/MUL): average 4 gas each - 1 Keccak-256 hash of 64 bytes: 30 + 6 * 2 = 42 gas - Base transaction cost: 21,000 gas

(a) Calculate the total gas cost for this transaction.

(b) If the base fee is 25 gwei and the priority fee is 2 gwei, what is the total cost in ETH?

(c) If ETH is priced at $3,000, what is the USD cost of this transaction?

(d) The developer wants to reduce costs. Which operation should they optimize first, and why?

Exercise 11.5 — EIP-1559 Fee Dynamics

The current block is 50% full (using 18 million out of 36 million gas).

(a) Will the base fee increase, decrease, or stay the same for the next block? By how much?

(b) If the next three blocks are each 100% full, and the current base fee is 20 gwei, calculate the base fee after each of those three blocks (assume the maximum 12.5% increase per block).

(c) A user submits a transaction with maxFeePerGas = 30 gwei and maxPriorityFeePerGas = 3 gwei. The current base fee is 25 gwei. How much does the user actually pay per gas? How much is burned? How much goes to the validator?

(d) What happens if the base fee rises to 28 gwei before the transaction is included?

Exercise 11.6 — The Halting Problem and Gas

Explain, in your own words, why the halting problem makes gas necessary for a Turing-complete blockchain. Your answer should address:

(a) What the halting problem states and why it cannot be solved algorithmically.

(b) What would happen to the Ethereum network if gas did not exist and a malicious user deployed a contract with an infinite loop.

(c) How gas transforms the halting problem from a theoretical impossibility into a practical non-issue.

(d) Whether gas completely eliminates denial-of-service risks on Ethereum (hint: consider the cost of gas during low-fee periods).

Applied Exercises

Exercise 11.7 — State Trie Proof

Using the concepts from Section 11.4, describe (conceptually, not in code) how a light client could verify that account 0xABC... has a balance of 5 ETH without storing the entire Ethereum state. What data would the light client need to receive? What would it need to trust?

Exercise 11.8 — The Merge Timeline

Research and construct a timeline of the key milestones in Ethereum's transition from PoW to PoS, starting from the Beacon Chain launch (December 1, 2020) through the Merge (September 15, 2022). Include at least: - Beacon Chain launch date - At least two testnet merges (name the testnets) - The shadow fork testing period - The Merge date and block number - The first PoS block slot number

Exercise 11.9 — State Growth Analysis

The code/state_trie.py script demonstrates a simplified trie structure.

(a) Run the script and observe how adding accounts changes the root hash.

(b) Modify the script to add 1,000 accounts. How does the trie depth compare to a trie with 10 accounts?

(c) Based on the current growth rate of Ethereum's state (~200 million new objects per year), estimate how many state objects will exist in 2030. What are the implications for node operators?

Exercise 11.10 — Voting dApp State Model Extension

Extend the voting dApp state model from Section 11.9 to support the following additional features. For each feature, specify the new state variables, their Solidity types, and any new state transitions:

(a) Weighted voting: Different voters have different voting weights (e.g., token-weighted governance).

(b) Delegation: A voter can delegate their vote to another eligible voter.

(c) Multiple-choice proposals: Instead of yes/no, proposals can have up to 10 options.

(d) For each extension, estimate the additional gas cost per vote compared to the base model. Which extension adds the most gas overhead, and why?

Challenge Problems

Exercise 11.11 — UTXO Model for Smart Contracts

Some blockchains (notably Cardano) implement smart contracts using an extended UTXO model rather than an account model. Research the extended UTXO (eUTXO) model and write a one-page comparison addressing:

(a) How does the eUTXO model represent contract state?

(b) What is the "concurrency problem" in the eUTXO model, and how does it differ from the nonce-ordering challenge in the account model?

(c) What are the advantages of eUTXO for formal verification compared to the account model?

Exercise 11.12 — Gas Optimization Challenge

Consider a contract that stores a list of 100 addresses (a whitelist) and checks membership before allowing a function call. Two implementations are proposed:

Implementation A: Store addresses in an array and loop through to check membership.

address[] public whitelist;  // 100 addresses
function isWhitelisted(address user) public view returns (bool) {
    for (uint i = 0; i < whitelist.length; i++) {
        if (whitelist[i] == user) return true;
    }
    return false;
}

Implementation B: Store addresses in a mapping.

mapping(address => bool) public whitelist;
function isWhitelisted(address user) public view returns (bool) {
    return whitelist[user];
}

(a) Calculate the worst-case gas cost for a membership check in Implementation A (the user is not in the list, so the entire array is scanned). Assume each SLOAD costs 2,100 gas and comparison costs 3 gas.

(b) Calculate the gas cost for a membership check in Implementation B.

(c) What is the ratio of gas costs? What lesson does this teach about data structure choice on Ethereum?

(d) Is there any advantage to Implementation A over Implementation B?

Exercise 11.13 — Design Your Own State Model

Choose one of the following decentralized applications and design a complete state model, following the approach used in Section 11.9 for the voting dApp:

A decentralized crowdfunding platform (like Kickstarter)
A simple decentralized exchange for two tokens
A reputation system where users rate each other

For your chosen application, specify: 1. All account types involved (EOAs and contracts) 2. All state variables with their types 3. All state transitions (functions) with their access control rules 4. Gas cost estimates for the most common operations 5. At least one design tradeoff you had to make (e.g., on-chain vs. off-chain storage)