Blockchain

What blockchain is

A blockchain is a shared, append-only ledger that many participants maintain without trusting each other or a central operator. “Append-only” means records can be added but not edited or deleted; “shared” means every participant holds a copy and can verify it themselves; and the “without trusting each other” part is the hard trick that makes blockchains different from ordinary databases.

The defining property is trust minimization. A normal database is owned by someone who can read, write, and change any row. A blockchain is designed so that no single party can rewrite history, censor records, or forge a balance — because doing so would require overpowering or corrupting a majority of an independent network, which the protocol makes prohibitively expensive. You verify instead of trust. That single difference is the whole reason the technology exists.1

Bitcoin was the first blockchain; Ethereum generalized the idea. Today “blockchain” describes a whole category — thousands of networks with different designs, rules, and purposes. They share the same skeleton: a chain of hashed blocks, a consensus rule for agreeing on the next block, and a peer-to-peer network that enforces it. The rest of this page unpacks that skeleton and then is honest about where it does and doesn't pay off.

How it works

At the mechanical level, a blockchain is a sequence of blocks, each containing a batch of transactions and a link to the previous block. The link is a hash — a fixed-size fingerprint of the previous block's contents. Because each block references the hash of the one before it, the blocks form a chain: change anything in an old block and its hash changes, which breaks the next block's reference, which breaks the next, and so on to the tip. Tampering is not forbidden; it is made self-evident.

Transactions and the mempool

A transaction is a signed message authorizing a state change (moving a coin, calling a contract). It goes to the mempool, a holding area of unconfirmed transactions, until a block producer includes it. Each node independently validates every transaction's signature and the rules of the network before accepting a block — there is no “trust the miner.”

Blocks, headers, and Merkle roots

A block is a header plus a list of transactions. The header carries the previous block's hash, a Merkle root summarizing all the transactions, a timestamp, and a nonce (or equivalent). The Merkle tree is what lets a light client prove a specific transaction is in a block without downloading the whole block — a cryptographic shortcut that keeps verification cheap even as chains grow to gigabytes.

Why “append-only” holds

The chain-of-hashes makes tampering visible, but consensus is what makes tampering futile. The network's rule is simple: the longest valid chain (or, in proof of stake, the finalized chain) is the truth. To rewrite history, an attacker would have to produce a competing chain that the rest of the network would accept — which, by design, costs more than it can be worth. That economic guarantee, not cryptography alone, is what makes a blockchain immutable in practice.

The cryptography

Blockchains are built from a small set of old, well-understood cryptographic primitives. There is nothing exotic here — the innovation is in how they are combined, not in the math itself.

Hash functions

A hash function maps any input to a fixed-size, unpredictable output. Bitcoin uses SHA-256; Ethereum uses Keccak-256. The properties that matter: any tiny change to the input completely changes the output (the avalanche effect), the output is effectively irreversible, and the function is fast to compute but impossible to invert. Hashing links blocks, commits to transactions (via Merkle roots), and, in proof of work, is the puzzle miners grind on. Try mining a hash yourself →

Public-key cryptography & signatures

Ownership on a blockchain is a public/private key pair. Your private key lets you sign transactions; your public key (or an address derived from it) is what others see. A digital signature proves a transaction was authorized by the key holder without revealing the key. Different chains use different schemes — Bitcoin moved from ECDSA to Schnorr with Taproot; Ethereum uses ECDSA on secp256k1; many newer chains use Ed25519. Lose the private key and you lose the coins — there is no password reset.

Merkle trees

A Merkle tree hashes transactions in pairs up to a single root. To prove a transaction is in a block you provide a short path of hashes (a Merkle proof) rather than the whole block. This is the data structure that makes blockchains verifiable at scale: a phone can confirm a transaction in a hundred-billion-dollar chain with a few kilobytes of data.

Consensus mechanisms

The hard problem is the Byzantine Generals Problem: how do a group of participants — some of whom may be malicious — agree on a single record over an unreliable network, without a central authority? A consensus mechanism is the answer. It is the rule by which the network decides which block comes next, and it is what makes a blockchain self-policing.

