By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.
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.
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; } }
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.
msg.sender
tx.origin
call, delegatecall, staticcall: Low?level EVM primitives. delegatecall runs code in the context of the calling contract, preserving its storage.
call
delegatecall
staticcall
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.
ADD
SSTORE
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.
require
assert
Simple.sol
bash npx hardhat compile
artifacts/.../Simple.json
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);
js await simple.set(42); // consumes gas const val = await simple.value(); // view, no gas console.log("Stored:", val.toString());
gasUsed
uint256
uint128
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?%).
estimateGas
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.
hardhat.config.js
solidity: "0.8.20"
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).
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.
tokensReceived
approve/transferFrom
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).
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).
maxFeePerGas
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.
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.
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.
EIP?2612
transferFrom
approve
totalSupply
balanceOf
transfer
Join 4M+ learners. Unlock unlimited quizzes, wrong-answer tracking, flashcards + reminders, study guides, and 1-on-1 challenges.