How Blockchain Works: Transactions, Mempool, Blocks, and Consensus

Educational guide. Updated February 15, 2026.

A blockchain is a distributed ledger in which each participant can independently verify each transaction without having to trust a central authority. It sounds simple, but the mechanisms that make it secure and resistant to censorship are precise and often misunderstood. This guide walks through the complete cycle of a transaction — from signature to final confirmation — without simplifications.

From signature to propagation: the cycle of a transaction

When you send a transaction, you are signing a cryptographic message that states your intent to move funds from one address to another. The signature uses your private key and the ECDSA (Elliptic Curve Digital Signature Algorithm): anyone can verify that the signature is authentic by knowing only the public key, but no one can derive the private key from the signature.

UTXO vs account model

Bitcoin uses the UTXO (Unspent Transaction Output) model: your funds are not a balance but a collection of “unspent outputs” from previous transactions. Each transaction consumes existing UTXOs and creates new UTXOs. Ethereum instead uses the account model: each address has an explicit balance and a nonce (transaction counter) that prevents the replay of the same tx.

The difference has practical implications: in the UTXO model it is more difficult to build complex applications but easier to verify double spending. In the account model it is easier to build smart contracts but the management of the nonce adds complexity (stuck transactions, nonce gap).

Broadcasting and propagation in the network

Once signed, the transaction is sent to one or more nodes in the peer-to-peer network. Each node validates it (correct signature? sufficient balance? correct nonce?) and propagates it to the other nodes that do not yet know it. Within seconds, the transaction is visible to most of the network.

The mempool: where transactions wait

The mempool (memory pool) is the temporary buffer where valid transactions wait to be included in a block. It is not a single global structure: each node manages its own mempool, and the visibility can vary. In times of congestion, the mempool can contain tens of thousands of transactions.

Fee market: how priority works

Validators/miners include transactions in order of profit: those with the highest fee first. On Ethereum (post-EIP-1559) the mechanism is more structured: each block has an automatically burned base fee and a priority tip that goes to the validator. The base fee automatically adjusts based on the use of the previous block: if the block is more than 50% full, the base fee rises; if it is below 50%, it goes down.

Setting the correct gas means choosing a base fee slightly above the current one (to be included within 1-2 blocks) and an adequate priority tip (1-2 gwei in normal conditions, more in congestion). Setting too little means remaining in mempool indefinitely; too much means paying unnecessarily.

What happens in congestion

In extreme congestion — such as during periods of high NFT or DeFi activity — the base fee can rise 10-20× in minutes. Low fee transactions are “evicted” from the mempool if it exceeds the configured size limit. A “stuck” transaction (in the mempool for too long) can be replaced via RBF (Replace-By-Fee) on Bitcoin, or by sending a new transaction with the same nonce and higher fee on Ethereum.

How a block is formed

Validators (or miners, in PoW systems) collect transactions from the mempool, sort them, execute them verifying that the result is valid and produce a candidate block. The block has two main parts: the header and the body.

Structure of a block

Headers: contains the hash of the previous block (which creates the chain), the Merkle root of the transactions, the timestamp, the difficulty target and the nonce (in PoW systems). The hash of the previous header is what makes the blocks immutable: changing an old transaction would require recalculating all subsequent blocks.

Leotards: the list of actual transactions, with the data necessary to execute them. On Ethereum it also includes transaction receipts, which record gas usage, and smart contract event logs.

Merkle tree: efficient verification

Transactions in the block are organized into a Merkle tree: each pair of transactions is hashed together, pairs of hashes are hashed together, and so on up to a single root hash (Merkle root). This allows you to verify that a specific transaction is in the block by checking only log₂(n) hashes instead of all n transactions — critical for light clients and mobile wallets.

Consensus mechanisms: how the network reaches agreement

Consensus is the central problem of blockchains: how do you get distributed nodes, who don’t know or trust each other, to agree on what the correct version of transaction history is?

Proof of Work: safety through energy

In PoW (Bitcoin), producing a valid block requires finding a nonce such that the header hash is less than a target. It’s a brute force process: the only way is to try billions of nonces per second. The difficulty adjusts every 2016 blocks (approximately 2 weeks) to keep the average block time at 10 minutes. Bitcoin’s security comes from the energy expended: attacking the network requires controlling 51% of the global hashrate, a prohibitive cost.

Proof of Stake: security through capital

In PoS (Ethereum post-Merge), validators lock ETH as stake and are randomly selected to propose and attest blocks. Anyone who behaves dishonestly risks slashing (partial or total loss of stake). Security does not come from energy but from capital at risk. The advantage is a drastic reduction in energy consumption; the downside is that security depends on the price of the native asset — in a market crash, the cost of the attack drops.

Purpose: when a transaction is truly irreversible

In PoW, finality is probabilistic: the more blocks you accumulate on top of a transaction, the more expensive a reorg is. Conventionally, 6 Bitcoin confirmations (~60 minutes) are considered sufficient for relevant amounts. In PoS with explicit finality (Ethereum Casper), finality is deterministic after 2 epochs (~12 minutes): at that point, changing the history would require 33% of the staked ETH to be slashed — mathematically impossible without destroying the protocol.

Layer 1 vs Layer 2: Where the computation actually happens

Scalability is the unsolved problem of Layer 1 blockchains: Bitcoin processes around 7 TPS, Ethereum base layer around 15-30 TPS. Demand far exceeds this capacity, hence the high fees in times of congestion.

