# Blockchain Interview Questions with Answers 12 Blockchain interview questions, each with a model answer, the points to cover, common mistakes and the follow-ups interviewers ask. _Source: Astra (https://useastra.in). Updated 2026-09-05._ ### 1. Explain the concept of 'Gas' in Ethereum. Why is it necessary, and how is it different from 'Gas Price'? Gas is the unit that measures the amount of computational effort required to execute specific operations on the Ethereum network. **1. Necessity:** It prevents infinite loops (Halting Problem) and spam attacks by making computation costly. **2. Gas Limit:** The maximum gas you are willing to spend on a transaction. **3. Gas Price:** The amount of Ether (in Gwei) you are willing to pay *per unit* of gas. Total fee = Gas Used * Gas Price. **Points a strong answer covers:** - Gas = computation unit priced per opcode - Prevents infinite loops + spam; pays validators - Gas price (gwei) = what you pay per unit; fee = used x price **Common mistakes:** - Gas and gas price conflated **Likely follow-ups:** - EIP-1559 base fee vs tip? - Out-of-gas mid-execution -- what happens to state? **What the interviewer is assessing:** - EVM-economics fundamentals. ### 2. What is a 'Reentrancy Attack' in Solidity, and how do you prevent it? A Reentrancy Attack occurs when an external contract calls back into the calling contract *before* the first invocation is finished, potentially draining funds (e.g., The DAO hack). **Prevention:** 1. **Checks-Effects-Interactions Pattern:** Update the state variables (Effects) *before* sending Ether (Interactions). 2. **ReentrancyGuard:** Use OpenZeppelin's `nonReentrant` modifier which locks the contract during execution. **Points a strong answer covers:** - External call re-enters before state update -> drains funds - The DAO hack pattern - Prevent: checks-effects-interactions, reentrancy guard, pull payments **Common mistakes:** - Only naming the guard modifier **Likely follow-ups:** - Walk the DAO attack sequence - Read-only reentrancy -- what is it? **What the interviewer is assessing:** - Contract-security cornerstone -- must be cold. ### 3. What is the difference between a 'Hard Fork' and a 'Soft Fork'? **Hard Fork:** A permanent divergence in the blockchain. It is a non-backward-compatible upgrade. Nodes running the old software will *not* accept the new blocks (e.g., Ethereum vs. Ethereum Classic). **Soft Fork:** A backward-compatible upgrade. Old nodes will still recognize the new blocks as valid, even if they don't understand the new rules. It only requires a majority of miners to upgrade. **Points a strong answer covers:** - Hard fork: incompatible rules -- old nodes reject new blocks (chain split risk) - Soft fork: backward-compatible tightening - Examples: ETH/ETC split vs SegWit **Common mistakes:** - Compatibility direction reversed **Likely follow-ups:** - Why did ETH/ETC split socially, not just technically? **What the interviewer is assessing:** - Protocol-governance mechanics. ### 4. Explain the difference between 'Proof of Work' (PoW) and 'Proof of Stake' (PoS). **PoW (Mining):** Miners solve complex mathematical puzzles (hashing) to validate transactions. It requires massive energy hardware. Security comes from the cost of electricity/hardware. **PoS (Staking):** Validators are chosen to create blocks based on the number of coins they hold and are willing to 'stake' (lock up) as collateral. It is energy-efficient. Security comes from the economic penalty (slashing) of misbehaving validators. **Points a strong answer covers:** - PoW: hash-race security, energy cost - PoS: staked capital + slashing security - Trade-offs: energy, decentralization pressure, finality style **Common mistakes:** - "PoS is just greener" one-liner **Likely follow-ups:** - What attack replaces 51% hash in PoS? **What the interviewer is assessing:** - Consensus-mechanism depth. ### 5. What is a Merkle Tree and why is it essential for blockchain efficiency? A Merkle Tree is a binary tree of hashes. **1. Structure:** Each leaf node is a hash of a block of data (transaction), and non-leaf nodes are hashes of their children. **2. Importance:** It allows for efficient and secure verification of content in large bodies of data. 'Light clients' can verify a specific transaction exists in a block by only downloading the 'Merkle Root' and a small 'Merkle Proof' branch, rather than the entire blockchain. **Points a strong answer covers:** - Merkle tree: hash pairs up to a single root - Light clients verify inclusion via log-size proofs - Tamper-evidence: any change bubbles to root **Common mistakes:** - No inclusion-proof use case **Likely follow-ups:** - Merkle proof size for 1M transactions? - Patricia-Merkle trie in Ethereum state? **What the interviewer is assessing:** - Data-structure-to-trust bridge. ### 6. What is the difference between `memory`, `storage`, and `calldata` in Solidity? These define where variables are stored. **1. Storage:** Persistent data stored on the blockchain. It is very expensive (high gas). **2. Memory:** Temporary data stored in RAM during function execution. It is erased after execution and is cheaper than storage. **3. Calldata:** Non-modifiable, temporary data area where function arguments are stored. It is the cheapest location and is mostly used for external function parameters. **Points a strong answer covers:** - storage: persistent state (expensive) - memory: transient per-call scratch - calldata: read-only input -- cheapest for external fn args **Common mistakes:** - No gas-cost dimension **Likely follow-ups:** - Why does copying calldata to memory cost more gas? **What the interviewer is assessing:** - Solidity-memory-model precision. ### 7. What are 'Smart Contracts', and what is the 'Oracle Problem'? **Smart Contracts:** Self-executing contracts with the terms of the agreement directly written into code. They run on the blockchain. **The Oracle Problem:** Blockchains are isolated networks; they cannot access 'real-world' data (like stock prices or weather) natively. **Oracles** (like Chainlink) are middleware that fetch external data and feed it into the blockchain securely. The 'problem' is ensuring the Oracle itself provides centralized, truthful data without being manipulated. **Points a strong answer covers:** - Smart contract: code enforcing agreement on-chain - Oracle problem: chain cannot trust external data natively - Solutions: decentralized oracles (Chainlink), commit-reveal **Common mistakes:** - Ignoring the trust-boundary problem **Likely follow-ups:** - Why is a single oracle a systemic risk (price feeds)? **What the interviewer is assessing:** - On-chain/off-chain boundary understanding. ### 8. Explain the concept of 'Sharding' in the context of blockchain scaling. Sharding is a Layer 1 scaling solution that splits the blockchain network into smaller partitions called 'shards'. **Mechanism:** Instead of every node validating *every* transaction (which is slow), nodes are assigned to specific shards. Each shard processes its own transactions and stores its own state. **Benefit:** It increases throughput (TPS) linearly with the number of shards. **Challenge:** Cross-shard communication and security. **Points a strong answer covers:** - Sharding: split state/execution across parallel chains - Ethereum pivot: danksharding for data availability (rollup-centric) - Cross-shard communication complexity **Common mistakes:** - Database-sharding answer verbatim **Likely follow-ups:** - Why did execution sharding lose to rollups? **What the interviewer is assessing:** - Scaling-roadmap currency. ### 9. What is the difference between an ERC-20 and an ERC-721 token? **ERC-20 (Fungible Tokens):** These tokens are identical and interchangeable (like currency). 1 ETH = 1 ETH. Used for currencies, voting tokens, etc. **ERC-721 (Non-Fungible Tokens - NFTs):** These tokens are unique and distinct. Token ID #1 is *not* equal to Token ID #2. Used for digital art, real estate deeds, and collectibles. **Points a strong answer covers:** - ERC-20: fungible, balance-based (currencies, governance) - ERC-721: non-fungible, unique tokenIds (NFTs) - Different interfaces: transfer vs transferFrom/ownerOf **Common mistakes:** - Fungibility undefined **Likely follow-ups:** - ERC-1155 -- what problem does it solve? **What the interviewer is assessing:** - Token-standard basics. ### 10. What is a '51% Attack', and is it possible on all blockchains? A 51% attack occurs when a single entity or group controls more than 50% of the network's mining hashrate (PoW) or staked tokens (PoS). **capabilities:** They can prevent new transactions from confirming and **double-spend** coins by reversing their own recent transactions. They *cannot* steal others' funds or change history indefinitely back. It is theoretically possible on all public blockchains but is economically unfeasible on large networks like Bitcoin due to the cost. **Points a strong answer covers:** - Majority hash/stake -> censor + reorg recent blocks - Cannot: steal keys, mint arbitrarily, rewrite deep history cheaply - Feasible on small chains; cost scales with security budget **Common mistakes:** - Omnipotent-attacker myth **Likely follow-ups:** - What CAN a 51% attacker actually do -- precisely? **What the interviewer is assessing:** - Threat-model precision. ### 11. What is the purpose of the `payable` modifier in Solidity? The `payable` modifier marks a function or address as capable of receiving Ether. **1. Functions:** If you send Ether to a function *not* marked `payable`, the transaction will automatically revert. **2. Addresses:** To send Ether *to* an address variable in Solidity, that address must be cast as `payable address`. **Points a strong answer covers:** - payable allows function/address to receive ETH - Without it, transfers revert - Constructor/receive/fallback payability **Common mistakes:** - Thinking all functions accept ETH **Likely follow-ups:** - Contract with no payable -- can you force ETH in (selfdestruct)? **What the interviewer is assessing:** - Solidity-mechanics basics. ### 12. Explain 'Layer 2' (L2) scaling solutions. What is the difference between Optimistic Rollups and ZK-Rollups? L2 solutions process transactions *off* the main chain (Layer 1) to save gas and speed, then post the data back to L1. **Optimistic Rollups:** Assume transactions are valid by default. They rely on a 'fraud proof' window (e.g., 7 days) where anyone can challenge a bad transaction. Slower withdrawal times. **ZK-Rollups (Zero-Knowledge):** Use cryptographic proofs (validity proofs) to verify transactions instantly. They are faster and more secure but computationally heavier to generate. **Points a strong answer covers:** - L2: execute off-chain, settle/prove on L1 - Optimistic: assume valid + fraud-proof window (7d exits) - ZK: validity proofs -- instant finality, heavier prover **Common mistakes:** - No proof-mechanism distinction **Likely follow-ups:** - Why do optimistic withdrawals take a week? - Where do ZK-rollups still struggle (EVM equivalence)? **What the interviewer is assessing:** - Scaling-architecture fluency. Full topic: https://useastra.in/interview-questions/topic/blockchain