Fatskills
Practice. Master. Repeat.
Study Guide: Blockchain and Web3 Development: Ethereum and Smart Contracts - Ethereum Architecture, EVM, Gas, Accounts vs. UTXO
Source: https://www.fatskills.com/cryptocurrency-bitcoin-blockchain-and-more/chapter/blockchain-and-web3-development-blockchain-and-web3-development-ethereum-and-smart-contracts-ethereum-architecture-evm-gas-accounts-vs-utxo

Blockchain and Web3 Development: Ethereum and Smart Contracts - Ethereum Architecture, EVM, Gas, Accounts vs. UTXO

By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.

⏱️ ~5 min read

What This Is

Ethereum’s architecture is the stack that lets anyone run smart contracts on a global, permission?less computer. The core piece is the Ethereum Virtual Machine (EVM), a sandboxed byte?code interpreter that charges gas for every operation, guaranteeing that the network stays alive and that contracts cannot “run forever”. Unlike Bitcoin’s UTXO model, Ethereum uses accounts (EOA?vs?contract) that hold balances and state, making it far easier to build DeFi, NFTs, and DAO voting contracts.
Real?world example: When you swap ETH for DAI on Uniswap, the front?end sends a transaction to the Uniswap router contract; the EVM executes the AMM logic, updates balances, and the gas you paid covers the compute that made the trade happen.


Key Terms & Code Snippets

  • EVM (Ethereum Virtual Machine): The runtime that executes compiled Solidity byte?code on every node.
    solidity // Simple storage contract – compiled to EVM bytecode contract Simple { uint256 public value; function set(uint256 _v) external { value = _v; } }

  • Gas: The unit that measures how much computational work a transaction uses. 1?gas?0.000000001?ETH (depends on the network’s gas price).

  • Gas Limit vs. Gas Price: Limit caps the total gas a tx can consume; price (gwei per gas) determines how quickly miners include it.

  • EOA (Externally Owned Account): A user?controlled account that holds a private key and can send transactions.

  • Contract Account: An address that holds byte?code and its own storage; it can only act when another transaction calls it.

  • UTXO (Unspent Transaction Output): Bitcoin’s model where each transaction consumes previous outputs and creates new ones. Ethereum replaces this with a single?balance account model, simplifying token transfers.

  • msg.sender vs. tx.origin: msg.sender is the immediate caller; tx.origin is the original EOA that started the transaction. Use msg.sender for access control.

  • call, delegatecall, staticcall: Low?level EVM primitives. delegatecall runs code in the context of the calling contract, preserving its storage.

  • Opcode Gas Costs: Each EVM instruction (e.g., ADD, SSTORE) has a fixed gas cost. Knowing the most expensive opcodes helps you write cheaper contracts.

  • EIP?1559: The fee?market upgrade that introduced a base fee (burned) + optional priority fee (tip).

  • require vs. assert: require reverts on user errors and refunds remaining gas; assert signals a bug and consumes all remaining gas.


Step?by?Step / Process Flow

  1. Write the contract – Open Remix or VS?Code, create Simple.sol (see snippet above).
  2. Compile with Hardhat
    bash npx hardhat compile
    This produces the EVM byte?code (artifacts/.../Simple.json).
  3. Deploy to a testnet – Use an Infura/Alchemy endpoint and a funded Goerli account:
    js const { ethers } = require("hardhat"); const Simple = await ethers.getContractFactory("Simple"); const simple = await Simple.deploy(); // tx sent, gas paid await simple.deployed(); console.log("Deployed at:", simple.address);
  4. Interact via Ethers.js – Call the setter and read the value:
    js await simple.set(42); // consumes gas const val = await simple.value(); // view, no gas console.log("Stored:", val.toString());
  5. Monitor gas usage – In Hardhat’s console or Etherscan, check the gasUsed field; iterate on the code (e.g., replace uint256 with uint128 if possible) to lower it.

Common Mistakes

  • Mistake: Using tx.origin for authentication.
    Correction: Always check msg.sender; tx.origin can be spoofed through a malicious contract, opening a phishing vector.

  • Mistake: Forgetting to set a gas limit high enough, causing the tx to run out of gas mid?execution.
    Correction: Estimate gas (estimateGas in ethers) and add a safety margin (10?20?%).

  • Mistake: Storing large structs in a single storage slot, leading to high SSTORE costs.
    Correction: Pack variables tightly (e.g., uint128 + uint128) or use mappings to spread storage.

  • Mistake: Assuming all EVM opcodes have the same cost.
    Correction: Use the opcode gas table; SSTORE (20?k gas) is far more expensive than ADD (3?gas).

  • Mistake: Deploying with the latest Solidity compiler without testing on the target EVM version.
    Correction: Pin the compiler version in hardhat.config.js (e.g., solidity: "0.8.20"), and run the full test suite on the same version.


Blockchain Developer Interview / Practical Insights

  1. Call vs. delegatecall: Interviewers love to ask why delegatecall is used in proxy patterns (it lets a “logic” contract upgrade while preserving the storage of the “proxy” contract).

  2. ERC?20 vs. ERC?777: Be ready to explain that ERC?777 adds hooks (tokensReceived) and reduces the need for approve/transferFrom, but it introduces extra complexity and compatibility concerns.

  3. Optimistic vs. ZK Rollups: Know that Optimistic Rollups assume transactions are valid and challenge only if fraud is suspected (higher latency), whereas ZK Rollups provide validity proofs instantly (lower latency, higher proof cost).

  4. EIP?1559 fee dynamics: Show you understand how the base fee is burned, how the priority fee incentivizes miners, and why gas?price spikes can be mitigated by setting a max fee (maxFeePerGas).


Quick Check Questions

  1. Scenario: A contract uses tx.origin to restrict a function to the contract owner.
    Answer: Dangerous – a malicious contract can trick the owner into calling it, making tx.origin equal the owner’s address and bypassing the check.

  2. Scenario: You see a transaction that consumed 210,000 gas but only 50,000 was needed for the actual logic.
    Answer: The extra gas was spent on storage writes (SSTORE) and event logs; optimizing storage layout or reducing emitted events would lower the cost.

  3. Scenario: A DeFi protocol wants to let users swap tokens without approving each pair individually.
    Answer: Use an ERC?20 permit (EIP?2612) so the user can sign an off?chain approval and the contract can call transferFrom in the same transaction, saving a separate approve tx.


Last?Minute Cram Sheet (10 one?liners)

  1. Never use tx.origin for auth – it’s trivially spoofed.
  2. SSTORE costs 20?k gas (first write) vs. 5?k for overwriting a non?zero slot.
  3. EIP?1559 base fee is burned; priority fee goes to the miner.
  4. delegatecall runs the callee’s code in the caller’s storage – perfect for upgradeable proxies.
  5. ERC?20 = 3 core functions (totalSupply, balanceOf, transfer).
  6. ERC?777 adds tokensReceived hook and eliminates the “approval race”.
  7. Gas limit must be estimated gas + 10?% safety buffer.
  8. require refunds remaining gas; assert consumes all remaining gas.
  9. Optimistic Rollup-fraud proofs; ZK Rollup-validity proofs.
  10. Hardhat default Solidity version is 0.8.20; pin it to avoid breaking changes.