Web3 / Blockchain Development — Learning Path

This learning path is tailored for systems-level developers comfortable with low-level programming (Rust, C) who want to enter the blockchain and decentralized application space. The Web3 ecosystem is heavily Rust-native, making it a natural fit for developers who already think in terms of memory layouts, concurrency primitives, and protocol design.

Progress

• Core Blockchain Fundamentals
• Smart Contract Development (Solidity, Rust, Move, Cairo)
• DeFi Protocols (Uniswap, Aave, Compound)
• MEV and Flashbots
• Infrastructure & Tooling (Foundry, Reth)
• Zero-Knowledge Proofs
• Security & Auditing
• The Rust Angle — ecosystem mapping
• Progressive Projects (0/10)

⏳ PART I: THE TECHNOLOGY LANDSCAPE

1. Core Blockchain Fundamentals — How It Actually Works at the Byte Level

What is a blockchain, really?

Strip away the hype: a blockchain is a replicated state machine where transitions (transactions) are ordered by a consensus protocol and linked via cryptographic hash chains. Every node independently executes the same transitions in the same order and arrives at the same state. That’s it. Everything else is optimization.

The data structures that matter:

• Hash chains: Each block contains the SHA-256 (Bitcoin) or Keccak-256 (Ethereum) hash of the previous block header. This creates a tamper-evident chain — changing any historical block invalidates all subsequent hashes. A block header is typically ~80 bytes (Bitcoin) containing: version, previous block hash, merkle root, timestamp, difficulty target, nonce.

• Merkle trees: Transactions within a block are organized into a binary hash tree. The root hash is stored in the block header. This enables Merkle proofs — you can prove a transaction is in a block by providing only ~log2(n) hashes instead of the entire block. This is fundamental to light clients (SPV nodes) that don’t store the full chain.

• Patricia Merkle Tries (Ethereum): Ethereum uses a more complex structure — a Modified Merkle Patricia Trie — to store the world state (all account balances, contract storage, code). Each node in the trie is hashed, and the root hash is stored in the block header. This means the entire state of the system is committed to in every block, enabling state proofs.

Transaction lifecycle (Ethereum):

1. User constructs a transaction (to, value, data, gas limit, gas price, nonce)
2. Transaction is signed with ECDSA using the user’s private key (secp256k1 curve)
3. Signed transaction is broadcast to the P2P network via gossip protocol
4. Transaction enters the mempool (memory pool) of each node
5. A block proposer (validator in PoS) selects transactions from the mempool, orders them, executes them against the state, and proposes a block
6. Other validators attest to the block’s validity
7. After enough attestations, the block is finalized — the state transition is permanent

Consensus mechanisms — WHY each exists:

P2P networking in blockchains:

• Gossip protocols: Nodes propagate transactions/blocks by telling a random subset of peers, who tell their peers, etc. Epidemiological spreading — reaches all nodes in O(log n) rounds.
• libp2p: The networking library used by Ethereum, Polkadot, Filecoin, and many others. Written in Go/Rust/JS. Handles peer discovery, NAT traversal, multiplexing, encryption. This is a fantastic Rust codebase to study (libp2p/rust-libp2p on GitHub).
• Kademlia DHT: Distributed hash table for peer discovery. Each node has a 256-bit ID; nodes maintain routing tables of peers at exponentially increasing distances.
• DevP2P (Ethereum): Ethereum’s networking layer. Uses RLPx for encrypted transport, supports multiple sub-protocols (eth, snap, les).

2. Smart Contract Development — The Languages and Runtimes

Solidity (EVM Ecosystem) — The Dominant Language

Solidity is the JavaScript of Web3 — not the best language, but the most ecosystem and tooling. It compiles to EVM bytecode which runs on Ethereum and every EVM-compatible chain (Polygon, Arbitrum, Optimism, BSC, Avalanche, Base, etc.).

How the EVM actually works (low-level):

The EVM is a stack-based virtual machine with:

• Stack: 1024 elements max, each 256-bit (32 bytes). All operations push/pop from here.
• Memory: Byte-addressable, volatile (cleared per transaction). Grows dynamically, costs gas quadratically.
• Storage: Key-value store mapping 256-bit keys to 256-bit values. Persistent across transactions. Most expensive operation — SSTORE costs 20,000 gas for a new slot, SLOAD costs 2,100 gas.
• Calldata: Read-only, contains the function selector (first 4 bytes of keccak256 of function signature) and ABI-encoded arguments.
• Program Counter: Points to current opcode.

Key opcodes to know:

PUSH1-PUSH32  — Push 1-32 bytes onto stack
ADD, MUL, SUB — Arithmetic (256-bit!)
SLOAD, SSTORE — Read/write persistent storage
MLOAD, MSTORE — Read/write memory
CALL          — Call another contract (forwards gas, sends value)
DELEGATECALL  — Call another contract but use caller's storage (proxy pattern!)
STATICCALL    — Read-only call (reverts if state changes attempted)
CREATE, CREATE2 — Deploy new contracts
REVERT        — Undo all state changes, return error data
SELFDESTRUCT  — (Deprecated post-Dencun) Destroy contract, send funds

Storage layout is critical for security:

• State variables are assigned sequential storage slots (0, 1, 2…)
• Smaller types are packed into single 32-byte slots when possible
• Mappings use keccak256(key . slot) to compute storage locations
• Dynamic arrays use keccak256(slot) as the base for element storage
• Understanding this is essential for: proxy patterns, storage collisions, upgradeable contracts, and debugging

