Imagine five organisations keeping copies of the same ledger. A new entry arrives, two copies disagree and nobody has appointed a central database administrator. A blockchain is one way to decide which update the group will accept and in what order.
Transactions are grouped into blocks, each block is cryptographically linked to earlier data, and network nodes verify proposed changes under agreed rules. The result can be tamper-evident and resistant to unilateral alteration. Its reliability still depends on what is recorded, who participates in consensus and which facts enter from outside the chain.
What is inside a blockchain?
A transaction describes a requested state change: transferring an asset, calling a program or recording an event. Nodes check that request against protocol rules. Valid transactions can be assembled into a block containing a reference to prior history, normally through a cryptographic hash.
A hash acts like a compact fingerprint. Changing earlier data changes its hash and breaks later references. That makes alteration detectable, but cryptography alone does not decide which competing history the network should accept. A consensus mechanism supplies those ordering and finality rules.
The US National Institute of Standards and Technology describes blockchains as distributed, tamper-evident and tamper-resistant ledgers. “Tamper-resistant” is more accurate than “immutable”: reorganisations, protocol upgrades and governance decisions can change outcomes under defined circumstances.
Nodes, consensus and finality
Nodes perform different jobs. A full node independently checks blocks and transactions. A block producer proposes new blocks. Lightweight clients verify less data and depend on additional assumptions. Running software called a node does not automatically give its operator an equal role in consensus. Collateralised service nodes are another network-specific role rather than a universal consensus class; the masternode guide separates those services from ordinary node validation.
Proof-of-work networks use computation and energy to make competing histories costly. The Monero tail-emission example shows how one proof-of-work network continues funding block production after its main issuance phase. Proof-of-stake networks use capital at risk and protocol penalties. Other distributed ledgers use identified validators or Byzantine agreement; our Hashgraph comparison examines one alternative approach to ordering and finality. Each design makes different trade-offs among participation, speed, cost, finality and resistance to capture.
Bitcoin accepts the valid chain with the most accumulated proof of work, so confidence grows as blocks are added. Our explanation of 51% attacks covers what majority hash power can and cannot change. Other systems provide protocol finality after a specified validator threshold. “Final” can therefore mean different things on different networks.
Public, private and permissioned networks
A permissionless network allows broad participation in submitting transactions and usually in verifying them. Participation in block production may still be economically or technically concentrated. A permissioned ledger restricts validation or access to approved organisations. It may be distributed without being open or censorship-resistant. Hybrid designs can also change over time; our VeChain overview documents its 2025 move from identity-vetted Proof of Authority to Delegated Proof of Stake.
Private blockchains can help organisations coordinate a shared database, but they retain trust in membership administrators and legal agreements. If one company controls every validator and database permission, an ordinary replicated database may be simpler. A blockchain is most useful when several parties need a common history and do not want one participant to rewrite it alone.
How Bitcoin and programmable blockchains differ
Bitcoin’s ledger tracks spendable transaction outputs and applies a deliberately constrained scripting system. The Bitcoin Developer Guide explains how full nodes validate blocks and how proof of work protects transaction history.
Programmable networks such as Ethereum maintain account and contract state. Transactions can invoke code, allowing exchanges, lending markets, games and governance systems to operate onchain. The blockchain provides execution and settlement rules; it does not supply a complete website, private database or trustworthy real-world data. Those components can remain centralised; the dApp architecture breakdown maps that boundary.
What blockchains can prove
A blockchain can prove that valid network participants accepted particular data in a particular order under the protocol rules. Digital signatures can show that a holder of a private key authorised a transaction. They do not prove that the signer understood it, owned an offchain asset or supplied truthful input.
This is the “garbage in, garbage out” boundary. A supply-chain ledger cannot detect a false warehouse scan by itself. Tokenising a property does not automatically transfer legal title. A blockchain oracle can deliver an external price, but the application still depends on that oracle’s accuracy and availability.
Common misconceptions
- “All blockchains are decentralised.” Control can concentrate among validators, developers, governance voters, infrastructure providers or administrators.
- “Data can never change.” Protocols can reorganise recent blocks, upgrade rules or coordinate exceptional interventions.
- “Cryptography makes the whole system secure.” Wallets, bridges, contracts, frontends and users create separate failure points.
- “Public means anonymous.” Addresses are usually pseudonymous and transaction histories can be analysed.
- “Blockchain removes trust.” It relocates trust into software, governance, economics, interfaces and external inputs.
How to evaluate a blockchain
Start with the ledger’s purpose and threat model. Identify who runs validating nodes, who produces blocks, how software upgrades occur and whether administrators can pause, censor or replace contracts. Examine finality, data availability, fees, hardware requirements and dependence on bridges or sequencers.
Then separate the network from the asset and application built on it. A sound consensus mechanism does not guarantee that a token is valuable or a smart contract is safe. The distinction between network validation and user custody becomes clearer in the explanation of keys, wallets and Bitcoin addresses.
The practical test is straightforward: name the parties that need a shared record, the behaviour consensus prevents and the offchain actors that remain trusted. If those answers are vague, adding a blockchain has not solved the underlying coordination problem.
Editorial note: this guide was fully reviewed and rewritten on September 3, 2026.
