Consensus mechanisms allow distributed nodes to agree on the state of the ledger. Proof of Work uses computational puzzles, Proof of Stake uses economic incentives through staking.

Byzantine Fault Tolerance: System can function even if up to 1/3 of nodes are malicious or fail.

Example: Ethereum's transition to PoS reduced energy consumption by 99.9% while maintaining security through validator slashing and economic penalties.

Coin: Native cryptocurrency of a blockchain (BTC on Bitcoin, ETH on Ethereum, SOL on Solana). Used for transaction fees and network security.

Token: Built on existing blockchain using smart contracts (USDC, LINK, UNI on Ethereum). Represents assets, utility, or governance rights.

Standards: ERC-20 for fungible tokens, ERC-721 for NFTs, ERC-1155 for multi-token contracts.

The trilemma states that blockchains can only optimize for two of three properties: Decentralization, Security, Scalability.

Bitcoin: Prioritizes decentralization + security, sacrifices scalability (7 TPS)

Ethereum: Moving to PoS + layer 2s (rollups) to scale while maintaining decentralization

Solana: High performance (65k TPS) but more centralized with fewer validators

Binary trees where each leaf is a hash of data and each parent is a hash of its children. Root hash represents entire dataset.

Benefits: Efficient verification (O(log n)), tamper detection, lightweight proofs for SPV clients

Use case: Bitcoin uses Merkle trees in blocks so light clients can verify transactions without downloading full blockchain.

UTXO (Bitcoin): Tracks unspent transaction outputs. More private, parallel processing, but complex for smart contracts.

Account-based (Ethereum): Tracks balances in accounts. Simpler for smart contracts, but sequential nonces and MEV issues.

Cardano: Uses Extended UTXO (eUTXO) to combine benefits—UTXO model with smart contract data.

Public: Open to everyone, fully decentralized (Bitcoin, Ethereum). Use case: Permissionless DeFi, payments

Private: Controlled access, centralized (Enterprise blockchains). Use case: Supply chain, internal auditing

Consortium: Semi-decentralized, controlled by group (Trade finance networks). Use case: B2B transactions

Hybrid: Combines public/private elements (JPM Coin). Use case: Regulated financial products

Hash functions (SHA-256) create fixed-size, deterministic outputs. Any input change produces completely different hash.

Block linking: Each block contains previous block's hash, creating chain. Changing historical data breaks chain.

Avalanche effect: Single bit change in input causes ~50% of output bits to flip, making tampering immediately detectable.

ECDSA: Elliptic Curve Digital Signature Algorithm. Used by Bitcoin and Ethereum for transaction signing.

EdDSA: Edwards-curve signatures. Faster verification, used by Solana and newer chains.

BLS signatures: Allows signature aggregation. Used in Ethereum 2.0 for validator consensus.

Multisig: Requires multiple signatures (m-of-n). Used for treasury management and enhanced security.

Probabilistic finality (Bitcoin): Confidence increases with block depth. 6 confirmations = ~99.9% secure.

Deterministic finality (Tendermint): Immediate finality after consensus. No risk of reorganization.

Ethereum: Moving to faster finality with PoS—about 12-15 minutes for full finality vs 6+ minutes for practical finality.

Consensus mechanism: Nodes agree on transaction order. First valid transaction is accepted, duplicates rejected.

UTXO tracking: Bitcoin tracks unspent outputs. Spent outputs can't be used again.

Nonce/sequence numbers: Ethereum uses account nonces to prevent replay attacks and ensure transaction ordering.

Storage optimization: Pack structs, use bytes32 instead of string, minimize storage writes

Function modifiers: Use 'external' for public functions called externally, 'pure'/'view' when possible

Examples:

• Use ++i instead of i++ in loops
• Cache storage variables in memory
• Use custom errors instead of require strings
• Batch operations to reduce transaction count

Reentrancy: External calls before state updates. Prevention: Checks-Effects-Interactions pattern, ReentrancyGuard

Integer overflow/underflow: Use SafeMath or Solidity 0.8+ built-in checks

Front-running/MEV: Commit-reveal schemes, private mempools, batch auctions

Access control: Use OpenZeppelin's Ownable, role-based permissions, multi-sig for admin functions

Proxy patterns: Transparent proxy, UUPS (Universal Upgradeable Proxy Standard), Diamond pattern

Benefits: Bug fixes, feature additions, emergency responses

Trade-offs: Centralization risk, storage collision issues, complexity, user trust concerns

Best practice: Use timelocks, multi-sig governance, clear upgrade policies, eventual immutability

call: External function call, executes in target contract's context. Returns bool + data

delegatecall: Executes target code in caller's context. Used for proxy patterns. Storage layout must match

staticcall: Read-only call, can't modify state. Used for view/pure functions, safer than call

Purpose: Bring off-chain data (prices, weather, events) to blockchain smart contracts

Oracle problem: Smart contracts can't access external data natively. Need trusted intermediaries