Gas optimization at the opcode level is a real skill. Example: calldata is cheaper than memory (3 gas/byte vs 3 gas/byte + expansion costs). Reading a cold storage slot costs 2,100 gas; warm (already accessed in same tx) costs 100 gas.

Rust for Smart Contracts — Where Systems Developers Fit In

This is where a Rust/systems developer has a massive advantage. Rust is used across multiple blockchain ecosystems:

Solana (Anchor Framework):

• Programs are compiled to eBPF bytecode (extended Berkeley Packet Filter — yes, the same technology used in Linux kernel networking)
• Solana uses an accounts model, not EVM’s contract model. Programs are stateless — all state lives in separate accounts that are passed to the program
• Every transaction must declare upfront which accounts it reads/writes. This enables parallel execution (Sealevel runtime)
• The #[program] macro from Anchor generates boilerplate (as seen in real GitHub code: declare_id!("..."); #[program] pub mod my_program { ... })
• Raw Solana programs use fn process_instruction(program_id: &Pubkey, accounts: &[AccountInfo], instruction_data: &[u8]) -> ProgramResult

How Sealevel (SVM) differs from EVM — this is architecturally fascinating:

NEAR Protocol (Rust + AssemblyScript):

• Uses WebAssembly (Wasm) as its VM
• Rust smart contracts compile to Wasm
• Sharded architecture — each shard processes transactions in parallel
• Interesting async cross-shard communication model

CosmWasm (Cosmos Ecosystem):

• Rust -> Wasm smart contracts for any Cosmos SDK chain
• Actor model — contracts communicate via messages
• Built-in IBC (Inter-Blockchain Communication) support

Substrate / Polkadot:

• Not just smart contracts — you build entire blockchains in Rust
• Substrate is a modular blockchain framework: pick your consensus, pick your runtime, pick your networking
• The runtime is compiled to Wasm and can be upgraded without hard forks (forkless upgrades!)
• Polkadot parachains are Substrate chains that share security with the relay chain
• This is the deepest Rust rabbit hole in blockchain — you’re writing the chain itself, not just contracts on it

Move Language (Aptos, Sui) — The New Wave

Move was designed by Meta (formerly Facebook) for the Diem blockchain. It introduces resource-oriented programming:

• Resources cannot be copied or implicitly discarded — they can only be moved. This prevents the “double-spend at the language level” problem.
• The borrow checker is inspired by Rust’s ownership model. If you know Rust, Move will feel familiar.
• Aptos Move (transaction-centric): Global storage, resources identified by type + address
• Sui Move (object-centric): Everything is an object with a unique ID. Objects can be owned, shared, or immutable. Enables parallel execution for owned objects.
• Move has a formal verifier built into the toolchain — you can write specifications and the compiler checks them
• In 2025, Move added higher-order functions and storable function values, and got a 2x VM performance lift

Why it matters: Move eliminates several classes of bugs that plague Solidity (reentrancy is impossible by design, integer overflow is handled natively). This is the language to watch.

💡 Key Insight: If you already know Rust’s ownership model, Move will feel like home. The resource-oriented programming paradigm is essentially Rust’s borrow checker applied to digital assets — resources can’t be copied or dropped, only moved.

Cairo (StarkNet) — Zero-Knowledge Native

Cairo is purpose-built for creating provable programs using STARKs:

• Every Cairo program can generate a cryptographic proof of its execution
• Syntax is Rust-inspired (Cairo 2.0 is a major improvement over the assembly-like Cairo 1.0)
• Compiles to Sierra -> CASM (Cairo Assembly) -> executed by CairoVM -> generates execution trace -> STARK proof
• StarkNet is an Ethereum L2 that posts STARK proofs to Ethereum mainnet, inheriting its security while processing transactions much cheaper
• If you want to go deep on ZK, Cairo is the language where cryptography meets practical programming

3. DeFi (Decentralized Finance) — Where the Money and CS Problems Live

AMMs (Automated Market Makers) — The Math

The core insight of Uniswap (the most important DeFi protocol):

Constant Product Formula: x * y = k

Where x and y are reserves of two tokens. When you swap, you provide dx and receive dy such that the product remains constant:

(x + dx) * (y - dy) = k
dy = y - k/(x + dx)
dy = y * dx / (x + dx)  // simplified

Uniswap v3 introduced concentrated liquidity — LPs provide liquidity within specific price ranges, dramatically improving capital efficiency. The math shifts from constant product to operating on virtual reserves within each active tick range.

Why this matters for developers: AMMs are pure math running on chain. The Uniswap v2 core contract is ~300 lines of Solidity. The v3 contract introduces tick math, square root price tracking (sqrtPriceX96), and position management — significantly more complex but incredibly elegant.

Study these codebases:

• Uniswap/v2-core — Simple enough to fully understand
• Uniswap/v3-core — Concentrated liquidity, tick math
• Uniswap/v4-core — Hooks architecture, singleton contract

Lending Protocols (Aave, Compound)

How lending works on-chain:

1. Suppliers deposit assets into a pool and receive yield-bearing tokens (aTokens/cTokens)
2. Borrowers post collateral (e.g., deposit ETH to borrow USDC)
3. Over-collateralization is required (typically 150%+) because there’s no credit scoring
4. Interest rates are determined algorithmically based on utilization rate: utilization = borrows / (cash + borrows)
5. If a borrower’s collateral value drops below the liquidation threshold, anyone can liquidate the position (repay the debt and receive the collateral at a discount)

