How a Blockchain Works

Short answer: A blockchain is a shared ledger made of ordered blocks, where each block holds a batch of transactions and the hash of the block before it, so any change to an old record breaks the links that follow and is visible to every computer that keeps a copy. Independent nodes validate new blocks against the same rules and follow the same chain selection rule, which lets strangers agree on one history without a central operator.

What a blockchain is, in plain terms

Think of a blockchain as a notebook that many people copy at the same time. Each page is a block listing transactions in a fixed order. At the top is a short header that summarises the page and points back to the page before it.

Three ideas do most of the work. The pages are linked by hashes, so the order cannot be quietly rearranged. Copies are held by many independent computers, called nodes, so there is no single master copy to edit in secret. The network has a public rule for deciding which next page counts when two candidates appear at the same time.

A blockchain is not a single program and it is not a company database. It is a data structure plus validation rules plus a peer to peer network that keeps copies in sync. Bitcoin and Ethereum share this structure but differ in how they choose block authors and when history counts as settled. Prices move on exchanges. The chain only records transfers and state changes the rules accept. For the market layer, see CryptosEyes markets.

Picture three layers: storage (blocks and the header chain), validation (nodes checking signatures, balances or state, and limits), and consensus (picking one valid history when timing produces more than one candidate). A transaction can be well formed but not yet included. A block can be included but not yet settled with high confidence.

The pieces: transactions, blocks, and headers

Transactions

A transaction is a signed instruction. In Bitcoin, a transaction spends earlier outputs and creates new outputs. The Bitcoin developer guide calls unspent outputs UTXOs and states that a payment is valid only when it uses UTXOs as inputs. A transaction identifier, or TXID, is the hash of the signed transaction data.

In Ethereum, a transaction is an instruction from an account that changes the global state, such as moving ether or calling a contract. Execution clients check funds and signature before the transaction enters the local pool of pending transactions, or mempool. In both systems a transaction is the smallest user action the ledger can accept or reject. Many transactions wait in mempools. Order matters, and later transactions can depend on earlier ones. For definitions, keep the CryptosEyes glossary open.

Blocks and block headers

A block has two parts: a header and a body that holds the ordered list of transactions. The header is small and fixed in purpose even when the body is large. It commits to everything in the body without repeating it.

Bitcoin makes this split explicit. A serialized block contains an 80 byte block header, a transaction count, and then the transactions in raw format. The header holds the previous block hash, the Merkle root, a timestamp, the difficulty target encoding, and a nonce miners vary for proof of work.

Ethereum blocks carry more state because Ethereum tracks accounts and contract storage. Ethereum documentation lists fields such as slot, proposer index, parent root, and state root, with a body holding attestations and an execution payload with the transaction list. The pattern is shared: the header commits to the parent, the transactions, and the resulting state, so a node can check consistency without trusting the sender. Headers also let light clients verify that work or attestations accumulate as expected and request full bodies only when needed.

Hashing: the glue that makes tampering obvious

What SHA-256 does in Bitcoin

Bitcoin uses SHA-256 for proof of work and transaction identifiers. The original Bitcoin design describes proof of work as scanning for a value that, when hashed with SHA-256, produces a hash beginning with a required number of zero bits. Miners hash the 80 byte header with different nonces until the hash is at or below the target. A hash takes input of any length and returns a fixed 256 bit output, shown as 64 hexadecimal characters. The same input always gives the same output. A tiny change gives a very different output that looks random, so a header hash acts as a compact fingerprint for a whole block.

What a good hash function guarantees

Four guarantees matter. Determinism: the same input always gives the same output, so nodes can compare fingerprints. Preimage resistance: given a hash, it is computationally infeasible to reconstruct the input, so a block hash does not reveal its transactions. Collision resistance: it is infeasible to find two inputs with the same output, so data cannot be swapped under the same fingerprint. Avalanche effect: changing one input bit changes about half the output bits unpredictably. The Bitcoin developer guide notes that a good hash converts arbitrary data into a seemingly random number, and any modification produces a new seemingly random number with no way to steer the result.

