What is a Blockchain? (Blocks, Hashes, Consensus)

What Is a Blockchain? A Complete Beginner-to-Builder Guide (with Diagrams)

Beginner Blockchain Basics Hands-on • Updated: 2025-11-07

1) The Distributed Ledger Idea (Why It Exists)

In traditional systems, a single organization (your bank, a game studio, a social network) maintains one authoritative database on its own servers. If they make an error or change a record without notice, there is little you can do. A blockchain replaces that single authority with a network of independent computers (nodes) that all hold the same ledger and constantly check each other’s work.

  • Decentralized: no single operator decides unilaterally; many nodes verify all changes.
  • Transparent: rules are public (protocol code & specifications); data is broadly inspectable.
  • Auditable: history is append-only; anyone can replay the chain to verify the current state.
[Full Node A: complete ledger]   [Full Node B: complete ledger]   [Full Node C: complete ledger]
           |                                  |                                  |
           +----------- gossip new transactions/blocks to peers ------------------+
ELI5: Think of a shared Google Sheet with unbreakable rules. Every row is sealed with a cryptographic “wax stamp.” If anyone edits an old row, the stamp breaks—and everyone sees the tampering immediately.

2) Blocks, Hashes & Merkle Trees (The Cryptographic Backbone)

Blockchains do not add transactions one by one. Instead, they batch transactions into blocks. Each block contains a set of transactions, metadata (time, proposer/miner, gas usage), and a pointer to the previous block’s hash. This pointer is what creates the “chain of blocks.”

A hash is the output of a cryptographic function (e.g., SHA-256 in Bitcoin, Keccak-256 in Ethereum). If you change even a single bit in the input, the resulting hash changes unpredictably. Hashes are perfect tamper-evident fingerprints: if any old block is altered, its hash changes, which breaks every later link in the chain. (NIST primer on hash functions)

Diagram: Blocks linked by previous block hash
Block #101 prev_hash: 0x8f3a...21bd tx_root : 0x557c...aa11 Block #102 prev_hash: 0x4c1e...9a77 ← tx_root : 0x12fe...cafe Block #103 prev_hash: 0xb2a9...c4de ← tx_root : 0x99aa...00ff

Each block stores the hash of the previous block. If Block #101 changes, Block #102’s prev_hash stops matching, and the chain breaks.

To efficiently summarize many transactions, blockchains use Merkle trees (or tries). Transactions are hashed in pairs; those hashes are hashed again, and so on, until one Merkle root remains. With a short Merkle proof (a sequence of sibling hashes), a light client can verify a transaction was included in a block without downloading everything. See Ethereum’s trie structure overview: Patricia/Merkle tries.

Diagram: A simple Merkle tree
H(tx1) H(tx2) H(tx3) H(tx4) H( H(tx1) || H(tx2) ) H( H(tx3) || H(tx4) ) Merkle Root

A Merkle proof lets you verify inclusion of a leaf (e.g., H(tx3)) by providing only its sibling hashes, not the entire block. 

Block #102
  prev_hash: 0x4c1e...9a77
  tx_root : 0x12fe...cafe  // Merkle root
  ...metadata...
  hash     : 0xb2a9...c4de

// If any tx changes, tx_root changes → block hash changes → chain breaks.

3) From Click to Chain: The Transaction Lifecycle

  1. Create & sign: Your wallet builds a transaction (recipient, amount, optional data/method). It signs with your private key (never share it).
  2. Broadcast: The transaction is propagated to peers and sits in the mempool (a public waiting room).
  3. Prioritization: Proposers/miners select a set of transactions, often by fees (or “tips”).
  4. Execution & inclusion: The transactions are executed according to protocol rules and written into the next block.
  5. Confirmations: Each new block that builds on top makes it costlier to reorganize the chain and drop your tx.

On Ethereum, fees are paid in gas. EIP-1559 introduced a dynamic base fee (burned) and a priority tip to compensate validators. Wallets estimate the gas required by simulating the transaction against the current state. (Ethereum transaction docs)

Tip: If your transaction is pending for too long, you can replace it with a new one using a higher fee and the same nonce (speed up) or cancel it (send 0 ETH to yourself with same nonce, higher fee). See MetaMask support for step-by-step instructions.

4) Consensus: How a Network Agrees Without a Boss

