Fatskills
Practice. Master. Repeat.
Study Guide: Blockchain and Web3 Development: Ethereum and Smart Contracts Smart Contract Development Remix Hardhat Foundry Truffle
Source: https://www.fatskills.com/cryptocurrency-bitcoin-blockchain-and-more/chapter/blockchain-and-web3-development-blockchain-and-web3-development-ethereum-and-smart-contracts-smart-contract-development-remix-hardhat-foundry-truffle

Blockchain and Web3 Development: Ethereum and Smart Contracts Smart Contract Development Remix Hardhat Foundry Truffle

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

Smart contract development is the practice of writing, testing, and deploying self‑executing programs that run on the Ethereum Virtual Machine (EVM). These contracts replace trusted intermediaries with code, enabling decentralized finance (DeFi), NFTs, DAOs, and more. Real‑world example: the Uniswap V2 router contract that atomically swaps ERC‑20 tokens, guaranteeing the constant‑product invariant (x*y = k) without a central order book.


Key Terms & Code Snippets

  • Remix IDE: A browser‑based Solidity editor + compiler + debugger.
    solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.21; contract Counter { uint256 public n; function inc() external { n++; } }
  • Hardhat: A Node.js‑powered development framework that gives you a local EVM, task runner, and plugin ecosystem.
    bash npx hardhat compile # compiles contracts in ./contracts npx hardhat test # runs Mocha/Chai tests against a local node
  • Foundry: A Rust‑based toolkit (forge, cast, anvil) focused on speed and Solidity‑native testing.
    bash forge build # compile forge test # run tests anvil --fork https://eth-mainnet.alchemyapi.io/v2/<key> # local fork node
  • Truffle Suite: The original full‑stack framework (migrations, testing, console).
    bash truffle compile truffle migrate --network goerli
  • EVM (Ethereum Virtual Machine): The sandboxed runtime that executes bytecode; every transaction pays gas to the EVM.
  • ERC‑20: The standard interface for fungible tokens (balanceOf, transfer, approve, allowance).
    solidity interface IERC20 { function transfer(address to, uint256 amount) external returns (bool); }
  • ERC‑721: The NFT standard; each token ID maps to a unique owner.
    solidity contract MyNFT is ERC721("MyNFT", "MNFT") { function mint(address to, uint256 id) external { _safeMint(to, id); } }
  • Check‑Effects‑Interactions (CEI) Pattern: Order your code as checks → state changes → external calls to avoid re‑entrancy.
    solidity require(balances[msg.sender] >= amount); balances[msg.sender] -= amount; // effect (bool ok,) = msg.sender.call{value: amount}(""); // interaction require(ok);
  • Delegatecall: Executes code from another contract in the context of the caller, preserving its storage. Used for upgradeable proxies.
  • Hardhat Deploy Plugin: Automates deployment scripts and tracks contract addresses across networks.
    js const { deploy } = deployments; const token = await deploy("MyToken", { from: deployer, args: [] });
  • Foundry Cheatcodes (vm): Special testing helpers (e.g., vm.prank(address)) that let you spoof msg.sender without writing a mock contract.


Step‑by‑Step / Process Flow

  1. Write & iterate – Open Remix or VS Code, create MyToken.sol, and compile with Solidity 0.8.21.
  2. Set up a local dev nodenpx hardhat node (or anvil) to spin up an in‑memory EVM with pre‑funded accounts.
  3. Write tests – In test/MyToken.test.js use ethers.js (Hardhat) or forge (Foundry) to assert balance changes, events, and re‑entrancy protection.
  4. Deploy to a testnet
    bash
    npx hardhat run scripts/deploy.js --network goerli # uses Infura/Alchemy RPC


    Or with Foundry: forge script script/Deploy.s.sol --rpc-url $GOERLI_RPC --broadcast.
  5. Interact from the front‑end – Connect MetaMask, instantiate the contract with new ethers.Contract(address, abi, signer), and call transfer, mint, or vote functions.

Common Mistakes

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

  • Mistake: Forgetting to reset state after a failed external call (e.g., not rolling back a token transfer).
    Correction: Follow the CEI pattern or use require on the call’s return value; Solidity automatically reverts on a failed require.

  • Mistake: Hard‑coding the compiler version (pragma solidity 0.8.0;) and then compiling with a newer version that introduces breaking changes.
    Correction: Use a caret (^) or specify the exact version in hardhat.config.js / foundry.toml to guarantee reproducible builds.

  • Mistake: Deploying a contract with uninitialized storage variables (e.g., forgetting to set the owner in the constructor).
    Correction: Initialize all critical state in the constructor or via an initializer function when using proxies.

  • Mistake: Ignoring gas‑limit errors on testnets because the local node auto‑adjusts gas.
    Correction: Simulate realistic gas limits (hardhat set --gas-price 20gwei) and monitor estimateGas before sending transactions.


Blockchain Developer Interview / Practical Insights

  1. Call vs. delegatecall – Interviewers love to ask you to explain the difference and give a scenario where delegatecall is required (e.g., proxy pattern for upgradeability).
  2. ERC‑20 vs. ERC‑777 – Be ready to compare the basic token interface with the newer standard that adds hooks (tokensReceived) and operator concepts.
  3. Optimistic Rollup vs. ZK Rollup – Know the trade‑offs: latency (challenge period) vs. proof generation cost, and why DeFi often prefers Optimism today.
  4. Testing for re‑entrancy – Show a quick Hardhat test that uses a malicious contract to re‑enter a vulnerable function, then demonstrate the fix with CEI or ReentrancyGuard.

Quick Check Questions

  1. Scenario: A contract uses tx.origin == owner to restrict withdrawals.
    Answer: Dangerous – a phishing contract can call the vulnerable contract on behalf of the owner, making tx.origin the owner’s address and allowing theft.

  2. Scenario: You deploy an ERC‑20 token but forget to emit the Transfer event in the mint function.
    Answer: Wallets and indexers rely on the Transfer event to track balances; omitting it breaks UI visibility and can cause off‑chain services to miss the mint.

  3. Scenario: A Hardhat test passes locally but fails on Goerli with “out‑of‑gas” errors.
    Answer: The local node may have an artificially high block gas limit; always run estimateGas and set realistic limits before mainnet deployment.


Last‑Minute Cram Sheet (10 one‑liners)

  1. ⚠️ Never use tx.origin for auth – it’s spoofable.
  2. CEI = Checks → Effects → Interactions; the simplest re‑entrancy guard.
  3. ERC‑20 = 20, ERC‑721 = 721, ERC‑1155 = multi‑token (fungible + non‑fungible).
  4. Hardhat uses hardhat.config.js; Foundry uses foundry.toml.
  5. Gas tip: Use unchecked {} for loops when you’re sure overflow can’t happen (saves ~5 gas per iteration).
  6. Solidity 0.8+ has built‑in overflow checks; you don’t need SafeMath unless you target <0.8.
  7. Delegatecall keeps the caller’s storage layout – mismatched slots cause silent corruption.
  8. Proxy pattern: TransparentUpgradeableProxy vs. UUPS; the latter is cheaper but requires a proxiableUUID.
  9. Foundry cheatcode vm.prank(address) = impersonate msg.sender in tests.
  10. Rollup security: Optimistic = challenge period; ZK = validity proof. Both still rely on Ethereum’s consensus for finality.


ADVERTISEMENT