How blockchains work: the complete guide

What a blockchain actually is

A blockchain is a shared, append-only ledger maintained by a network of independent computers that do not trust one another, yet arrive at agreement on a single history of transactions without a central authority. Strip away the jargon and it is a database with two unusual properties: no one is in charge of it, and once data is recorded and settled, changing it is computationally infeasible. Those two properties, working together, are what let strangers exchange value directly.

Traditional systems achieve trust through an intermediary — a bank confirms your balance and executes your transfer, and you trust the bank. A blockchain replaces that intermediary with three ingredients: cryptography to prove who authorised each transaction and to link records tamper-evidently, a consensus mechanism so that distributed participants agree on which transactions are valid and in what order, and economic incentives that make honest participation more profitable than cheating. This guide explains each ingredient in turn. Understanding it is also the foundation of using crypto safely, because most security failures are failures to understand what a given action really does; the companion guide at /crypto-security/ builds directly on these concepts.

Keys, addresses, and accounts

Ownership on a blockchain is defined entirely by cryptographic keys. Using public-key cryptography, each user has a private key — a very large secret number — and a corresponding public key derived from it. On Ethereum and similar networks, the private key is a 256-bit integer drawn from the secp256k1 elliptic curve, and the public key is produced by multiplying that private key by a fixed point on the curve. The operation is easy to perform one way and infeasible to reverse, which is why the public key can be shared freely while the private key stays secret.

Your public address — the string you share to receive funds — is derived from the public key. On Ethereum, the address is the last twenty bytes of the Keccak-256 hash of the public key, presented in a mixed-case checksum format (defined by EIP-55) that helps catch typos. Crucially, an address is a destination, not a secret; publishing it is safe, but it also means anyone can view its balance and full transaction history on a public explorer.

Ethereum distinguishes two kinds of account. An externally owned account (EOA) is controlled by a private key held outside the chain; only an EOA can originate a transaction, because the protocol validates an ECDSA signature over secp256k1 against the sender’s address. A contract account holds code and cannot act on its own — it only executes when an EOA (or another contract, in a chain of calls triggered by an EOA) calls it. This distinction matters for security and is explored further in /wallets-and-custody/. Bitcoin uses a different model (unspent transaction outputs, or UTXOs) but rests on the same secp256k1 cryptography.

Transactions and how they are signed

A transaction is a signed instruction submitted to the network — for example, “send this amount from my address to that address,” or “call this function on this contract with these inputs.” To be valid it must carry a digital signature produced by the private key of the sending account.

The signing process, at a high level, is: the wallet assembles the transaction details, computes a cryptographic hash of them, and the private key produces a signature over that hash using ECDSA. Anyone on the network can then use the public verification primitive (on Ethereum, ecrecover) to confirm that the signature corresponds to the sender’s address, without ever seeing the private key. This delivers two guarantees at once: authentication (only the key holder could have produced the signature) and integrity (if even one detail of the transaction is altered, the hash changes and the signature no longer verifies).

Two security implications follow directly. First, because signing is what authorises movement of funds, the act of signing is the moment of maximum risk — which is why the security guide stresses reading transactions before approving them. Second, a signature can authorise more than a simple transfer; it can grant a smart contract permission to move your assets later. Signing something you do not understand can therefore be as damaging as revealing a key.

The double-spend problem this all solves

It helps to know what problem this machinery exists to solve. Digital information is trivially copyable, so the fundamental obstacle to digital cash without an intermediary is the double-spend problem: what stops someone from spending the same unit twice by sending two conflicting transactions? A bank solves it by being the single authority that decides the order of events. A blockchain has no such authority, so it must let a decentralised network agree on one canonical ordering of transactions that everyone accepts.

That is precisely what the combination of signed transactions, hash-linked blocks, and consensus achieves. Signatures prove who authorised each transaction; the ordered chain of blocks establishes a single agreed sequence; and consensus makes producing a conflicting sequence prohibitively expensive. Once a transaction is settled in the canonical chain, a contradicting one cannot also be valid, because the network has already agreed on the order. Understanding that every mechanism in this guide is ultimately in service of ordering transactions without a trusted referee makes the rest of the design far easier to follow.

Blocks, hashing, and the chain

Transactions are grouped into blocks, and blocks are linked into a chain — hence “blockchain.” The linkage is what makes the ledger tamper-evident, and it depends on cryptographic hash functions.

A hash function takes any input and produces a fixed-length output (a “digest”) that behaves as a digital fingerprint: the same input always yields the same digest, a tiny change in input produces a completely different digest, and the output cannot be reversed to recover the input. Bitcoin uses SHA-256; Ethereum uses Keccak-256. Each block contains a header holding metadata: a timestamp, a nonce, the hash of the previous block’s header, and a Merkle root.

