Blockchain is a distributed digital ledger technology that records transactions across multiple computers in a way that makes the data tamper-resistant and transparent. At its core, blockchain combines cryptography, consensus mechanisms, and peer-to-peer networks to create trustless systems where participants can transact without intermediaries. Understanding blockchain fundamentals—from how blocks link through cryptographic hashes to how networks reach consensus—is essential for anyone working with cryptocurrencies, smart contracts, or decentralized applications. The key insight: blockchain achieves security not through central authority but through mathematical proofs and network-wide verification.
Quick Index
Mind Map
12 tables, 90 concepts. Select a concept node to jump to its table row.
Preparing mind map...
Table 1: Core Components
The fundamental building blocks every blockchain shares — understanding how blocks, hashes, and transactions fit together gives you the mental model needed to reason about anything built on top.
| Component | Example | Description |
|---|---|---|
Header: prev_hash, merkle_root, timestamp, nonceBody: [tx1, tx2, tx3...] | Container for transaction data consisting of a header (metadata) and body (transactions), linked via hashes to form the chain. | |
from: addr1, to: addr2,amount: 0.5 BTC, signature: ... | Record of value transfer including sender, recipient, amount, and digital signature for authentication. | |
SHA-256("hello") =2cf24dba... (64 hex chars) | • Cryptographic fingerprint of data — one-way function producing fixed-size output • any input change produces a completely different hash | |
Every node stores full copy of blockchain | • Decentralized database replicated across all network nodes with no single point of control • all participants maintain identical records | |
merkle_root = hash(hash(tx1+tx2) + hash(tx3+tx4)) | • Binary tree of transaction hashes enabling efficient verification of transaction inclusion without downloading the entire block • root stored in header | |
nonce = 2847563091 | • Random 32-bit number miners adjust to find a valid block hash • essential for the Proof-of-Work puzzle ("number used once"). | |
Bitcoin Block 0: "Chancellor on brink..."Jan 3, 2009 | • First block in a blockchain with no previous block reference • hardcoded into the protocol and establishes the chain's origin and initial state |
Table 2: Consensus Mechanisms
Consensus mechanisms are how decentralized networks agree on the true state of the ledger without a central authority — the choice of mechanism directly determines the network's security, energy use, speed, and degree of decentralization.
| Mechanism | Example | Description |
|---|---|---|
Bitcoin mining: find hash < target | • Miners compete to solve a computational puzzle by finding a hash below the difficulty target • first to solve wins block reward • energy-intensive | |
Ethereum: validators stake 32 ETH | • Validators selected based on staked cryptocurrency • probability proportional to stake • energy-efficient alternative to PoW • dishonest validators risk slashing | |
EOS: 21 elected block producers | • Token holders vote for a small group of delegates to validate blocks • high throughput and fast block times at the cost of some decentralization | |
VeChain, private consortium chains | • Validators are pre-approved trusted nodes with known identities • very fast and low-overhead, suited for permissioned enterprise blockchains | |
Solana: cryptographic timestamps embedded in ledger | • Cryptographic clock that encodes the passage of time directly into the blockchain, enabling validators to agree on transaction order without waiting for consensus rounds • enables Solana's high throughput | |
Network functions with up to 33% malicious nodes | • System's ability to reach consensus despite faulty or malicious participants • ensures agreement even when nodes send conflicting information | |
Adjusts every 2,016 blocks (≈2 weeks) | • Dynamic parameter controlling puzzle complexity • auto-adjusts to maintain target block time despite hashrate changes | |
1 conf = in block; 6 confs = highly secure | • Number of blocks added after a transaction's block • more confirmations = lower reversal risk • standard is 1–6 depending on value transferred | |
Stake 32 ETH → validate blocks → earn rewards | • PoS node that proposes and attests to blocks • selected based on stake • replaces miners in proof-of-stake systems | |
Transaction irreversible after 6 confirmations | • Point when a transaction becomes immutable and irreversible • varies by consensus type (instant in BFT, probabilistic in PoW, epoch-based in Ethereum PoS). | |
Attacker controls >50% hashrate → double-spend | • Occurs when an entity controls majority of network power, enabling transaction reversal and double-spending • economically infeasible on major chains |
Table 3: Cryptography Fundamentals
Blockchain security rests entirely on cryptographic primitives — public-key cryptography, hash functions, and digital signatures make trustless verification possible without any central authority.
| Technique | Example | Description |
|---|---|---|
e9873d79... (32 bytes, 256 bits)Never share! | • Secret key used to sign transactions and prove ownership • must be kept secure — losing it means permanent loss of access to funds | |
04a1b2c3... (65 bytes uncompressed) | • Cryptographic key shared publicly to receive funds • mathematically derived from private key • safe to distribute openly | |
ECDSA(privkey, tx_hash) → (r, s) | • Cryptographic proof that a transaction was authorized by the key owner • verifiable with public key • ensures authenticity and non-repudiation | |
Bitcoin: 1A1zP1eP... (Base58)Ethereum: 0x742d35... (hex) | • Shortened hash of public key used as a receiving identifier • human-shareable format • derived via HASH160(pubkey) or similar | |
Input → a591a6d4... (always 256 bits) | • Cryptographic hash function producing a fixed 256-bit output • collision-resistant • core of Bitcoin's Proof-of-Work and block linking | |
Elliptic Curve Digital Signature Algorithm | • Standard signature scheme using elliptic curve cryptography • provides same security as RSA with smaller keys • used in Bitcoin and Ethereum | |
Prover proves x satisfies a conditionwithout revealing x | • Method of proving the validity of a statement without revealing the statement itself • enables privacy and efficient verification • foundational to ZK rollups | |
Zcash shielded transactions; zkSync Era proofs | • Zero-Knowledge Succinct Non-interactive Argument of Knowledge — small proof size, fast verification, but requires a trusted setup ceremony • used in most ZK rollups | |
Starknet proofs (no trusted setup) | Zero-Knowledge Scalable Transparent Argument of Knowledge — no trusted setup required, post-quantum secure (hash-based), but produces larger proofs than SNARKs. |
Table 4: Network Architecture
The peer-to-peer network layer determines how resilient and decentralized a blockchain actually is — node type, propagation speed, and access model all shape what the network can withstand.
| Type | Example | Description |
|---|---|---|
Each node connects to 8–125 peers | • Decentralized network where nodes communicate directly without a central server • all participants are equal • enhances resilience | |
Downloads and validates entire blockchain (500+ GB) | • Stores complete blockchain history and validates all transactions and blocks • enforces consensus rules independently • most secure node type | |
Pending txs: [tx1: 50 sat/byte, tx2: 20 sat/byte...] | • Temporary storage for unconfirmed transactions awaiting inclusion in a block • each node maintains its own mempool • higher fees = faster inclusion | |
Downloads only block headers (~80 bytes each) | • Stores block headers only • verifies transactions via Merkle proofs • lower resource requirements but partially trusts full nodes | |
Full node + mining software (PoW) | • Full node that attempts to create new blocks by solving Proof-of-Work puzzle • earns block rewards plus transaction fees | |
New block → relay to peers → network-wide in seconds | • Process of broadcasting a new block across the network • propagation delay affects orphan block rate • optimized via compact block relay | |
Bitcoin, Ethereum: anyone can join | • Network where participation is open to all without approval • maximizes decentralization • characteristic of public blockchains | |
Hyperledger Fabric: invited members only | • Network requiring authorization to join and transact • controlled access suited for enterprises • trades decentralization for privacy and efficiency |
Table 5: Transaction Models
How a blockchain accounts for balances and tracks value fundamentally shapes smart contract design, privacy properties, and how fees are calculated.
| Model | Example | Description |
|---|---|---|
Bitcoin: inputs consumed → new outputs created | • Tracks discrete spendable outputs like digital cash • inputs are fully consumed to create new outputs • enhances parallelism and privacy | |
Ethereum: balance[addr] += amount | • Maintains a running balance per address like a bank account • simpler for smart contracts • easier to track total balance | |
Ethereum: (Base + Priority) × Gas Limit | • Transaction cost paid to compensate validators • measured in gwei • higher fee = faster processing • base fee is burned (EIP-1559). | |
Mempool with priority queue by fee | • Collection of broadcast but unconfirmed transactions • miners/validators select from pool for the next block using fee-based prioritization | |
Attempting to spend same BTC twice | • Attack where same funds are used in multiple transactions • prevented by consensus requiring acceptance of the longest/heaviest chain |
Table 6: Block Structure
Every block in a blockchain follows a precise binary structure — understanding the individual fields explains how blocks are verified, linked, and mined.
| Field | Example | Description |
|---|---|---|
Version, prev_hash, merkle_root, timestamp, bits, nonce (80 bytes) | • Compact 80-byte metadata section containing version, previous hash, Merkle root, timestamp, difficulty target, and nonce • the only part hashed in PoW | |
00000000000000000008a89... | • Hash of the prior block's header • creates immutable chain linkage — changing any past block invalidates all subsequent blocks | |
Bitcoin: 3.125 BTC (post-2024 halving) | • Newly minted cryptocurrency awarded to the block creator • combined with transaction fees • halves periodically to control supply | |
Compact bits: 0x1703a30c → target value | • Threshold that the block hash must fall below • lower target = higher difficulty • adjusts to maintain consistent block time | |
Unix time: 1704723600 | • Records approximate block creation time • used for difficulty adjustment • must be greater than the median of the last 11 blocks | |
List: [coinbase_tx, tx1, tx2...] | • Contains actual transaction data • variable size depending on block capacity • validated via Merkle root in header | |
Bitcoin: 1 MB limit; Ethereum: dynamic | • Maximum data capacity per block • affects throughput and decentralization — larger blocks reduce the number of nodes that can validate |
Table 7: Security and Immutability
Blockchain's security model is adversarial by design — these concepts define how the system resists tampering, manipulation, and centralization pressure from both external attackers and insiders.
| Concept | Example | Description |
|---|---|---|
Altering Block 100 invalidates Blocks 101–200,000 | • Property where recorded data cannot be changed without detection • achieved through cryptographic hashing and chain linkage | |
No need to trust counterparty or intermediary | • System where participants transact without trusting each other • trust is replaced by cryptographic proofs and consensus • math-based security | |
No single entity controls the network | • Distribution of authority across many independent nodes • eliminates single points of failure and censorship • core blockchain principle | |
Validator reorders txs to front-run a DEX trade | • Maximum value extractable from block production by reordering, including, or excluding transactions • source of front-running and sandwich attacks in DeFi | |
Ethereum: validator double-signs → 1+ ETH burned | • Penalty mechanism that destroys part of a validator's staked funds for provably malicious behavior such as double-signing • aligns economic incentives with honesty | |
All transactions publicly viewable on block explorer | • Property where all network activity is visible to participants • public blockchains allow anyone to audit • privacy preserved through pseudonymous addresses | |
Modify tx → hash changes → chain breaks | • Design making unauthorized alterations immediately detectable • hash functions and consensus ensure any modification is evident to all nodes |
Table 8: Wallets and Key Management
A wallet is really a key manager, not a coin container — the funds live on-chain while the wallet holds the cryptographic secrets that prove ownership and authorize spending.
| Type | Example | Description |
|---|---|---|
MetaMask, hardware wallet: user controls keys | • User fully controls private keys • maximum sovereignty and full responsibility for security • hardware or software options available | |
Exchange wallet: Coinbase holds your keys | • Third party controls private keys on your behalf • convenient but "not your keys, not your coins" • easier for beginners | |
Ledger, Trezor (offline hardware) | • Wallet stored offline (hardware or paper) • maximum security for long-term storage • immune to online attacks • requires physical access to sign | |
MetaMask, Trust Wallet (online) | • Wallet connected to the internet • convenient for frequent transactions • higher security risk • suitable for small daily amounts | |
12–24 words: witch collapse practice... | • Mnemonic backup for recovering a wallet • generates all private keys deterministically (BIP-39 standard) • must be stored securely offline | |
Single seed → unlimited child keys via derivation path | • Hierarchical Deterministic wallet that derives an entire tree of key pairs from one seed • enables address reuse avoidance and easy backup with a single phrase | |
2-of-3: requires 2 signatures from 3 keyholders | • Wallet requiring multiple private-key signatures to authorize a transaction • eliminates single point of failure • used for treasuries and joint accounts |
Table 9: Smart Contracts & Protocols
Smart contracts are the programmable layer of blockchain — they eliminate intermediaries by encoding business logic directly in tamper-proof code. Understanding the standards, governance patterns, and upgrade mechanisms is essential for any practical blockchain work.
| Concept | Example | Description |
|---|---|---|
if (condition) { transfer(amount); } on Ethereum | • Self-executing code deployed on blockchain • automatically enforces rules when conditions are met • immutable once deployed • no intermediaries required | |
USDC, DAI, UNI — transfer(), balanceOf() | • Ethereum standard for fungible tokens • defines a common API (transfer, approve, allowance) enabling interoperability across wallets and DeFi protocols | |
CryptoPunks, Bored Apes: unique token IDs | • Ethereum standard for non-fungible tokens (NFTs) • each token has a unique ID and cannot be divided • used for digital art, collectibles, and real-world asset tokenization | |
Web3 game: swords (fungible) + unique skins (NFTs) | • Multi-token standard supporting both fungible and non-fungible tokens in a single contract • enables batch transfers and reduces gas costs for gaming assets | |
Chainlink feeds real-world price data on-chain | • Service that brings external data onto blockchain • solves the oracle problem (blockchains cannot access off-chain data natively) • critical infrastructure for DeFi | |
MakerDAO: MKR holders vote on protocol parameters | • Smart-contract-governed organization with no central authority • rules encoded in code • decisions made via token-holder voting • treasury controlled by the group | |
Unique digital artwork or in-game item with provable ownership | • Blockchain token that is one-of-a-kind and non-divisible • ownership and provenance are publicly verifiable on-chain • implemented via ERC-721 or ERC-1155. | |
Bitcoin → Bitcoin Cash (2017) | • Non-backward-compatible protocol change • creates a permanent chain split • all nodes must upgrade • can result in two separate cryptocurrencies | |
SegWit activation (2017) | • Backward-compatible upgrade • old nodes still function • tightens rather than loosens rules • no chain split required | |
Bitcoin reward: 50 → 25 → 12.5 → 6.25 → 3.125 BTC | • Periodic reduction of block reward by 50% • occurs every 210,000 blocks (≈4 years) • controls supply inflation • next Bitcoin halving ≈2028. |
Table 10: Scaling Solutions
Blockchains face a trilemma between security, decentralization, and throughput — scaling solutions attack the throughput constraint by moving computation off the base layer while inheriting its security guarantees.
| Solution | Example | Description |
|---|---|---|
Bitcoin, Ethereum base blockchain | • The base blockchain protocol itself • handles consensus and final settlement • security foundation • limited throughput by design | |
Lightning Network, Arbitrum, zkSync Era | • Secondary protocol built atop L1 • processes transactions off-chain then settles on L1 • increases throughput without sacrificing L1 security | |
zkSync Era, Starknet, Polygon zkEVM | • L2 that batches thousands of transactions off-chain and posts a cryptographic validity proof (zk-SNARK/zk-STARK) to L1 • enables instant finality and fast withdrawals | |
Arbitrum, Optimism, Base | • L2 that assumes transactions are valid and relies on fraud proofs during a ~7-day challenge window to catch invalid batches • simpler to build, wider EVM compatibility | |
Ethereum roadmap: parallel execution shards | • Horizontal partitioning of the blockchain into parallel shards that process transactions simultaneously • multiplies base-layer throughput without L2 dependence | |
Lightning Network payment channels | • Off-chain communication channel between parties where only opening and closing transactions are settled on-chain • enables near-instant, fee-free repeated interactions | |
OMG Network (legacy) | • Early L2 framework using a child chain anchored to Ethereum via Merkle roots • largely superseded by rollups due to data availability challenges and slow withdrawals |
Table 11: DeFi Primitives
Decentralized finance (DeFi) recreates financial services — trading, lending, earning yield — directly in smart contracts, eliminating custodians; knowing the core primitives is prerequisite for building or auditing any DeFi protocol.
| Primitive | Example | Description |
|---|---|---|
Aave, Uniswap, Compound on Ethereum | • Umbrella term for financial services built on public blockchains with no intermediaries • includes lending, trading, derivatives, and insurance powered by smart contracts | |
Uniswap: x * y = k constant product formula | • DEX mechanism that prices assets algorithmically using a liquidity pool rather than an order book • anyone can trade 24/7 against pooled assets | |
ETH/USDC pool on Uniswap | • Smart contract holding pairs of tokens deposited by liquidity providers • enables AMM trading • LPs earn a share of swap fees but face impermanent loss risk | |
Ethereum: deposit 32 ETH → earn ~2.9% APR | • Locking tokens in a PoS protocol to participate in consensus and earn rewards • staked capital acts as a bond that can be slashed for misbehavior | |
Deposit LP tokens → earn governance token rewards | • Strategy of providing liquidity to earn additional protocol tokens on top of swap fees • rewards can come from token inflation and protocol incentives | |
Borrow 1M USDC → arbitrage → repay — all in one tx | • Uncollateralized loan that must be borrowed and repaid within a single transaction • unique to DeFi • used for arbitrage, liquidations, and collateral swaps | |
EigenLayer: restake stETH to secure AVS protocols | • Reusing already-staked assets to secure additional services (AVSs) and earn extra rewards • introduces additional slashing conditions and systemic risk |
Table 12: Cross-chain & Interoperability
With thousands of isolated blockchains, interoperability protocols are the connective tissue of Web3 — they allow assets and data to move between networks, but every bridge also introduces new trust assumptions and attack surface.
| Concept | Example | Description |
|---|---|---|
Wormhole, Chainlink CCIP, Polygon Portal | • Protocol that locks assets on a source chain and mints equivalent tokens on a destination chain • most blockchain hacks involve bridges due to their concentrated value and complexity | |
BTC ↔ LTC swap using HTLC | • Trustless cross-chain exchange using Hash Time-Locked Contracts (HTLCs) • funds are locked until a secret is revealed, ensuring the swap either completes fully or reverts | |
Polygon PoS, RSK (Bitcoin sidechain) | • Independent blockchain connected to a parent chain via a two-way peg • uses its own consensus rules • assets locked on the main chain are represented equivalently on the sidechain | |
WBTC: Bitcoin locked → ERC-20 token on Ethereum | • Token that represents an asset from another chain • the original is locked in a custodian or smart contract while a 1:1 pegged token is minted on the destination chain | |
Cosmos chains trading assets via IBC protocol | • Standardized protocol for trustless messaging and token transfers between independent blockchains • core interoperability layer of the Cosmos ecosystem • maintained as a formal spec |