The liquidation mechanism is a beautiful incentive design — it’s a permissionless, competitive market where “liquidators” compete to be first to liquidate underwater positions, earning a ~5% bonus.

Oracles — The Oracle Problem

Smart contracts can’t access external data (prices, weather, API responses). Oracles bridge this gap:

• Chainlink: Network of independent node operators that fetch off-chain data, aggregate it, and post it on-chain. Uses a commit-reveal scheme and reputation system.
• The oracle problem: Your billion-dollar DeFi protocol is only as secure as its price feed. If the oracle reports the wrong price for 1 block, the protocol can be drained.
• TWAP oracles (Time-Weighted Average Price): Uniswap provides on-chain price oracles based on cumulative price over time. Harder to manipulate than spot price.
• Oracle manipulation is one of the most common attack vectors in DeFi. Flash loans + oracle manipulation = instant drain.

MEV (Maximal Extractable Value) — The Dark Forest

This is the most fascinating CS problem in blockchain. MEV refers to the value that can be extracted by reordering, inserting, or censoring transactions within a block.

Types of MEV:

• Frontrunning: See a large buy order in the mempool -> submit a buy before it -> profit from the price increase. Classic information asymmetry.
• Sandwich attacks: Frontrun AND backrun a victim transaction. Buy before their large swap (raises price), let their swap execute (at a worse price), sell after (capturing the difference).
• Arbitrage: Price differences between DEXs. If ETH is $2000 on Uniswap and $2005 on SushiSwap, buy on Uniswap and sell on SushiSwap atomically.
• Liquidations: Race to liquidate underwater positions in lending protocols.
• JIT (Just-In-Time) Liquidity: Provide concentrated liquidity right before a large swap, earn fees, remove liquidity immediately after. Only profitable because you know the swap is coming.

Flashbots is the key infrastructure:

• Provides a private mempool (Flashbots Protect) — your transactions can’t be frontrun because they’re not visible in the public mempool
• MEV-Boost: Separates block proposing from block building. Validators outsource block construction to specialized builders who optimize for MEV
• MEV-Share: Redistributes MEV back to users. Your transaction generates MEV -> you get a refund
• Searchers: Developers who write bots to find and extract MEV opportunities. They submit transaction bundles to builders via Flashbots

Why MEV matters for systems developers: MEV bots are performance-critical, latency-sensitive systems. The best ones are written in Rust. You’re competing against other bots for microseconds — this is HFT-level systems programming applied to blockchain.

⚠️ Watch Out: MEV is the most ethically gray area in blockchain. Pure arbitrage improves market efficiency, but sandwich attacks directly harm users. Understand the distinction before building — your reputation in the ecosystem matters.

Flash Loans — The “Impossible” Financial Instrument

A flash loan lets you borrow any amount of capital with zero collateral, as long as you repay it within the same transaction. If you don’t repay, the entire transaction reverts — it’s as if it never happened.

1. Borrow $10M from Aave (0 collateral)
2. Use $10M for arbitrage, liquidation, or collateral swap
3. Repay $10M + 0.09% fee
4. All in ONE atomic transaction

This only works because of transaction atomicity — everything succeeds or everything reverts. There is no state where the lender has lost funds.

Flash loan attacks are not exploits of flash loans themselves — they’re exploits of vulnerable protocols that become economically viable when you have unlimited capital for one transaction. Total losses from flash loan-enabled exploits exceed $1B.

4. Infrastructure & Tooling

Development Frameworks (2026 Standard):

Node Clients — Where Rust Dominates:

Reth’s architecture (study this):

• Built with the Reth SDK — you can build custom EVM chains by composing components without forking
• ExEx (Execution Extensions): Build custom indexers, bridges, and off-chain services that react to on-chain events
• Base’s L2 node is built on Reth in ~3K lines of code
• Paradigm’s ress project is a stateless Ethereum client built on Reth components

Indexing (Reading Blockchain Data):

• The Graph: Decentralized indexing protocol. You write a subgraph (GraphQL schema + event handlers) and it indexes events from the chain into a queryable database.
• Custom indexing with Reth ExEx: Build your own high-performance indexer in Rust, directly plugged into the node
• Ponder / Envio / Goldsky: Newer indexing tools optimized for specific use cases

RPC Providers: Alchemy, Infura, QuickNode provide hosted Ethereum/Solana nodes. You send JSON-RPC requests to interact with the chain. Self-hosting (running your own Reth/Geth/Lighthouse) gives you full control.

5. Zero-Knowledge Proofs — The Cutting Edge

What ZK proofs actually are:

A ZK proof lets you prove that you know something (or that a computation was done correctly) without revealing the input. More practically in blockchain: you can prove “I executed 10,000 transactions correctly” by posting a single small proof to Ethereum.

The two families:

Why ZK matters (three killer applications):

1. Scalability (ZK-Rollups): Execute thousands of transactions off-chain, generate a proof that all were valid, post only the proof to Ethereum. StarkNet, zkSync, Polygon zkEVM, Scroll, Linea all do this. This is the primary scaling strategy for Ethereum.

2. Privacy: Prove you’re over 18 without revealing your age. Prove you have enough funds without revealing your balance. Tornado Cash (now sanctioned) used ZK proofs for private transactions.

3. Verifiable Computation: Run any computation off-chain (machine learning, game state, complex calculations) and prove on-chain that it was done correctly. RISC Zero’s zkVM lets you write normal Rust code and generate proofs of its execution.