The Merkle root is a single hash that summarises every transaction in the block. It is built by hashing transactions in pairs, then hashing those results in pairs, repeatedly, until one hash remains at the top of the tree. This structure means any change to any transaction changes the Merkle root, and it also lets a lightweight client verify that a specific transaction is included without downloading the whole block.

Because each header includes the previous block’s hash, the blocks form a cryptographic chain. Altering a transaction in an old block would change that block’s Merkle root and therefore its hash, which would break the link stored in the next block, and the next, all the way to the tip. Rewriting history would require redoing the work for every subsequent block faster than the rest of the network extends the honest chain — infeasible on a healthy network. This is the concrete meaning of blockchain “immutability”: not that data physically cannot be changed, but that changing settled data is computationally and economically prohibitive.

Consensus: how the network agrees

Linking blocks with hashes makes tampering evident, but it does not by itself decide who may add the next block or which competing version of history is canonical. That is the job of a consensus mechanism. Two dominate today.

Proof of Work (PoW), used by Bitcoin, has participants called miners compete to find a nonce that, combined with the block’s contents, produces a hash below a difficulty target. Finding it requires enormous trial-and-error computation, but verifying a valid answer is trivial. The network is tuned so that, on average, one miner succeeds roughly every ten minutes on Bitcoin, earning the right to add the block and collect its reward. Because rewriting history would mean out-computing the entire honest network, security is anchored in the cost of energy and hardware.

Proof of Stake (PoS), which Ethereum adopted, replaces computational competition with economic bonding. Validators lock up (stake) the network’s currency and are selected to propose and attest to blocks. Time is divided into fixed slots of twelve seconds, grouped into epochs of thirty-two slots, with one validator selected to propose a block each slot. A validator that behaves dishonestly — for example, by proposing conflicting blocks — can have part of its stake destroyed (“slashing”), so honesty is enforced by the risk of financial loss rather than the expenditure of energy. Ethereum completed its transition from PoW to PoS in an event known as The Merge on 15 September 2022, which reduced the network’s energy consumption by an estimated 99.95 percent.

Both mechanisms produce the same essential outcome: a decentralised, Sybil-resistant way to agree on one ordered history, where attacking the ledger costs more than any plausible gain.

Finality, confirmations, and reorganisations

A transaction included in the latest block is not necessarily settled with certainty. Networks can briefly produce competing blocks, and a short “reorganisation” (reorg) can drop a very recent block in favour of another. This is why exchanges and merchants wait for confirmations — additional blocks built on top of the one containing your transaction. Each added block makes reversal exponentially less likely.

Proof-of-work networks like Bitcoin offer probabilistic finality: the deeper a transaction is buried, the safer it is, which is the reasoning behind conventions like waiting several confirmations. Proof-of-stake Ethereum adds a notion of economic finality: after a checkpointing process spanning a couple of epochs, reverting finalised blocks would require an attacker to lose an enormous amount of staked value, making reversal not merely unlikely but ruinously expensive. In practice, the guidance is the same for users: for significant transfers, wait for the confirmations recommended for that network before treating funds as settled.

Gas and transaction fees

Every operation a network performs consumes resources, so networks charge fees to prevent spam and to compensate the participants who process transactions. On Ethereum this cost is measured in gas: each computational step has a gas cost, and a transaction’s fee is the gas it uses multiplied by a price per unit of gas.

Since the London upgrade of August 2021, which activated EIP-1559, Ethereum’s fee has two parts. A protocol-determined base fee adjusts automatically block by block — rising when blocks are congested and falling when they are not — and, notably, the base fee is burned (permanently removed from circulation) rather than paid to the validator. On top of it, users add an optional priority fee, or tip, which goes to the validator as an incentive to include the transaction. This replaced an older first-price auction in which users had to guess a single gas price, making fees more predictable. Fees are a security consideration too: they make certain attacks costly, and the low cost of some operations is precisely what makes nuisance tactics like address-poisoning “dust” transfers economical for attackers.

Smart contracts and the EVM

Some blockchains do more than record transfers; they run programs. On Ethereum, a smart contract is code deployed to a contract account that executes deterministically on the Ethereum Virtual Machine (EVM) — the runtime replicated across every node so that every participant computes the same result from the same inputs. Once deployed, a contract’s code runs exactly as written whenever it is called, without anyone able to intervene.

This programmability enables tokens, lending, exchanges, and much of what is called decentralised finance and Web3. It also expands the attack surface. A contract can contain bugs, can be designed to be malicious, or can be granted sweeping permissions over your assets through the approval mechanism described in /crypto-security/. “Code is law” cuts both ways: the same determinism that makes contracts trustworthy also means a flawed or hostile contract will execute its logic faithfully, including logic that drains a wallet. Interacting with a contract means trusting its code, so verifying what you are calling — and what you are signing — is essential.