Blockchains need rules to choose the next block and to resolve conflicts when more than one valid block is proposed. These rules, consensus protocols make honest behavior economically rational and cheating expensive.

Proof of Work (PoW)

  • Used by Bitcoin (since 2009). Miners compete to find a nonce that makes the block hash lower than a target (computational “lottery”).
  • Security comes from the enormous cost of attempting to redo work faster than the honest majority can extend the chain.
  • References: Bitcoin whitepaper; Bitcoin dev guide.

Proof of Stake (PoS)

  • Used by Ethereum since The Merge (Sept 2022). Validators lock up stake and are randomly selected to propose and attest to blocks.
  • Dishonest validators risk slashing (loss of stake). Far more energy-efficient than PoW.
  • References: Ethereum PoS docs, consensus specs.

BFT-style protocols & hybrids

Some chains use Byzantine Fault Tolerant (BFT) consensus (e.g., Tendermint/CometBFT in Cosmos) or hybrids that combine stake and message rounds to finalize blocks quickly. Reference: CometBFT docs.

5) Forks, Confirmations & Finality (When Is a Tx “Done”?)

Because networks are distributed, it’s possible for two different blocks to appear at the same height. This temporary fork is resolved by a fork-choice rule (e.g., the chain with the most work in PoW, or the chain with the most justified/finalized checkpoints in PoS).

  • Confirmations: Each block added on top of yours lowers the chance it will be orphaned. Bitcoin apps often wait for “6 confirmations.”
  • Finality: Some PoS systems (like Ethereum) add finalized checkpoints after which reorgs are practically impossible without huge penalties. See PoS finality FAQ.
Analogy: A transaction in the latest block is like wet cement—good, but still soft. After several blocks (confirmations), it hardens. After finality, it’s cured concrete.

6) Threat Model: Why This Design Is Secure (and What Can Go Wrong)

  • Cryptography: Hashes make tampering obvious; signatures ensure only key holders can authorize transfers.
  • Chaining: Altering Block N breaks Block N+1’s prev_hash and every block after it.
  • Decentralization: Many verifiers reduce single-point failures and unilateral censorship.
  • Economics: Attacks require huge costs (energy in PoW, staked value in PoS) and risk slashing or lost revenue.

A 51% attack is when an attacker controls a majority of mining power (PoW) or stake (PoS). They can potentially re-order recent transactions (double-spend) but cannot sign away coins they do not control. Mitigations include monitoring reorg depth, waiting for sufficient confirmations/finality, and decentralizing stake/mining pools. Reference: Bitcoin whitepaper §11; Ethereum PoS.

Key safety: Most losses are from poor key management, phishing, or malicious approvals, not protocol failures. Use hardware wallets, verify contract addresses, and set spending limits. Guides: Wallet basics, Ledger support, Trezor learn.

7) Throughput & Scalability: Rollups, Data Availability & Sharding

Base layers (L1s) prioritize security and decentralization, which limits throughput. The most successful approach so far is to move most computation off L1 while keeping verification trust-minimized.

  • Rollups (Layer 2): Batch many transactions and post a succinct commitment to L1. Optimistic rollups use fraud proofs; ZK rollups use validity proofs. Resources: Rollups on ethereum.org.
  • Data Availability (DA): Making raw data available cheaply so anyone can verify state transitions; see EIP-4844 (proto-danksharding) and project docs like Celestia.
  • Sharding / parallelization: Splitting work among subsets of validators (historically part of Ethereum’s roadmap; the strategy evolved with rollups + DA).
Bottom line: Users get faster, cheaper transactions on L2, while L1 acts as the secure anchor for data and finality.

8) What Blockchains Are Good (and Not Good) For

  • Great for: Open money (BTC, ETH), DeFi (DEXs, lending/borrowing), NFTs & tickets, on-chain identity/credentials, timestamping/audit trails, global payments with stablecoins.
  • Mixed: Supply chains (data quality at the edges), gaming economies (UX & fees must be managed carefully).
  • Not ideal: High-throughput private databases where a trusted admin already exists; traditional SQL/NoSQL is simpler, cheaper, faster.

9) Reading a Block Explorer (Your Superpower)