The Rust angle in ZK is enormous:

• RISC Zero: zkVM that executes RISC-V programs and generates STARKs. Write your program in Rust, get a ZK proof for free. The prover is Rust.
• Plonky2/3 (Polygon): Recursive SNARK system written in Rust. Fastest prover in its class.
• Halo2 (Zcash/Scroll): SNARK proving system with no trusted setup. Rust implementation.
• arkworks: Rust ecosystem for SNARK development (finite fields, elliptic curves, R1CS)
• bellman: Zcash’s SNARK library in Rust
• SP1 (Succinct): zkVM built on STARK proofs, prover in Rust
• Almost every production ZK prover is written in Rust because proving is compute-intensive and benefits from Rust’s performance

The ZK developer experience is rapidly improving. With RISC Zero or SP1, you can:

// Write normal Rust code
fn fibonacci(n: u64) -> u64 {
    // ... normal implementation
}

// The framework generates a proof that this computation was correct
// Post the proof on-chain for anyone to verify

This is genuinely revolutionary — you no longer need to think in circuits or constraints to use ZK.

📝 Note: The ZK space is moving incredibly fast. RISC Zero and SP1 are making ZK accessible to any Rust developer. Start here before diving into raw circuit writing — you’ll build intuition for what proofs can do before wrestling with the math.

6. Security — Where the Real Money Is

Common smart contract vulnerabilities:

1. Reentrancy (~$1B+ total losses): A contract calls an external contract, which calls back into the first contract before it updates its state. The DAO hack (2016, $60M) was reentrancy. Still the #1 vulnerability class — $420M in Q1-Q3 2025 alone.

   // VULNERABLE
   function withdraw() {
       uint amount = balances[msg.sender];
       msg.sender.call{value: amount}(""); // External call BEFORE state update
       balances[msg.sender] = 0;           // Too late!
   }
   
   // FIXED (Checks-Effects-Interactions pattern)
   function withdraw() {
       uint amount = balances[msg.sender];
       balances[msg.sender] = 0;           // State update FIRST
       msg.sender.call{value: amount}(""); // External call AFTER
   }

2. Flash loan attacks: Borrow massive capital -> manipulate oracle price -> drain protocol -> repay loan. All in one atomic transaction.

3. Oracle manipulation: Price feeds are only as secure as their weakest link. Manipulating a spot price oracle (even temporarily) can make lending protocols think collateral is worth more/less than it is.

4. Integer overflow/underflow: Pre-Solidity 0.8.0, integers silently wrapped. uint8(255) + 1 = 0. Led to infinite minting, bypassed balance checks.

5. Access control failures: Functions missing onlyOwner or similar guards. Anyone can call admin functions.

6. Frontrunning/MEV: Your transaction is visible in the mempool before execution. Attackers can see and exploit it.

7. Solana-specific: Account validation bugs (not checking account ownership), PDA (Program Derived Address) seed collisions, missing signer checks.

Security tooling:

• Slither: Static analysis for Solidity (Python-based, detects common patterns)
• Mythril: Symbolic execution (explores all possible execution paths)
• Foundry fuzzing: Feed random inputs to find edge cases
• Certora Prover: Formal verification — mathematically prove properties about your contract
• Echidna: Property-based fuzzing for smart contracts

The audit industry:

• Top firms: Trail of Bits ($150K-$200K/yr for engineers), OpenZeppelin ($54K-$257K/yr), Cyfrin, Spearbit, Cantina
• Independent auditors on platforms like Code4rena, Sherlock, Immunefi can earn more with reputation
• Bug bounties: Immunefi has facilitated $100M+ in payouts. Critical bugs pay $100K-$1M+ (Veda protocol offers up to $1M, larger protocols go to $10M+)
• Over $2.2B was stolen through crypto hacks in 2024 alone — there is massive demand for security expertise

Career numbers (2025-2026):

• Junior smart contract auditor: $70K-$100K
• Senior auditor (firm): $150K-$257K
• Independent auditor (top reputation): $200K-$500K+
• Bug bounty hunters (top tier): Variable, but six/seven figures possible
• DeFi quant researcher/trader: $180K-$325K+
• Protocol/security lead: Up to $500K TC with tokens

7. The Rust Angle — A Comprehensive Map

Rust is not just “used in blockchain” — it’s becoming THE language of blockchain infrastructure. Here’s the complete map:

Ecosystem stats (2025): Rust blockchain ecosystem commands $22B+ in TVL, processes 200M+ daily transactions, employs 4M+ developers (doubled in 2 years), with VC investment hitting $13.6B in 2024.

🔮 PART II: 10 PROGRESSIVE PROJECTS — Beginner to Nightmare

Project 1: “Hash Chain” — Build a Toy Blockchain in Rust

Difficulty: 1/5 (Beginner) Time estimate: 1-2 weeks

What you build: A local blockchain with blocks, SHA-256 hashing, merkle trees, and basic proof-of-work. No networking. Single node.

What you’ll implement:

• Block struct: index, timestamp, data, previous_hash, hash, nonce
• SHA-256 hashing with the sha2 crate
• Merkle tree for transaction verification
• Simple PoW: find nonce where hash < difficulty_target
• Chain validation (verify hash linkage)
• ECDSA key generation and transaction signing with k256 or secp256k1 crate

Critical learnings:

• How hash chaining creates tamper-evidence — change one block, all subsequent hashes break
• Merkle proofs — verify a transaction exists in a block with O(log n) data
• The mining puzzle is trivially adjustable — difficulty is just “how many leading zeros”
• ECDSA signatures — the actual cryptographic primitive that secures every blockchain transaction
• Rust-specific: working with byte arrays, serialization (serde), cryptographic crate ecosystem

Reference codebases:

• 0xsouravm/mockchain — Modular Rust blockchain with PoW/PoS, ECDSA, gRPC
• JoshOrndorff/blockchain-from-scratch (228 stars) — Tutorial: state machines -> consensus -> full blockchain
• Build a Blockchain from Scratch with Rust (YouTube playlist by various creators)
• The Bitcoin whitepaper (9 pages, read it end to end)

Project 2: “P2P Gossip” — Networked Blockchain Nodes

Difficulty: 2/5 (Beginner+) Time estimate: 2-3 weeks

What you build: Extend Project 1 with libp2p networking. Multiple nodes discover each other, gossip transactions, and propagate blocks.

What you’ll implement:

• libp2p transport (TCP + Noise encryption)
• Kademlia DHT for peer discovery
• GossipSub for publishing/subscribing to topics (“new_transaction”, “new_block”)
• Mempool: receive transactions from peers, validate, store
• Block propagation: when a node mines a block, gossip it to all peers
• Fork choice rule: longest chain wins (Nakamoto consensus)

Critical learnings:

• P2P networking is hard — NAT traversal, peer churn, message deduplication, bandwidth management
• Gossip protocols — how information spreads epidemically through a network
• The CAP theorem in action — temporary forks are normal; eventual consistency via longest chain
• libp2p is a massive, well-documented Rust codebase — studying it teaches you advanced Rust patterns (async, traits, tower-style middleware)
• Network partitions — what happens when nodes disagree? This is where consensus theory becomes real.

Reference codebases:

• libp2p/rust-libp2p (5.4k stars) — The library itself (study the examples directory)
• Ethereum DevP2P spec

Project 3: “Token Factory” — Your First Smart Contracts on Solana

Difficulty: 2/5 (Intermediate-entry) Time estimate: 2-3 weeks

What you build: A Solana program (smart contract) using the Anchor framework that creates custom SPL tokens, allows transfers, and manages token metadata.

What you’ll implement:

#[program]
pub mod token_factory {
    use super::*;

    pub fn create_token(ctx: Context<CreateToken>, decimals: u8, name: String) -> Result<()> { ... }
    pub fn mint_tokens(ctx: Context<MintTokens>, amount: u64) -> Result<()> { ... }
    pub fn transfer(ctx: Context<Transfer>, amount: u64) -> Result<()> { ... }
}

#[derive(Accounts)]
pub struct CreateToken<'info> {
    #[account(init, payer = authority, space = 8 + TokenMint::LEN)]
    pub token_mint: Account<'info, TokenMint>,
    #[account(mut)]
    pub authority: Signer<'info>,
    pub system_program: Program<'info, System>,
}

Critical learnings:

• Solana’s accounts model is fundamentally different from EVM. Programs are stateless; state lives in accounts. Every account has an owner program, lamports balance, and data.
• PDAs (Program Derived Addresses) — deterministic addresses derived from seeds. No private key exists for them — only the program can sign for them. This is Solana’s version of “contract-owned storage.”
• Account validation — every instruction must validate that accounts are who they claim to be. Anchor does this declaratively with the #[account] attributes.
• CPI (Cross-Program Invocations) — calling other programs from your program. How composability works on Solana.
• Compute units vs gas — Solana meters computation differently than Ethereum.

Reference codebases:

• solana-foundation/anchor — Study the examples directory (basic-0 through basic-5)
• solana-labs/solana-program-library — SPL Token program source code

Project 4: “DEX Core” — Build an AMM on Solana or EVM

Difficulty: 3/5 (Intermediate) Time estimate: 3-4 weeks

What you build: A constant-product AMM (like Uniswap v2) that allows users to create liquidity pools, add/remove liquidity, and swap tokens. Build it on Solana (Rust) or EVM (Solidity tested with Foundry).

What you’ll implement:

• Pool creation: pair two tokens, initialize reserves
• add_liquidity(): deposit tokens proportionally, receive LP tokens
• remove_liquidity(): burn LP tokens, receive proportional reserves
• swap(): constant product formula with 0.3% fee
• Price calculation: output = (input * output_reserve * 997) / (input_reserve * 1000 + input * 997)
• LP token minting: liquidity = min(amount0 * totalSupply / reserve0, amount1 * totalSupply / reserve1)
• Initial liquidity: liquidity = sqrt(amount0 * amount1) - MINIMUM_LIQUIDITY

Critical learnings:

• The constant product formula and why it works — it’s a bonding curve where price is the ratio of reserves
• Impermanent loss — why LP returns diverge from simply holding. The math: IL = 2*sqrt(price_ratio) / (1 + price_ratio) - 1
• Slippage — large swaps move the price. The formula gives you progressively worse rates for larger amounts.
• Front-running — without slippage protection, someone can sandwich your swap. This is where MEV becomes personal.
• The minimum liquidity lock (Uniswap burns 1000 LP tokens to the zero address on first deposit) — prevents the pool from being drained to zero.
• Fixed-point arithmetic — no floating point on chain. Everything is integer math with implicit decimals.

Reference codebases:

• Uniswap v2 Core (Uniswap/v2-core) — ~300 lines, beautifully simple
• Raydium (Solana AMM) — Rust-based DEX on Solana
• If doing Foundry (Solidity): test with fuzzing to find edge cases