None of this makes data true. It makes data tamper evident. Alter a transaction and its hash changes, the Merkle root changes, the header hash changes, and every later header pointing to the old hash no longer matches. Detection is cheap. Hiding the change is expensive.

Merkle trees: one short fingerprint for many transactions

A block can contain many transactions. Putting every transaction hash into the header would make the header grow with the block. A Merkle tree solves this by hashing transactions in pairs, then hashing the results in pairs, until one hash remains: the Merkle root. Only the root goes into the header. The Bitcoin developer guide describes the same process, noting that an odd last hash is paired with a copy of itself, and that transaction order in the block must match TXID order in the first row of the tree.

Merkle trees exist for two reasons: compact commitment (one 32 byte root commits to the full ordered list) and efficient inclusion proofs (proving one transaction sits in a block needs only the hashes on the path to the root, so a light client need not download every transaction).

Worked mini example with four transactions, illustrative

The following numbers are illustrative and shortened for readability. They are not live chain data.

Suppose a block contains four transactions labelled TxA, TxB, TxC, and TxD, with hashes H(A) = a1, H(B) = b2, H(C) = c3, and H(D) = d4. Pair and hash the first level: H(AB) = hash(a1 + b2) = ab12 and H(CD) = hash(c3 + d4) = cd34. Pair the second level: Merkle root = hash(ab12 + cd34) = root99. Only root99 goes into the block header.

To prove TxC is in this block, a verifier needs d4 and ab12 plus the root. The verifier computes hash(c3 + d4) to get cd34, then hash(ab12 + cd34) and checks it equals root99. Alter TxC and the check fails. Real hashes are full length SHA-256 outputs, often applied twice for TXIDs, and real blocks hold far more than four transactions. The structure is the same.

Linking blocks into a chain

Each block header stores the hash of the previous block header. That field turns blocks into a chain. The genesis block is first and has no parent. Every later block points to one parent by hash.

Ethereum documentation states the same principle: blocks are batches of transactions with a hash of the previous block in the chain, and because hashes are cryptographically derived from block data, one change in any block in history would invalidate all following blocks since all subsequent hashes would change.

Suppose an attacker edits a transaction in block 100. The transaction hash, the Merkle root in block 100, and the header hash of block 100 all change. Block 101 stored the old header hash as its previous block hash, so it now points to a parent that no longer exists in that form. The attacker must rebuild block 100, then 101 with the new previous hash, then 102, and so on to the tip. In proof of work chains each rebuilt block needs new proof of work. In proof of stake chains each needs validator signatures honest validators will not provide for a conflicting history. Depth is therefore protection: a transaction near the tip can be displaced by a competing branch, while a buried transaction requires rewriting all that later work or stake weighted support.

Building one block, step by step, illustrative walkthrough

The table below is a simplified illustrative example of a single block being built, from pending transactions to a linked header. Hash values are shortened and labelled illustrative. They are not live chain data and are not taken from Bitcoin or Ethereum mainnet.

Transactions determine the Merkle root. The Merkle root plus the previous hash determine the header. The header determines the block hash, which becomes the anchor the next block must reference. That loop is the chain mechanism in one pass. The BTC asset page and the ETH asset page track assets on chains built with this same pattern, even though block author selection differs.

Nodes: who stores the ledger

A node is a computer running the chain software. Nodes receive transactions and blocks, validate them, store accepted history, and relay valid data. When several nodes hold the same blocks, the Bitcoin developer guide describes them as being in consensus: copies match because each node applied the same rules.

Full nodes, light clients, miners and validators

A full node stores the full history or a pruned version that still validates from genesis, and checks every transaction and block on its own without trusting an exchange or explorer. Anyone can run one, and the security model assumes many independent operators do.

A light client stores headers and requests inclusion and state proofs as needed, trading independence for lower storage and bandwidth. The Bitcoin whitepaper calls this Simplified Payment Verification: keep the headers of the longest proof of work chain and obtain the Merkle branch linking a transaction to its block. Ethereum light clients use sync aggregates and checkpoint data in a similar role.