A block explorer lets you inspect the chain: addresses, transactions, blocks, token transfers, logs/events, and contract code. Popular examples include Etherscan, Blockchain.com explorer (BTC), and chain-specific sites (e.g., Solscan).

  • Address page: balances, token holdings, nonce, and history of incoming/outgoing transactions.
  • Transaction page: status (success/pending), fees paid, sender/recipient, method called, emitted events/logs.
  • Block page: block number, timestamp, proposer/miner, gas used, list of transactions, block hash.
Pro move: When debugging a DeFi interaction, always check the logs/events section of your tx. It shows what tokens actually moved and where.

10) Hands-On Exercises (15–45 minutes)

A) Inspect a live transaction (10–15 min)
  1. Open Etherscan → Transactions.
  2. Pick any recent tx. Identify: status, gas used, fee paid, method called, events emitted.
  3. Find the block link; confirm the tx appears in that block’s list.
B) Build & send a safe test transaction (15–30 min)
  1. Install MetaMask (or similar wallet).
  2. Switch to a testnet (e.g., Base Sepolia) and claim test ETH from a faucet (search your network’s docs).
  3. Send a small tx to your second account. Watch it on the explorer; read the logs.
C) Visualize a Merkle proof (15–45 min)
  1. Pick a block, download its transactions (some explorers let you export JSON).
  2. Hash each tx (Keccak-256 for Ethereum), pair and hash up to the root.
  3. For one tx, list the sibling hashes that reconstruct the root (your Merkle proof).
  4. Background: Ethereum Merkle tries.

11) FAQ & Common Misconceptions

“Can anyone just change the blockchain?”

No. Nodes verify every block against strict rules. Changing an old block would alter its hash and require re-doing consensus work (or controlling large stake) faster than the rest of the network—a practical impossibility on established chains.

“Proof of Stake is ‘just voting,’ right?”

Not exactly. Validators must lock economic stake that can be slashed for misbehavior. It’s a game-theoretic system with real financial penalties, not a simple poll. See Ethereum PoS docs.

“If my tx is pending, is my money gone?”

Pending just means it hasn’t been included yet. You can speed up or cancel by sending a replacement transaction with the same nonce and a higher fee. See MetaMask: Speed up / Cancel.

“Why are gas fees sometimes high?”

Demand spikes during popular mints or market volatility. EIP-1559 adjusts base fees; you compete with a tip. Using L2s often dramatically reduces fees while maintaining L1 security via rollup proofs. References: EIP-1559, EIP-4844.

Recap

  • Blockchain = distributed, append-only ledger synchronized by many nodes.
  • Blocks link via hashes; Merkle structures summarize contents efficiently.
  • Consensus (PoW/PoS/BFT) selects valid blocks and makes cheating costly.
  • Security comes from cryptography, chaining, decentralization, and economics.
  • Scaling leans on L2 rollups + robust data availability.
  • Explorers are your window into what actually happened on-chain.

Quick Check

  1. What immediately breaks if someone edits data in an old block?
  2. In one sentence, contrast PoW and PoS.
  3. What problem do Merkle trees solve for light clients?
  4. Why do additional “confirmations” make a transaction safer?
  5. Name one benefit of L2 rollups for users.
Show answers
  • The edited block’s hash changes, breaking every subsequent link in the chain.
  • PoW secures the chain with computational work; PoS secures with economic stake and slashing.
  • They allow verifying inclusion with a short proof instead of downloading the whole block.
  • Each block added on top raises the cost and risk of reorganizing the chain to remove your tx.
  • Cheaper and faster transactions while inheriting L1 security via proofs.

Bonus: Beginner Glossary

Address
Public identifier derived from your public key. Others send funds here.
Private key
Secret that proves you control an address. Never share it.
Nonce
Per-address transaction counter preventing replay. Must be sequential.
Gas
Unit measuring computational work on Ethereum-style chains. You pay gas fees for execution.
Mempool
Public waiting room for pending transactions.
Finality
Point after which a block is extremely unlikely to be reverted.
Rollup
Layer-2 system that executes off L1 but posts proofs/data to L1.

Primary Sources & Further Learning

All links point to primary or widely used references as of Nov 7, 2025. For protocol-level changes, always check the latest official specs.

Next up: understand wallets, addresses, and signatures so you can transact safely and read explorers like a pro.

Next: Public & Private Keys Explained →
Disclaimer: Educational content only, not financial advice. Verify addresses, smart contracts, and network settings before sending funds.