Blockchain & Web3 Fundamentals
In short: A blockchain is a shared digital ledger copied across many computers.
- Transactions are grouped into blocks; each block stores the hash of the previous block, forming a chain, so changing an old record would break every later link.
- A consensus mechanism lets the computers agree on the next block without a central authority.
- Result: a tamper-evident, transparent, append-only record that participants don't have to trust a single party to maintain.
In short: Web2 is today's platform-centric internet: users create content but companies own the data, accounts and payment rails.
- Web3 adds native ownership via blockchains: users hold assets and identity in wallets (private keys), applications are built on open smart contracts, and value can move peer to peer without intermediaries.
- Trade-offs: user responsibility for keys, scalability limits, UX friction and regulatory uncertainty.
In short: A hash function maps any input to a fixed-size output (SHA-256 → 256 bits) that is deterministic, one-way, collision-resistant and changes completely with any tiny input change.
- Blockchains use hashes to link blocks (each header contains the previous block's hash), summarise transactions (Merkle root), derive addresses, and in Proof of Work mining (finding a hash below a target).
In short: A public (permissionless) blockchain lets anyone read, transact and participate in consensus (Bitcoin, Ethereum) — maximally decentralised and censorship-resistant, but slower and fully transparent.
- A private/permissioned blockchain restricts participants to known organisations (Hyperledger Fabric, Corda) — faster, private data channels, governance by a consortium, but less decentralised;
- often used for supply chains and inter-bank settlement.
In short: A program stored on a blockchain that runs automatically and deterministically when called by a transaction, enforcing rules without intermediaries — e.g. an escrow releasing funds when conditions are met, a token contract tracking balances, a DEX swapping tokens.
- On Ethereum, contracts are written in Solidity, compiled to EVM bytecode, are immutable once deployed (unless proxies are used), and every execution costs gas.
In short: A wallet manages private keys and signs transactions; the blockchain holds the balances.
- A seed phrase (12–24 words, BIP-39) is a human-readable backup from which all the wallet's keys are derived.
- If you lose it and the device, the funds are permanently inaccessible — there's no reset.
- If someone else gets it, they can take everything.
- Store it offline; never share it or type it into websites.
In short: In PoW, miners spend computing power to find a valid block hash;
- the chain with the most cumulative work is canonical — very secure and battle-tested (Bitcoin) but energy-intensive.
- In PoS, validators lock up (stake) coins to earn the right to propose and attest blocks;
- dishonest behaviour is punished by slashing — far more energy-efficient (Ethereum cut energy use by ~99.95% after The Merge in Sep 2022) and gives economic finality, but is more complex and can concentrate stake.
In short: Gas measures the computational work of an EVM operation; every transaction sets a gas limit and pays gasUsed × gas price.
- EIP-1559 (London, 2021) introduced a protocol-set base fee per block (adjusts with congestion and is burned) plus an optional priority tip to the validator;
- users specify
maxFeePerGasandmaxPriorityFeePerGas. - Failed transactions still consume gas.
- Gas prevents infinite loops and spam and pays for network resources.
In short: Ethereum token standards (interfaces).
- ERC-20 defines fungible tokens with
balanceOf,transfer,approve,allowance,transferFromand Transfer/Approval events — every unit is identical (stablecoins, governance tokens). - ERC-721 defines non-fungible tokens where each
tokenIdis unique with anownerOfandtokenURIfor metadata (NFTs). - ERC-1155 supports many fungible and non-fungible token types in one contract with batch transfers.
In short: Layer 2s execute transactions off the main chain and post compressed data and proofs to layer 1, inheriting its security while increasing throughput and cutting fees.
- Optimistic rollups (Arbitrum, Optimism, Base) assume batches are valid and allow fraud proofs during a challenge period (~7 days for L1 withdrawals).
- ZK rollups (zkSync, Starknet, Scroll, Linea) post validity proofs, giving faster finality without a challenge window but with more complex proving.
- EIP-4844 blobs (2024) made L2 data much cheaper.
In short: UTXO (Bitcoin): a transaction consumes previous unspent outputs and creates new ones; a balance is the sum of UTXOs you can unlock.
- It's parallelisable and privacy-friendlier (new addresses), but less convenient for complex logic.
- Account model (Ethereum): global state stores balances and contract storage per address, and transactions update them directly — simpler for smart contracts, needs nonces for replay protection.
In short: Smart contracts can only see on-chain data; they can't call web APIs, because every node must produce the same result.
- An oracle is a service that brings external data (prices, sports results, randomness) on-chain, ideally decentralised and tamper-resistant (Chainlink aggregates many data providers).
- Poor oracle design — e.g. using a single DEX pool's spot price — enables price manipulation and flash-loan exploits.
In short: The observation that a blockchain finds it hard to be simultaneously decentralised, secure and scalable — optimising two tends to sacrifice the third.
- Bitcoin and Ethereum L1 prioritise decentralisation and security; high-throughput chains often use fewer, more powerful validators.
- Layer 2 rollups, sharding of data (danksharding/blobs) and better clients try to improve scalability without giving up the other two.
In short: Generate a unique deposit address or payment reference per order (HD wallet derivation, or a payment contract with order IDs), subscribe to new blocks/Transfer events via an RPC provider (Nethereum with WebSockets or a provider's webhooks), match incoming transfers to orders (exact token contract, amount, decimals), wait for N confirmations or finality before marking paid (re-org safety), make processing idempotent (by tx hash + log index), persist state in SQL Server, handle under/over-payments and expirations, keep signing keys in an HSM (Azure Key Vault Managed HSM) if you send refunds, and monitor RPC failures with fallbacks.
- Also account for KYC/AML and tax rules.
In short: Maximal Extractable Value is profit that block builders/searchers make by including, excluding or reordering transactions in a block — e.g. front-running a large DEX swap (buy before it, sell after: a "sandwich attack"), arbitrage and liquidations.
- Users are protected by slippage limits, private transaction relays (Flashbots Protect, MEV-blocker RPCs), batch auctions (CoW Swap) and commit-reveal schemes in contract design.
In short: When a single trusted party (or a small set that already trusts each other) controls the data;
- when you need high throughput, low latency and cheap writes;
- when data must be deleted or kept private (GDPR right to erasure conflicts with immutability);
- when there's no need for censorship resistance or a shared ledger among mistrusting parties.
- A regular database with audit logs, digital signatures or a ledger database (SQL Server ledger tables, Azure Confidential Ledger) is usually simpler, cheaper and faster.
In short: Likely causes: they signed a malicious approval or permit (gasless signature) giving a drainer contract the right to spend their tokens, signed a phishing transaction disguised as a mint/claim, interacted with a compromised frontend, or had malware.
- Protections: show clear human-readable signing (EIP-712), request exact (not unlimited) approvals, warn on known-malicious addresses, use transaction simulation (wallets like Rabby/Blockaid), domain verification, and encourage revoking old approvals (revoke.cash) and using hardware wallets.
In short: Ask: who are the participants and do they distrust each other?
- Who writes data, and who verifies it?
- Blockchain only guarantees that recorded data hasn't been altered — not that it was true when entered (garbage in, garbage out), so you need trusted inputs (IoT sensors, signed attestations).
- Evaluate a permissioned ledger (Hyperledger Fabric) vs a public chain with hashes/anchoring vs a shared database with signed audit logs;
- consider privacy of commercial data, throughput, cost, governance, integration with ERP, and regulation.
- Often the best design anchors document hashes on-chain and keeps data off-chain.
In short: Nonces must be sequential per sending account.
- Concurrent workers sending from the same account race for nonces, and a stuck low-fee transaction blocks later ones.
- Fixes: one nonce manager per account (serialise sends, track the pending nonce in DB/Redis), set EIP-1559 fees from current base fee + a reasonable tip, replace stuck transactions by resending the same nonce with a higher fee (speed-up/cancel), use multiple sender accounts for throughput, and monitor the mempool and receipts with retries.