Project 5: “Lending Protocol” — Build a Simplified Aave

Difficulty: 3/5 (Intermediate+) Time estimate: 4-6 weeks

What you build: A lending protocol where users can supply assets (earn interest), borrow against collateral, and get liquidated if undercollateralized.

What you’ll implement:

• Supply/withdraw with interest-bearing tokens (receipt tokens)
• Borrow/repay with collateral requirements
• Interest rate model: borrowRate = baseRate + (utilization / optimalUtilization) * slope1 (below optimal), plus a steep slope2 above optimal utilization
• Collateral factor and health factor: healthFactor = (collateral * collateralFactor) / debt
• Liquidation mechanism: when healthFactor < 1, anyone can repay a portion of the debt and receive the collateral at a discount
• Oracle integration (mock for dev, Chainlink/Pyth for production)

Critical learnings:

• Interest rate curves are governance-controlled incentive mechanisms — they balance supply and demand for capital
• The liquidation race — liquidators compete for the bonus. This creates an ecosystem of bots.
• Oracle dependency is the scariest part — if the price feed is wrong for even one block, the protocol can be drained
• Reentrancy in complex protocols — interactions between supply, borrow, and liquidate create subtle reentrancy paths. Use CEI (Checks-Effects-Interactions) religiously.
• Accounting precision — rounding errors accumulate. Use “shares” instead of absolute amounts for yield tracking.
• Composability risk — your protocol can be composed with others in ways you didn’t anticipate (flash loan -> manipulate -> liquidate)

Reference codebases:

• Aave V3 (aave/aave-v3-core) — Production lending protocol
• Aave V4 (aave/aave-v4, 117 stars) — Modular hub-and-spoke design, unified liquidity layer
• Compound V2 (compound-finance/compound-protocol) — Simpler to study than Aave
• Solend (Solana) — Rust-based lending

Project 6: “MEV Searcher Bot” — Extract Value from the Mempool

Difficulty: 4/5 (Advanced) Time estimate: 4-6 weeks

What you build: A bot that monitors the Ethereum mempool, identifies profitable arbitrage opportunities between DEXs, and submits bundles via Flashbots.

What you’ll implement:

• WebSocket connection to an Ethereum node to stream pending transactions
• Transaction decoder: parse calldata to understand what each pending tx does (which DEX, which tokens, how much)
• Arbitrage calculator: given reserves of multiple pools, find profitable circular paths (A->B->C->A)
• Bundle construction: create a transaction that executes the arbitrage, bundle it with the victim transaction
• Flashbots integration: submit bundles to the Flashbots relay, bid for inclusion
• Gas estimation and profit calculation (revenue - gas cost - builder tip > 0)
• Latency optimization: pre-compute common paths, cache pool states

Critical learnings:

• The mempool is a dark forest — every pending transaction is visible. This fundamentally changes the game theory of transactions.
• Atomicity is your friend — if the arbitrage isn’t profitable, the transaction reverts. You only pay gas for the failed attempt (and with Flashbots, you don’t even pay that).
• Latency matters — you’re competing against other searchers. The fastest bot wins. This is where Rust shines.
• MEV-Share — the new paradigm where users get refunds from the MEV their transactions create. Understanding this is understanding the future of Ethereum’s transaction supply chain.
• The builder-proposer separation — understanding how blocks are actually constructed in post-Merge Ethereum.
• Ethical considerations — pure arbitrage improves market efficiency. Sandwich attacks harm users. The line isn’t always clear.

Reference codebases:

• flashbots/mev-share-client-ts (study the concepts, implement in Rust)
• paradigmxyz/artemis — MEV framework in Rust by Paradigm
• paradigmxyz/mev-share-rs — Rust client for MEV-Share

Project 7: “Substrate Chain” — Build Your Own Blockchain

Difficulty: 4/5 (Advanced) Time estimate: 6-8 weeks

What you build: A custom blockchain using the Substrate framework. You’ll define your own runtime logic (pallets), consensus mechanism, and state transition function.

What you’ll implement:

• Custom runtime with pallets (modules): balances, staking, governance
• Custom consensus: experiment with Aura (authority round), BABE (blind assignment), or GRANDPA (finality gadget)
• Storage: Substrate’s key-value trie-based storage
• Extrinsics (transactions): define your own transaction types and validation
• Runtime upgrades: deploy code changes without hard-forking (this is Substrate’s killer feature — the runtime is Wasm)
• RPC endpoints: expose chain data via JSON-RPC

Critical learnings:

• A blockchain is a modular system — consensus, execution, networking, storage are separable concerns. Substrate makes this concrete.
• Forkless upgrades — the runtime is Wasm code stored on-chain. A governance vote can upgrade the chain’s logic without any node restart. This is revolutionary.
• The state transition function is everything — it takes (previous_state, transaction) -> new_state. The rest is infrastructure.
• Weight-based metering (Substrate’s alternative to gas) — each extrinsic’s computational cost is known at compile time via benchmarking.
• Polkadot integration — you can register your chain as a parachain and inherit Polkadot’s shared security.
• FRAME (Framework for Runtime Aggregation of Modularized Entities) — learn how Substrate composes runtime logic from independent pallets.

Reference codebases:

• paritytech/polkadot-sdk — The monorepo containing Substrate, Cumulus, Polkadot
• Substrate Node Template — Starting point for a new chain
• Substrate Kitties tutorial — Classic beginner tutorial

Project 8: “ZK Proof System” — Implement SNARKs from Scratch