Proof of work

Proof of work (Bitcoin) makes block producers solve a computationally expensive hashing puzzle; the first to solve it wins the right to add a block and earns a reward. The work is real (it costs electricity) and useless for anything except securing the chain, which is the point: an attacker must spend more energy than the honest network to rewrite history, making attacks self-defeating. Finality is probabilistic — the more blocks on top of yours, the safer it is.

Proof of stake

Proof of stake (Ethereum, post-Merge) replaces energy with capital: validators lock up coins and are chosen to propose and attest blocks in proportion to their stake. Dishonest validators are punished by slashing — the forced destruction of their stake. It uses vastly less energy142 and can offer absolute finality (a finalized block cannot be reverted without destroying a third of all stake). The tradeoff is a different set of risks: stake centralization and the “nothing at stake” problem.

Other flavors and the spectrum

There is a whole spectrum. Proof of authority trusts a fixed set of approved validators (common in permissioned and test networks). Delegated proof of stake lets holders vote for a small set of producers. BFT-style protocols (Tendermint, HotStuff) give instant finality by having validators explicitly vote on each block. Each design is a different bet on the tradeoff between decentralization, security, and throughput — the trilemma we come to below. PoW vs. PoS deep dive →

Nodes & the network

A node is a computer running the chain's software, connected peer-to-peer to other nodes. Nodes relay transactions and blocks, validate everything against the consensus rules, and reject anything invalid. The number and independence of nodes is the practical meaning of “decentralization” — a chain run by three nodes in one data center is not decentralized no matter what its marketing says.

• Full nodes store and verify the entire chain from genesis, enforcing every rule themselves. Running one is what gives you sovereignty — you accept only what your own node says is valid.
• Light nodes (SPV) download only block headers and Merkle proofs for their own transactions, trusting the heaviest chain is valid. Most mobile wallets are light nodes.
• Archive nodes keep every historical state, not just the current one — needed for indexers, explorers, and anything querying the chain's past.

The network is peer-to-peer: no central server, no API key, no single point of failure. When you “use” a blockchain through an exchange or app, you are usually trusting that intermediary's node; running your own node is the difference between using the chain and depending on it.

Public vs. private chains

Not all blockchains are open. The big divide is between permissionless public chains (anyone can run a node, read, or write) and permissioned or consortium chains (a known set of vetted parties runs the validators).

Public chains — Bitcoin, Ethereum, and their relatives — trade raw efficiency for censorship resistance and open access. Anyone can join, no one can be kicked out, and the rules change only by consensus. This is why they are slow and expensive per transaction: openness has a cost.

Permissioned chains (Hyperledger Fabric, enterprise deployments) flip the trade. With a known validator set you get high throughput, privacy between participants, and no need for a token or costly consensus — but you also give up the thing that makes blockchains distinctive. If the validators are a fixed group of banks who all trust the same auditor, the honest question is whether you need a blockchain at all, or just a shared database with good access controls. The 2015–2018 enterprise “blockchain for everything” boom produced a lot of projects that quietly became exactly that, and a lasting skepticism about blockchain-for-its-own-sake.

UTXO vs. account model

Blockchains track state in one of two main ways, and the choice has real consequences.

Bitcoin uses the UTXO model: coins are discrete unspent outputs, and a transaction consumes some outputs and creates new ones. It is like physical cash — you hand over a bill and get change. UTXOs make parallel validation easy, enable privacy techniques like CoinJoin, and map cleanly to proof-of-work validation, at the cost of more complex wallet logic and a change address on nearly every transaction.

Ethereum uses the account model: balances are numbers in accounts, debited and credited like a bank ledger. This makes smart contracts natural (a contract is just another account with code) and the UX familiar, at the cost of weaker baseline privacy and a harder time parallelizing execution.

The two are not just cosmetic. They shape how a chain scales, what privacy tooling is possible, and how smart contracts are written. Bitcoin and Ethereum each dive into their model in depth.

The scaling trilemma & Layer 2s