Tokens and standards

Most assets people hold beyond a network’s native currency are tokens: entries tracked by a smart contract rather than by the base protocol. Standards define how these contracts behave so that wallets and applications can interact with any conforming token. The ERC-20 standard specifies the functions for fungible tokens — including transfer, approve, and transferFrom, the same approval functions that make allowance hygiene so important. ERC-721 and ERC-1155 define non-fungible and multi-token standards used for NFTs and similar assets, where setApprovalForAll can grant broad control over a whole collection.

The practical point for a user is that a token’s balance lives inside a contract, and moving or granting access to it means interacting with that contract’s functions. That is why “sending a token” and “sending the native currency” can behave differently, and why approvals exist at all. Definitions for these standards and terms are collected in the /glossary/.

Nodes, clients, and decentralisation

The network that maintains a blockchain is made of nodes: computers running the network’s software, each keeping a copy of the ledger and independently checking that every block and transaction obeys the rules. There is no central server; the ledger’s authority comes from the fact that thousands of independent nodes agree on it. A node that receives an invalid block — one with a bad signature, a double-spend, or a broken hash link — simply rejects it, which is how the network enforces its rules without anyone in charge.

It is worth separating two roles that are often conflated. Full nodes validate and relay the chain but do not necessarily produce blocks; anyone can run one, and doing so lets you verify the chain for yourself rather than trusting a third party. Miners (under proof of work) or validators (under proof of stake) are the subset that proposes new blocks and earns rewards. The health of a blockchain’s decentralisation depends on both: a wide distribution of block producers so no small group can censor or rewrite history, and a wide distribution of independent validating nodes so the rules cannot be quietly changed. When you use a wallet, it typically talks to a node (often one run by a provider) to read balances and broadcast your transactions; running your own node, or at least understanding that this relationship exists, is part of appreciating what “trustless” really means in practice.

Networks, layer 2s, and bridges

There is not one blockchain but many, and they do not automatically share assets. Bitcoin and Ethereum are separate networks with separate ledgers; a large ecosystem of additional networks exists alongside them, many compatible with the EVM so that the same address format and tooling work across them. Because they are compatible does not mean they are the same chain — a token on one network is a distinct entry from a token on another, and sending assets to the right address on the wrong network is a common and often unrecoverable mistake.

To relieve congestion and cost on a base network (“layer 1”), layer 2 networks process transactions off the main chain and periodically settle a compressed proof or summary back to it, inheriting much of the base layer’s security while offering lower fees. Rollups are the dominant design. This matters to users because funds on a layer 2 live under that system’s rules, and moving assets between layers involves a bridge.

Bridges deserve particular caution. A bridge locks or burns an asset on one network and issues a representation on another, and the contracts and custody arrangements that make this work have historically been among the most valuable and most attacked components in the entire ecosystem, with several of the largest thefts on record involving bridge exploits. The security lesson connects back to /crypto-security/: interacting with a bridge means trusting its contracts and operators, so verify you are using the official bridge for the network in question, understand what you are signing, and treat cross-chain moves as higher-risk operations that warrant extra checking.

Block explorers: reading the chain yourself

Because a blockchain’s history is public, anyone can inspect it directly using a block explorer such as Etherscan for Ethereum. An explorer lets you look up any address to see its balance and full transaction history, examine an individual transaction by its hash to confirm its status and exact effect, read a contract’s verified source code, and — importantly for security — review the token approvals an address has granted.

Learning to read an explorer turns the blockchain from a black box into something you can verify for yourself. Before trusting that a payment arrived, you can confirm it on-chain by its transaction hash rather than relying on a screenshot. Before interacting with a contract, you can check whether its code is verified and what other users’ transactions with it look like. And when auditing your security, an explorer is where you can see, and act on, the approvals discussed throughout this series. Self-verification is one of the defining advantages of a public ledger; the practical steps for using it defensively are covered in /how-to-revoke-token-approvals/ and /crypto-security/.

Sources

• Bitcoin: A Peer-to-Peer Electronic Cash System (whitepaper)
• ethereum.org — Ethereum accounts (EOAs and contract accounts)
• ethereum.org — Transactions and signing
• ethereum.org — Proof-of-stake (slots, epochs, finality)
• ethereum.org — The Merge
• ethereum.org — Gas and fees (EIP-1559 base fee and priority fee)
• EIP-1559 — Fee market change specification
• ethereum.org — The Ethereum Virtual Machine (EVM)
• EIP-20 — ERC-20 token standard