Blockchain Fundamentals: Blocks, Consensus & Finality

Blockchain Fundamentals

A blockchain is an append-only log replicated across machines that don't trust each other, where the order and contents of entries are agreed without a coordinator. Strip away the terminology and you have a distributed systems problem with an unusual threat model: not just crash failures, but participants actively trying to rewrite history for profit.

The design follows from that threat model. Entries are batched into blocks, each block commits to the previous one by hash so tampering is detectable, entries are authorized by digital signature so nobody can spend what they don't own, and a consensus mechanism makes producing a competing history expensive enough that nobody bothers. Everything else — smart contracts, tokens, rollups — is built on those four ideas.

TL;DR

A blockchain is a hash-linked chain of blocks: each header contains the previous block's hash, so altering old data invalidates everything after it.
Digital signatures authorize transactions; your private key is your account. There is no password reset.
Consensus decides who appends next — proof of work spends electricity, proof of stake bonds capital that can be slashed.
Finality is probabilistic in PoW (wait N confirmations) and explicit in modern PoS (a checkpoint you can point to).
Merkle trees let a light client verify one transaction is in a block without downloading the block.
The blockchain trilemma: decentralization, security, scalability — pick two, or move work to layer 2.
Blockchains are slow, expensive, and fully public by design. Use one only when multiple distrusting parties need shared state without an intermediary.

Quick Example

The whole structure, in fifty lines:

Change one transaction in block 5 and its merkle_root changes, so its hash changes, so block 6's previous_hash no longer matches — and every subsequent block must be re-mined. That cascade is the entire immutability guarantee.

Core Concepts

The chain

Keys, addresses, and signatures

There is no account recovery. Losing the private key means losing the assets permanently; a leaked key means anyone can spend as you. This is the most consequential difference from any conventional system, and it's why wallet and key-management design is treated as a first-class problem rather than a UI detail.

⚠️ Warning: Never enter a seed phrase or private key into a website, a support chat, or any tool that asks for it. Legitimate applications ask you to sign with a wallet; they never ask for the key itself. This is the single most exploited pattern in the space.

Merkle trees

This is what makes light clients possible: a phone can verify that a transaction was included without storing hundreds of gigabytes of chain data.

Consensus

Consensus answers "who gets to append the next block, and why should anyone accept it?"

The economic argument is the same in both: make honest participation more profitable than attacking. PoS adds a property PoW lacks — misbehavior is punishable, not merely unprofitable, because the validator's bonded stake can be destroyed.