Every public blockchain fights the same tension, usually called the blockchain trilemma: you can have at most two of decentralization, security, and scalability. A chain anyone can validate on cheap hardware (decentralization) and that is expensive to attack (security) cannot also process millions of transactions per second — because every node would have to do all that work. Raising throughput by enlarging blocks or raising hardware requirements buys speed at the cost of making the chain run by fewer, bigger players. This is the core of the block-size war.

The dominant answer is layering: keep the base (Layer 1) small and secure, and push throughput to Layer 2 systems that batch transactions and settle to the base chain. The main flavors:

• Rollups — execute off-chain and post a compressed batch plus a proof to L1. Optimistic rollups assume validity and allow fraud challenges; zk-rollups post a validity proof so L1 mathematically cannot accept an invalid state.
• State channels — open an on-chain channel, transact freely off-chain, close on chain. The Lightning Network is the canonical example.
• Sidechains — parallel chains with their own consensus that bridge to the main chain; more independent, and therefore inheriting less of L1's security.

The pattern across all of them: a maximally secure, minimally expressive base for final settlement, with faster systems on top that inherit its credibility. Ethereum's rollup-centric roadmap is the clearest expression of this bet.

Smart contracts & programmability

A blockchain can be just a ledger (Bitcoin) or a ledger plus a computer (Ethereum). A smart contract is a program deployed to the chain: immutable once deployed, deterministic in execution, and run by every node. The combination — public, unstoppable code that holds and moves value — is what makes decentralized applications possible.

