Build on blockchain: smart contracts from scratch
This curriculum takes an intermediate learner from a solid conceptual grounding in how blockchains work, through hands-on Solidity and smart contract development, and finally into architecting and securing full decentralized applications. Each stage builds directly on the vocabulary and mental models of the one before it, so skipping ahead is discouraged — the ramp is intentional.
How Blockchains Actually Work
IntermediateUnderstand the cryptographic primitives, consensus mechanisms, and economic incentives that make blockchains function — giving you the 'why' behind every design decision you'll encounter as a developer.
▸ Study plan for this stage
Pace: 8–10 weeks total. Week 1–4: "Bitcoin and Cryptocurrency Technologies" by Narayanan (~30–35 pages/day, covering all 12 chapters systematically — treat each chapter as a self-contained module). Week 5–10: "Mastering Bitcoin" by Antonopoulos (~25–30 pages/day — slower pace to allow deep dives into code
- Cryptographic hash functions and their properties (collision resistance, hiding, puzzle-friendliness) as introduced in Narayanan Ch.1 — the bedrock of block linking and proof-of-work
- Digital signatures (ECDSA) and public/private key pairs: how ownership of bitcoin is defined and proven without a trusted third party (Narayanan Ch.1, Antonopoulos Ch.4)
- The structure of a Bitcoin transaction: inputs, outputs, UTXOs, and locking/unlocking scripts (Antonopoulos Ch.6–7; Narayanan Ch.2)
- Bitcoin Script: a stack-based, intentionally non-Turing-complete language that encodes spending conditions — P2PKH, P2SH, multisig patterns (Antonopoulos Ch.7)
- Proof-of-Work consensus: the mining puzzle, difficulty adjustment, and why honest majority makes the chain tamper-evident (Narayanan Ch.2–3, Antonopoulos Ch.10)
- The blockchain data structure: Merkle trees, block headers, chaining via previous-block hash, and how SPV clients leverage Merkle proofs (Narayanan Ch.2, Antonopoulos Ch.9)
- Economic incentives in mining: block rewards, transaction fees, mining pools, and the game-theoretic argument for honest behavior (Narayanan Ch.3, Antonopoulos Ch.10)
- Network propagation, forks (accidental and intentional), and the longest-chain rule — why decentralization requires probabilistic finality (Narayanan Ch.3, Antonopoulos Ch.10)
- Given only hash functions and digital signatures, how does Bitcoin eliminate the need for a trusted central ledger? Trace the argument from Narayanan Ch.1–2.
- Walk through the lifecycle of a single Bitcoin transaction — from key-pair generation through UTXO creation, broadcast, mempool inclusion, mining, and confirmation — citing specific mechanisms from Antonopoulos Ch.4–10.
- Why is Bitcoin Script deliberately NOT Turing-complete, and what security and predictability guarantees does that limitation buy developers? (Antonopoulos Ch.7)
- Explain the difficulty-adjustment algorithm: what problem does it solve, how often does it run, and what would happen to the network if it didn't exist? (Antonopoulos Ch.10, Narayanan Ch.3)
- How do Merkle trees allow a lightweight (SPV) client to verify a transaction without downloading the full blockchain? What are the security trade-offs? (Narayanan Ch.2, Antonopoulos Ch.9)
- What is a 51% attack? Under what economic conditions does it become rational for a miner to attempt one, and what real-world factors make it impractical on Bitcoin? (Narayanan Ch.3)
- **Hash & signature lab (Narayanan Ch.1):** Using Python's `hashlib` and the `cryptography` library, write a script that (a) hashes an arbitrary message with SHA-256, (b) generates an ECDSA key pair, (c) signs the message, and (d) verifies the signature. Mutate one byte of the message and confirm verification fails — viscerally demonstrating collision resistance and signature binding.
- **UTXO ledger simulation (Narayanan Ch.2 + Antonopoulos Ch.6):** Build a minimal in-memory UTXO set in Python or JavaScript. Implement `create_transaction(inputs, outputs)` that validates input ownership (via mock signatures), checks no double-spend, and updates the UTXO set. Run a sequence of 10 chained transactions and print the final state.
- **Build a toy blockchain (Narayanan Ch.2–3 + Antonopoulos Ch.9):** Implement a 50-line blockchain in Python: each block contains a list of transactions, a timestamp, the previous block's hash, a nonce, and its own SHA-256 hash. Add a `mine(difficulty)` function that increments the nonce until the hash starts with N zeros. Observe how increasing difficulty exponentially increases mining time.
- **Merkle tree from scratch (Antonopoulos Ch.9):** Implement a Merkle tree builder that takes a list of transaction IDs (strings), hashes pairs up the tree, and returns the Merkle root. Then write a `generate_proof(tx_id)` and `verify_proof(tx_id, proof, root)` function pair — simulating exactly what an SPV client does.
- **Decode a real Bitcoin transaction (Antonopoulos Ch.6–7):** Use a block explorer (e.g., mempool.space) to find a real P2PKH transaction. Manually decode its raw hex using Antonopoulos's serialization tables: identify the version, input count, each input's txid/vout/scriptSig, output count, each output's value/scriptPubKey, and locktime. Annotate every byte in a text file.
- **Mining economics spreadsheet (Narayanan Ch.3 + Antonopoulos Ch.10):** Build a spreadsheet modeling a miner's expected profit: variables include hash rate (TH/s), network difficulty, electricity cost ($/kWh), hardware cost, block reward, and BTC price. Plot break-even BTC price vs. electricity cost. Then model a mining pool with 10 participants and show how variance in solo vs. pool rewards chang
Next up: Mastering the cryptographic primitives, transaction model, and consensus rules established in these two books gives you the precise mental model of what a blockchain can and cannot guarantee natively — the exact gap that smart contract platforms like Ethereum were designed to fill, making the next stage's exploration of the EVM and Solidity immediately intuitive rather than abstract.
A rigorous, bottom-up explanation of hashing, Merkle trees, proof-of-work, and the UTXO model. Reading this first means you'll never treat the blockchain as a magic black box.
Translates the cryptographic theory into concrete code and protocol details. It bridges pure concepts to the developer's perspective and is the canonical reference for how a real blockchain node operates.
Ethereum & the Smart Contract Platform
IntermediateUnderstand Ethereum's architecture — accounts, the EVM, gas, and the role of smart contracts — and write your first Solidity contracts with confidence.
▸ Study plan for this stage
Pace: 8–10 weeks total: Weeks 1–5 cover "Mastering Ethereum" (~35–40 pages/day, 5 days/week); Weeks 6–10 cover "Solidity Programming Essentials" (~25–30 pages/day, 5 days/week). Reserve one day per week for review, experimentation, and exercises.
- Ethereum's account model: the distinction between Externally Owned Accounts (EOAs) and Contract Accounts, and how state is stored on-chain (Mastering Ethereum, Ch. 1–4)
- The Ethereum Virtual Machine (EVM): stack-based execution, opcodes, bytecode compilation, and how the EVM provides a sandboxed, deterministic runtime (Mastering Ethereum, Ch. 13)
- Gas mechanics: why gas exists, how gas price and gas limit interact, out-of-gas exceptions, and the economic incentive structure for miners/validators (Mastering Ethereum, Ch. 7)
- Transactions and messages: anatomy of a transaction (nonce, to, value, data, v/r/s), the difference between transactions and internal message calls, and the transaction lifecycle (Mastering Ethereum, Ch. 6)
- Smart contract fundamentals: deployment flow (source → bytecode → ABI), contract storage layout, and the role of the ABI in encoding/decoding calls (Mastering Ethereum, Ch. 7–8)
- Solidity language core: data types, state variables vs. local variables, visibility specifiers (public/private/internal/external), and function modifiers (Solidity Programming Essentials, Ch. 2–5)
- Control structures, events, and error handling in Solidity: if/else, loops, require/revert/assert, custom errors, and emitting events for off-chain observability (Solidity Programming Essentials, Ch. 6–8)
- Inheritance, interfaces, and libraries in Solidity: contract composition patterns, the 'is' keyword, abstract contracts, and using libraries to share reusable logic safely (Solidity Programming Essentials, Ch. 9–11)
- How does Ethereum differentiate between an EOA and a contract account, and what are the practical implications for how each initiates or responds to transactions?
- Trace the full lifecycle of a transaction from signing by a user's wallet through EVM execution to final state commitment — what role does gas play at each step?
- What happens at the EVM level when a Solidity contract is deployed? What is stored on-chain, and what is the significance of the ABI versus the bytecode?
- Explain the difference between 'require', 'revert', and 'assert' in Solidity — when should each be used, and how do they affect gas consumption on failure?
- How do Solidity visibility specifiers (public, private, internal, external) control access to state variables and functions, and what are the security implications of choosing incorrectly?
- How does Solidity implement inheritance and what is the Method Resolution Order (MRO) when multiple contracts are inherited? Why might you prefer an interface over an abstract contract?
- Set up a local development environment using Hardhat or Remix IDE; deploy the canonical 'Hello World' storage contract from Mastering Ethereum Chapter 7 and inspect the resulting bytecode and ABI in the artifacts.
- Using Remix, write a simple Bank contract (deposit, withdraw, check balance) that uses require() for validation and emits Deposit/Withdrawal events — referencing the event and error-handling patterns in Solidity Programming Essentials Ch. 6–8.
- Experiment with gas: write two versions of the same loop-heavy function — one optimized (e.g., caching storage reads in memory) and one naive — deploy both to a local testnet, and compare gas costs using Hardhat's gas reporter.
- Implement a small inheritance hierarchy (e.g., Ownable base contract → a Pausable contract → a concrete Token contract) following the patterns in Solidity Programming Essentials Ch. 9–11; verify that visibility and override keywords behave as expected.
- Use the Ethereum JSON-RPC API (via ethers.js or web3.py) to manually construct, sign, and send a raw transaction to your local Hardhat node; log the transaction receipt and decode the logs using the contract ABI — tying together the transaction anatomy covered in Mastering Ethereum Ch. 6.
- Read and annotate the EVM opcode output of one of your compiled contracts using 'solc --opcodes' or the Remix debugger; identify at least five opcodes (e.g., SSTORE, SLOAD, CALL, REVERT, PUSH) and map them back to the Solidity source lines they originate from.
Next up: Mastering the EVM execution model, Solidity syntax, and basic contract patterns here provides the essential foundation for the next stage, where these primitives are applied to real-world contract architectures — covering security vulnerabilities, design patterns (upgradability, access control), and DApp integration that build directly on the account model, gas awareness, and Solidity fluency deve
The definitive Ethereum developer reference. It covers the EVM, accounts vs. UTXOs, gas mechanics, and the ABI — essential vocabulary before writing a single line of Solidity.
A focused, hands-on introduction to the Solidity language itself — data types, control flow, inheritance, and events. Reading it after Mastering Ethereum means you already understand why each language feature exists.
Building & Deploying Real Smart Contracts
IntermediateUse professional tooling (Hardhat/Truffle, OpenZeppelin, testnets) to write, test, and deploy production-grade smart contracts, including tokens and NFTs.
▸ Study plan for this stage
Pace: 8–10 weeks total. Week 1–4: "Building Ethereum DApps" by Roberto Infante (~25–30 pages/day, ~5 days/week) — read Parts I–III covering Ethereum fundamentals, Solidity contract writing, and DApp architecture. Week 5–9: "Hands-On Smart Contract Development with Solidity and Ethereum" by Hoover (~25–30
- Ethereum account model, gas mechanics, and the EVM execution environment (Infante, Part I) — foundational mental model for everything that follows
- Solidity contract anatomy: state variables, functions, modifiers, events, and inheritance patterns (Infante, Parts I–II)
- DApp architecture: how the front-end (Web3.js), smart contracts, and the blockchain node layer interact end-to-end (Infante, Part III)
- Professional development toolchains — Hardhat and Truffle project setup, compilation, migration scripts, and local blockchain simulation with Ganache (Hoover, Chapters 1–5)
- OpenZeppelin contract standards: ERC-20 fungible tokens and ERC-721 NFTs, safe math, access control (Ownable, Roles), and upgrade patterns (Hoover, Chapters 6–10)
- Smart contract testing methodology: unit tests with Mocha/Chai, testing events and reverts, achieving meaningful coverage (Hoover, Chapters 7–9)
- Testnet deployment workflow: configuring network providers (Infura/Alchemy), managing private keys securely with dotenv, deploying to Goerli/Sepolia, and verifying contracts on Etherscan (Hoover, Chapters 11–12)
- Security best practices: reentrancy guards, checks-effects-interactions pattern, integer overflow/underflow awareness, and using OpenZeppelin audited libraries as a safety baseline (both books)
- After reading Infante's DApp architecture chapters, can you trace a single user transaction — from a front-end button click through Web3.js, into the EVM, and back — identifying every layer involved?
- Can you explain the difference between an ERC-20 and ERC-721 contract (as covered in Hoover), and describe a real use case where you would choose one over the other?
- Using the Hardhat workflow from Hoover, what is the exact sequence of commands and configuration steps needed to compile, test locally, and then deploy a contract to the Sepolia testnet?
- How do OpenZeppelin's Ownable and AccessControl modules (Hoover) differ in their permission models, and when would you inherit from each?
- What testing patterns does Hoover prescribe for verifying that a function correctly emits an event and that an unauthorized call correctly reverts — and why does each matter for production safety?
- Drawing on both Infante and Hoover, what are three concrete smart contract vulnerabilities, and which specific coding patterns or OpenZeppelin utilities mitigate each one?
- 'Hello Blockchain' to Production Token (Infante → Hoover): Start by coding the simple storage and voting contracts from Infante to get comfortable with Solidity syntax, then extend one into a full ERC-20 token using OpenZeppelin's ERC20 base contract from Hoover. Deploy it to a local Hardhat network, then to Sepolia.
- Full Hardhat Project Scaffold (Hoover, Chapters 1–5): From scratch, initialize a Hardhat project, write a custom contract, create a Migrations/deploy script, and run the built-in local node. Document every config decision in a README as if onboarding a teammate.
- NFT Minting Contract (Hoover, Chapters 6–10): Build an ERC-721 NFT contract inheriting from OpenZeppelin's ERC721URIStorage. Add an Ownable mint function, store metadata URIs, and write at least 10 Mocha/Chai unit tests covering: successful mint, unauthorized mint revert, correct URI storage, and Transfer event emission.
- Testnet Deploy & Etherscan Verification (Hoover, Chapters 11–12): Configure hardhat.config.js with Infura/Alchemy RPC URLs and a .env file for private keys. Deploy your ERC-20 and ERC-721 contracts to Sepolia, then verify both on Etherscan using the hardhat-etherscan plugin. Screenshot the verified source page.
- Security Audit Exercise (both books): Take the voting contract from Infante and deliberately introduce a reentrancy vulnerability. Then fix it using the checks-effects-interactions pattern and OpenZeppelin's ReentrancyGuard. Write a test that proves the attack fails on the fixed version.
- End-to-End Mini DApp (Infante, Part III + Hoover): Wire a minimal HTML/JS front-end using Web3.js (as shown in Infante) to your deployed Sepolia ERC-20 token — display the user's balance and allow a token transfer. This closes the full loop from contract authorship to user-facing interaction.
Next up: ">Mastering professional tooling, OpenZeppelin standards, and testnet deployment here gives you the production-grade contract foundation needed to tackle the next stage's advanced topics — such as DeFi protocol mechanics, contract upgradeability patterns, and cross-contract interactions — where the complexity lives in the architecture and economics rather than the basic deployment workflow.
Walks through the full development lifecycle — writing contracts, unit testing, and deploying to a testnet — using realistic project examples that mirror professional workflows.
Deepens practical skills with Truffle, web3.js, and front-end integration, reinforcing the deploy-test-iterate loop with progressively complex contract patterns.
Architecting Full Decentralized Applications
ExpertDesign and ship complete DApps by integrating smart contracts with front-end frameworks, decentralized storage, oracles, and Layer 2 scaling solutions.
▸ Study plan for this stage
Pace: 8–10 weeks, ~25–35 pages/day (Mastering Blockchain is a dense, technically rich text of ~800+ pages); dedicate weekdays to reading and weekends to hands-on exercises and review sessions.
- End-to-end DApp architecture: how smart contracts, front-end frameworks (e.g., Web3.js/Ethers.js), and wallets (MetaMask) interact as a unified system, as covered in Mastering Blockchain's DApp and Ethereum chapters
- Smart contract design patterns and security: reentrancy guards, upgradeable proxy patterns, access control, and gas optimization strategies drawn from Bashir's deep-dive into Solidity and EVM internals
- Decentralized storage integration: using IPFS and Swarm to store off-chain data (files, metadata, large payloads) and anchoring content hashes on-chain, as discussed in Mastering Blockchain's storage and Web3 sections
- Oracle architecture: understanding how Chainlink-style oracles bridge off-chain data to on-chain contracts, the trust assumptions involved, and the request-response pattern Bashir outlines
- Layer 2 scaling solutions: state channels, rollups (Optimistic and ZK), and sidechains — their trade-offs in throughput, finality, and security as analyzed in Mastering Blockchain's scalability chapters
- Token standards and DeFi primitives: ERC-20, ERC-721, ERC-1155 token mechanics and how they serve as composable building blocks for full DApps, per Bashir's coverage of Ethereum standards
- Consensus and network-layer awareness: understanding how the underlying consensus mechanism (PoW → PoS transition, finality guarantees) affects DApp design decisions around confirmation times and re-org risk
- Testing, deployment, and DevOps for DApps: using Hardhat/Truffle pipelines, testnets (Goerli, Sepolia), and Infura/Alchemy node providers to ship production-grade contracts as described in Mastering Blockchain's development workflow sections
- How does Mastering Blockchain describe the layered architecture of a DApp, and what responsibilities belong to the smart-contract layer versus the front-end layer versus decentralized storage?
- According to Bashir's treatment of Solidity and the EVM, what are the most critical security vulnerabilities (e.g., reentrancy, integer overflow, front-running) and which design patterns mitigate each?
- How do oracles solve the 'blockchain oracle problem' as explained in Mastering Blockchain, and what trust trade-offs does a developer accept when integrating an external data feed into a smart contract?
- What Layer 2 approaches does Bashir cover, and how do Optimistic Rollups and ZK-Rollups differ in their proof mechanisms, finality times, and suitability for different DApp use cases?
- How does Mastering Blockchain recommend integrating IPFS or Swarm with an on-chain contract — what data lives off-chain, what lives on-chain, and how is integrity guaranteed?
- What deployment and testing workflow does Bashir outline for taking a smart contract from local development through testnet to mainnet, and what role do tools like Truffle, Hardhat, and node providers play?
- Build a full-stack DApp from scratch: write an ERC-20 or ERC-721 smart contract in Solidity, deploy it to a testnet (Goerli/Sepolia) using Hardhat, and connect it to a React front-end via Ethers.js and MetaMask — mirroring the end-to-end architecture Bashir describes.
- Implement and exploit a reentrancy vulnerability in a local Hardhat environment, then refactor the contract using the checks-effects-interactions pattern and OpenZeppelin's ReentrancyGuard; document the before/after gas costs.
- Integrate IPFS (via the js-ipfs or web3.storage SDK) into your DApp: upload an NFT image and metadata JSON to IPFS, store the resulting CID on-chain in your contract, and retrieve and render it in the front-end.
- Set up a Chainlink oracle integration: write a consumer contract that requests ETH/USD price data from a Chainlink Data Feed on a testnet, consume the result in contract logic (e.g., a price-gated function), and verify the transaction on Etherscan.
- Deploy your DApp's contracts to an Optimistic Rollup testnet (e.g., Optimism Goerli or Arbitrum Goerli), measure gas costs versus Ethereum L1, and document the deposit/withdrawal bridge flow and finality differences.
- Write a comprehensive test suite for your smart contracts using Hardhat + Chai covering: happy-path functionality, edge cases, access-control restrictions, and at least one security scenario — targeting >90% line coverage before any testnet deployment.
Next up: Mastering Blockchain's holistic treatment of DApp architecture, scaling, and security equips the reader with the systems-level thinking needed to tackle the next stage's focus on advanced protocol design, cross-chain interoperability, and production-grade DeFi or DAO governance systems.
Takes a broad architectural view — covering DeFi primitives, Layer 2 rollups, cross-chain bridges, and decentralized storage — giving you the system-design vocabulary to make informed trade-offs in real projects.
Discussion
Keep reading
Paths that share books, cover the same subject, or open a related topic.