Security risks: Oracle manipulation, flash loan attacks, front-running, centralization

Solutions: Chainlink (decentralized oracles), time-weighted average pricing (TWAP), multiple data sources, circuit breakers

Events: Logging mechanism for smart contracts. Stored in transaction receipts, not in contract storage

Benefits: Cost-effective logging, frontend notifications, indexing for dApps, audit trails

Indexed parameters: Up to 3 indexed parameters for efficient filtering and searching

Use cases: Token transfers, state changes, debugging, analytics, triggering off-chain actions

Problem: Block hash, timestamp easily manipulated by miners. Not cryptographically secure

Solutions:

• Chainlink VRF (Verifiable Random Function)
• Commit-reveal schemes with future block hashes
• Oracle-based randomness with multiple sources
• RANDAO (Ethereum 2.0 beacon chain randomness)

Required functions: totalSupply(), balanceOf(), transfer(), transferFrom(), approve(), allowance()

Required events: Transfer(), Approval()

Key concepts: Approval pattern for third-party transfers, safe transfer checks

Extensions: ERC-20 Burnable, Mintable, Pausable, Permit (EIP-2612 for gasless approvals)

Modifiers: Reusable code that can change function behavior. Run before/after function execution

Example: onlyOwner modifier checks msg.sender == owner before function execution

Best practices: Use OpenZeppelin's AccessControl, role-based permissions, multi-sig for critical functions

Gas consideration: Complex modifiers increase gas costs. Keep logic simple

Unit testing: Hardhat, Truffle with Mocha/Chai. Test individual functions with edge cases

Integration testing: Test contract interactions, multi-contract scenarios

Fuzzing: Echidna, Foundry for property-based testing with random inputs

Tools: Coverage reports, gas profiling, mainnet forking for testing with real data

Web3 provider: MetaMask, WalletConnect, Coinbase Wallet inject window.ethereum

Libraries: ethers.js, web3.js for blockchain interaction, wagmi/RainbowKit for React

Process: Detect wallet → Request connection → Get signer → Create contract instance → Call functions

State management: Track connection status, account changes, network switches, transaction states

IPFS: InterPlanetary File System - distributed file storage using content addressing

Benefits: Immutable content, deduplication, censorship resistance, reduced on-chain storage costs

Use cases: NFT metadata, dApp frontends, document storage, media files

Implementation: Upload to IPFS → Get content hash → Store hash on blockchain → Retrieve via hash

Multi-wallet support: Support MetaMask, WalletConnect, Coinbase, hardware wallets

Error handling: Network mismatch, insufficient gas, transaction failures, user rejection

UX improvements: Gas estimation, transaction status, loading states, clear error messages

Mobile considerations: WalletConnect for mobile wallets, responsive design, mobile-first approach

Legacy transactions: Basic transfers with gasPrice. Simple but less efficient

EIP-1559 (Type 2): Base fee + priority fee. Better fee predictability and UX

EIP-2930 (Type 1): Access lists to reduce gas costs for some operations

Meta transactions: Gasless transactions where relayer pays gas. Better onboarding for new users

Approval process: User approves contract to spend tokens → Contract can transferFrom tokens

UX pattern: Check allowance → Request approval if needed → Execute main transaction

Security: Approve exact amounts, not unlimited. Reset to 0 before changing allowance for some tokens

Gas optimization: Permit (EIP-2612) for gasless approvals, batch approve+action transactions

Optimistic Rollups: Assume transactions valid, use fraud proofs. Examples: Arbitrum, Optimism

ZK Rollups: Use zero-knowledge proofs for validity. Examples: zkSync, StarkNet

Sidechains: Separate chains with bridges. Examples: Polygon, xDai

State channels: Off-chain transactions, settle on-chain. Examples: Lightning Network, Raiden

Transaction lifecycle: Pending → Included → Confirmed → Final

Monitoring: Watch for transaction hash, check receipt, handle replacements/cancellations

Error handling: Parse revert reasons, handle common errors (insufficient gas, reverted transactions)

User feedback: Real-time status updates, retry mechanisms, clear error messages

MEV: Profit extractable by ordering, including, or excluding transactions within blocks

Types: Arbitrage, liquidations, front-running, sandwich attacks

Impact: Higher slippage, failed transactions, worse execution prices for users

Mitigation: Private mempools (Flashbots), commit-reveal schemes, batch auctions, MEV-aware protocols

EIP-2771: Trusted forwarder pattern. Contract checks msg.sender vs _msgSender()

Process: User signs message → Relayer submits transaction → Contract verifies signature

Standards: OpenGSN, Biconomy for relayer infrastructure

Use cases: User onboarding, sponsored transactions, improving UX for non-crypto users

Indexing: The Graph Protocol, Alchemy NFT API, custom indexers for complex queries

Caching: Cache contract calls, use localStorage for user preferences, service workers

Pagination: Limit query results, implement infinite scroll, use cursor-based pagination

RPC optimization: Batch calls, use read replicas, implement circuit breakers for rate limits