There is a spectrum. Bitcoin's scripting is deliberately tiny, built for spending conditions and little else; Ethereum's EVM is a general-purpose virtual machine; newer chains offer richer or different environments (Move, CosmWasm, Solana's runtime). More expressiveness means more applications — but also a larger attack surface, since every line of contract code is a potential bug that holds real money. The smart-contracts module covers the recurring bug classes; the DeFi exploits deep dive shows what happens when they go wrong.

Immutability & forks

Immutability — the property that past records cannot be changed — is the source of a blockchain's credibility. It is also the source of its hardest governance questions, because sometimes a chain wants to change its own rules.

A fork is a change to the protocol's rules. A soft fork tightens the rules in a backward-compatible way (old nodes still see the new blocks as valid); a hard fork changes the rules such that old nodes reject the new blocks, splitting the network into two chains unless everyone upgrades together. Bitcoin has never had a contested hard fork of its consensus rules and treats that as a feature; Ethereum hard-forks on a schedule and treats that as normal operation. The most consequential fork in crypto history — the 2016 DAO fork — split Ethereum into Ethereum and Ethereum Classic over whether to rewrite history to bail out a hack.

Immutability is never absolute. It is a social contract: the chain is immutable unless the community agrees to change it. The real governance question is who counts as “the community” and how hard it is to reach that agreement — and the answer is different for every chain.

Security & attack surface

A blockchain's security rests on two pillars: the cryptography, which is unbreakable in practice, and the economics, which make attacking the network more expensive than it is worth. Most real losses do not come from breaking either — they come from the layers built on top.

• 51% attacks — controlling a majority of the hash power or stake to censor or reorganize recent blocks. Never successfully sustained against major chains, because the economics are self-defeating, but real on smaller networks.
• Reorgs — a chain reorganization where a previously-accepted block is replaced. Rare and short on major chains; the deeper a block is buried, the safer it is.
• Smart-contract bugs — the largest category of losses by far. Reentrancy, oracle manipulation, and access-control flaws have drained billions. The chain is secure; the code people put on it often is not. Exploits deep dive →
• Bridge hacks — cross-chain bridges hold huge value in complex code and are the single most-hacked category in crypto. Bridge hacks deep dive →
• The oracle problem — contracts that need outside data (prices, events) must trust an oracle, and a manipulated oracle can bankrupt a protocol even when the chain itself is untouched.
• Key compromise — the chain cannot help you if your private keys are stolen or lost. Most “lost” crypto is lost this way, not to network attacks.

The throughline: blockchains make one specific thing — rewriting the shared ledger — extremely hard. They do not automatically secure anything built on top of them, and they do not secure your keys. The security of a crypto system is the security of its weakest link, and that link is almost never the chain.

Privacy & transparency

Public blockchains are radically transparent: every transaction, every balance, every contract is visible to anyone, forever. Addresses are pseudonymous (strings of characters, not names), but pseudonymity is not anonymity. The transaction graph is public, and once an address is linked to a person — through an exchange KYC record, a payment, or a slip — the entire history of that address is exposed. This is why chain analysis is a thriving industry. See how tracing works →

Privacy coins take the opposite bet. Monero hides sender, receiver, and amount by default; Zcash uses zk-SNARKs to prove a transaction is valid without revealing any of its details.196 The tradeoff is regulatory friction: privacy is exactly the property that makes money-laundering controls hard, which is why privacy coins face delistings and bans. The privacy coins module covers the whole tension; the zero-knowledge deep dive covers the math.

The deeper tension is that transparency and privacy are both desirable and partly in conflict. A fully private chain is great for individuals and bad for auditors; a fully public chain is great for verification and bad for anyone who needs confidentiality. The technology is still working out how to give both — selective disclosure and zero-knowledge proofs are the most promising directions.

History & origins

Beyond crypto

Every few years someone proposes a blockchain for a non-financial use — supply-chain tracking, land registries, voting, identity, ticketing. The honest pattern is that most of these either turn into a database or quietly fail, and the reason is structural: a blockchain only earns its keep when you need trust minimization between parties who do not trust each other and cannot agree on a central operator.

Inside one company, a regular database is faster, cheaper, and easier to govern. Between a few known partners who broadly trust each other, a shared database or permissioned ledger usually suffices. The cases where a public blockchain genuinely helps are the cases where the parties have a reason not to trust any single one of themselves — cross-border value transfer, settlement between competitors, systems that must keep working even if any one operator disappears. Central bank digital currencies (CBDCs) and tokenized real-world assets are the current frontier where this question is being worked out in public.

Criticisms & limitations

• The trilemma is real. No public chain has solved decentralization + security + scalability simultaneously; every “solution” is a different point on the tradeoff. Claims of millions of transactions per second usually mean the chain has quietly given up decentralization.
• Energy (for proof of work). Bitcoin's energy use is a genuine environmental concern, defended on the grounds that the energy is often stranded or renewable and that the cost is the point. The energy debate covers both sides.
• “A solution looking for a problem.” The most common outside critique, and it is fair for the long tail of use cases. The honest reply is that the problem it solves — trustless settlement between strangers — is large and historically expensive, and that the cases where it is overkill say more about the cases than the technology.
• Centralization drift. Mining pools, liquid staking, stablecoin issuers, and exchanges all concentrate power in ways that blunt the decentralization story. A chain is only as decentralized as its most concentrated layer.
• Irreversibility as a feature and a bug. Immutability protects against censorship and tampering, but it also means a stolen coin cannot be clawed back and a buggy contract cannot be patched. Consumer protection and self-custody are genuinely in tension.
• Governance is still human. “Code is law” sounds clean until a bug or a hard fork forces a human decision. The social layer never goes away; it just moves out of sight.

Why it matters

Strip away the speculation and the hype, and the genuine contribution of blockchain is narrow but important: it is a way for strangers to keep a shared record — of money, of ownership, of agreements — without appointing a trusted middleman they must all rely on. That is a real thing, and before 2009 no one knew how to do it at scale. Trust minimization, censorship resistance, and verifiable decentralization are properties that databases do not have and, by design, cannot have.

Whether those properties are worth the cost — the energy, the complexity, the irreversibility, the slow throughput — is the real argument, and it has a different answer for each use. For a settlement layer between parties who do not trust each other, the cost is worth paying. For an internal records system, it almost never is. The technology is not a universal upgrade to databases; it is a different tool for a narrower set of problems, and its value depends entirely on whether the problem in front of you is one of them.

Two decades after the cryptographic building blocks were invented and seventeen years after Bitcoin assembled them, that is where the technology actually stands: proven, uneven, and still being argued about — which, for a tool whose whole purpose is to settle arguments without trust, is about right.