Miners and validators are nodes that also propose blocks: miners compete on proof of work, validators stake ether and are selected to propose and attest. An invalid proposal gains nothing, because full nodes reject invalid blocks regardless of source. Block production is gated by work or stake. Validation is open to every node. A price chart, wallet interface, or exchange does not store the ledger for you. If you do not run a node, you trust the service reporting chain data to you.

Consensus: how strangers agree without a central operator

Validation alone is not enough. Nodes also need a rule for choosing between two valid candidate histories, because network delay lets two producers create competing blocks at nearly the same height. A consensus mechanism is the full stack of protocols, incentives, and fork choice rules that lets distributed nodes agree on the chain state, which is the framing Ethereum documentation uses. Proof of work and proof of stake decide who may propose the next block and provide Sybil resistance, meaning they make fake identities costly. Fork choice decides which chain to follow. For a direct comparison, see proof of work vs proof of stake.

Bitcoin proof of work in plain English

Miners assemble a candidate block and search for a nonce that makes the header hash fall at or below the target. The search is a lottery weighted by computing power. The first miner to find a valid hash broadcasts the block. Other nodes verify it and start building the next candidate on top.

Difficulty keeps the tempo steady. Every 2,016 blocks the network measures how long the last 2,016 blocks took using header timestamps. The ideal is 1,209,600 seconds, two weeks, or ten minutes per block on average. Faster means difficulty rises. Slower means it falls. The ten minute target is an average maintained by this retarget, not a timer.

Nodes follow the chain with the most cumulative proof of work, often called the longest chain. When two blocks compete at one height, nodes keep the first they saw. When the next block extends one branch, that branch has more work and nodes reorganise onto it. The losing block becomes stale, and its transactions can return to mempools if still valid. The coinbase in a main chain block pays the subsidy plus fees. A losing branch block pays nothing the main network will honour, so honest extension pays when honest miners hold the majority of hash power.

Ethereum proof of stake in plain English

Ethereum now uses proof of stake. Validators deposit 32 ether and run execution, consensus, and validator software. Time is divided into slots of 12 seconds and epochs of 32 slots. In each slot one validator is selected at random to propose a block, and a committee attests to the head block.

The proposer bundles transactions into an execution payload, executes them to compute a new state, and wraps the result in a beacon block carrying attestations, deposits, exits, and slashing records. Other validators re execute the transactions, check the state change, then attest. Fork choice follows the chain with the greatest attestation weight, weighted by staked ether, using LMD GHOST combined with the Casper finality gadget, together called Gasper. Stake is the scarce resource limiting fake identities. Proposing multiple blocks for one slot or sending contradictory attestations can be proven from signed messages and punished by slashing, which destroys part or all of the stake. The tempo is fixed by the slot clock, although a proposer can miss its slot.

Finality: when is a block really settled

Inclusion is not settlement. A tip block is the current best view, but a short reorganisation can replace it. Finality describes how confidence grows until reversal becomes impractical or economically prohibitive.

Probabilistic finality in Bitcoin

Bitcoin has probabilistic finality. No block is marked absolutely irreversible. Confidence grows with each confirmation, meaning each block built on top of the block holding your transaction. The whitepaper shows the probability of a slower attacker catching up falls exponentially as blocks are added. One confirmation means inclusion once. Six confirmations means five blocks built on top, so an attacker must redo six blocks of work and outpace the honest chain. Services pick thresholds by value at risk. Settlement is a risk curve, not a switch.

Checkpoint finality in Ethereum

Ethereum proof of stake adds explicit finality through checkpoints. The first block in each epoch is a checkpoint. Validators vote on pairs of checkpoints. If a pair attracts votes representing at least two thirds of total staked ether, the target checkpoint becomes justified and the earlier checkpoint becomes finalized. Ethereum documentation names this mechanism Casper the Friendly Finality Gadget, or Casper FFG.

A finalized block cannot be reverted without a large amount of ether burned through slashing. Reverting finality would require at least one third of staked ether to be slashed for contradictory votes. If finality stalls for more than four epochs, an inactivity leak reduces the stake of validators not voting with the majority until a two thirds majority can be restored. Fork choice handles the head slot by slot. Checkpoint votes handle settlement epoch by epoch.