Other mechanisms exist for different trust models: proof of authority (known validators, used in consortium and test networks), BFT variants like Tendermint (fast finality, fixed validator sets), and proof of history (Solana's verifiable clock, used alongside PoS).

Finality and forks

The practical consequence for application developers: a transaction that is "confirmed" is not necessarily permanent. Exchanges and bridges wait for a chain-specific confirmation depth precisely because reorgs happen.

The trilemma

The trilemma is a heuristic rather than a theorem, but it holds well in practice: every increase in throughput at layer 1 has come with heavier hardware requirements for validators, which reduces how many people can run one. Rollups are the dominant response — execute elsewhere, settle on a chain that stays decentralized.

What Blockchains Are Actually Good For

Blockchains are far slower and more expensive than a database, so the question is always what you get in exchange. What you get is: shared state that multiple distrusting parties can verify and none can unilaterally alter.

When a database is better

If any of these is true, use PostgreSQL:

One organization controls the data, or all participants trust a common operator.
You need high throughput, low latency, or low per-write cost.
The data is private or subject to deletion requirements — see the GDPR problem below.
You need to correct mistakes.
The "decentralization" is nominal — a permissioned chain run by one company is a database with extra steps.

This is not a marginal caveat. Most proposed blockchain applications fail this test, and being able to apply it is the most useful thing an engineer can take from this page.

Best Practices

Treat key management as the primary security problem

Keys are the whole security model. For users: hardware wallets and never entering a seed phrase anywhere. For applications: never handle user private keys at all — have the user sign in their own wallet. For services that must hold keys: HSMs or a managed KMS, multi-signature for anything valuable, and strict separation from application servers.

Wait for an appropriate confirmation depth

Reorgs are normal. Choose a confirmation threshold based on the value at risk and the chain's finality model, and don't credit irreversible off-chain value (shipping goods, releasing fiat) before it's met.

Assume everything on-chain is public forever

There is no private on a blockchain. Contract storage marked private is readable by anyone with an RPC endpoint, transaction data is permanently archived, and addresses are trivially linkable across transactions. Never put personal data on-chain — hash it and store the data off-chain if you need a commitment.

Design for immutability from the start

You cannot delete or amend on-chain data. Applications need an explicit story for corrections: versioned records, a supersede-and-mark-invalid pattern, or an off-chain layer that holds mutable state with only commitments on-chain.

Use an established chain and established libraries

Rolling your own chain, consensus, or cryptography is a research project, not an engineering task. Use Ethereum or an EVM chain and audited libraries; the failure modes of DIY cryptography are catastrophic and silent.

Understand the cost model before designing

Storage on-chain is extraordinarily expensive relative to any other medium. The standard architecture is: commitments and ownership on-chain, bulk data off-chain (IPFS, Arweave, or ordinary object storage) with the hash recorded on-chain. Designing as though on-chain storage is free produces applications nobody can afford to use.

Common Mistakes

Assuming "private" means private

Trusting block timestamps

Treating one confirmation as final

Putting personal data on-chain

Building a "private blockchain" where a database belongs

Reusing a key across environments

Test and production keys must never overlap. A key that has touched a testnet faucet, a CI log, or a developer laptop is compromised; treat it as public.

FAQ

Is blockchain the same as cryptocurrency?

No. A cryptocurrency is one application of a blockchain — the first one, and still the one that funds the security model. A blockchain is the underlying data structure and consensus system, and it can record any state: ownership, attestations, contract execution. The dependency runs one way: in a permissionless chain, a native token is usually necessary to pay validators and meter execution, which is why "blockchain without a token" typically means a permissioned system.

How many transactions per second can a blockchain handle?

Bitcoin is around 7, Ethereum layer 1 around 15–30, high-throughput chains claim thousands, and rollups reach thousands with L1 security. For comparison, Visa handles tens of thousands. This gap is why layer 2 exists and why no serious design puts high-frequency operations directly on a decentralized L1.

What is a 51% attack?

An attacker controlling a majority of the consensus resource can censor transactions and reverse recent ones by building a longer competing chain. They cannot steal funds from arbitrary accounts — that would require forging signatures — and they cannot alter deeply buried history. On large chains the cost is prohibitive; on small ones it's been done repeatedly, which is why chain choice is a security decision.

Can data be deleted from a blockchain?

No, and this is a genuine legal tension with data protection regimes that grant erasure rights. The accepted engineering answer is to never put personal data on-chain: store a hash as a commitment and keep the underlying data in a system you control and can delete from. "Crypto-shredding" — encrypting on-chain data and destroying the key — is sometimes proposed, and its legal sufficiency is unsettled.

What's the difference between a public, private, and consortium chain?

Public chains are permissionless — anyone can read, transact, and validate. Private chains are run by one organization. Consortium chains are run by a group of known organizations. Only public chains provide the trustlessness that motivates the architecture; private chains are a database with more overhead. Consortium chains have a narrow legitimate niche where several distrusting organizations need shared state with known identities, though even there the honest comparison should be against a signed, replicated log.

Is this environmentally damaging?

Proof of work is genuinely energy-intensive — Bitcoin's consumption is comparable to a mid-size country's. Proof of stake is not: Ethereum's transition cut its energy use by more than 99%, since validators only need to run ordinary servers. Most active development today is on proof-of-stake chains and rollups, so the environmental objection applies to a shrinking, though still significant, part of the ecosystem.