Difficulty: 5/5 (Very Advanced) Time estimate: 8-12 weeks

What you build: Implement a simplified zk-SNARK prover and verifier from scratch in Rust. Not using a library — implementing the math.

What you’ll implement:

• Finite field arithmetic: Modular addition, multiplication, inversion over a prime field
• Elliptic curve operations: Point addition, scalar multiplication on BN254 or BLS12-381
• Polynomial commitment: KZG commitments or FRI (Fast Reed-Solomon IOP)
• R1CS (Rank-1 Constraint System): Represent computations as constraint systems
• QAP (Quadratic Arithmetic Program): Convert R1CS to polynomial form
• Groth16 protocol: The SNARK with the smallest proof size
• Verifier: On-chain Solidity contract that verifies proofs

Critical learnings:

• Finite fields are the foundation of everything — all ZK math happens in finite fields. Understanding modular arithmetic, Fermat’s little theorem, and field extensions is prerequisite.
• Elliptic curve pairings — the mathematical operation that makes SNARKs possible. A pairing e(P, Q) maps two curve points to a field element, enabling “encrypted polynomial evaluation.”
• The trusted setup — why it’s needed for SNARKs (the toxic waste problem), and why STARKs avoid it.
• Arithmetic circuits — how any computation is represented as a series of addition and multiplication gates.
• The prover is O(n log n), the verifier is O(1) — this is why ZK is useful. Verification is constant time regardless of computation size.
• This will be the hardest project you’ve ever done. The math is real. But understanding ZK from first principles is an incredibly rare and valuable skill.

Reference codebases:

• Koukyosyumei/MyZKP — Educational zkSNARK implementation from scratch in Rust (with accompanying eBook!)
• arkworks-rs/arkworks (1.1k+ stars) — Production Rust ZK library (study after building your own)
• zkcrypto/bellman (1.1k stars) — Groth16 implementation used by Zcash
• Vitalik’s “An approximate introduction to how zk-SNARKs are possible”
• halo2 book (halo2.zksecurity.xyz) — Halo2 circuit development course
• RISC Zero’s “STARK by Hand” (12-lesson tutorial)

Project 9: “Custom EVM” — Write an Ethereum Virtual Machine

Difficulty: 5/5 (Nightmare-entry) Time estimate: 8-12 weeks

What you build: A from-scratch implementation of the EVM in Rust. Executes Solidity bytecode, handles gas metering, storage, and passes (a subset of) the Ethereum state tests.

What you’ll implement:

• Bytecode parser: read and decode EVM opcodes
• Stack machine: push/pop/dup/swap operations on 256-bit integers
• Memory: byte-addressable, dynamic expansion with quadratic gas cost
• Storage: key-value store (256-bit -> 256-bit) with warm/cold access costs
• Arithmetic: 256-bit add, sub, mul, div, mod, exp, signextend (use ruint or primitive-types crate)
• Control flow: JUMP, JUMPI, JUMPDEST validation
• Environment opcodes: CALLER, CALLVALUE, CALLDATALOAD, CALLDATASIZE, etc.
• CALL, DELEGATECALL, STATICCALL: nested execution contexts
• Gas metering: each opcode costs gas; out-of-gas -> revert
• State tests: run against the ethereum/tests suite to verify correctness

Critical learnings:

• The EVM is elegant in its simplicity — ~140 opcodes, stack-based, deterministic. But the devil is in the details.
• 256-bit arithmetic is everywhere — Ethereum uses 256-bit integers natively. Efficient big-number handling is critical.
• Gas is the economic mechanism — it prevents infinite loops and prices computation. Understanding gas at the opcode level makes you a better smart contract developer.
• DELEGATECALL is the most dangerous opcode — it executes another contract’s code in the caller’s context (storage, msg.sender). This enables proxy patterns but also proxy attacks.
• The state test suite (ethereum/tests) is your ground truth. 10,000+ test cases covering every edge case.
• revm (Rust EVM by Paradigm) is what Reth uses — study it after building your own.

Reference codebases:

• bluealloy/revm — The Rust EVM used in production (Reth, Foundry). Study after building yours.
• ethereum/tests — The official EVM test suite
• ethereum/yellowpaper — The formal EVM specification
• evm-from-scratch — Various community implementations to compare against

Project 10: “ZK-Rollup” — Build a Layer 2 Scaling Solution

Difficulty: 6/5 (Nightmare) Time estimate: 3-6 months

What you build: A simplified ZK-rollup that batches transactions off-chain, generates a validity proof, and posts it to Ethereum. The holy grail: a mini-StarkNet or mini-zkSync.

What you’ll implement:

• Sequencer: Accept user transactions, order them, execute them against the off-chain state
• State management: Sparse Merkle Tree for account states (balance, nonce, contract storage). The root hash is posted on-chain.
• Transaction execution engine: A mini-VM that processes transfers, and optionally, simple smart contracts
• Prover: Generate a ZK proof (STARK or SNARK) that the state transition was correct. Input: old state root + transactions -> output: new state root + proof
• Verifier contract: Solidity contract on Ethereum L1 that verifies the proof and updates the state root
• Data availability: Post transaction data to L1 (calldata or blobs post-EIP-4844)
• Deposit/withdrawal bridge: L1 contract accepts deposits; L2 processes them; withdrawals require proof verification

Critical learnings:

• This is the frontier of blockchain engineering. Building a rollup combines: VM design, cryptography (ZK proofs), smart contract development, distributed systems, and data availability.
• The prover bottleneck — generating ZK proofs is the most compute-intensive part. Real rollups use GPU acceleration, proof markets (multiple provers compete), and recursive proving (prove proofs of proofs to amortize cost).
• Data availability is the real scalability bottleneck. The proof is small, but you need to post enough data for anyone to reconstruct the state. EIP-4844 (blobs) dramatically reduces this cost.
• Escape hatches — a good rollup allows users to force-exit even if the sequencer is offline. This is a critical safety property.
• The economics: rollups pay L1 gas for proof verification and data posting. Revenue comes from L2 transaction fees. The margin is the rollup’s profit.
• You are now operating at the level of the teams building StarkNet, zkSync, Scroll, and Polygon zkEVM. If you can build even a simplified version of this, you are in the top 0.1% of blockchain engineers.

Reference codebases:

• matter-labs/zksync-era — zkSync’s full rollup implementation
• starkware-libs/cairo — Cairo language and StarkNet infrastructure
• scroll-tech/scroll — Scroll’s zkEVM rollup
• risc0/risc0 — RISC Zero’s zkVM (use as your proving backend)
• privacy-scaling-explorations/zkevm-circuits — Ethereum Foundation’s zkEVM circuits

🔮 PART III: THE GENUINELY HARD CS PROBLEMS

These are the problems that make blockchain interesting regardless of market sentiment:

1. Byzantine Fault Tolerance in open networks: How do you achieve consensus when anyone can join, anyone can be malicious, and the network is asynchronous? This is the fundamental theoretical question.

2. State growth: Ethereum’s state is ~150GB and growing. Every full node must store all of it. State rent, state expiry, Verkle trees are active research areas.

3. The trilemma: Decentralization x Security x Scalability — pick two (or find clever trade-offs). Rollups are the current best answer: outsource execution, inherit L1 security.

4. MEV and fair ordering: Is it possible to have fair transaction ordering? Encrypted mempools, threshold decryption, commit-reveal schemes — all being researched.

5. Bridging: Trustlessly moving assets between chains is an unsolved problem. Bridge hacks have lost billions ($600M+ Ronin bridge, $325M Wormhole). Every bridge makes trust assumptions somewhere.

6. Efficient ZK proving: Current provers are too slow for real-time applications. Hardware acceleration (FPGAs, ASICs), proof composition, and better polynomial commitment schemes are active research.

7. Formal verification of smart contracts: Can we mathematically prove a contract is correct? Tools exist (Certora, Move’s verifier, K framework) but adoption is low because writing specs is hard.

⏳ PART IV: OPEN-SOURCE PROJECTS TO STUDY (Ranked by Educational Value)

🔮 PART V: RECOMMENDED LEARNING PATH

Month 1-2: Foundations
+-- Project 1: Hash Chain (understand primitives)
+-- Project 2: P2P Gossip (understand networking)
+-- Read: Bitcoin whitepaper, Ethereum yellowpaper (skim)
+-- Study: Uniswap v2 source code

Month 3-4: Smart Contract Development
+-- Project 3: Token Factory on Solana
+-- Project 4: DEX Core (AMM)
+-- Study: Anchor examples, Foundry testing
+-- Read: Mastering Ethereum (Andreas Antonopoulos)

Month 5-6: DeFi & Security
+-- Project 5: Lending Protocol
+-- Project 6: MEV Searcher Bot
+-- Study: Damn Vulnerable DeFi (CTF challenges)
+-- Study: Ethernaut (Solidity security challenges)
+-- Start: Bug bounty on Immunefi (read past reports)

Month 7-9: Deep Infrastructure
+-- Project 7: Substrate Chain
+-- Project 8: ZK Proof System
+-- Study: Reth source code
+-- Read: Proofs, Arguments, and Zero-Knowledge (Thaler)

Month 10-12: The Frontier
+-- Project 9: Custom EVM
+-- Project 10: ZK-Rollup (ongoing)
+-- Study: revm, zkSync, Cairo
+-- Contribute: Open PRs to Reth, Lighthouse, or Anchor

✅ PART VI: FINANCIAL REALITY CHECK

The Web3 ecosystem pays extremely well for deep technical skills, especially those involving Rust and security:

• Smart contract auditors: $150K-$257K at top firms; independent auditors with reputation can exceed $500K
• Bug bounties: Immunefi has facilitated $100M+ in payouts. Critical smart contract bugs pay $100K-$1M+. Some protocols offer up to $10M for critical findings.
• MEV: Top searcher bots extract millions per year. This is competitive but lucrative.
• Protocol engineering: Core contributors to L1s/L2s earn $200K-$400K+ with token compensation
• ZK engineering: Extremely scarce skill. ZK-rollup teams are hiring aggressively. $200K-$350K+
• Audit competitions: Code4rena, Sherlock, Cantina — compete to find bugs in protocols before launch. Top auditors earn six figures from competitions alone.

The key insight: Web3 pays for scarcity. Rust + blockchain + security is an extremely rare combination. There are more open positions than qualified candidates.

Bottom line: Web3 is genuinely one of the most technically rich domains in computing — combining distributed systems, cryptography, game theory, compiler design, and financial engineering. For a systems developer who loves Rust and low-level programming, the path is: Solana programs -> Reth/revm internals -> ZK proving systems -> custom chain/rollup construction. The ecosystem is heavily Rust-native, the CS problems are real and hard, and the financial incentives (bug bounties, audit fees, protocol engineering salaries) are among the highest in software engineering.