Forks: when the chain briefly splits

A fork is a divergence where nodes follow different branches. Short forks are normal. The Bitcoin guide notes that when miners produce simultaneous blocks, each node keeps the block it saw first, and the tie breaks when the next block extends one branch. The other branch blocks become stale.

Forks also arise from rule changes. A soft fork tightens rules so upgraded nodes reject some blocks older nodes would accept, but older nodes still accept upgraded blocks, so one chain can persist with majority producer support. A hard fork changes rules older nodes reject, which can split the network into two chains. A brief tip fork is expected and resolves by fork choice. A lasting fork means the network has divided over rules or an attack.

What a blockchain does not do

A blockchain guarantees that accepted history is hard to rewrite quietly. It does not guarantee the data entered was correct. A false statement written into a transaction or contract is preserved with the same fidelity as a true one. The ledger proves an input was submitted, signed, and included at a given position. It does not prove an off chain claim matches reality. Oracles, auditors, and counterparties still carry that burden. A blockchain does not make false data true.

A blockchain is not fast by default. Bitcoin targets ten minutes per block on average, with throughput bounded by block size and validation cost so ordinary nodes can keep up. Ethereum blocks every 12 seconds when proposers are online, but every full node re executes transactions and gas limits cap computation per block. Scaling designs move execution off the main chain and post commitments back, covered at layer 1 vs layer 2. The base layer stays conservative because every node must be able to check the result.

A blockchain is not private by default. Ledgers are public. Addresses are pseudonymous, but transaction graphs, amounts, timing, and contract calls are visible to anyone who downloads the chain and can be clustered. Privacy needs additional techniques, and the base record remains public. A blockchain is also not free storage: every full node stores the data or a commitment to it, and fees ration that resource. Large files belong off chain with only a hash on chain. Key management, software bugs, and contract errors sit outside the header guarantees. The chain executes validly signed instructions exactly as written, including ones the signer later regrets.

Frequently Asked Questions

If every node has a copy, who is in charge of the blockchain?

No single operator is in charge. Each node enforces the same rules on its own copy and rejects invalid proposals regardless of source. Rule changes need node operators to adopt new software. A chain nobody runs has no authority.

Can someone edit an old transaction without anyone noticing?

In practice, no. Editing a transaction changes its hash, the Merkle root, and the block hash, which breaks the previous block hash link in every later block. Nodes hold the original headers and reject a rewritten branch unless it also satisfies the consensus proof: more cumulative work in Bitcoin, or supermajority attestation and finality support in Ethereum.

What stops a miner or validator from including invalid transactions?

Full nodes check every transaction in every block. An invalid transaction, such as spending a spent output in Bitcoin or a bad state change in Ethereum, makes honest nodes reject the whole block. The producer loses its expected reward and wastes the work or the slot.

Why does Bitcoin wait about ten minutes between blocks?

It is an average target, not a timer. Every 2,016 blocks the network compares actual elapsed time to the ideal 1,209,600 seconds and adjusts difficulty so the next span should again average ten minutes per block. Ten minutes balances global propagation time against confirmation latency and keeps short forks uncommon.

How is Ethereum finality different from Bitcoin confirmations?

Bitcoin confidence grows block by block with no defined point of absolute settlement. Ethereum adds checkpoint votes at epoch boundaries. With support from at least two thirds of staked ether, checkpoints become justified and then finalized. Reverting a finalized checkpoint would require a large slashable offence.

Does a blockchain make the information in it true?

No. The chain proves ordering, inclusion, and tamper evidence. It does not verify off chain facts. Inaccurate data submitted in a valid transaction is preserved reliably. Accuracy depends on the submitter and on any oracle feeding the chain.

Do I need to run a node to use Bitcoin or Ethereum?

No. Wallets connect to nodes run by others. Running your own node removes the need to trust that reporting layer and gives you an independent copy of the rules and history. Most users rely on a provider for convenience.

Sources