A blockchain is a shared record that many computers can verify without asking one central database administrator for the latest version. The name describes part of the design: transactions are grouped into blocks, and each block normally contains a cryptographic reference to an earlier block. The result is an ordered history whose past becomes increasingly difficult to alter as more blocks are added.
That summary is useful, but incomplete. A functioning blockchain also needs rules for valid transactions, a network for distributing data, a consensus mechanism for choosing an accepted history, and incentives or permissions that discourage participants from breaking the rules. Different blockchains make different choices, so “the blockchain” is not one universal machine.
From a transaction to a candidate block
A user begins by creating a transaction, such as sending bitcoin or calling an Ethereum smart contract. The user’s wallet signs the transaction with a private key. Other participants can use the corresponding public key to verify that the signature is valid, without learning the private key. A valid signature proves authorization under the protocol’s rules; it does not prove that the signer is the legal owner of an asset or that the transaction was wise.
The transaction is broadcast to peers. Nodes perform checks before relaying or accepting it. Depending on the network, they may verify the signature, confirm that funds are available, check a nonce that prevents replay, and reject operations that violate size or fee rules. Valid pending transactions wait to be selected by a miner, validator, or other block producer.
A block typically includes a header, a list or compact commitment to transactions, and metadata required by the consensus protocol. Bitcoin uses a Merkle tree to summarize transactions in a Merkle root. Ethereum’s block structure includes commitments to state and transaction data. These commitments let a node detect whether data has changed: even a small change produces a different cryptographic hash with overwhelming probability.
Why blocks form a chain
Each block header references its parent block. If someone rewrites an old transaction, the commitment for that block changes, which changes its block hash and breaks the references in later blocks. An attacker would therefore need to rebuild or replace the subsequent history and persuade the network to accept it. Cryptographic linking makes tampering evident; consensus and economic cost make an alternative history difficult to establish.
“Immutable” is shorthand, not an absolute physical law. A young chain can reorganize when competing blocks appear, software communities can coordinate protocol changes, and an attacker with enough relevant power may reverse recent history. Finality is therefore a spectrum. Users often wait for additional Bitcoin confirmations, while some proof-of-stake systems provide protocol-defined finality after validators attest to checkpoints.
What consensus actually does
Distributed networks can temporarily see different valid blocks because messages take time to travel. Consensus rules help nodes converge on one canonical history. In Bitcoin’s proof-of-work design, miners repeatedly hash block headers, and nodes follow the valid chain with the most accumulated work. Producing an alternative history requires computational work, electricity, and hardware capacity.
Ethereum now uses proof of stake. Validators deposit ETH, propose blocks, and attest to blocks they consider valid. The protocol rewards correct participation and can penalize or slash certain provably conflicting behavior. Its fork-choice and finality rules help nodes agree on the head of the chain and finalized checkpoints. Proof of work and proof of stake use different resources and failure assumptions; consensus does not mean every participant votes on every fact in the outside world.
Permissioned distributed ledgers may use named organizations and Byzantine fault tolerant voting rather than open mining or staking. They can reach fast finality among a smaller known validator set, but users must accept the governance and membership process. The appropriate model depends on whether open participation, performance, regulatory accountability, or organizational control matters most.
Nodes, ledgers, and state
A full node independently checks blocks against protocol rules. That verification is central to the trust model: the node does not accept a payment merely because a miner or block explorer says it occurred. Lightweight clients may verify block headers and request proofs instead of storing and executing everything, trading some independence for lower hardware requirements.
The ledger is more than a spreadsheet of balances. Bitcoin tracks unspent transaction outputs: new transactions consume existing outputs and create new ones. Ethereum maintains account-based state, including balances, contract code, and contract storage. Transactions cause deterministic state transitions. If honest nodes start from the same state, process the same valid ordered transactions, and run compatible software, they should calculate the same new state.
What a blockchain guarantees—and what it does not
A well-functioning public blockchain can provide a verifiable ordering of protocol-valid transactions and strong evidence that recorded data has not been silently changed. It can reduce dependence on one operator and allow anyone to audit rules with node software. Availability and censorship resistance vary with node distribution, validator concentration, network design, and the cost of participation.
Blockchain does not automatically make input data true. If a smart contract receives an incorrect asset price from an oracle, the ledger can preserve and execute the incorrect input perfectly. Public chains are not private by default: pseudonymous addresses and transparent transaction histories can still expose behavior. A transaction’s protocol finality also does not settle every legal question about fraud, ownership, sanctions, insolvency, or consumer rights.
A useful mental model
Think of a blockchain as a replicated state machine with a public rulebook. Digital signatures authorize proposed changes, the peer-to-peer network carries them, block producers order them, consensus selects a history, and nodes verify the result. Cryptography helps reveal alteration, while incentives and governance shape who can influence the system.
When evaluating a blockchain, ask concrete questions: Who may produce blocks? What resource or identity limits attacks? How do nodes choose between competing histories? When is a transaction considered final? Can ordinary users verify the chain? Those answers explain far more than the label “decentralized.”