Blockchain

Definition: A distributed, append-only ledger where transactions are grouped into blocks, cryptographically linked to the previous block, and replicated across many independent nodes.

How It Works

Transactions are broadcast to the network, collected by nodes, and grouped into a candidate block along with a timestamp
Each block header stores a cryptographic hash of the previous block’s header, this hash pointer is the “chain” in blockchain
Transactions within a block are organized into a Merkle tree, so any single transaction can be verified against the block without downloading the whole block
Before a block is accepted, the network must agree it’s valid through a consensus mechanism, no single party appends blocks unilaterally
Full nodes each store a complete copy of the ledger and independently re-check every new block against the same validation rules, they don’t trust another node’s word for it
Light (SPV) nodes skip storing the full chain and instead verify just block headers plus a Merkle proof for the transactions they care about
Occasionally two valid blocks are produced at nearly the same time, a fork, and nodes temporarily follow different chains until the network converges on one, typically the chain with the most accumulated work or stake behind it
New blocks reference exactly one parent, so the ledger’s history forms a tree in principle but converges to a single accepted chain in practice

Network Types

Public/permissionless: anyone can run a node, validate, or submit transactions, e.g. Bitcoin, Ethereum
Private/permissioned: only approved participants can validate, used inside a single company or consortium
Consortium: a fixed group of organizations jointly operates the validating nodes, common in interbank settlement pilots
Hybrid: a public settlement layer with a permissioned layer on top for specific participants, used by some enterprise chains

Block Anatomy

Field	Purpose
Previous hash	Links this block to its parent, forms the chain
Merkle root	Single hash summarizing every transaction in the block
Timestamp	When the block was proposed
Nonce	A value miners vary to find a valid Proof of Work hash
Transaction list	The actual transfers/contract calls included

Forks

Soft fork: a backward-compatible rule tightening, old nodes still accept new blocks as valid
Hard fork: a rule change that old nodes reject, splitting the network into two chains unless everyone upgrades
Orphan block: a validly mined block that loses the race to another block at the same height and gets discarded by the eventual winning chain

Under the Hood

Hash-linking makes the ledger tamper-evident rather than tamper-proof. Altering history is technically possible, it’s just prohibitively expensive once enough blocks have been built on top of the one you’d need to change.

Hash-Linked Blocks

Block Proposal and Validation

Worked example: why editing one block breaks the chain

Given: Block 101 originally records “Alice sends Bob 5 coins” and hashes to 0x77e9, Block 102’s header stores Prev: 0x77e9
Step: an attacker edits Block 101’s content to say “Alice sends Bob 50 coins”
Step: since a hash is a function of the block’s content, Block 101’s hash changes from 0x77e9 to something like 0x93bc
Step: Block 102 still stores Prev: 0x77e9, which no longer matches Block 101’s real hash, so Block 102 fails validation, and every block after it too
Answer: the attacker must recompute every block from 101 to the current tip and get honest nodes to accept that alternate chain, before they extend the real one further

Worked example: Merkle proof for one transaction

Given: a block contains 2,048 transactions, a wallet wants to confirm its one transaction was included without downloading all 2,048
Step: the block header stores only one Merkle root hash, built by repeatedly hashing pairs of transactions together up a binary tree
Step: the wallet requests a Merkle proof, roughly log2(2048) = 11 sibling hashes along the path from its transaction to the root
Answer: hashing its transaction up through those 11 sibling hashes and comparing the result to the block’s published Merkle root confirms inclusion, without downloading the other 2,047 transactions

Why It Matters

Enables trustless coordination between parties who don’t know or trust each other, no bank, court, or company has to vouch for the ledger’s accuracy
Removes a single point of failure, there’s no central server to hack, subpoena, or shut down to alter the record
Makes the full transaction history independently auditable by anyone running a node, rather than trusted to a private party’s word
Underpins everything else in this glossary section, smart contracts, NFTs, and DeFi all depend on the base ledger’s guarantees
Gives users direct custody of assets through a Wallet, instead of a bank holding the actual ledger entry on their behalf
Provides a common settlement layer that different applications and organizations can build on without negotiating bilateral trust agreements

Common Pitfalls

Assuming “blockchain” automatically means “secure” or “better,” most applications don’t need a decentralized, trustless ledger, and a normal database is faster, cheaper, and easier to fix when something goes wrong
Confusing the blockchain (the ledger and its consensus rules) with cryptocurrency (one application built on top of it), plenty of blockchain use cases don’t involve a tradable coin at all
Treating “on the blockchain” as synonymous with “permanent and true,” a bug or bad input can still permanently record wrong data, immutability preserves whatever was written, not whether it was correct
Underestimating how few nodes some smaller chains actually run, a chain with a handful of validators is far easier to attack than the “thousands of nodes worldwide” framing implies
Forgetting that “immutable” is a matter of degree, a 51% attack or a coordinated hard fork, as happened after The DAO hack on Ethereum in 2016, can rewrite recent history in practice
Overestimating throughput, base-layer blockchains typically process single-digit to low hundreds of transactions per second, far below centralized payment networks
Confusing confirmation count with finality, a transaction with one confirmation can still be reorganized out on some chains, most wallets and exchanges wait for several before treating it as settled

Comparison

	Public blockchain	Private/permissioned blockchain	Traditional centralized database
Who can validate	Anyone (Bitcoin, Ethereum)	Approved participants only	N/A, single operator
Trust model	Trustless, rules enforced by consensus	Trust the approving organization(s)	Trust the database owner
Speed/throughput	Slower, global consensus overhead	Faster, fewer validators	Fastest
Censorship resistance	High	Low to medium	None
Data can be deleted	No, only appended	Usually no	Yes
Governance	On-chain votes or rough consensus among developers	Controlling organization decides	Owner decides
Typical use	Public money, open protocols	Interbank settlement, supply chain	Most business applications

Example

Bitcoin’s blockchain is a public ledger of every transaction since block 0, the 2009 genesis block, replicated across thousands of independently operated nodes worldwide, none of which needs permission to join or verify the chain.

Referenced by

Dig deeper

Spot an error in this note?