Layer 2 moves execution off the main chain, using L1 only for data availability and final settlement security. The main models are rollups (Optimistic like Arbitrum and OP, ZK like zkSync and StarkNet) and payment channels (Lightning Network for Bitcoin). The key difference: ZK rollups carry a cryptographic proof of each batch’s correctness to the L1; Optimistic rollups assume the batch is correct and give a challenge window (7 days on Arbitrum) to challenge it.

What to check before interacting with a blockchain

Understanding the mechanisms helps you make better operational decisions. Here are practical questions to ask yourself:

Purpose: How many confirmations do I need for this transaction? For large amounts on Bitcoin, wait at least 3-6 blocks.
Fee market: Check the current base fee on Etherscan/Blocknative before urgent transactions in times of congestion.
Nonce: If a transaction is stuck on Ethereum, don’t send new ones before resolving it — it will be queued behind it.
L2 vs L1: consider withdrawal times (7 days for Optimistic rollup) if you need quick liquidity.

Nodes: how the network remains decentralized

A blockchain is secure and decentralized only if there are enough independent nodes to validate it. A full node downloads the entire transaction history, verifies each block independently, and propagates valid transactions. He doesn’t need to trust anyone – he checks everything himself. This is the fundamental property that distinguishes a public blockchain from a private distributed database.

Types of knots

Full node: download and verify the entire blockchain. For Bitcoin, the database is approximately 600 GB (February 2026). For Ethereum, with full state, it is several TB — that’s why many users use clients with partial state sync (snap sync, fast sync). Running a full node requires adequate hardware (SSD, 16+ GB RAM for Ethereum) and bandwidth.

Light clients: download only the block headers and verify the transactions of interest via Merkle proof. It consumes little bandwidth and storage, but relies on full nodes for the content of the blocks. Mobile wallets are almost all light clients. They do not actively participate in network security.

Archive node: maintains the complete state of the blockchain with each block (not just the current state). Requires hundreds of TB of storage. Necessary for historical analysis and to provide APIs that allow queries on past blocks (e.g. “what was the balance of this address at block 12,000,000?”).

Why managing a node is important

Every full node you add to the network increases resilience against censorship and attacks. A user running their own full node does not depend on any third party to verify transactions — not Infura, not Alchemy, not the exchange. If these providers are banned in certain jurisdictions, those with a local node continue to operate normally.

Permissionless blockchain vs traditional distributed systems

A recurring question is: why not use a normal distributed database instead of a blockchain? The answer lies in the nature of the problem being solved. A distributed database like Apache Cassandra provides consistency and availability among nodes that trust each other — typically within an organization. A public blockchain must guarantee consensus between nodes that do not know each other, do not trust, and can be controlled by actors with opposing interests.

The cost of this property is efficiency: a blockchain processes fewer transactions per second than a centralized database, consumes more energy (in the case of PoW) or requires complex staking mechanisms (in the case of PoS), and has higher latency. The tradeoff is only acceptable when lack of trust towards a central party is the main requirement — monetary systems, property registers, contracts that do not require intermediaries.

Ethereum vs Bitcoin: two different architectures

Bitcoin is optimized for one thing: transferring value in a secure, censorship-resistant manner. Bitcoin’s script language is purposely limited (it is not Turing-complete) to reduce the attack surface. Simplicity is a feature, not a limit.

Ethereum is a general programmable platform: the EVM (Ethereum Virtual Machine) runs any program expressible in Solidity or Vyper. This flexibility allows for smart contracts, DeFi, NFTs, DAOs — but introduces complexity and risk that Bitcoin does not have. The move to PoS (The Merge, September 2022) reduced Ethereum’s power consumption by ~99.95%, but the protocol complexity remains significantly higher than Bitcoin.

Choosing which chain to operate on depends on the use: for simple store of value and transfer, Bitcoin offers the greatest security certainty and the longest network. For programmable applications, DeFi, or anything requiring smart contracts, the Ethereum ecosystem (including L2) is the most mature and liquid.

Resources for further information: where to really study blockchain

Most educational resources on blockchain are superficial or incentivized to sell something. Quality sources are few but they exist. For Bitcoin, the Bitcoin Whitepaper Satoshi Nakamoto’s original (8 pages, readable in an hour) remains the densest and most correct starting point. Mastering Bitcoin by Andreas Antonopoulos (available for free on GitHub) is the technical reference manual.

For Ethereum, the official documentation on ethereum.org has significantly improved in quality in recent years. The Ethereum Yellow Paper is the formal reference of the EVM — dense but precise. For those who want to understand PoS, Vitalik Buterin’s posts on his blog (vitalik.eth.limo) are the most accessible primary source.

For Layer 2, the technical blogs for Arbitrum (arbitrum.io/blog), Optimism (optimism.mirror.xyz), and Starkware explain the design choices in detail. Reading the research discussions on ethresear.ch allows you to understand where the protocol is going before changes become mainstream.

Conclusion

A blockchain is a system in which trust is replaced by mathematics: cryptographic signatures, hashing, and a distributed consensus mechanism make the history of transactions verifiable and virtually immutable. Understanding these mechanisms is not academic: every operational choice – from the fee to the moment of withdrawal from an L2 – depends on these fundamentals.

Glossary

UTXO: Unspent Transaction Output — the model used by Bitcoin to track funds.
Nonce: progressive counter of transactions from an account (Ethereum) or random number used in mining (PoW).
Mempool: Buffer of valid transactions awaiting confirmation.
Base fee: Share of gas burned automatically on Ethereum (EIP-1559), adjusts based on congestion.
Merkle root: Summary hash of all transactions in a block, used for efficient verification.
Slashing: Penalty applied to PoS validators who behave dishonestly.
Purpose: state in which a transaction is practically irreversible.
Rollups: Layer 2 which compresses many transactions into a batch and records them on the L1.